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

From: "Ahmed Bashandy (bashandy)" <[email-masked]>
Date: Fri, 01 Dec 2017 10:02:55 -0800

Not necessarily. However even if the intention of marking the adj-SID as 
protected is to protect against the failure of the link but not the far 
end of the link, then it is the responsibility of operator who 
instantiated the policy creator to know what is the type of protection 
that he/she configured on the link.

Ahmed

On 11/28/2017 9:15 AM, Alexander Vainshtein wrote:
> Ahmed,
> I believe that the so-called protected Adj-SID simply means that if 
> the link that it represents fails, it can be replaced with the 
> Node-SID of the node at the remote end if the adjacency.
> It does not help at all if the downstream node fails.
>
> Sent from Yahoo Mail on Android 
> <https://overview.mail.yahoo.com/mobile/?.src=Android>
>
>     On Tue, Nov 28, 2017 at 11:02, Ahmed Bashandy (bashandy)
>     <[email-masked]> wrote:
>     Stewart,
>
>     I am sure you are aware that ISIS and OSPF adj-SID advertisements
>     indicate whether an adj-SID is protected or not. If the ingress
>     router
>     decided to use a protected adj-SID for a policy, then the
>     protection of
>     such adj-SID is within the policy.
>
>     Ahmed
>
>     On 11/28/2017 7:15 AM, Stewart Bryant wrote:
>     >
>     >
>     > On 28/11/2017 12:04, Ahmed Bashandy (bashandy) wrote:
>     >>
>     >> - 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 it is an adjacency SID for (S,F) then you are violating the
>     > original intent of the ingress PE which was to send the packet
>     along
>     > the path S->F. I really don't think you can blindly repair such a
>     > packet since to do so violates the policy applied to the packet.
>     You
>     > have to do a policy check, and you have to make sure that the
>     packet
>     > is not subject to ECMP along the repair path since ECMP avoidance
>     > might have been the intent of using the SR Adjacency in the
>     first place.
>     >
>     > - Stewart
>
>     _______________________________________________
>     rtgwg mailing list
>     [email-masked] <mailto:[email-masked]>
>     https://www.ietf.org/mailman/listinfo/rtgwg
>

---

From: Muthu Arul Mozhi Perumal <[email-masked]>
Date: Mon, 4 Dec 2017 09:37:54 +0530

Thanks for your response. See inline..

On Tue, Nov 28, 2017 at 10:55 PM, Ahmed Bashandy (bashandy) <
[email-masked]> 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) <
> [email-masked]> 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
>> - 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 <
>> [email-masked]> 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.
>>>
>>> On Wed, Nov 22, 2017 at 3:27, Muthu Arul Mozhi Perumal
>>> <[email-masked]> 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
>>> [email-masked]
>> rtgwg mailing [email-masked]://www.ietf.org/mailman/listinfo/rtgwg
>>
>>
>>
>
>

---

From: Muthu Arul Mozhi Perumal <[email-masked]>
Date: Mon, 4 Dec 2017 09:52:13 +0530

Thanks for the pointer
to ​draft-hegde-spring-node-protection-for-sr-te-paths. Agree it describes
local protection for SR-TE paths better..

But, just wondering whether the data plane complexity is worth compared to
provisioning disjoint end-to-end SR-TE backup path together with S-BFD..

Regards,
Muthu

On Tue, Nov 28, 2017 at 10:28 PM, Alexander Vainshtein <[email-masked]>
wrote:

> Muthu,
> Please take a look at
> ​​
> draft-hegde-spring-node-protection-for-sr-te-paths that provides accurate
> descriprion of the requured DP behavior in the standard terms
> (context-specifuc label spaces and context-identifying labels).
>
> My 2c.
>
> On Tue, Nov 28, 2017 at 10:54, Muthu Arul Mozhi Perumal

---

From: Alexander Vainshtein <[email-masked]>
Date: Mon, 4 Dec 2017 16:16:03 +0000 (UTC)

Muthu,E2E protection of SR-TE LSPs against failure of Node- and Adj-SIDs that are part of the policy is definitely a valid and reasonable approach IMHO. And I also think that it can be combined with local (e.g., LFA-based) protection against failure of lunks and nodes that are NOT part of the policy and can be triggered by SR-LSP BFD as per RFC 5884.
For this approach  to work primary and backup SR-TE LSPs MUST NOT have any common SIDs.
Unfortunately, SPRING WG leaders have strongly opposed my proposal to combine local and E2E protection when SR protection use cases draft has been discussed.
Such a combination, indeed, is never used with RSVP-TE LSPs - but, IMHO, SR-Te LSPs are quite different.
My 2c,Sasha
Sent from Yahoo Mail on Android 
 
  On Sun, Dec 3, 2017 at 22:22, Muthu Arul Mozhi Perumal<[email-masked]> wrote:   __________________________________________ _____
rtgwg mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/rtgwg