Editor's Note: Minutes received 7/29 CURRENT_MEETING_REPORT_ Reported by David Bolen/ANS Minutes of the Border Gateway Protocol Working Group (BGP) During the first of two BGP Working Group sessions, the majority of the time was spent discussing two documents -- the Internet Draft for BGP4 (Yakov Rekhter and Tony Li), and BGP4 <-> OSPF Interaction Document (Kannan Varadhan) -- with a small portion of time devoted to discussing BGP Communities proposal (Yakov Rekhter and Tony Li). BGP Communities Discussion To start the meeting off, Tony Li presented the BGP Communities proposal (the use of a new path attribute to ``color'' a route), as previously posted to the BGP mailing list. The use of communities is intended to help solve the current AUP (acceptable use policy) routing problem by distributing some of the policy information (as kept in the NSFNET policy database) as a community associated with a route. The document predefines communities for research, education and commercial ASs. A community may be associated with a route by the source of that route, or may be added or augmented by any transit router (so a provider can ``stamp'' a route on behalf of a customer). While not a truly general solution (i.e., it does not help in cases where customers are using default routes), it may still prove beneficial in a large number of cases. The general consensus of the Group was that the proposal was worthwhile and would be useful to move forward. BGP-4 Protocol Specifications Discussion Next, the current BGP4 Internet Draft was discussed - driven primarily by comments from M. Craren of Proteon, as he had questions about the document after having examined it in anticipation of implementing BGP for Proteon. The Working Group directly answered several of the simpler BGP implementation questions, while some points resulted in proposed changes to the draft, as follows: o Section 2 Introduction - Revise to indicate that BGP4 no longer absolutely carries full AS path information (due to the possible use of the new ATOMIC_AGGREGATE attribute by intermediate routers). - Provide additional clarification as to what routes may be advertised by a BGP speaker (namely that it cannot advertise routes that it is not using). - Add a description of the FIB (forwarding information base). 1 o Section 3.2 (c) Routing Information Bases - Adj-RIBs-Out - Clarify that an outgoing policy (for the selection of routes to be advertised to a neighbor) is applied only for ``external'' neighbors. o Section 6.1 Message Header error handling - Remove the use of the ``flash'' qualifier to discuss update messages. Its use was thought to be a holdover from the early GATED implementation of BGP. There were also a few simple grammatical changes pointed out. The BGP-4 document will be updated and released as a new version of the Internet Draft. BGP-4 <-> OSPF Interaction Discussion Kannan Varadhan then held a discussion of the updates necessary to his BGP<->OSPF interaction document to bring it in line with BGP4. For the most part the changes were to reflect the use of NLRI (Network Layer Reachability Information) within the BGP4 draft, since BGP4 carries IP prefixes rather than ``class''-based network numbers. One point brought up was that the document states that the OSPF router ID must be set to an interface address. OSPF does not require this, but the OSPF and BGP router IDs must be identical and BGP does set this requirement. It was agreed that the appropriate change to make was to update the BGP4 draft so that the router ID can be chosen as any address assigned to the router, but need not be associated with a physical interface. The BGP<->OSPF interaction document would then be updated to include the same restriction. Kannan will also be releasing an updated version of his document. The second BGP Working Group session was Chaired by Tony Li, and spent most of the time discussing the creation of a BGP4 usage document. The document is still to be done, but it was agreed that it would be very similar to the current BGP usage document, but extended to discuss BGP4 aggregation rules and requirements, and how to handle interactions with protocols that did not understand aggregated routes (such as EGP and older versions of BGP). One issue that was left undecided (after a lengthy discussion) was what aggregation should be performed by a BGP4 implementation by default. There was no clear consensus on what option would be less likely to cause problems either for existing systems or for the site using BGP4 itself. Some time was also spent on the BGP Communities proposal and on the BGP MIB document. The Group agreed that the BGP Communities document should 2 proceed forward, probably with a release as an Internet Draft. The MIB document requires updating to include references to NLRI within BGP4's routes rather than networks as well as changes in the format of the AS_PATH attribute and creation of new path attributes. It was agreed to make the necessary changes. Attendees Nagaraj Arunkumar nak@3com.com Dennis Baker dbaker@wellfleet.com Tony Ballardie a.ballardie@cs.ucl.ac.uk John Ballard jballard@microsoft.com Tony Bates tony@ean-relay.ac.uk Jordan Becker becker@nis.ans.net David Bolen db3l@nis.ans.net Steve Buchko stevebu@newbridge.com Ross Callon callon@bigfut.enet.dec.com James Carlson carlson@xylogics.com William Carter carter@ctron.com Frank Chen frankc@casc.com Dean Cheng dean@sun2.retix.com Robert Ching natadm!rching@uunet.uu.net Chris Chiotasso chris@artel.com Henry Clark henryc@oar.net Rob Coltun rcoltun@ni.umd.edu Jim Comen comenj@interlan.interlan.com Michael Craren mjc@proteon.com Steven Fancher sfancher@ursa-major.spdcc.com Dennis Ferguson dennis@mrbill.canet.ca Peter Ford peter@lanl.gov AnneMarie Freitas afreitas@microcom.com Vince Fuller vaf@stanford.edu Der-Hwa Gan dhg@nsd.3com.com Martin Gray mg@spider.co.uk Dimitry Haskin dhaskin@bbn.com Dwight Jamieson djamies@bnr.ca Matthew Jonson jonson@server.af.mil Dan Jordt danj@nwnet.net George Kajos kajos@coral.com Mark Knopper mak@merit.edu Mark Knutsen knutsen@almaden.ibm.com John Krawczyk jkrawczy@wellfleet.com Alan Kullberg akullber@bbn.com John Labbe labbe@merit.edu Tony Li tli@cisco.com Anthony Lisotta lisotta@nas.nasa.gov Robin Littlefield rlittlef@wellfleet.com Kent Malave kent@chang.austin.ibm.com Matt Mathis mathis@a.psc.edu Dennis Morris morrisd@imo-uvax.disa.mil Kraig Owen tko@merit.edu Eric Peterson elpeterson@eng.xyplex.com Yakov Rekhter yakov@watson.ibm.com 3 ^L April Richstein abm@tycho.ncsc.mil Martin Schulman mas@loyola.edu Hellen Sears sears@interlan.interlan.com Erik Sherk sherk@sura.net Marten Terpstra terpstra@ripe.net Linda Tom toml@interlan.interlan.com Kannan Varadhan kannan@oar.net Ross Veach rrv@uiuc.edu Curtis Villamizar curtis@ans.net John Vollbrecht jrv@merit.edu David Waitzman djw@bbn.com Luanne Waul luanne@wwtc.timeplex.com Honda Wu natadm!honda@uunet.uu.net 4