CURRENT_MEETING_REPORT_ Reported by Jessica Yu/Merit Minutes of the BGP Deployment Working Group (BGPDEPL) Thanks to Mark Knopper and Bill Manning for taking the notes from which these minutes were derived. Overview Jessica Yu presented a summary of CIDR deployment status. Several different efforts are working on CIDR deployment: o BGPDEPL Working Group meetings at IETFs o BGPDEPL subgroup meeting at INTEROP (March) by Claudio Topolcic o NSFNET regional-techs meetings by Merit o RIPE Routing Working Group meeting by Tony Bates CIDR has two major components: the route aggregation strategy, and the IP address assignment strategy as described in draft-fuller-cidr-strategy-03.txt (an update to RFC 1338). The IP address assignment strategy described in RFC 1466 has been implemented since the fall of 1992 by IR. Jeff Huston from AARnet mentioned that non-CIDR compatible IP address assignments have been handed to Pacific region networks. Jeff will document the situation and inform the NIC. The status of route aggregation implementation is as follows: o The CIDR-capable routing protocol specification is done. o Software development is underway. o An initial deployment plan has been developed. The following is a list of CIDR-related documents: o CIDR spec - draft-fuller-cidr-strategy-03.txt (update to RFC 1338) o Addressing - RFC 1466 - draft-rekhter-ipaddress-guide-08.txt o Deployment - RFC 1367 - draft-rekhter-cidr-environment-01.txt - draft-ietf-bgpdepl-minutes-93feb-00.txt - Minutes of BGPDEPL sessions at IETF meetings (July 1992, November 1992 and March 1993) - Minutes of Merit NSFNET Regional-Techs meetings o Route Aggregation Registry - RFC 1482 o Other - RFC 1481 (The IAB Statement) CIDR Deployment The Current Deployment Plan: (initial) Step 1 -- Deploy BGP4 without aggregation Step 2 -- Advertise test aggregated route Step 3 -- Aggregate at site level or single policy level, whichever is a smaller block Step 4 -- Understand more Step 5 -- Aggregate more Steps 4 and 5 are recursive until CIDR is fully implemented. As soon as the CIDR software is ready, step 1 could be executed. The rules for aggregation at initial deployment stage: o Aggregate based on manual configuration o Proxy aggregation allowed (with agreement of the advertiser) o Holes in aggregates allowed o IGP/IBGP carry aggregation within a domain o Coordination: bi-lateral and overall o Aggregate routing registry A concern was raised about the merit of IBGP and whether it would be continuously supported by vendor software. Dennis Ferguson clarified that IBGP doesn't scale to very large numbers since it requires a full mesh peering session between all the border routers within a domain. On ANS's network, each external router has over 90 IBGP neighbors. If an external network is lost, 90 announcements go out. This results in large overhead when routes flap. If your network grows big enough you should have something other than IBGP. Dennis is willing to write a short paper on the usefulness and limits of IBGP. Tony Li of cisco stated that running IBGP is currently tractable and will be supported for a while, though we may consider alternatives for the future. It is generally agreed that IBGP is usable in the size of the current network. It works on NSF/ANSnet, which has about 90 nodes participating in IBGP. A typical network has much fewer nodes participating in IBGP. It was suggested to add another rule of aggregation, i.e. no network should aggregate routes without informing other networks. It was agreed that the aggregated routes should be registered. Implementing route aggregate registry will provide a means of sharing such information. It was suggested that de-aggregation should not be done at the initial stage. Since initially the plan is to only aggregate at site level or a single policy level, it (hopefully) will not cause too much inconvenience. But if it does, the issue would be revisited. It was also agreed that if a network de-aggregates, those de-aggregated networks should not be propagated outside the network. With more experience gained on aggregation (or de-aggregation), these issues will be discussed further. CIDR Capable Software Implementation Router vendors are asked to respond to the following questions about the status of software implementation: 1. Is a CIDR implementation available? 2. What features are included and what are not? 3. Which version and where to get them? 4. Aggregation configuration syntax? 5. Interoperability test plan? o Gated (by Dennis Ferguson) ANS gated's BGP4 and aggregation implementation is being debugged and will be a beta-release soon. It is being tested on the NSFNET research network as well as in the ANS labs. It is ready for interoperability testing and Dennis will test against all the other implementations he can find. The code is able to form route aggregates. Aggregation by proxy is supported. Each route can only contribute to a single aggregate, though the aggregate can contribute to a larger aggregate. Null routes to non-existent networks can be installed but needs kernel to support it. No controlled de-aggregation exists in this implementation. The code is expected to be available in about two weeks. Dennis will create a distribution when it looks like things are working. Dale Johnson mentioned that the syntax for the Merit ``Network Announcement Change Request'' will allow aggregates. The syntax for aggregates is x.x.x/len where len is the prefix length. o 3com (by Arun Arunkumar) BGP4 is being tested in the lab, talking to itself and ready to do interoperability test with other vendor's code. The code accepts, forwards and manages aggregated routes properly, but does not form route aggregates yet. The current implementation does not support controlled de-aggregation but will support it in the future if necessary. This will be released as part of version 6.2 in the September-October time frame. Aggregates could be carried by BGP4 and OSPF as well. 3com is working on implementing OSPF-BGP interaction. One month's testing is still needed. o cisco (by Paul Traina) Pre-beta code is available via anonymous FTP from cisco. Send mail to Paul Traina if you intend to use this code, and you will be added to the bgp-beta mailing list and told how to get the code. BGP4 is currently based on version 9.21 of the router software, which is not yet in beta and thus is very ``experimental.'' The implementation currently carries, advertises, and redistributes aggregates, but aggregate generation is still a few weeks off. Aggregate configuration uses the new route map feature, for which the user interface is not yet stable. BGP4 will redistribute aggregate routes with any routing protocol that carries mask information (EIGRP, OSPF, and ISIS). BGP3- and BGP4-OSPF interaction and automatic tag stuff is supported. Controlled de-aggregation is not currently supported (and may never be). Automatic negotiation is supported for BGP versions 2 through 4. The code will be deployed in a few test routers on regional networks and is currently going through early field testing. It is ready for interoperability testing (and probably has been tested against gated by the time you read this). o Proteon (by Ed Stern) They are currently testing BGP4, but are not ready for interoperability testing. They are not able to aggregate for the first release, but can pass aggregated routes and forward on the longest match. BGP can exchange routes between all other protocols. BGP and EGP can run simultaneously. o Wellfleet (by John Kraczyk) Release 7.60 is going into beta next month. This version contains BGP3, which also implements OSPF-BGP interaction. A beta version of CIDR/BGP4 will hopefully be available sometime in early 1994. Plans include accepting, forwarding, and forming aggregates (also proxy), OSPF-BGP4 interaction, and possibly OSPF LSA type 8. Some form of controlled de-aggregation will also be included. Interoperability testing will be done when the implementation is closer. o EuropaNET (by Peder Chr) EuropaNET is working on implementation of BGP4. The Megaswitch is used, which is a custom router. InterOperability Test Tony Li requested feedback on BGP4 interoperability tests that so he can update his interoperability matrix for BGP and send it to the list. Yakov suggested running a virtual DMZ for BGP testing, i.e. to establish remote BGP4 sessions between BGP4 test boxes at different locations on the net. Route Aggregation Registry Mark Knopper presented a syntax to register route aggregates in the NSFNET policy routing database. It is written in RFC 1842, and comments and suggestions are welcome. Mark Knopper also presented a summary of the discussion at the NSFNET regional-techs meeting held June 10-11, 1993. The transcript of Mark's presentation, and other presentations, given at the Merit meeting can be obtained via FTP from merit.edu:/pub/nsfnet/regional-techs. CIDR Analysis It was suggested to do a CIDR analysis to evaluate CIDR's impact on the lifetime of IPv4. The IAB chartered this working group to write a paper to include such an analysis. The group suggested that the following areas be included in the analysis. o CIDR impact on the routing table growth o CIDR impact on the rate of IP address space depletion o The rate of use of IP address space o Impact of policy (AUP) on CIDR efficiency The following people volunteered to work together to produce this analysis paper: Peter Ford, Dale Johnson, Tony Li, Bill Manning and Yakov Rekhter. Peter Ford agreed to take a lead on this. The paper should be ready by September 1993, before the IAB meeting takes place. There was also a discussion about renumbering hosts to make better use of the assigned IP address space and increase the efficiency of aggregation. Peter Ford observed that lots of assigned Class B addresses have only 50 or so hosts on it, leaving the rest of the space unused. It was agreed that autoconfiguration could be of great help to renumbering. It was also suggested that it does not hurt to study the renumbering process with currently available technology. John Kraczyk mentioned that Wellfleet manually renumbered its network recently. He will document the process as a case study. Attendees Arun Arunkumar nak@3com.com Toshiya Asaba asaba@iij.ad.jp Tony Bates tony@ripe.net Rebecca Bostwick bostwick@es.net Ronald Broersma ron@nosc.mil Thomas Brunner brunner@switch.ch Henry Clark henryc@oar.net David Conrad davidc@iij.ad.jp Tom Easterday tom@cic.net Deborah Estrin estrin@usc.edu Stefan Fassbender stf@easi.net Mark Fedor fedor@psi.com Peter Ford peter@goshawk.lanl.gov Vince Fuller vaf@stanford.edu Craig Haney craig@icp.net Frank Hoffmann hoffmann@dhdibm1.bitnet Geoff Huston g.huston@aarnet.edu.au David Jacobson dnjake@vnet.ibm.com Dale Johnson dsj@merit.edu Anders Karlsson sak@cdg.chalmers.se Daniel Karrenberg daniel@ripe.net Sean Kennedy liam@nic.near.net Lothar Klein lothar.klein@gmd.de Rajeev Kochhar rajeev_kochhar@3com.com Mark Kosters markk@internic.net John Krawczyk jkrawczy@wellfleet.com Tony Li tli@cisco.com Susan Lin suelin@vnet.ibm.com Robin Littlefield robin@wellfleet.com Peter Lothberg roll@stupi.se Bill Manning bmanning@rice.edu Jun Matsukata jm@eng.isas.ac.jp Keith Mitchell keith@pipex.net Jun Murai jun@wide.ad.jp Peder Chr. Noergaard pcn@tbit.dk Michael O'Dell mo@uunet.uu.net David O'Leary doleary@cisco.com Andrew Partan asp@uunet.uu.net Michael Patton map@bbn.com Juergen Rauschenbach jrau@dfn.de Yakov Rekhter yakov@watson.ibm.com Robert Reschly reschly@brl.mil Duncan Rogerson d.rogerson@nosc.ja.net Ulla Sandberg ulla@kiera.ericsson.se Miguel Sanz miguel.sanz@rediris.es John Scudder jgs@merit.edu Tim Seaver tas@concert.net Henk Steenman henk@sara.nl Ed Stern els@proteon.com John Stewart jstewart@cnri.reston.va.us Marten Terpstra marten@ripe.net Claudio Topolcic topolcic@cnri.reston.va.us Paul Traina pst@cisco.com Willem van der Scheun scheun@sara.nl Ruediger Volk rv@informatik.uni-dortmund.de Sam Wilson sam.wilson@ed.ac.uk Wilfried Woeber Wilfried.Woeber@CC.UniVie.ac.at Jessica Yu jyy@merit.edu Paul Zawada Zawada@ncsa.uiuc.edu