Re: BGP-4+

Curtis Villamizar <curtis@ans.net> Fri, 20 December 1996 18:35 UTC

Received: from cnri by ietf.org id aa19071; 20 Dec 96 13:35 EST
Received: from merit.edu by CNRI.Reston.VA.US id aa16534; 20 Dec 96 13:35 EST
Received: (from daemon@localhost) by merit.edu (8.8.4/merit-2.0) id NAA02718 for idr-outgoing; Fri, 20 Dec 1996 13:04:11 -0500 (EST)
Received: from interlock.ans.net (interlock.ans.net [147.225.5.5]) by merit.edu (8.8.4/merit-2.0) with SMTP id NAA02713 for <bgp@merit.edu>; Fri, 20 Dec 1996 13:04:05 -0500 (EST)
Received: by interlock.ans.net id AA02602 (InterLock SMTP Gateway 3.0 for bgp@ans.net); Fri, 20 Dec 1996 13:04:02 -0500
Received: by interlock.ans.net (Internal Mail Agent-1); Fri, 20 Dec 1996 13:04:02 -0500
Message-Id: <199612201801.NAA29251@brookfield.ans.net>
To: Dimitry Haskin <dhaskin@baynetworks.com>
Cc: dkatz@cisco.com, yakov@cisco.com, jstewart@metro.isi.edu, photon@nol.net, 6bone@isi.edu, bgp@ans.net, dhaskin@mailhost4.baynetworks.com
Reply-To: curtis@ans.net
Subject: Re: BGP-4+
In-Reply-To: Your message of "Thu, 19 Dec 1996 10:25:11 EST." <199612191525.KAA07565@pobox.BayNetworks.com>
Date: Fri, 20 Dec 1996 13:01:19 -0500
From: Curtis Villamizar <curtis@ans.net>
Sender: owner-idr@merit.edu
Precedence: bulk

In message <199612191525.KAA07565@pobox.BayNetworks.com>om>, Dimitry Haskin writes
:
> 
> > 
> > The expansion of the AS/RD space is an orthogonal issue, and one that is
> > far more difficult to achieve in a backward compatible fashion.  I would
> > argue that this is beyond the scope of the hack on the table...
> > 
> 
> 1) Is the backward compatibility with BGP4 is really necessary or even useful
>    for v6?

Yes.  It would be a good thing is we could just set the top bits to
zero for some transition period (possible a long period) and then
start using all 32 bits after older BGP4 implementations were gone.

This way there would just be one 32 bit AS space to deal with where
for a long time the top 16 were all zero.

> 2) What are actual benefits and applicability of the proposed multiprotocol
>    capabilities of BGP4+?  Can we require that all v6 RD boundaries
>    stay the same as the v4 AS boundaries for the proposed scheme to work? 

I don't know about requiring it but those of us that want to keep
their sanity might want to do things in a simple manner.  There will
be all IPv4 AS for a long time.  If someone has a need for a different
IPv4 and IPv6 boundaries, then figuring out which routers to IBGP peer
with gets to be a problem.

> 3) Depending on the answer on 1) and 2), it may be that BGPng don't
>    have to be more a hack that BGP4 is, and to this end provide
>    a longer term solution that "the hack on the table".
> 
> 4) Not that I necessary disagree that 2-byte AS space is large enough
>    for the time being,  but, if there is any discomfort with that,
>    it is a perfect opportunity to use expanded space for v6 (to avoid
>    pain later).
> 
> Dimitry

I agree that it would be worthwhile to provide an extension mechanism
in the form of a 32 bit attribute which much match the AS in the lower
16 bits and overrides the AS and specify that NLRI can only be passed
to an older 16 bit AS implementation from an extended AS if the AS
number of the extended AS has all the top bits set to zero.  This
would prevent a routing loop after the transition due to an old
implementation at the expense of isolating the old implemenetation.

All attributes which include AS numbers would be affected, so this is
not a trivial change.  From an implementation standpoint it also means
changing a lot of data structures used internally, but then again so
does the handling of IPv6.

Curtis