Tony I agree. We have to be careful not to confuse path protection mentioned to RSVP FRR protection based on TEDs or LFA style local protection. We will redo the verbiage carefully to not call use pre-existing terminology term that will add confusion.
Thanks for the feedback!! Thanks Gyan On Tue, Nov 17, 2020 at 1:31 AM <[email protected]> wrote: > > 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 > -- <http://www.verizon.com/> *Gyan Mishra* *Network Solutions A**rchitect * *M 301 502-134713101 Columbia Pike *Silver Spring, MD
_______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
