Re: Protecting SR policy midpoints (draft-bashandy-rtgwg-segment-routing-ti-lfa)

[Muthu Arul Mozhi Perumal <[e-mail]>]

On Tue, Nov 28, 2017 at 5:34 PM, Ahmed Bashandy (bashandy) <
[e-mail]> wrote:

> Hi,
>
> The behavior described in section 5.3 is clear:
> - The top label of incoming packet to node "S" is either a prefix SID
> owned by node "F" or an adjacency SID for (S,F)
> - If the link from node "S" to node "F" is up, then the normal behavior
> for node "S" is to apply penultimate hop popping (PHP). HEnce node "S"
> *pops* the top label and sends the packet to node "F"
> - But if the link (S,F) is down and "S" is configured to do node
> protection, then node "S" will still pop the top label. This will promote
> the label right underneath the incoming label to become the *top* label.
> Hence there is no need to peek into the label stack
>

​What if the new top label is a BSID assigned from the SRLB of node F or a
BGP-LU or a VPN label assigned by node F?​


> - In a link-state envirnoment, node "S" knows the SRGB of node "F" as well
> as all adjacency SIDs of node "F". Hence it can now compare the new top
> label against the SRGB or the list of adj-SIDs of the node "F"
>

​What does "it" stand for in "it can now compare"?

​For the control plane to be able to compare it also needs to be imposing
the SR policy as I said earlier.

Or is the MPLS data plane expected to do such a comparison on the fly?


> - If the new top label is within the SRGB of node "F" or an adj-SID of
> node "F", then node "S" applies the behavior described in section 5.3.1 or
> section 5.3.2, respectively
>
> The bottom line is that there is no need for any peeking into the label
> stack. Just inspect the new top label
>

​How is the MPLS data plane in a transit node expected to be programmed to
make this work?

Regards,
Muthu​



> Thanks
>
> Ahmed
>
>
> On 11/23/2017 5:04 AM, 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 <[e-mail]
> > 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
>> <[e-mail]> 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
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/rtgwg
>>
>>
>
>
> _______________________________________________
> rtgwg mailing [e-mail]://www.ietf.org/mailman/listinfo/rtgwg
>
>
>