BGP-4+

[John W. Stewart III]

i have a follow-up question to one of the things dennis asked,
but i have a general question as well

the UPDATE message looks like:

      +-----------------------------------------------------+
      |   Unfeasible Routes Length (2 octets)               |
      +-----------------------------------------------------+
      |  Withdrawn Routes (variable)                        |
      +-----------------------------------------------------+
      |   Total Path Attribute Length (2 octets)            |
      +-----------------------------------------------------+
      |    Path Attributes (variable)                       |
      +-----------------------------------------------------+
      |   Network Layer Reachability Information (variable) |
      +-----------------------------------------------------+

let's say that i'm an implementation with these extensions and
i want to advertise an IPv6 route over an ebgp session with
just the mandatory well-known attributes ORIGIN="IGP",
AS-PATH="3561" and NEXT-HOP="10.1.1.1".  what do i put in the
"NLRI" field of the UPDATE message (not the NLRI component of
the attribute)?  as i read it, the proposed extension doesn't
include the ability to specify attributes within the
MP_REACH_NLRI attribute, so the "Total Path Attribute Length"
and "Path Attributes" fields of the UPDATE message need to be
used.  the spec says:

 >>
 >>   Total Path Attribute Length:
 >>
 >>      [...]
 >>
 >>      A value of 0 indicates that no Network Layer Reachability
 >>      Information field is present in this UPDATE message.
 >>

so conversely a non-zero value in "Total Path Attribute Length"
means that NLRI *is* present.  since i need to associate
attributes with the IPv6 route, "Total Path Attribute Length"
needs to be non-zero, so what goes in NLRI if i don't have any
IP4-related thing to do in this message?

 > > (2) It seems to me advantageous that IPv4 and IPv6 routes with the same pa
th
 > >     attributes are able to be advertised in the same update message, rathe
r
 > >     than replicating the same set of attributes in two messages.  The curr
ent
 > >     proposal does indeed allow this to happen.  Given that this may have e
ven
 > >     been designed in rather than happy circumstance, however, I find the
 > 
 > It was intentional - not just "happy circumstance". 
 > 
 > >     `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.
 > 
 > Yes, this is an undesirable restriction.
 > 
 > >     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?
 > 
 > 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).

given that the attributes of an advertised route will always
include AS-PATH, ORIGIN and NEXT-HOP (and LOCAL-PREF for IBGP),
and given that in practice there is a high degree of
variability of these fields (the variability of each
individually is high and in combination the variability is even
higher), is it necessary to complicate the protocol with an
optimization which would require an implementation to be very
ineffecient to take advantage of?

/jws