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
