CURRENT_MEETING_REPORT_
Reported by Guy Almes/Rice
IWG Minutes
The most important agenda item was the review and approval of a MIB for
the management of agents that speak BGP. A second draft was provided in
advance by Steve Willis and served as the reference document for the
discussion. Among the key points of discussion:
o What action should be taken by an agent upon state transitions (as
defined by the finite automaton in the BGP protocol document)? We
agreed that SNMP traps would be defined for a subset of these
transitions and we agreed on the information to be provided upon
each such trap.
o What variables in the MIB could be eliminated or streamlined in the
interests of simplicity of definition and implementation? The
final MIB will reflect a significant reduction in the total number
of variables defined in the second draft.
o There were two tables in the second draft that describe the
attribute lists of routes. One table describes all received
routes, and the other describes those actually in use. We
tightened the description of just when entries in these tables
existed and what they would contain.
Steve took these decisions and used them to produce a revised document
Tuesday evening. This MIB will be used provisionally in our early use
of BGP version 2, and will be the MIB submitted when we propose
advancement of BGP to `Draft Internet Standard' status.
The rest of our time was spent discussing early experience implementing
and using BGP-2. Dennis Ferguson and Yakov Rekhter were among the early
implementors present, and Dennis Ferguson and Jessica Yu were among the
early users present. Among the items discussed were:
o Since the BGP-2 header is an odd number of bytes, implementors
should be careful of the C-language size of operator.
o In view of the overhead of processing the message and update
headers and the attribute lists of each BGP update message, the
inclusion of many routes per update message is an extremely
important efficiency concern.
o In BGP-3 we should seriously consider letting the `next hop'
attribute of an update message default to the IP address of the
speaker. This would not only simplify the implementation, but
would allow an identical update message to be sent to several peers
in even more cases than at present.
o Dennis reports a problem with the FSM in the case when two peers
try to connect to one another at the same time. This causes a `BGP
1
Transport connection open' event in the OpenSent state, which
causes both ends to disconnect and return to the Idle state, all
with no particular reason to think it won't happen again. An
improved FSM would fix this.
o Dennis reports the need for a default inter-AS metric attribute.
Without one, it is not clear how to compare an advertisement from
one peer with an explicit metric with an advertisement from another
peer with no metric.
o There was great appreciation for the lack of split horizon in
BGP-2. Since each update message contains a complete AS-level
path, there is no need for split horizon. Further, by having
speaker A advertise to speaker B the nets it gets to via speaker B
in a safe way, two significant advantages arise:
- assembly of update messages is considerably simplified by not
having the identity of the peer influence the update message.
For example, when A assembles update messages for B and C, it
can use the same update for both despite the fact that some of
the routes it is advertising may have been derived from B. In
many cases, particularly with IBGP, identical update messages
can be sent to several peers.
- the use of BGP-2 for monitoring inter-AS routing is
considerably improved, since a speaker learns more fully what
routes its peer uses. For example, when A advertises to B even
the routes A has derived from B, B learns that A is actually
using the advertised routes. This will allow useful sanity
checks.
o Similarly, the lack of need for having a Holddown period, as in
BGP-1, is taken by the implementors as a major improvement.
In view of the mild nature of the `problems' encountered by early
implementors, continued deployment of BGP-2 throughout the Internet
appears likely.
Due to a very strong overlap of IWG and NJM, we decided to cancel the
afternoon session which had been planned. We agreed that gaining
experience with the implementation and use of BGP-2 during the next
several months will be an important task for the IWG. At the Boulder
IETF meeting, we will need to review this experience with a view toward
moving BGP, with possible revisions, to the Draft Internet Standard
level.
Attendees
Guy Almes almes@rice.edu
Jeffrey Burgan jeff@nsipo.nasa.gov
Dino Farinacci dino@buckeye.esd.3com.com
Dennis Ferguson dennis@gw.ccie.utoronto.ca
Vince Fuller fuller@jessica.stanford.edu
Robert Hinden hinden@bbn.com
2
Dan Jordt danj@cac.washington.edu
Alex Koifman akoifman@bbn.com
Solomon Liou solomon%penril@uunet.uu.net
Dan Long long@bbn.com
Olivier Martin martin@cearn.cern.ch
Matt Mathis mathis@pele.psc.edu
Milo Medin medin@nsipo.nasa.gov
Philippe Park ppark@bbn.com
Yakov Rekhter yakov@ibm.com
Martha Steenstrup msteenst@bbn.com
Rudiger Volk rv@informatik.uni-dortmund.de
Steve Willis swillis@wellfleet.com
Robert Woodburn woody@saic.com
3