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