home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Internet Info 1997 December
/
Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso
/
ietf
/
bgpdepl
/
bgpdepl-minutes-93jul.txt
< prev
next >
Wrap
Text File
|
1993-09-23
|
13KB
|
325 lines
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 nak@3com.com
Toshiya Asaba asaba@iij.ad.jp
Tony Bates tony@ripe.net
Rebecca Bostwick bostwick@es.net
Ronald Broersma ron@nosc.mil
Thomas Brunner brunner@switch.ch
Henry Clark henryc@oar.net
David Conrad davidc@iij.ad.jp
Tom Easterday tom@cic.net
Deborah Estrin estrin@usc.edu
Stefan Fassbender stf@easi.net
Mark Fedor fedor@psi.com
Peter Ford peter@goshawk.lanl.gov
Vince Fuller vaf@stanford.edu
Craig Haney craig@icp.net
Frank Hoffmann hoffmann@dhdibm1.bitnet
Geoff Huston g.huston@aarnet.edu.au
David Jacobson dnjake@vnet.ibm.com
Dale Johnson dsj@merit.edu
Anders Karlsson sak@cdg.chalmers.se
Daniel Karrenberg daniel@ripe.net
Sean Kennedy liam@nic.near.net
Lothar Klein lothar.klein@gmd.de
Rajeev Kochhar rajeev_kochhar@3com.com
Mark Kosters markk@internic.net
John Krawczyk jkrawczy@wellfleet.com
Tony Li tli@cisco.com
Susan Lin suelin@vnet.ibm.com
Robin Littlefield robin@wellfleet.com
Peter Lothberg roll@stupi.se
Bill Manning bmanning@rice.edu
Jun Matsukata jm@eng.isas.ac.jp
Keith Mitchell keith@pipex.net
Jun Murai jun@wide.ad.jp
Peder Chr. Noergaard pcn@tbit.dk
Michael O'Dell mo@uunet.uu.net
David O'Leary doleary@cisco.com
Andrew Partan asp@uunet.uu.net
Michael Patton map@bbn.com
Juergen Rauschenbach jrau@dfn.de
Yakov Rekhter yakov@watson.ibm.com
Robert Reschly reschly@brl.mil
Duncan Rogerson d.rogerson@nosc.ja.net
Ulla Sandberg ulla@kiera.ericsson.se
Miguel Sanz miguel.sanz@rediris.es
John Scudder jgs@merit.edu
Tim Seaver tas@concert.net
Henk Steenman henk@sara.nl
Ed Stern els@proteon.com
John Stewart jstewart@cnri.reston.va.us
Marten Terpstra marten@ripe.net
Claudio Topolcic topolcic@cnri.reston.va.us
Paul Traina pst@cisco.com
Willem van der Scheun scheun@sara.nl
Ruediger Volk rv@informatik.uni-dortmund.de
Sam Wilson sam.wilson@ed.ac.uk
Wilfried Woeber Wilfried.Woeber@CC.UniVie.ac.at
Jessica Yu jyy@merit.edu
Paul Zawada Zawada@ncsa.uiuc.edu