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
- Re: BGP-4+ Yakov Rekhter
- Re: BGP-4+ Susan Hares
- Re: BGP-4+ Susan Hares
- Re: BGP-4+ John W. Stewart III
- Re: BGP-4+ Yakov Rekhter
- Re: BGP-4+ John W. Stewart III
- Re: BGP-4+ Yakov Rekhter
- Re: BGP-4+ Yakov Rekhter
- Re: BGP-4+ Brandon Black
- Re: BGP-4+ John W. Stewart III
- Re: BGP-4+ Dorian R. Kim
- Re: BGP-4+ Yakov Rekhter
- Re: BGP-4+ Tony Bates
- BGP-4+ Dave Katz
- Re: BGP-4+ Dimitry Haskin
- Re: BGP-4+ John W. Stewart III
- Re: BGP-4+ Brad Smith
- Re: BGP-4+ Dorian R. Kim
- Re: BGP-4+ bmanning
- Re: BGP-4+ Tony Li
- Re: BGP-4+ Brad Smith
- Re: BGP-4+ Dorian R. Kim
- Re: BGP-4+ Brad Smith
- Re: BGP-4+ Curtis Villamizar
- Re: BGP-4+ Curtis Villamizar
- Re: BGP-4+ Curtis Villamizar
- Re: BGP-4+ Curtis Villamizar
- Re: BGP-4+ Dennis Ferguson
- Re: BGP-4+ Brandon Black
- Re: BGP-4+ Yakov Rekhter
- Re: BGP-4+ Dennis Ferguson
- Re: BGP-4+ John W. Stewart III
- Re: BGP-4+ Yakov Rekhter
- Re: BGP-4+ Yakov Rekhter
- Re: BGP-4+ John W. Stewart III
- Re: BGP-4+ Yakov Rekhter
- Re: BGP-4+ Geert Jan de Groot
- Re: BGP-4+ Brad Smith
- Re: BGP-4+ [QOS et al] John G. Scudder
- Re: BGP-4+ Paul Traina