Hi Tony: In fact, this protection use case protects the SRv6 mid-point. https://datatracker.ietf.org/doc/draft-chen-rtgwg-srv6-midpoint-protection/. When the SRv6 mid-point fails, the PLR node can perform the next SID operation, which is triggered by FIB miss. However, if there is a summary or default route in the area, FIB Miss cannot be triggered.
Thanks Zhibo From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of tony...@tony.li Sent: Tuesday, November 17, 2020 2:31 PM To: Aijun Wang <wangai...@tsinghua.org.cn> Cc: lsr <lsr@ietf.org>; Jeff Tantsura <jefftant.i...@gmail.com>; Robert Raszuk <rob...@raszuk.net>; Acee Lindem (acee) <acee=40cisco....@dmarc.ietf.org> Subject: Re: [Lsr] Prefix Unreachable Announcement Use Cases 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. This seems to be making some major assumptions about how path protection features operate. Those assumptions need to be very explicitly called out. The path protection features that I’m familiar with are triggered by topological changes along the existing operable path. A PUA does not provide that. Rather, it’s something of a temporary signal saying ’this broke’. Without more specifics about the failure, it’s difficult to understand exactly what path protection should make of this. If a prefix is unreachable, the obvious implication is that the associated link has failed. Path protection in a remote area is highly unlikely to have the topological details necessary to find an alternate path to that prefix. Tony
_______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
