Re: BGP-4+
Dennis Ferguson <dennis@jnx.com> Mon, 23 December 1996 06:07 UTC
Received: from cnri by ietf.org id ab25249; 23 Dec 96 1:07 EST
Received: from merit.edu by CNRI.Reston.VA.US id aa15710; 22 Dec 96 18:29 EST
Received: (from daemon@localhost) by merit.edu (8.8.4/merit-2.0) id SAA02367
for idr-outgoing; Sun, 22 Dec 1996 18:08:48 -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 SAA02362 for <bgp@merit.edu>;
Sun, 22 Dec 1996 18:08:45 -0500 (EST)
Received: by interlock.ans.net id AA04520
(InterLock SMTP Gateway 3.0 for bgp@ans.net);
Sun, 22 Dec 1996 18:08:43 -0500
Received: by interlock.ans.net (Internal Mail Agent-2);
Sun, 22 Dec 1996 18:08:43 -0500
Received: by interlock.ans.net (Internal Mail Agent-1);
Sun, 22 Dec 1996 18:08:43 -0500
Message-Id: <199612222307.PAA15376@skank.jnx.com>
X-Mailer: exmh version 1.6.6 3/24/96
To: Yakov Rekhter <yakov@cisco.com>
Cc: 6bone@isi.edu, bgp@ans.net
Subject: Re: BGP-4+
In-Reply-To: Your message of "Sun, 22 Dec 1996 06:29:18 PST."
<199612221429.GAA03193@puli.cisco.com>
Mime-Version: 1.0
Content-Type: text/plain
Date: Sun, 22 Dec 1996 15:07:43 -0800
From: Dennis Ferguson <dennis@jnx.com>
Sender: owner-idr@merit.edu
Precedence: bulk
Yakov, > This is certainly one possibility. Another possibility is to allow > MP_REACH_NLRI and MP_UNREACH_NLRI to carry NLRI for multiple address > families (this would require minor changes to the proposed encoding). This would work too. Now that I've though about it I think I might have a slight preference for doing it your way. The tradeoff seems to be that you have to spend a few more bytes of encoding to do it your way, but you get to keep all attributes-that-are-really-routes together in one spot. I think the latter is probably a feature. The only other issue I have relates to protocol-specific usage. I think there probably needs to be a paragraph or so on IPv6-specific gorp written down somewhere to ensure working, interoperable implementations. The one example I can think of off-hand is that of IPv6 next hop addresses. Most routing protocols for IPv6 specify the exclusive use of link-local addresses for next hops, as the interface addresses least likely to change over the life of a routing protocol session, but this is probably not right for BGP since link-local addresses are not likely to be well-received when readvertised via IBGP. Is it intended that protocol-specific (or, at least, IPv6-specific) issues are to be documented elsewhere (or anywhere)? A multiprotocol specification by itself seems insufficient. Dennis
- 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