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

[Robert Raszuk <[e-mail]>]

That's good addition to the draft.

My comment is addressed.

Thx,
R.

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

> Thanks for the the feedback
>
> 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 but
> rather an egress point failure
>
> 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.
>
> Ahmed
>
>
> On 11/28/2017 6:38 AM, Robert Raszuk wrote:
>
> Hi Ahmed,
>
> > - In a link-state envirnoment, node "S" knows the SRGB of node "F" as
> well as all adjacency SIDs of node "F"
>
> What you say is all true, but the way I read the question of this thread
> seems to be what happens in the cases where node S has no clue of the new
> top label. Say it was controller imposed EPE label or worse it is a VPN
> label.
>
>
> In the former EPE case the packet could still be "rescued" by picking into
> IP header. After all EPE is just an optimization.
>
> However in the latter case where we are carrying L2 or L3 VPNs packet
> header after the label stack may not help or may be even a security issue
> if node S would start to make routing decision in global RIB based on
> customer's space.
>
> So I think the point to document is what is the expected behavior of S
> node in case of new top label is unknown. It is ok to say drop it, but I
> think it needs to be clearly stated.
>
> Best,
> Robert
>
>
> On Tue, Nov 28, 2017 at 1:04 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
>> - 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"
>> - 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
>>
>> 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
>>
>>
>>
>> _______________________________________________
>> rtgwg mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/rtgwg
>>
>>
>
>