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