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