Re: [Lsr] Prefix Unreachable Announcement Use Cases

Jeff,

I was not bringing RIFT's negative routies example as something inherently
negative. I was just pointing it out to illustrate that today's data plane
lookup does not really support "if does not match" checks.

So if you intend to use unreachable prefixes in data plane as result you
need to break summary into as atomic prefixes as your unreachable
advertisement mask.

Hence my recommendation to use IGP to flood unreachable only for the
purpose of control plane (namely BGP paths invalidation).

Cheers,
R.

On Sun, Nov 15, 2020 at 8:29 PM Jeff Tantsura <jefftant.ietf@gmail.com>
wrote:

> As RIFT chair - I’d like to respond to Robert’ comment -  the example is
> rather  unfortunate, in RIFT disaggregation is conditional and well
> contained within its context, it doesn’t  affect overall scalability.
>
> Regards,
> Jeff
>
> On Nov 15, 2020, at 08:44, Robert Raszuk <robert@raszuk.net> wrote:
>
> 
> Hi Aijun,
>
> I would in fact only propose that the presented mechanism is narrowed down
> to invalidate BGP (service) routes - in fact their next hops.
>
> The reason being that the moment you make the solution generic, moreover
> the moment you want it to be used in RIB and data plane I am afraid you are
> running into similar (even if local) deaggregation mechanism like recently
> described in RIFT. That would kill all the scalability of advertising
> summary routes in the first place and I bet would face lots of opposition.
>
> Thx,
> R.
>
>
>> I would actually trim most use cases leaving just one - to signal remote
>> service node (ex: PE) going down in the presence of summary route being
>> advertised from remote area or pop.
>>
>>  [WAJ] Yes, this may be the most useful use case, but the PUA mechanism
> can also apply to other scenarios. We want to make it one general solution.
> _______________________________________________
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr
>
>