Hi, Robert:
Does the following responses satisfy your concerns If I understand your questions correctly? From: lsr-boun...@ietf.org [mailto:lsr-boun...@ietf.org] On Behalf Of Robert Raszuk Sent: Monday, November 16, 2020 4:04 AM To: Jeff Tantsura <jefftant.i...@gmail.com> Cc: lsr <lsr@ietf.org>; Aijun Wang <wangai...@tsinghua.org.cn>; Acee Lindem (acee) <acee=40cisco....@dmarc.ietf.org> Subject: Re: [Lsr] Prefix Unreachable Announcement Use Cases 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. [WAJ] In data plane, the device do still the “match” check, not “does not match” check. When the router receives the PUA information, it will install one black hole route for a short time. 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. [WAJ] When the number of unreachable prefixes is limited(this is the common situation), Summary Route+PUA is the most efficient solution. Hence my recommendation to use IGP to flood unreachable only for the purpose of control plane (namely BGP paths invalidation). [WAJ] PUA and “Smart Disaggregation” in RIFT aim to the same problems, but there are some differences: 1. In RIFT, the parallel node will advertise the detailed prefix when it detects that another node on the same level can’t reach the mentioned prefix. But for PUA, the decision/advertisement is made by the ABR node itself that knows the failure of links/nodes. 2. The advertisement information is different. In RIFT, the detail prefix information is advertised(by another node that can reach the failure prefix); in PUA, the detail unreachable prefix information is advertised instead(by the node that can’t reach the failure prefix). After knowing this information, the receiver node can switch the path to send the traffic, or trigger the BGP control plane switchover as you said. Cheers, R. On Sun, Nov 15, 2020 at 8:29 PM Jeff Tantsura <jefftant.i...@gmail.com <mailto: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 <mailto: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 <mailto:Lsr@ietf.org> https://www.ietf.org/mailman/listinfo/lsr
_______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
