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

my 2c

-- tony

On Sun, Nov 15, 2020 at 11:29 AM Jeff Tantsura <jefftant.i...@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 <rob...@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

Reply via email to