CURRENT_MEETING_REPORT_ Reported by Matt Mathis/PSC Minutes of the BGP Deployment Working Group (BGPDEPL) Administrivia A question of venue was discussed, but not settled. A hand vote indicated the majority of those present were planning to attend the Amsterdam meeting. However, several of the key players would be unable to attend. There was also a question about whether an additional meeting was needed before the next IETF. This question was deferred pending organizational changes. Later during the meeting it was observed that most of the configuration discussion was not really BGP related, but more apropos of the original ``Internet Working Group (IWG)'', which was tasked with fostering sanity in topology, routing policy, and configuration databases. It is interesting to note that the original BGP1 arose out of the IWG. It was suggested that the IWG be reconstituted, and that the BGP Deployment Working Group be folded in as one of its key tasks. Vendor Reports o ANS/NSFnet/GATED. Dennis Ferguson reported that BGP4 is working in a test mode. He also reported that new IGP code is under development. This new code is needed to interoperate with the existing routed code in the backbone. o Cisco. Paul Traina indicated that BGP4 is still under development. The development effort has been hit with some pretty significant delays and is going to be late. BGP4 was not approved for inclusion into 9.21, so there will be a special software release based upon 9.21 with BGP4 support added. This release will be available for testing and limited deployment before 9.21 has completed beta cycle. The BGP4 special release should be ready for general availability near 9.21 FCS (no date available). [This is an updated report to make it more accurate (for the worse).] o 3COM. Nagaraj Arunkumar expects to support BGP4 in release 6.2 due sometime early this fall. o Wellfleet. John Krawczyk anticipates rolling out BGP4 support this summer. 1 o Telebit Communications. Peder C. Norgaard reports that EUROPAnet is in the process of deploying BGP3 with no current plans for BGP4 deployment. CIDR core plans (Alternet, CIX, EBone, NSFnet/ANS, NSI, PSI, Sprint) As there appeared to be a critical mass of people interested in the BGP4 deployment who were also attending DC INTEROP, Claudio Tolpocic convened a meeting to update plans. The Minutes for this meeting are available in the usual IETF directories as draft-ietf.bgpdepl-minutes-feb93-00.txt (even though the meeting took place in March!). That meeting was also summarized for the Group with clarifications and expansions. There was quite a bit of discussion concerning the deployment plan. It now looks like this: 1. Start deploying BGP4 code as soon as possible. It now appears that this may be delayed to as late as June. The goal here is just to verify that the code works. Exercise no new features of the protocol in the production Internet. 2. NSI (or some alternative) starts announcing one aggregated network. This step has been split into two pieces: 2a) Initially announce an aggregated test network (assigned but non-production). After verification that it is propagating properly to the rest of the core, 2b) aggregate ONE site (several production class C networks), and verify correct interoperability with the rest of the Internet. 3. Additional CIDR core members start aggregating networks, first with test network and then with one production site each. Steps 2 and 3 can be partially overlapped as long as there are no adverse side effects of the announced aggregated nets, and that the selected aggregated sites can make arrangements to reach any portion of the Internet not yet supporting CIDR. 4. Aggregation is officially ``turned on'' in the Internet. This is a pseudo flag day because all sites requiring full routing tables must be either running BGP4 or must have made alternative arrangements (e.g., default routing). Aggregation should be phased in incrementally (a few sites at a time) and continue to be restricted to the site level (aggregate only multiple class C networks at one site). Aggregation of larger blocks of networks requires better solutions to some configuration management issues. Particularly mixed traffic types, etc., (e.g., AUP/non-AUP, multi-homed sites). 5. Think.... At this point there was a discussion of a number of side issues. Tony 2 Hain of ESnet indicated that he was not sure what would happen in the early phases, he would not be ready to support BGP4 by June. ESnet may have to use default routing to survive. Paul Traina of cisco mentioned the possibility of adding something to statically manage ``controlled de-aggregation'' using access lists and last resort approach to CIDR. Dennis Ferguson quiped that he would probably add something to gated in that case since ``gated should be able to do anything the cisco can do''. It was generally agreed that another meeting is need before step 4. It is unclear at this time if there would be contention and a real flag day. Hopefully all seven members of the CIDR core would either be fully BGP4 or have made peace with default routing well in advance of step 4, such that its precise timing is unimportant. If there is a contentious straggler, the community will eventually be forced to choose a flag day over their protests. The Group decided not to attempt to place precise dates on the schedule. The members of the CIDR core are progressing as fast as possible, and are well coordinated among themselves. The schedule has already slipped by about two months from where we projected at the DC IETF (in November). The next Regional-Techs meeting was mentioned as a possibility for another BGP deployment Working Group meeting. It is tentatively scheduled for May or June in Washington, DC. Matt felt that this would be a little too early. CIDR Configuration Issues There is some controversy over how to do global configuration checking. In addition, how can we one ensure topology matches policy? Mark Knopper of Merit presented a preliminary plan for aggregation support in the NSFnet. This support would: 1. Accept aggregate routes from a midlevel, or 2. Would accept site routes from a midlevel, and aggregate on the midlevels behalf. A strawman database format had netprefix and length, source (aggregating router) AS, and a destination AS list as components. This proposal is documented in the ``Inter-domain Routing Policy Description and Sharing'' Internet-Draft written by Yun, Yu, Chen and Rekhter (draft-yu-rpd.00.txt). This presentation resulted in a suggestion to split the single view into two views keyed on source AS. There was quite a bit of discussion on where and how to split this to best support debugging connectivity problems. 3 Matt Mathis argued fairly strongly for aggregation being controlled by the site owning the networks. The argument is that configuration control is far easier to manage if it is local. Sue Hares felt fairly strongly that central management is better. Matt did concur that it is a feature that Merit will have the capabilities to aggregate routes on behalf of regionals who cannot, but would like to. The representatives from RIPE pointed out that the existing U.S. databases, including the current Merit configuration database and the above proposal are not adequate to solve international routing problems. In particular none can be used to determine which backbone (CIDR core member) is the preferred path to a given U.S. network. Consider for a moment several sites with external connectivity to both NSFnet and PSI. Each site may prefer one or the other for various reasons including differing bandwidth, AUP, etc. This is further complicated because the ANS AS path does not reveal if the connection is ``blessed'' for non-NSF AUP traffic. Ideally the traffic from Europe could be routed solely on the basis of ASpath but essential information is missing. Alternatively there should be a way to glean from our configuration databases which backbone the site prefers, but again there is not. Global Configuration Issues Daniel Karrenberg presented the RIPE efforts in the Global configuration database area. He indicated the real focus of this effort was to provide a tool their operators could use. This database also contains enough information o allow someone to compile suitable router network configuration files. It is documented as ``Representation of IP Routing Policies in the RIPE Database'', and is available from the RIPE repositories: ftp.ripe.net:ripe/docs/ripe-docs/ripe-81.[txt,ps]. Things the RIPE effort cannot do include an inability to process and propagate policies information on transit networks. It cannot use unpublished AS's, and it does nothing to solve the ``half baked'' AS problem, outside of pointing out inconsistencies. Closing Remarks The sense of urgency came form concerns about configuration management and database issues. Although there is still a lot of work to be done to complete the BGP4 roll out, it seems to be a fairly well understood problem except for configuration management. CIDR and BGP4 do impose some new requirements on the databases but the majority of the issues center around topology and AUP enforcement. For these reasons it makes sense to broaden the scope of this Working Group from just BGP deployment to the wider task of fostering sanity in topology, routing policy, and configuration databases. Thanks to Robert Reschly and Gene Hastings for taking meeting notes. Attendees 4 Nagaraj Arunkumar nak@3com.com William Barns barns@gateway.mitre.org Tony Bates tony@ripe.net Jordan Becker becker@ans.net David Bolen db3l@ans.net Rebecca Bostwick bostwick@es.net Jeffrey Burgan jeff@nsipo.nasa.gov Robert Calderon calderon@noc.ans.net Henry Clark henryc@oar.net Robert Collet rcollet@icm1.icp.net Tom Easterday tom@cic.net Stefan Fassbender stf@easi.net Mark Fedor fedor@psi.com Dennis Ferguson dennis@ans.net Vince Fuller vaf@stanford.edu Tony Hain alh@es.net Martyne Hallgren martyne@nr-tech.cit.cornell.edu Eugene Hastings hastings@psc.edu Roland Hedberg Roland.Hedberg@rc.tudelft.nl Ittai Hershman ittai@ans.net Jeffrey Honig Jeffrey_C_Honig@Cornell.edu Laurent Joncheray lpj@merit.edu Matthew Jonson jonson@server.af.mil Dan Jordt danj@nwnet.net Daniel Karrenberg daniel@ripe.net John Krawczyk jkrawczy@wellfleet.com Padma Krishnaswamy kri@sabre.bellcore.com Frank Liu fcliu@pacbell.com Daniel Long long@nic.near.net Peter Lothberg roll@stupi.se Glenn Mackintosh glenn@canet.ca Jamshid Mahdavi Mahdavi@a.psi.edu Bill Manning bmanning@sesqui.net Jun Matsukata jm@eng.isas.ac.jp Daniel McRobb dwm@noc.ans.net Dennis Morris morrisd@imo-uvax.disa.mil Peder Norgaard pcn@tbit.dk David O'Leary doleary@cisco.com Andrew Partan asp@uunet.uu.net Brad Passwaters bjp@sura.net Michael Patton map@bbn.com Willi Porten porten@gmd.de Selina Priestley sfp@noc.ans.net Yakov Rekhter yakov@watson.ibm.com Robert Reschly reschly@brl.mil Tony Richards richards@icm1.icp.net Vilson Sarto vilson@fapq.fapesp.br John Scudder jgs@merit.edu Paul Serice serice@cos.com Kim Smith kas@noc.ans.net Bernhard Stockman boss@ebone.net Roxanne Streeter streeter@nsipo.arc.nasa.gov John Tavs tavs@vnet.ibm.com Marten Terpstra marten@ripe.net 5 Paul Traina pst@cisco.com Curtis Villamizar curtis@ans.net Jack Waters waters@sura.net Linda Winkler lwinkler@anl.gov Cathy Wittbrodt cjw@barrnet.net Paul Zawada Zawada@ncsa.uiuc.edu 6