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] <mailto:[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] <mailto:[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] <mailto:[email protected]>
        https://www.ietf.org/mailman/listinfo/rtgwg
        <https://www.ietf.org/mailman/listinfo/rtgwg>




_______________________________________________
rtgwg mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/rtgwg

_______________________________________________
rtgwg mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/rtgwg

Reply via email to