My understanding is that draft wants to provide a solution for the problem where the active segment is a prefix/adjacency segment of the neighbor and the neighbor fails. A solution to this is possible only at a node that is enforcing the SR policy (consisting of the segment list). For a transit node, its data plane would have to peek into the label stack and determine the type of the segment/label following the active segment and act accordingly, which is not inline with the SR architecture which requires SR to work 'as is' on traditional MPLS data plane
​Muthu​ On Wed, Nov 22, 2017 at 8:22 PM, Alexander Vainshtein <[email protected]> wrote: > Muthu and all, > I do not see how the draft in quesrion us related to "SR Policy". > > From my POV its scope is a SR LSP comprised of multiple Node SIDs within a > single IGP domain, and it provides local fast protection against failure of > a node that terminates one of the segments comprising this LSP. Pritection > action is performed by the penultimate node. > > My 2c. > > Sent from Yahoo Mail on Android > <https://overview.mail.yahoo.com/mobile/?.src=Android> > > On Wed, Nov 22, 2017 at 3:27, Muthu Arul Mozhi Perumal > <[email protected]> wrote: > Section 5.3 of draft-bashandy-rtgwg-segment-routing-ti-lfa describes > protecting SR policy midpoints against node failure for the case where the > active segment is the prefix or adjacency segment of a neighbor. > > I believe the steps described in the procedure is applicable only for a > node steering packets into the SR policy. This could be an ingress PE > steering IP packets into a SR-TE tunnel or an intermediate node steering > labeled packets received with a BSID into a SR-TE tunnel identified by that > BSID. > > A transit node that has no idea about the SR policy itself is not expected > to perform the procedure described in that section. > > Is my understanding correct? > > Regards, > Muthu > _______________________________________________ > rtgwg mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/rtgwg > >
_______________________________________________ rtgwg mailing list [email protected] https://www.ietf.org/mailman/listinfo/rtgwg
