Re: BGP-4+
Dimitry Haskin <dhaskin@baynetworks.com> Thu, 19 December 1996 16:00 UTC
Received: from cnri by ietf.org id aa04600; 19 Dec 96 11:00 EST
Received: from merit.edu by CNRI.Reston.VA.US id aa12407; 19 Dec 96 11:00 EST
Received: (from daemon@localhost) by merit.edu (8.8.4/merit-2.0) id KAA21355
for idr-outgoing; Thu, 19 Dec 1996 10:25:51 -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 KAA21350 for <bgp@merit.edu>;
Thu, 19 Dec 1996 10:25:47 -0500 (EST)
Received: by interlock.ans.net id AA16667
(InterLock SMTP Gateway 3.0 for bgp@ans.net);
Thu, 19 Dec 1996 10:25:45 -0500
Received: by interlock.ans.net (Internal Mail Agent-2);
Thu, 19 Dec 1996 10:25:45 -0500
Posted-Date: Thu, 19 Dec 1996 10:29:57 -0500 (EST)
Received: by interlock.ans.net (Internal Mail Agent-1);
Thu, 19 Dec 1996 10:25:45 -0500
Date: Thu, 19 Dec 1996 10:25:11 -0500
From: Dimitry Haskin <dhaskin@baynetworks.com>
Message-Id: <199612191525.KAA07565@pobox.BayNetworks.com>
To: dkatz@cisco.com
Subject: Re: BGP-4+
Cc: yakov@cisco.com, jstewart@metro.isi.edu, photon@nol.net, 6bone@isi.edu,
bgp@ans.net, dhaskin@mailhost4.baynetworks.com
Sender: owner-idr@merit.edu
Precedence: bulk
> > 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? 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? 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
- 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