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

[Robert Raszuk <[e-mail]>]

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