Re: [Idr] Robustness of NLRI encoding in draft-ietf-idr-add-paths

["Shyam Sethuram (shsethur)" <[e-mail]>]

Hi Robert,
IMO the use of two different MP attributes to encode prefixes
belonging to the same afi/safi can lead to consistency issues.
Consider a prefix that currently is advertised using MP_REACH.
Suppose that prefix is now 'enabled' for add-paths. Would there
be an explicit MP_UNREACH followed by MP_ADD_PATHS_REACH ? And
vice-versa...

The only 'drawback' I see with the current scheme, as you also
noted, is the extra 4 bytes per NLRI if there's only
a bestpath to advertise.
Coming back to the original issue of mishandled capability
negotiation, that is akin to handling of 4byte AS capability
and AS_PATH. I'm not entirely sure we need to address a way
around implementation bugs for this particular case. But if
there's a dire need to do so using separate MP attribute types,
then we need to make the use of MP_REACH and MP_ADD_PATHS_REACH
mutually exclusive on a given session for a given afi/safi.

thanks--shyam


>-----Original Message-----
>From: [e-mail] [mailto:[e-mail]] On Behalf Of
Robert Raszuk
>(raszuk)
>Sent: Tuesday, November 23, 2010 12:31 PM
>To: John Scudder
>Cc: Daniel Ginsburg; [e-mail]
>Subject: Re: [Idr] Robustness of NLRI encoding in
draft-ietf-idr-add-paths
>
>
>Hi John/Enke,
>
>It is indeed right that one may send with current encoding single path
>for a given net and the price of this would be the extra 4 octets per
>those nets.
>
>If add-paths is enabled per net or per SAFI is on the border of
>implementation choice vs operation requirements of the network .. and I
>think the former is currently winning :)
>
>Last if we acknowledge that add-paths may be useful to be enabled for
>some specific prefixes I think it would be worth to standardize in base
>add-paths encoding document an explicit way to enable such behaviour
>domain wide instead of counting for consistent explicit configuration
on
>each bgp speaker. Set of defined standard communities each indicating
>the number of required paths per prefix it is attached to would be
>sufficient.
>
> >> Add-paths must be as defined today enabled for all IPv4 unicast
> >> SAFI
> >
> > I'm not sure what you mean by this either.  There is no requirement
> > in the spec to enable it for any particular AFI/SAFI.
>
>That was specific to the example provided.
>
>Many thx,
>R.
>
>
> > Robert,
>>
>> On Nov 23, 2010, at 8:48 AM, Robert Raszuk wrote: ...
>>> So while we are looking to change the NLRI format let me point out
>>> another observation of current add-paths proposal .. it allows to
>>> work on a per AFI/SAFI level only. If I have 1 million of IPv4
>>> routes and 10-50 voice gateways prefixes I particularly care about
>>> I do not have a way to continue sending my 1 million of IPv4 routes
>>> (less the 50 voice gateways) the old MP_REACH way with single best
>>> path only, with packing enabled and without path_id attached.
>>
>> I don't know what you mean by "with packing enabled"?  You are
>> correct that if you enable add-paths for a given AFI/SAFI the path_id
>> as to be attached for all routes of that AFI/SAFI; however, there
>> isn't any requirement to send multiple paths for all routes.  If you
>> didn't want to send multiple paths, you could certainly send the
>> path_id as zero (or any other fixed value) and essentially ignore it
>> in every other respect.
>>
>>> Add-paths must be as defined today enabled for all IPv4 unicast
>>> SAFI
>>
>> I'm not sure what you mean by this either.  There is no requirement
>> in the spec to enable it for any particular AFI/SAFI.
>>
>>> and what's worse with current implementations enabled uniformly ...
>>> that means if I need to send all paths for my voice gateways it
>>> will also result in distribution of all paths for the entire
>>> address family.
>> ...
>>
>> As you observe, this is an implementation choice and not fundamental
>> to the protocol.  As I point out above, an implementation is free to
>> pick and choose which prefixes it sends multiple paths for.  (This
>> might be a topic to be mentioned in the add-paths-guidelines draft,
>> though?)
>>
>> Regards,
>>
>> --John
>
>_______________________________________________
>Idr mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/idr