Hi, Tony: Aijun Wang China Telecom
> On Nov 20, 2020, at 17:45, Tony Przygienda <[email protected]> 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 <[email protected]> >> 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 <[email protected]> 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 >>> [email protected] >>> https://www.ietf.org/mailman/listinfo/lsr >> _______________________________________________ >> Lsr mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/lsr > _______________________________________________ > Lsr mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/lsr
_______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
