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