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