Re: [Lsr] Prefix Unreachable Announcement Use Cases

Hi, Tony:

Aijun Wang
China Telecom

> On Nov 20, 2020, at 17:45, Tony Przygienda <tonysietf@gmail.com> wrote:
> 
> 
> Yes, acknowledging the idea of negative disaggregation is inspired by RIFT work is fine (and normally, when inspired by an idea at least in research cycles it is considered basic courtesy to refer to the according source, something has been lost more and more in IETF over time I dare to observe which in itself reflects on the community IMO) but please do not try to compare the two beyond that.
[WAJ] PUA has no relation with RIFT. I have not yet study what’s problem it encountered, but welcome the experts have such design experience to point out the pitfall that PUA can bypass.

> Disaggregation works well on directed graphs (lattices) or arguably if your addressing scheme is aligned with regular topology (hypercube e.g.). it works in generic graphs in super special cases only & it will be @ best a crutch that may under all the correct circumstances have some utility but probably ends up hurting operationally more than helping.
[WAJ] PUA will try to avoid the solution that can only fit some special topology or address schema.

> The indication that "magic timer" is needed in the draft should be first warning, all kind of seat-of-pants heuristics to dis- and re-aggregate 2nd. 

[WAJ] “timer” is not uncommon in IGP protocol. Using it within PUA mechanism is just to assure the service switch successfully upon it receives the PUA.

> Just quickly flying through the draft I see lots of logic problems already that will lead to vexing effects, e.g. indication of missing neighbor will work in specific type of topologies, in others varying by one link only may lead to stable blackholes. 
[WAJ] Would you like to state the above conclusion more clearly?

> 
> my 2c
> 
> -- tony 
> 
>> On Sun, Nov 15, 2020 at 11:29 AM 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
>> _______________________________________________
>> Lsr mailing list
>> Lsr@ietf.org
>> https://www.ietf.org/mailman/listinfo/lsr
> _______________________________________________
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr