Re: BGP-4+
Dennis Ferguson <dennis@jnx.com> Sat, 21 December 1996 06:06 UTC
Received: from cnri by ietf.org id aa09194; 21 Dec 96 1:06 EST
Received: from merit.edu by CNRI.Reston.VA.US id aa02277; 21 Dec 96 1:06 EST
Received: (from daemon@localhost) by merit.edu (8.8.4/merit-2.0) id AAA19175
for idr-outgoing; Sat, 21 Dec 1996 00:42:42 -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 AAA19166 for <bgp@merit.edu>;
Sat, 21 Dec 1996 00:42:34 -0500 (EST)
Received: by interlock.ans.net id AA26770
(InterLock SMTP Gateway 3.0 for bgp@ans.net);
Sat, 21 Dec 1996 00:42:33 -0500
Received: by interlock.ans.net (Internal Mail Agent-2);
Sat, 21 Dec 1996 00:42:33 -0500
Received: by interlock.ans.net (Internal Mail Agent-1);
Sat, 21 Dec 1996 00:42:33 -0500
Message-Id: <199612210541.VAA21920@skank.jnx.com>
X-Mailer: exmh version 1.6.6 3/24/96
To: Yakov Rekhter <yakov@cisco.com>
Cc: skh@merit.edu, 6bone@isi.edu, dkatz@cisco.com, bgp@ans.net
Subject: Re: BGP-4+
In-Reply-To: Your message of "18 Dec 1996 20:11:14 GMT."
<199612182011.MAA23562@puli.cisco.com>
Mime-Version: 1.0
Content-Type: text/plain
Date: Fri, 20 Dec 1996 21:41:34 -0800
From: Dennis Ferguson <dennis@jnx.com>
Sender: owner-idr@merit.edu
Precedence: bulk
Yakov,
This indeed seems like a fine hack to me. Apart from the size-of-an-AS
issue, which I think is orthogonal in any case, I have several minor
comments:
(1) Would it be possible to specify explicitly that the MP_REACH_NLRI
attribute, when included in the path attributes, must always be inserted
at the end after everything else? The reason is that (at least for the
implementation I'm familiar with) it is usually necessary that all
path attributes have been collected and internalized before one starts
to process the routes having those attributes. If you can't rely on
the MP_REACH_NLRI being last in the list of attributes then you lose
the ability to process each message sequentially, instead having to
step around collecting the non-NLRI attributes before coming back
to process the routes.
(2) It seems to me advantageous that IPv4 and IPv6 routes with the same path
attributes are able to be advertised in the same update message, rather
than replicating the same set of attributes in two messages. The current
proposal does indeed allow this to happen. Given that this may have even
been designed in rather than happy circumstance, however, I find the
`Address Family' field a bit annoying. There seem to be only two
possibilities for its use:
(i) BGP-4 never carries routes from an address family other than IPv4
and IPv6. In this case the address family field is a constant in
attributes with type codes 0x14 and 0x15, and might just as well
have not been present since 0x14 and 0x15 always imply IPv6.
(ii) BGP-4 is used to carry routes from address families in addition
to IPv4 and IPv6. In this case the address family field is a
variable, but the constraint on a path attribute type appearing
twice in one message now prevents you from listing all routes with
the same attributes in the same message, independent of family.
That is, you get to advertise IPv4 and something in the same message,
but only one something.
Given that the total number of protocol families there are to carry in
BGP-4 is relatively small anyway, that type codes are not in short
supply and that the `Address Family' seems more a constraint than a
generalization, might it not be better to do away with the address
family identifier and just use different attribute type codes to
identify the x_REACH_NRLI's and x_UNREACH_NLRI's for different
protocols?
Dennis Ferguson
- 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