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

From: Muthu Arul Mozhi Perumal <[email-masked]>
Date: Wed, 22 Nov 2017 14:57:42 +0530

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

---

From: Alexander Vainshtein <[email-masked]>
Date: Wed, 22 Nov 2017 14:52:43 +0000 (UTC)

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 
 
  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_______________________________________________
rtgwg mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/rtgwg

---

From: Muthu Arul Mozhi Perumal <[email-masked]>
Date: Thu, 23 Nov 2017 18:34:01 +0530

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.
>
> <https://overview.mail.yahoo.com/mobile/?.src=Android>
>
> On Wed, Nov 22, 2017 at 3:27, Muthu Arul Mozhi Perumal
> <[email-masked]> wrote:
> _______________________________________________
> rtgwg mailing list
> [email-masked]

---

From: Stewart Bryant <[email-masked]>
Date: Thu, 23 Nov 2017 14:58:48 +0000

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-masked] <mailto:[email-masked]>> wrote:
>
>     Muthu and all,
>     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.
>
>         <[email-masked] <mailto:[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.
>
>         [email-masked] <mailto:[email-masked]>
>         <https://www.ietf.org/mailman/listinfo/rtgwg>
>
>
>
>

---

From: Muthu Arul Mozhi Perumal <[email-masked]>
Date: Mon, 27 Nov 2017 18:25:16 +0530

Assuming ToS stands for Top of the Stack..

The point is, if the ToS is the node/adjacency SID of the neighbor and the
neighbor fails, then for a PLR to be able to find a repair path the PLR
also needs to be the node enforcing the SR policy (i.e imposing the segment
list). This is not very evident from section 5.3 of the draft and my
original request for clarification..

Muthu

On Thu, Nov 23, 2017 at 8:28 PM, Stewart Bryant <[email-masked]>
wrote:

> 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 Wed, Nov 22, 2017 at 8:22 PM, Alexander Vainshtein <[email-masked]
> > wrote:
>
>> Muthu and all,
>> 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.
>>
>> A transit node that has no idea about the SR policy itself is not
>> expected to perform the procedure described in that section.
>>
> rtgwg mailing [email-masked]://www.ietf.org/mailman/listinfo/rtgwg
>
>
>

---

From: "Ahmed Bashandy (bashandy)" <[email-masked]>
Date: Tue, 28 Nov 2017 04:04:53 -0800

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

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 28 Nov 2017 15:38:25 +0100

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) <
[email-masked]> wrote:

> 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"
> node "F", then node "S" applies the behavior described in section 5.3.1 or
> section 5.3.2, respectively
>
> ​ Muthu​

---

From: Stewart Bryant <[email-masked]>
Date: Tue, 28 Nov 2017 15:15:07 +0000

> 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

---

From: Alexander Vainshtein <[email-masked]>
Date: Tue, 28 Nov 2017 16:04:15 +0000 (UTC)

Ahmed and all,Two points:1. From my POV your description of forwarding behavior when the link S-->F fails is incomplete: the top label in the stack may be poppoed, but it is not "forgotten", and the next exposed label is looked up by S in the context label space that is F-specific. I.e., if S has two downstream neighbors, F and G, and both links S-->F and S-->G fail, lookup of the next exposed label for packets with ToS being S label for F and S label for G will yield different results.
2. From my POV draft-hegde-spring-node-protection-for-sr-te-paths provides roughly equjvalent behavior, but it is much more clear when it comes to describibg the DP mechanisms involved. (IMHO and FWIW calling a spae by its name is greatly preferable in most cases.)
My 2c

  On Tue, Nov 28, 2017 at 6:04, Ahmed Bashandy (bashandy)<[email-masked]> wrote:   _______________________________________________
rtgwg mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/rtgwg

---

From: Alexander Vainshtein <[email-masked]>
Date: Tue, 28 Nov 2017 16:12:20 +0000 (UTC)

Stewart,I understand your concern. However, as I see it, the alternatives to local protection of a failed pinned node of a SR-TE LSP are somewhat limited:
1. You can wait (with no traffic) until failure of the pinned node is recognized (e.g., fillowing IGP cobversion) and a new policy(that does not inckude the failed node) is recomputed and installed. 
2. You can pre-compute and pre-install a backup policy that does not have any common pinned nodes with the original ones and, once the origibal policy fails, switch ti the backup one end-to-end.
My 2c.

  On Tue, Nov 28, 2017 at 9:15, Stewart Bryant<[email-masked]> wrote:   

- Stewart

---

From: Muthu Arul Mozhi Perumal <[email-masked]>
Date: Tue, 28 Nov 2017 22:24:20 +0530

> 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?​

> 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?

> 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​

---

From: "Ahmed Bashandy (bashandy)" <[email-masked]>
Date: Tue, 28 Nov 2017 08:58:17 -0800

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:
> 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.
>
> 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.
>
> 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) 
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>     Hi,
>
>     - 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"
>     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
>
>
>>     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​
>>
>>         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.
>>
>>             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
>>             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.
>>
>>     https://www.ietf.org/mailman/listinfo/rtgwg  <https://www.ietf.org/mailman/listinfo/rtgwg>
>
>

---

From: Alexander Vainshtein <[email-masked]>
Date: Tue, 28 Nov 2017 16:58:52 +0000 (UTC)

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.
Sent from Yahoo Mail on Android 
 
  On Tue, Nov 28, 2017 at 10:54, Muthu Arul Mozhi Perumal<[email-masked]> wrote:   _______________________________________________
rtgwg mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/rtgwg

---

From: "Ahmed Bashandy (bashandy)" <[email-masked]>
Date: Tue, 28 Nov 2017 09:01:51 -0800

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:
> 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

---

From: "Ahmed Bashandy (bashandy)" <[email-masked]>
Date: Tue, 28 Nov 2017 09:14:49 -0800

See inline

Ahmed

On 11/28/2017 8:04 AM, Alexander Vainshtein wrote:
> Ahmed and all,
> Two points:
> 1. From my POV your description of forwarding behavior when the link 
> S-->F fails is incomplete: the top label in the stack may be poppoed, 
> but it is not "forgotten", and the next exposed label is looked up by 
> S in the context label space that is F-specific. I.e., if S has two 
> downstream neighbors, F and G, and both links S-->F and S-->G fail, 
> lookup of the next exposed label for packets with ToS being S label 
> for F and S label for G will yield different results.
>
#Ahmed: I do not understand what is not clear. The draft says in 
sections 5.3.1 and 5.3.2 "Confirm that the next segment is in the SRGB 
of F" and "the active segment is a prefix SID for a neighbor F" and 
"Confirm that the next segment is an adjacency SID of F".

In my previous email I said 'node "S" knows the SRGB of node "F" as well 
as all adjacency SIDs of node "F"'

So it is quite clear that the checks done on the new top label is within 
the context of the next-hop "F"

> 2. From my POV draft-hegde-spring-node-protection-for-sr-te-paths 
> provides roughly equjvalent behavior, but it is much more clear when 
> it comes to describibg the DP mechanisms involved. (IMHO and FWIW 
> calling a spae by its name is greatly preferable in most cases.)
#Ahmed: thanks for pointing out that 
draft-hegde-spring-node-protection-for-sr-te-paths overlaps with 
draft-bashandy-rtgwg-segment-routing-ti-lfa :)

>     On Tue, Nov 28, 2017 at 6:04, Ahmed Bashandy (bashandy)
>     <[email-masked]> wrote:

---

From: Alexander Vainshtein <[email-masked]>
Date: Tue, 28 Nov 2017 17:15:50 +0000 (UTC)

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.

  On Tue, Nov 28, 2017 at 11:02, Ahmed Bashandy (bashandy)<[email-masked]> wrote:   Stewart,

Ahmed

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 28 Nov 2017 18:17:43 +0100

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) <
[email-masked]> wrote:

> 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
>
>
>> 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
>> On Wed, Nov 22, 2017 at 8:22 PM, Alexander Vainshtein <
>> [email-masked]> wrote:
>>
>>> Muthu and all,

---

From: "Ahmed Bashandy (bashandy)" <[email-masked]>
Date: Tue, 28 Nov 2017 09:25:57 -0800

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] <mailto:[email-masked]>>wrote:
>
>     Hi,
>
> ​ 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
midpoint.

> ​ 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. It is not that 
difficult. Just make sure you have a good forwarding ASIC :)
> ​ 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 :)
> Muthu ​

---

From: Alexander Vainshtein <[email-masked]>
Date: Tue, 28 Nov 2017 17:54:01 +0000 (UTC)

Ahmed,Regarding what was not clear:
As I see it, you have been carefully avoiding usage of the RFC 5331 language (context-specific label spaces and context identifiers) in your SR-related drafts. We (you and I) have already discussed this point wrt the SR anycast draft. 
Regarding the overlap: it is quite substantial IMHO and should be addressed in some way.

  On Tue, Nov 28, 2017 at 11:14, Ahmed Bashandy (bashandy)<[email-masked]> wrote:   _______________________________________________
rtgwg mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/rtgwg

---

From: Stewart Bryant <[email-masked]>
Date: Tue, 28 Nov 2017 20:06:12 +0000

2. looks to be similar to 1+1 backup from the headend, which would be 
the normal default, but you have to prevent the packet going down the 
repair.

What would be nice would be to install a tailored backup hence:

3. Install a purpose built backup and somehow map to it on failure.

Both of these are analogous to the RSVP solutions.

Maybe to do 3 you use an SPL followed by a policy identifier so that the 
FRR node knows to abandon the repair or to pick a particular path such 
as a particular binding SID.

- Stewart

On 28/11/2017 16:12, Alexander Vainshtein wrote:
> Stewart,
> I understand your concern. However, as I see it, the alternatives to 
> local protection of a failed pinned node of a SR-TE LSP are somewhat 
> limited:
>
> 1. You can wait (with no traffic) until failure of the pinned node is 
> recognized (e.g., fillowing IGP cobversion) and a new policy(that does 
> not inckude the failed node) is recomputed and installed.
>
> 2. You can pre-compute and pre-install a backup policy that does not 
> have any common pinned nodes with the original ones and, once the 
> origibal policy fails, switch ti the backup one end-to-end.
>
> My 2c.
>
>
>
>     original

---

From: Alexander Vainshtein <[email-masked]>
Date: Tue, 28 Nov 2017 21:32:06 +0000 (UTC)

Stewart,Lots of thanks for a prompt response.From my POV "normal" FRR (based on LFA or RLFA) can be employed safely to protect against the"middle of a segment" link and/or node failure without any impact on the policy. And it would not respond to failure of the nodes (or links) that are part of the policy unless the mechanism defined in draft-hegde or in Section 5.3 of this draft (hich are the same mechanism under different names) were enabled.
My definituon of (2)  explicitly states that main abd backup policues should not have any common SIDs. So I do not see much difference between (2) and (3).
What did I miss?
Sent from Yahoo Mail on Android 
 
  On Tue, Nov 28, 2017 at 14:06, Stewart Bryant<[email-masked]> wrote:    

 2. looks to be similar to 1+1 backup from the headend, which would be the normal default, but you have to prevent the packet going down the repair.

 
 
 Maybe to do 3 you use an SPL followed by a policy identifier so that the FRR node knows to abandon the repair or to pick a particular path such as a particular binding SID.
 
 - Stewart

Stewart, I understand your concern. However, as I see it, the alternatives to local protection of a failed pinned node of a SR-TE LSP are somewhat limited: 
  1. You can wait (with no traffic) until failure of the pinned node is recognized (e.g., fillowing IGP cobversion) and a new policy(that does not inckude the failed node) is recomputed and installed.  
  2. You can pre-compute and pre-install a backup policy that does not have any common pinned nodes with the original ones and, once the origibal policy fails, switch ti the backup one end-to-end. 
  My 2c. 

  On Tue, Nov 28, 2017 at 9:15, Stewart Bryant <[email-masked]> wrote:   

 
 - Stewart

---

From: Sikhivahan Gundu <[email-masked]>
Date: Wed, 29 Nov 2017 05:34:03 +0000

Drafts allow a B-Flag to be attached to the Adj-SID, which says that the
adjacency is “eligible for protection”. Such an adjacency may perhaps
also be interpreted as ineligible for SR policies that are particular that
only the selected adjacency must be used to reach the protected node.
This prevents packets from going down the (TI-LFA) repair path,  but
of course does not offer a solution with regard to mapping Adj-SID/BSID
to a non-TI-LFA backup. Perhaps more flags and signaling would be needed
for the latter.

Thx
Sikhi

From: rtgwg [mailto:[email-masked]] On Behalf Of Stewart Bryant
Sent: 29 November 2017 01:36
To: [email-masked]; Ahmed Bashandy (bashandy) <[email-masked]>; Muthu Arul Mozhi Perumal <[email-masked]>; [email-masked]
Cc: [email-masked]
Subject: Re: Protecting SR policy midpoints (draft-bashandy-rtgwg-segment-routing-ti-lfa)

- Stewart

On 28/11/2017 16:12, Alexander Vainshtein wrote:
Stewart,
I understand your concern. However, as I see it, the alternatives to local protection of a failed pinned node of a SR-TE LSP are somewhat limited:

My 2c.

Sent from Yahoo Mail on Android<https://overview.mail.yahoo.com/mobile/?.src=Android>

On Tue, Nov 28, 2017 at 9:15, Stewart Bryant
<[email-masked]><mailto:[email-masked]> wrote:

- Stewart

_______________________________________________
rtgwg mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/rtgwg