BGP Deployment minutes

[[e-mail]]

Minutes of BGP Deployment Working Group meeting
	29 March 1993 at the Columbus OH IETF

Administrivia:

A question of venue was discussed, but not settled.  A hand vote indicated the
majority of those present were planning to attend the Amsterdam meeting.
However, several of the key players would be unable to attend.  There was also
a question about whether an additional meeting was needed before the next
IETF.   This question was deferred pending organizational changes.

Matt Mathis wants to step down from chairing the BGP deployment working group
as soon as possible.  Several candidate for a new chair were identified:
Jessica Wu (not present), Tony Bates and Jeff Burgan.  Jeff is attractive
because he represents the CIDR core member with the most deployment
constraints, but he outright declined due to time constraints.  Tony Bates
declined due to conflict-of-interest, and it was noted that Jessica has the
same COI.  Both are authors of competing proposals for global Internet
configuration databases (see below).

Later during the meeting it was observed that most of the configuration
discussion was not really BGP related, but more apropos of the original
"Internet Working Group", which was tasked with fostering sanity in topology,
routing policy, and configuration databases.  It is interesting to note that
the original BGP1 arose out of the IWG.

It was suggested that the IWG be reconstituted, and that the BGP deployment
WB be folded in as one of its key tasks.

----------------
Vendor Reports:

ANS/NSFnet/GATED: Dennis Ferguson reported that BGP4 is working in a test
    mode.  Also reported that new IGP code is under development.  This new code
    is needed to interoperate with the existing routed code in the backbone.

Cisco: Paul Traina indicated that BGP4 is under still under development.  The
    development effort has been hit with some pretty significant delays and is
    going to be late.  BGP4 was not approved for inclusion into 9.21, so there
    will be a special software release based upon 9.21 with BGP4 support
    added.  This release will be available for test and limited deployment
    before 9.21 has completed beta cycle.  The BGP4 special release should be
    ready for general availability near 9.21 FCS (no date available). [This is
    an updated report to make it more accurate (for the worse).]

3-COM:  N. Arunkumar expects to support BGP4 in release 6.2 due sometime
    early this fall.

Wellfleet:  John Krawczyk anticipates rolling out BGP4 support this summer.

Telebit Communications: Peder Chr. Norgaard reports that EUROPAnet is in the
    process of deploying BGP3 with no current plans for BGP4 deployment.

----------------
CIDR core plans (Alternet, CIX, EBone, NSFnet/ANS, NSI, PSI, Sprint):

As there appeared to be a critical mass of people interested in the BGP4
deployment attending the DC InterOp, Claudio Tolpocic convened a meeting
to update plans.  The minutes for this meeting are available in the usual
IETF directories as draft-ietf.bgpdepl-minutes-feb93-00.txt (even though
the meeting took place in March!).  That meeting was also summarized for
the group with clarifications and expansions.

There was quite a bit of discussion concerning the deployment plan.  It now
looks like this:

1) Start deploying BGP4 code as soon as possible.  It now appears that this
may be delayed to as late as June.  The goal here is just to verify that the
code works.  Exercise no new features of the protocol in the production
Internet.

2) NSI (or some alternative) starts announcing one aggregated network.  This
step has been split into two pieces: 2a) Initially announce an aggregated test
network (assigned but non-production).  After verification that it is
propagating properly to the rest of the core, 2b) aggregate ONE site (several
production class C networks), and verify correct interoperability with the
rest of the Internet.

3) Additional CIDR core members start aggregating networks, first with test
network and then with one production site each.

Steps 2 and 3 can be partially overlapped as long as there are no adverse side
effects of the announced aggregated nets, and that the selected aggregated
sites can make arrangements to reach any portion of the Internet not yet
supporting CIDR.  

4) Aggregation is officially "turned on" in the Internet.  This is a psuedo
flag day because all sites requiring full routing tables must be either
running BGP4 or must have made alternative arrangements (e.g. default
routing).  Aggregation should be phased in incrementally (a few sites at a
time) and continue to be restricted to the site level (aggregate only multiple
class C networks at one site).  Aggregation of larger blocks of networks
requires better solutions to some configuration management issues.
Particularly mixed traffic types, etc (e.g. AUP/non-AUP, multi-homed sites).

5) Think....

At this point there was a discussion of a number of side issues.  Tony Hain of
ESnet indicated that he was not sure what would happen in the early phases, he
would not be ready to support BGP4 by June.  ESnet may have to use default
routing to survive.

Paul Traina of Cisco mentioned the possibility of adding something to
statically manage "controlled de-aggregation" using access lists and last
resort approach to CIDR.  Dennis Ferguson quiped that he would probably add
something to gated in that case since "gated should be able to do anything the
cisco can do".

It was generally agreed that another meeting is need before step 4.  It is
unclear at this time if there would be contention and a real flag day.
Hopefully all seven members of the CIDR core would either be fully BGP4
or have made peace with default routing well in advance of step 4, such that
its precise timing is unimportant.  If there is a contentious straggler, the
community will eventually be forced to choose a flag day over their protests.

The group decided not to attempt place precise dates on the schedule.   The
members of the CIDR core are progressing as fast a possible, and are well
coordinated among themselves.  The schedule has already slipped by about
two months from where we projected at the DC IETF (in November).

The next Regional-Techs meeting was mentioned as a possibility for another BGP
deployment WG meeting.  It is tentatively scheduled for May or June in
Washington DC.   Matt felt that this would be a little too early.

----------------
CIDR configuration issues:

There is some controversy over how to do global configuration checking. In
addition, how can we one ensure topology matches policy?

Mark Knopper of Merit presented a preliminary plan for aggregation support in
the NSFnet.  This support would: 1) accept aggregate routes from a midlevel.
or 2) would accept site routes from a midlevel, and aggregate on the midlevels
behalf.  A strawman database format had netprefix and length, source
(aggregating router) AS, and a destination AS list as components.  This
proposal is documented in the "Inter-domain Routing Policy Description and
Sharing" Internet Draft written by Yun, Yu, Chen and Rekhter
(draft-yu-rpd.00.txt).  This presentation resulted in a suggestion to split
the single view into two views keyed on source AS. There was quite a bit of
discussion on where and how to split this to best support debugging
connectivity problems.

Matt Mathis argued fairly strongly for aggregation being controlled by the
site owning the networks.  The argument is that configuration control is far
easier to manage if it is local.  Sue Hares of Merit felt fairly strongly
that central management is better.  Matt did concur that is is a feature that
Merit will have the capabilities to aggregate routes on behalf of regionals
who can not, but would like to.

The representatives from RIPE pointed out that the existing US databases,
including the current Merit configuration database and the above proposal are
not adequate to solve international routing problems.  In particular none can
be used to determine which backbone (CIDR core member) is the preferred path to
a given US network.  Consider for a moment several sites with external
connectivity to both NSFnet and PSI.  Each site may prefer one or the other
for various reasons including differing bandwidth, AUP, etc.  This is further
complicated because the ANS AS path does not reveal if the connection is
"blessed" for non-NSF AUP traffic.  Ideally the traffic from Europe could be
routed solely on the basis of ASpath but essential information is missing.
Alternatively there should be a way to glean from our configuration databases
which backbone the site prefers, but again there is not.

----------------
Global configuration issues:

Tony Bates presented the RIPE efforts in the Global configuration database
area.  He indicated the real focus of this effort was to provide a tool their
operators could use.  This database also contains enough information to allow
someone to compile suitable router network configuration files.  It is
documented as "Representation of IP Routing Policies in the RIPE Database, an
is available from the RIPE repositories as ripe-81.

Things the RIPE effort cannot do include an inability to process and propagate
policies information on transit networks. It cannot use unpublished AS's, and
it does nothing to solve the "half baked" AS problem, outside of pointing out
inconsistencies.

----------------
Closing remarks:

The vast majority of sense of urgency came form concerns about configuration
management and database issues.  Although there is still a lot of work to be
done to complete the BGP4 roll out, it seems to be a fairly well understood
problem except for configuration management.  CIDR and BGP4 do impose some new
requirements on the databases but the majority of the issues center around
topology and AUP enforcement.  For theses reasons it makes sense to broaden
the scope of this WG from just BGP deployment to the wider task of fostering
sanity in topology, routing policy, and configuration databases.

Thanks to Robert Reschly and Gene Hastings for taking meeting notes.