CURRENT_MEETING_REPORT_

Reported by Jessica Yu/Merit

Minutes of the BGP Deployment Working Group (BGPDEPL)

Thanks to Mark Knopper and Bill Manning for taking the notes from which
these minutes were derived.



Overview

Jessica Yu presented a summary of CIDR deployment status.  Several
different efforts are working on CIDR deployment:


  o BGPDEPL Working Group meetings at IETFs
  o BGPDEPL subgroup meeting at INTEROP (March) by Claudio Topolcic
  o NSFNET regional-techs meetings by Merit
  o RIPE Routing Working Group meeting by Tony Bates


CIDR has two major components:  the route aggregation strategy, and the
IP address assignment strategy as described in
draft-fuller-cidr-strategy-03.txt (an update to RFC 1338).

The IP address assignment strategy described in RFC 1466 has been
implemented since the fall of 1992 by IR. Jeff Huston from AARnet
mentioned that non-CIDR compatible IP address assignments have been
handed to Pacific region networks.  Jeff will document the situation and
inform the NIC.

The status of route aggregation implementation is as follows:


  o The CIDR-capable routing protocol specification is done.
  o Software development is underway.
  o An initial deployment plan has been developed.


The following is a list of CIDR-related documents:

  o CIDR spec
     -  draft-fuller-cidr-strategy-03.txt (update to RFC 1338)

  o Addressing
     -  RFC 1466
     -  draft-rekhter-ipaddress-guide-08.txt

  o Deployment
     -  RFC 1367
     -  draft-rekhter-cidr-environment-01.txt
     -  draft-ietf-bgpdepl-minutes-93feb-00.txt
     -  Minutes of BGPDEPL sessions at IETF meetings (July 1992,
        November 1992 and March 1993)
     -  Minutes of Merit NSFNET Regional-Techs meetings

  o Route Aggregation Registry
     -  RFC 1482

  o Other
     -  RFC 1481 (The IAB Statement)



CIDR Deployment

The Current Deployment Plan:  (initial)

Step 1  --  Deploy BGP4 without aggregation
Step 2  --  Advertise test aggregated route
Step 3  --  Aggregate at site level or single policy level, whichever is a
            smaller block
Step 4  --  Understand more
Step 5  --  Aggregate more

Steps 4 and 5 are recursive until CIDR is fully implemented.  As soon as
the CIDR software is ready, step 1 could be executed.

The rules for aggregation at initial deployment stage:


  o Aggregate based on manual configuration
  o Proxy aggregation allowed (with agreement of the advertiser)
  o Holes in aggregates allowed
  o IGP/IBGP carry aggregation within a domain
  o Coordination:  bi-lateral and overall
  o Aggregate routing registry


A concern was raised about the merit of IBGP and whether it would be
continuously supported by vendor software.

Dennis Ferguson clarified that IBGP doesn't scale to very large numbers
since it requires a full mesh peering session between all the border
routers within a domain.  On ANS's network, each external router has
over 90 IBGP neighbors.  If an external network is lost, 90
announcements go out.  This results in large overhead when routes flap.
If your network grows big enough you should have something other than
IBGP. Dennis is willing to write a short paper on the usefulness and
limits of IBGP.

Tony Li of cisco stated that running IBGP is currently tractable and
will be supported for a while, though we may consider alternatives for
the future.

It is generally agreed that IBGP is usable in the size of the current
network.  It works on NSF/ANSnet, which has about 90 nodes participating
in IBGP. A typical network has much fewer nodes participating in IBGP.

It was suggested to add another rule of aggregation, i.e.  no network
should aggregate routes without informing other networks.  It was agreed
that the aggregated routes should be registered.  Implementing route
aggregate registry will provide a means of sharing such information.

It was suggested that de-aggregation should not be done at the initial
stage.  Since initially the plan is to only aggregate at site level or a
single policy level, it (hopefully) will not cause too much
inconvenience.  But if it does, the issue would be revisited.

It was also agreed that if a network de-aggregates, those de-aggregated
networks should not be propagated outside the network.  With more
experience gained on aggregation (or de-aggregation), these issues will
be discussed further.

CIDR Capable Software Implementation

Router vendors are asked to respond to the following questions about the
status of software implementation:


 1. Is a CIDR implementation available?
 2. What features are included and what are not?
 3. Which version and where to get them?
 4. Aggregation configuration syntax?
 5. Interoperability test plan?


  o Gated (by Dennis Ferguson)
    ANS gated's BGP4 and aggregation implementation is being debugged
    and will be a beta-release soon.  It is being tested on the NSFNET
    research network as well as in the ANS labs.  It is ready for
    interoperability testing and Dennis will test against all the other
    implementations he can find.
    The code is able to form route aggregates.  Aggregation by proxy is
    supported.  Each route can only contribute to a single aggregate,
    though the aggregate can contribute to a larger aggregate.  Null
    routes to non-existent networks can be installed but needs kernel
    to support it.  No controlled de-aggregation exists in this
    implementation.
    The code is expected to be available in about two weeks.  Dennis
    will create a distribution when it looks like things are working.
    Dale Johnson mentioned that the syntax for the Merit ``Network
    Announcement Change Request'' will allow aggregates.  The syntax
    for aggregates is x.x.x/len where len is the prefix length.

  o 3com (by Arun Arunkumar)
    BGP4 is being tested in the lab, talking to itself and ready to do
    interoperability test with other vendor's code.  The code accepts,
    forwards and manages aggregated routes properly, but does not form
    route aggregates yet.  The current implementation does not support
    controlled de-aggregation but will support it in the future if
    necessary.  This will be released as part of version 6.2 in the
    September-October time frame.  Aggregates could be carried by BGP4
    and OSPF as well.  3com is working on implementing OSPF-BGP
    interaction.  One month's testing is still needed.

  o cisco (by Paul Traina)
    Pre-beta code is available via anonymous FTP from cisco.  Send mail
    to Paul Traina if you intend to use this code, and you will be
    added to the bgp-beta mailing list and told how to get the code.
    BGP4 is currently based on version 9.21 of the router software,
    which is not yet in beta and thus is very ``experimental.''

    The implementation currently carries, advertises, and redistributes
    aggregates, but aggregate generation is still a few weeks off.
    Aggregate configuration uses the new route map feature, for which
    the user interface is not yet stable.  BGP4 will redistribute
    aggregate routes with any routing protocol that carries mask
    information (EIGRP, OSPF, and ISIS). BGP3- and BGP4-OSPF
    interaction and automatic tag stuff is supported.  Controlled
    de-aggregation is not currently supported (and may never be).
    Automatic negotiation is supported for BGP versions 2 through 4.
    The code will be deployed in a few test routers on regional
    networks and is currently going through early field testing.  It is
    ready for interoperability testing (and probably has been tested
    against gated by the time you read this).

  o Proteon (by Ed Stern)
    They are currently testing BGP4, but are not ready for
    interoperability testing.  They are not able to aggregate for the
    first release, but can pass aggregated routes and forward on the
    longest match.  BGP can exchange routes between all other
    protocols.  BGP and EGP can run simultaneously.

  o Wellfleet (by John Kraczyk)
    Release 7.60 is going into beta next month.  This version contains
    BGP3, which also implements OSPF-BGP interaction.
    A beta version of CIDR/BGP4 will hopefully be available sometime in
    early 1994.  Plans include accepting, forwarding, and forming
    aggregates (also proxy), OSPF-BGP4 interaction, and possibly OSPF
    LSA type 8.  Some form of controlled de-aggregation will also be
    included.  Interoperability testing will be done when the
    implementation is closer.

  o EuropaNET (by Peder Chr)
    EuropaNET is working on implementation of BGP4.  The Megaswitch is
    used, which is a custom router.


InterOperability Test

Tony Li requested feedback on BGP4 interoperability tests that so he can
update his interoperability matrix for BGP and send it to the list.

Yakov suggested running a virtual DMZ for BGP testing, i.e.  to
establish remote BGP4 sessions between BGP4 test boxes at different
locations on the net.

Route Aggregation Registry

Mark Knopper presented a syntax to register route aggregates in the
NSFNET policy routing database.  It is written in RFC 1842, and comments
and suggestions are welcome.

Mark Knopper also presented a summary of the discussion at the NSFNET
regional-techs meeting held June 10-11, 1993.  The transcript of Mark's
presentation, and other presentations, given at the Merit meeting can be
obtained via FTP from merit.edu:/pub/nsfnet/regional-techs.


CIDR Analysis

It was suggested to do a CIDR analysis to evaluate CIDR's impact on the
lifetime of IPv4.  The IAB chartered this working group to write a paper
to include such an analysis.  The group suggested that the following
areas be included in the analysis.


  o CIDR impact on the routing table growth
  o CIDR impact on the rate of IP address space depletion
  o The rate of use of IP address space
  o Impact of policy (AUP) on CIDR efficiency


The following people volunteered to work together to produce this
analysis paper:  Peter Ford, Dale Johnson, Tony Li, Bill Manning and
Yakov Rekhter.  Peter Ford agreed to take a lead on this.  The paper
should be ready by September 1993, before the IAB meeting takes place.

There was also a discussion about renumbering hosts to make better use
of the assigned IP address space and increase the efficiency of
aggregation.  Peter Ford observed that lots of assigned Class B
addresses have only 50 or so hosts on it, leaving the rest of the space
unused.  It was agreed that autoconfiguration could be of great help to
renumbering.  It was also suggested that it does not hurt to study the
renumbering process with currently available technology.  John Kraczyk
mentioned that Wellfleet manually renumbered its network recently.  He
will document the process as a case study.


Attendees

Arun Arunkumar           [email protected]
Toshiya Asaba            [email protected]
Tony Bates               [email protected]
Rebecca Bostwick         [email protected]
Ronald Broersma          [email protected]
Thomas Brunner           [email protected]
Henry Clark              [email protected]
David Conrad             [email protected]
Tom Easterday            [email protected]
Deborah Estrin           [email protected]
Stefan Fassbender        [email protected]
Mark Fedor               [email protected]
Peter Ford               [email protected]
Vince Fuller             [email protected]
Craig Haney              [email protected]
Frank Hoffmann           [email protected]
Geoff Huston             [email protected]
David Jacobson           [email protected]
Dale Johnson             [email protected]
Anders Karlsson          [email protected]
Daniel Karrenberg        [email protected]
Sean Kennedy             [email protected]
Lothar Klein             [email protected]
Rajeev Kochhar           [email protected]
Mark Kosters             [email protected]
John Krawczyk            [email protected]
Tony Li                  [email protected]
Susan Lin                [email protected]
Robin Littlefield        [email protected]
Peter Lothberg           [email protected]
Bill Manning             [email protected]
Jun Matsukata            [email protected]
Keith Mitchell           [email protected]
Jun Murai                [email protected]
Peder Chr.  Noergaard    [email protected]
Michael O'Dell           [email protected]
David O'Leary            [email protected]
Andrew Partan            [email protected]
Michael Patton           [email protected]
Juergen Rauschenbach     [email protected]
Yakov Rekhter            [email protected]
Robert Reschly           [email protected]
Duncan Rogerson          [email protected]
Ulla Sandberg            [email protected]
Miguel Sanz              [email protected]
John Scudder             [email protected]
Tim Seaver               [email protected]
Henk Steenman            [email protected]
Ed Stern                 [email protected]
John Stewart             [email protected]
Marten Terpstra          [email protected]
Claudio Topolcic         [email protected]
Paul Traina              [email protected]
Willem van der Scheun    [email protected]
Ruediger Volk            [email protected]
Sam Wilson               [email protected]
Wilfried Woeber          [email protected]
Jessica Yu               [email protected]
Paul Zawada              [email protected]

You are viewing proxied material from ftp.icm.edu.pl. The copyright of proxied material belongs to its original authors. Any comments or complaints in relation to proxied material should be directed to the original authors of the content concerned. Please see the disclaimer for more details.