Hi Zhibo, > However, if there is a summary or default route in the area, FIB Miss cannot be triggered.
If PUA is a /dev/null route this is not a FIB miss. It's a FIB hit. Thx, R. On Wed, Nov 18, 2020 at 3:36 AM Huzhibo <[email protected]> wrote: > 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:[email protected]] *On Behalf Of *[email protected] > *Sent:* Tuesday, November 17, 2020 2:31 PM > *To:* Aijun Wang <[email protected]> > *Cc:* lsr <[email protected]>; Jeff Tantsura <[email protected]>; Robert > Raszuk <[email protected]>; Acee Lindem (acee) <acee= > [email protected]> > *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 [email protected] https://www.ietf.org/mailman/listinfo/lsr
