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

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

Thanks for your response. See inline..

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

> Thanks for the feedback
>
> See inline
>
> Ahmed
>
> On 11/28/2017 8:54 AM, Muthu Arul Mozhi Perumal wrote:
>
> 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?​
>
> #Ahmed: I just replied to Robert. Let me put it here
> The node "S" knows the SRGB and the adj-SIDs of the  neighboring node "F".
> Hence if the new top label is not within these two sets, then the node "S"
> will always be able to know that the node that failed is NOT a midpoint.
>

​
​Define
what "policy midpoint" is. Also,
​the
case where the new ToS is a BSID
​assigned from the SRLB of node F needs consideration..


>
> I will add a statement in the document to explain how a node can determine
> that a failure is a midpoint failure. I will also add a statement to
> indicate that if the node determines that the failure is not a midpoint
> failure then it may apply other protection techniques that are beyond the
> scope of this document or simply drop the packet and wait for normal
> protocol conversion.
>
>
>
>> - 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"?
>
> "Ahmed: "It" refers to the node "S"
>
>
> ​ For the control plane to be able to compare it also needs to be imposing
> the SR policy as I said earlier.
>
> #Ahmed: There is no control plane comparison.
>
>
> Or is the MPLS data plane expected to do such a comparison on the fly?
>
> #Ahmed: data plane is expected to do such comparison.
>

​This is not clear from the current draft. Would suggest stating it
explicitly..

Muthu


> It is not that difficult. Just make sure you have a good forwarding ASIC :)
>
>
>
>> - 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?
>
> #Ahmed: Implementation details that should become big problems for good
> forwarding ASICs :)
>
>
> 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
>>
>>
>>
>
>