CURRENT_MEETING_REPORT_

Reported by Guy Almes/ Rice

MINUTES


  1. Guy Almes and Yakov Rekhter led a review of progress to date,
     including the conditional acceptance of the BGP Protocol document
     as a Proposed Internet Standard.  (By mid-May, the BGP Protocol
     document was approved by the IESG and forwarded to the IAB for
     approval as a Proposed Internet Standard.  Both the BGP Protocol
     and the BGP Usage documents will soon be published.)  Changes to
     the protocol since the Florida State meeting were discussed.
  2. Yakov Rekhter led a discussion of BGP stability.  It is possible to
     configure a pair of neighboring ASes with incompatible routing
     policies such that an oscillation sets in.  Yakov sketched the
     problem in detail and showed how the oscillation could be
     automatically detected.
  3. Steve Willis led a discussion of a proposed MIB for BGP. This
     discussion resulted both in a better proposed MIB and a deeper
     understanding within the group of a number of BGP issues.  A key
     issue was whether the BGP MIB should reflect the BGP information
     received from neighbors, actually used locally, or advertised to
     neighbors.  Steve will follow up with an Internet Draft describing
     the MIB.
  4. Guy Almes led a discussion of the use of BGP in monitoring the
     health of global Inter-AS routing.  In the course of the
     discussion, the implications of External vs Internal BGP, even in
     the case of the monitoring station not being involved in routing,
     were shown to be important.  The use of BGP for monitoring will
     allow a number of monitoring applications that would be totally
     impractical using only SNMP.
  5. Guy Almes led a discussion of authentication.  Consultation with
     members of the Security Area led to an agreement that a 16-byte
     Marker field per message would allow detection of spoofing.
     Prevention of spoofing seems to be beyond the ability of any
     application layered over available implementations of TCP. The
     presence of this 16-byte field, together with our provision of
     multiple authentication schemes, will allow very strong
     authentication.  Having agreed on the need for supporting strong
     authentication and having modified the protocol to support it, we
     agreed that our needs in the near-term future were not great.



                                   1






ATTENDEES
    L. Allyson Brown          allyson@umd5.umd.edu
    Guy Almes                 almes@rice.edu
    Isidro Castineyra         isidro@bbn.com
    Steve Crumb               scrumb@mot.com
    Robert Enger              enger@sccgate.scc.com
    Dino Farinacci            dino@esd.3com.com
    Dennis Ferguson           dennis@gw.ccie.utoronto.ca
    Jeffrey Honig             jch@tcgould.tn.cornell.edu
    Wendy Huntoon             huntoon@a.pse.edu
    Peter Kirstein            kirstein@cs.ucl.ac.uk
    Alex Koifman              akoifman@bbn.com
    Kanchez Loa               loa@sps.mot.com
    Yoni Malachi              yoni@cs.stanford.edu
    C. Philip Wood            cpw@lanl.gov
    Yakov Rekhter             yakov@ibm.com
    Mike StJohns              stjohns@umds.umd.edu
    Steve Storch              sstorch@bbn.com
    Steven Willis             swillis@wellfleet.com



                              2