Hi, Jeff and Robert:
Please see the response inlines. From: Jeff Tantsura <[email protected]> Sent: Monday, November 16, 2020 6:36 PM To: Robert Raszuk <[email protected]> Cc: Aijun Wang <[email protected]>; lsr <[email protected]>; Acee Lindem (acee) <[email protected]> Subject: Re: [Lsr] Prefix Unreachable Announcement Use Cases +1 with Robert. So you expect the following RIB state after PUA has been advertised: 10.0.0.1 - drop 10/24 - forward [WAJ] Yes, this is the expected result. Unless there’s a recursively discarded next-hop (ala RTBH ) - how do you envision it? [WAJ] This is the action that the node receives the PUA should do. Existing router may not support it, so we define the PUA capabilities announcement in section-6.3 of this draft <https://datatracker.ietf.org/doc/html/draft-wang-lsr-prefix-unreachable-annoucement-04#section-6.3> Regards, Jeff On Nov 16, 2020, at 00:25, Robert Raszuk <[email protected] <mailto:[email protected]> > wrote: 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 your idea is that you install route for unreachable prefix to /dev/null ? [WAJ] Yes. And how would that help connectivity restoration ? [WAJ] This action will trigger the path protection procedures, which will divert the traffic to other backup path. Moreover it seems that it will just also prevent any local protection to locally bypass the failed destination. [WAJ] No, It will trigger the local protection instead, not prevent. Bottom line is that I agree with one problem statement. However IMHO described actions upon reception of PUA are questionable at best. Cheers, R.
_______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
