Re: BGP-4+

[Yakov Rekhter <[e-mail]>]

Dennis,

> This indeed seems like a fine hack to me.  

Thanks !!!

> Apart from the size-of-an-AS
> issue, which I think is orthogonal in any case, 

I agree that the size-of-an-AS issue is orthogonal.

> 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.

That would be fine. We'll incorporate this in the next iteration
of the document.

> (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

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).

Yakov.