Thanks for clarification Robert, makes sense.
Cheers, Jeff On Nov 15, 2020, 12:03 PM -0800, Robert Raszuk <rob...@raszuk.net>, wrote: > 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.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
