Assuming ToS stands for Top of the Stack.. The point is, if the ToS is the node/adjacency SID of the neighbor and the neighbor fails, then for a PLR to be able to find a repair path the PLR also needs to be the node enforcing the SR policy (i.e imposing the segment list). This is not very evident from section 5.3 of the draft and my original request for clarification..
Muthu On Thu, Nov 23, 2017 at 8:28 PM, Stewart Bryant <[email protected]> wrote: > > From my reading of the draft the proposal is only to try to find the > conventional shortest repair path from the PLR to the node specified by ToS > > I have always though that this needed a health warning, as presumably the > SR path was calculated for a reason and FRR needs to respect that reason. > > This is true if ToS is an node-SID, it is even more the case if the ToS is > an adj-SID. > > - Stewart > > On 23/11/2017 13:04, Muthu Arul Mozhi Perumal wrote: > > 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 [email protected]https://www.ietf.org/mailman/listinfo/rtgwg > > >
_______________________________________________ rtgwg mailing list [email protected] https://www.ietf.org/mailman/listinfo/rtgwg
