Subject: [spring] Spring protection - determining applicability

From: "Joel M. Halpern" <[email-masked]>
Date: Sun, 2 Aug 2020 19:50:38 -0400

(WG Chair hat Off, this is merely a note from a slightly confused WG 
participant.)

I have been reading the various repair drafts, and the various networks 
programming and service programming draft, and I am trying to figure out 
one aspect of the combination.

How does a node that is doing some form of bypass (suppose, for 
simplicity, it is Node N2 deciding to bypass the next SID for a failed 
node N3) know that it is safe to do so?

If the path was just for TE, then it is "safe" if the new path meets the 
TE criteria.  or maybe it is safe if it is even close, as long as it is 
not used for too long.

But what if the node were a Firewall, included to meet legal requirements?
Or was some other necessary programmatic transform (wince we are 
deliberately vague about what nodes can do when asked suitably.)

Is there some "can be bypassed" indication in the routing advertisements 
that I missed?

Thank you,
Yours,
Joel

---

From: Mach Chen <[email-masked]>
Date: Mon, 3 Aug 2020 03:30:14 +0000

Hi Joel,

I think this is a good point that may not be discussed in the past. And I also don't think there is a "can be bypassed" indication in the routing advertisement for now.

IMHO, the information advertised by routing is neutral, such information (can or cannot be bypassed) is more path specific, thus normally the controller should be responsible for deciding whether/which SID can be bypassed. 

Best regards,
Mach

> -----Original Message-----
> From: spring [mailto:[email-masked]] On Behalf Of Joel M. Halpern
> Sent: Monday, August 3, 2020 7:51 AM
> To: [email-masked]
> Subject: [spring] Spring protection - determining applicability
> 
> How does a node that is doing some form of bypass (suppose, for simplicity,
> it is Node N2 deciding to bypass the next SID for a failed node N3) know that
> it is safe to do so?
> 
> If the path was just for TE, then it is "safe" if the new path meets the TE
> criteria.  or maybe it is safe if it is even close, as long as it is not used for too
> long.
> 
> _______________________________________________
> spring mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/spring

---

From: Alexander Vainshtein <[email-masked]>
Date: Mon, 3 Aug 2020 06:36:33 +0000

Mach, Joel and all,

I think that in most cases:

1.       There is clear differentiation between "topological" and "service" instructions in SID advertisements. E.g.:

o   IGP Prefix Node SIDs IGP Adj-SIDs (identified as such in the corresponding IGP advertisements) represent topological instructions

o   Service SIDs for SRv6 (see SRv6 BGP-Based Overlay Services<https://datatracker.ietf.org/doc/html/draft-ietf-bess-srv6-services-04> draft) unsurprisingly represent "service" instructions

2.       Segments that represent topological instructions can be bypassed, while segments that represent service instructions require alternative protection mechanisms.

This view seems to be aligned with RFC 8402<https://tools.ietf.org/html/rfc8402> that says in Section 1:

   In the context of an IGP-based distributed control plane, two

   topological segments are defined: the IGP-Adjacency segment and the

   IGP-Prefix segment.

   In the context of a BGP-based distributed control plane, two

   topological segments are defined: the BGP peering segment and the

   BGP-Prefix segment.

In the case of SR-MPLS this differentiation is assumed in Section 3.4 of the Node Protection for SR-TE Path<https://datatracker.ietf.org/doc/html/draft-hegde-spring-node-protection-for-sr-te-paths-07#section-3.4> draft that says:

   The node protection mechanism described in the previous sections

   depends on the assumption that the label immediately below the top

   label in the label stack is understood in the IGP domain.  When the

   provider edge routers exchange service labels via BGP or some other

   non-IGP mechanism the bottom label is not understood in the IGP

   domain.

   The egress node protection mechanisms described in the draft

   [RFC8679<https://datatracker.ietf.org/doc/html/rfc8679>] is applicable to this use case and no additional changes

   will be required for SR based networks

The scenarios in which  differentiation between "topological" and "service" instructions is broken are indeed problematic. E.g., consider the use case in which a Node SID in the ERO of a SR-TE path identifies a node that acts as a firewall for all packets it receives, i.e., provides the firewall service without any dedicated service SID identifying it. One could say that the Node SID of such a node would combine topological and service instructions thus breaking the differentiation between the two.

I am not sure if usage of such "combined" SIDs could be prevented or at least discouraged.

If not, providing an ability to identify such SIDs in the advertisement mechanisms would be useful IMHO.

My 2c,

Sasha

Office: +972-39266302

Cell:      +972-549266302

Email:   [email-masked]

-----Original Message-----
From: spring <[email-masked]> On Behalf Of Mach Chen
Sent: Monday, August 3, 2020 6:30 AM
To: Joel M. Halpern <[email-masked]>; [email-masked]
Subject: Re: [spring] Spring protection - determining applicability

Hi Joel,

Best regards,

Mach

> From: spring [mailto:[email-masked]] On Behalf Of Joel M.

> Halpern

> To: [email-masked]<mailto:[email-masked]>

> I have been reading the various repair drafts, and the various

> networks programming and service programming draft, and I am trying to

> figure out one aspect of the combination.

> If the path was just for TE, then it is "safe" if the new path meets

> the TE criteria.  or maybe it is safe if it is even close, as long as

> it is not used for too long.

> Is there some "can be bypassed" indication in the routing

> advertisements that I missed?

> [email-masked]<mailto:[email-masked]>

> https://clicktime.symantec.com/367qhU4KiUkzW9uGC4eAvP46H2?u=https%3A%2<https://clicktime.symantec.com/367qhU4KiUkzW9uGC4eAvP46H2?u=https%3A%252>

> F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring

spring mailing list

[email-masked]<mailto:[email-masked]>

https://clicktime.symantec.com/367qhU4KiUkzW9uGC4eAvP46H2?u=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring

-----------------------------------------------------------------------------------------------------------------------
Notice: This e-mail together with any attachments may contain information of Ribbon Communications Inc. that
is confidential and/or proprietary for the sole use of the intended recipient.  Any review, disclosure, reliance or
distribution by others or forwarding without express permission is strictly prohibited.  If you are not the intended
recipient, please notify the sender immediately and then delete all copies, including any attachments.
-----------------------------------------------------------------------------------------------------------------------

---

From: "Chengli (Cheng Li)" <[email-masked]>
Date: Mon, 3 Aug 2020 09:14:07 +0000

Hi Joel and Mach,

Yes, we should consider to bypass or not bypass the node in different cases.

Like Joel said, we can not skip the firewall, while it can be fine to skip a TE node, if the repair path meets the TE SLA requirements.

Regarding these two cases, AFAIK, two documents describes the related mechanisms
* Bypass:  https://tools.ietf.org/html/draft-chen-bess-srv6-service-bypass-sid-00
* No bypass: https://datatracker.ietf.org/doc/draft-li-rtgwg-enhanced-ti-lfa/

Hope it help the discussion, and comments are welcome! 

Respect,
Cheng

-----Original Message-----
From: spring [mailto:[email-masked]] On Behalf Of Mach Chen
Sent: Monday, August 3, 2020 11:30 AM
To: Joel M. Halpern <[email-masked]>; [email-masked]
Subject: Re: [spring] Spring protection - determining applicability

Hi Joel,

Best regards,
Mach

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 3 Aug 2020 12:43:17 -0400

What I am hearing is that we all know there is an issue here, but the 
documents do not connect the dots?

Yours,
Joel

On 8/3/2020 2:36 AM, Alexander Vainshtein wrote:
> 1.There is clear differentiation between "topological" and "service" 
> instructions in SID advertisements. E.g.:
> 
> oIGP Prefix Node SIDs IGP Adj-SIDs (identified as such in the 
> corresponding IGP advertisements) represent topological instructions
> 
> oService SIDs for SRv6 (see SRv6 BGP-Based Overlay Services 
> <https://datatracker.ietf.org/doc/html/draft-ietf-bess-srv6-services-04> 
> draft) unsurprisingly represent “service” instructions
> 
> 2.Segments that represent topological instructions can be bypassed, 
> while segments that represent service instructions require alternative 
> protection mechanisms.
> 
> This view seems to be aligned with RFC 8402 
> <https://tools.ietf.org/html/rfc8402> that says in Section 1:
> 
> In the case of SR-MPLS this differentiation is assumed in Section 3.4 of 
> the Node Protection for SR-TE Path 
> <https://datatracker.ietf.org/doc/html/draft-hegde-spring-node-protection-for-sr-te-paths-07#section-3.4> 
> draft that says:
> 
>     [RFC8679 <https://datatracker.ietf.org/doc/html/rfc8679>] is 
> applicable to this use case and no additional changes
> 
> The scenarios in which  differentiation between “topological” and 
> “service” instructions is broken are indeed problematic. E.g., consider 
> the use case in which a Node SID in the ERO of a SR-TE path identifies a 
> node that acts as a firewall for all packets it receives, i.e., provides 
> the firewall service without any dedicated service SID identifying it. 
> One could say that the Node SID of such a node would combine topological 
> and service instructions thus breaking the differentiation between the two.
> 
> I am not sure if usage of such “combined” SIDs could be prevented or at 
> least discouraged.
> 
> I think this is a good point that may not be discussed in the past. And 
> I also don't think there is a "can be bypassed" indication in the 
> routing advertisement for now.
> 
> IMHO, the information advertised by routing is neutral, such information 
> (can or cannot be bypassed) is more path specific, thus normally the 
> controller should be responsible for deciding whether/which SID can be 
> bypassed.
> 
> Best regards,
> 
> Mach
> 
>  > To: [email-masked] <mailto:[email-masked]>
> 
>  > [email-masked] <mailto:[email-masked]>
> 
>  > 
> https://clicktime.symantec.com/367qhU4KiUkzW9uGC4eAvP46H2?u=https%3A%2 
> <https://clicktime.symantec.com/367qhU4KiUkzW9uGC4eAvP46H2?u=https%3A%252>
> 
> [email-masked] <mailto:[email-masked]>
> 
> ------------------------------------------------------------------------
> Notice: This e-mail together with any attachments may contain 
> information of Ribbon Communications Inc. that is confidential and/or 
> proprietary for the sole use of the intended recipient. Any review, 
> disclosure, reliance or distribution by others or forwarding without 
> express permission is strictly prohibited. If you are not the intended 
> ------------------------------------------------------------------------
>

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 3 Aug 2020 14:10:18 -0400

Well less serious for TE SIDs, I am not sure the problem is restricted 
to just service SIDs.

Suppose that the PCE has specified the path to meet some complex te 
objective.  The bypass node has no way of knowing what those constraints 
were.  And for some kinds of traffic, it is better to drop the packet 
than to deliver it outside the envelop.  I suspect that the right answer 
to this is "too bad".  If so, as with the distinction regarding service 
nodes, we should say so, shouldn't we?

Yours,
Joel

---

From: Robert Raszuk <[email-masked]>
Date: Mon, 3 Aug 2020 20:30:25 +0200

Joel,

Are we still talking about IP networks here ? Or perhaps some hard slicing
with real resource reservations or detnets ?

Because if we are talking about IP networking I have two observations:

A) If you need to traverse via a specific node (ie. firewall) you better
apply IP encapsulation to that node. I don't think IP encapsulation can be
hijacked today such that destination address of the packet is ignored.

B) Have you seen any IP network where upon topology change (link or node
failure) you suddenly start dropping flows in spite of SPT offering perhaps
few ms longer path with 10 ms more jitter ?

Or are some SR marketing slides promise to turn IP networks in
something new ? Worse ... do they mention path quality guarantees, resource
reservations ? I hope not.

Thx,
R.

On Mon, Aug 3, 2020 at 8:10 PM Joel M. Halpern <[email-masked]> wrote:

> > <
> https://datatracker.ietf.org/doc/html/draft-hegde-spring-node-protection-for-sr-te-paths-07#section-3.4>
>
> > draft that says:
> >
> > <
> https://clicktime.symantec.com/367qhU4KiUkzW9uGC4eAvP46H2?u=https%3A%252>
> >

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 3 Aug 2020 14:35:47 -0400

(Since the thread has gotten long enough, reiterating that this is as a 
participant, not a WG chair.)

Yes, we are talking IP networks.  And yes, I have seen IP networks that 
choose to drop packets.  For all sorts of reasons.
I think there are likely other reasons why one may not want a random 
path rather than a chosen TE path.  I think it is important we be clear 
about what constraints may be / are violated when we tell people they 
have this tool (protective rerouting) that is intended to preserve QoS.

Let's be clear.  I am not arguing that this is not a good idea.  It is a 
good idea.  And useful.  I am trying to figure otu what combination of 
additional mechanisms and clear descriptions will lead to everyone 
getting the behavior they expect (which may not be the behavior they 
desire, but sometimes is the best we can do.)

Yours,
Joel

On 8/3/2020 2:30 PM, Robert Raszuk wrote:
> Joel,
> 
> Are we still talking about IP networks here ? Or perhaps some hard 
> slicing with real resource reservations or detnets ?
> 
> apply IP encapsulation to that node. I don't think IP encapsulation can 
> be hijacked today such that destination address of the packet is ignored.
> 
> failure) you suddenly start dropping flows in spite of SPT offering 
> perhaps few ms longer path with 10 ms more jitter ?
> 
> something new ? Worse ... do they mention path quality guarantees, 
> resource reservations ? I hope not.
> 
> Thx,
> R.
> 
> 
> 
> 
> 
> 
> 
> 
> 
> On Mon, Aug 3, 2020 at 8:10 PM Joel M. Halpern <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
>      > If not, providing an ability to identify such SIDs in the
>     advertisement
>      > mechanisms would be useful IMHO.
>      >
>      > My 2c,
>      >
>      > Sasha
>      >
>      > Office: +972-39266302
>      >
>      > Cell:      +972-549266302
>      >
>     <mailto:[email-masked]>
>      >
>      > From: spring <[email-masked]
>     <mailto:[email-masked]>> On Behalf Of Mach Chen
>      > To: Joel M. Halpern <[email-masked]
>     <mailto:[email-masked]>>; [email-masked] <mailto:[email-masked]>
>      >  > -----Original Message-----
>      >
>      >  > From: spring [mailto:[email-masked]
>     <mailto:[email-masked]>] On Behalf Of Joel M.
>      >
>      >  > Halpern
>      >
>      >  > Sent: Monday, August 3, 2020 7:51 AM
>      >
>      >  > To: [email-masked] <mailto:[email-masked]>
>     <mailto:[email-masked] <mailto:[email-masked]>>
>      >
>      >  > Subject: [spring] Spring protection - determining applicability
>      >
>      >  >
>      >
>      >  > (WG Chair hat Off, this is merely a note from a slightly
>     confused WG
>      >
>      >  > participant.)
>      >
>      >  >
>      >
>      >  > I have been reading the various repair drafts, and the various
>      >
>      >  > networks programming and service programming draft, and I am
>     trying to
>      >
>      >  > figure out one aspect of the combination.
>      >
>      >  >
>      >
>      >  > How does a node that is doing some form of bypass (suppose, for
>      >
>      >  > simplicity, it is Node N2 deciding to bypass the next SID for
>     a failed
>      >
>      >  > node N3) know that it is safe to do so?
>      >
>      >  >
>      >
>      >  > If the path was just for TE, then it is "safe" if the new path
>     meets
>      >
>      >  > the TE criteria.  or maybe it is safe if it is even close, as
>     long as
>      >
>      >  > it is not used for too long.
>      >
>      >  >
>      >
>      >  > But what if the node were a Firewall, included to meet legal
>      > requirements?
>      >
>      >  > Or was some other necessary programmatic transform (wince we are
>      >
>      >  > deliberately vague about what nodes can do when asked suitably.)
>      >
>      >  >
>      >
>      >  > Is there some "can be bypassed" indication in the routing
>      >
>      >  > advertisements that I missed?
>      >
>      >  >
>      >
>      >  > Thank you,
>      >
>      >  > Yours,
>      >
>      >  > Joel
>      >
>      >  >
>      >
>      >  > _______________________________________________
>      >
>      >  > spring mailing list
>      >
>      >  > [email-masked] <mailto:[email-masked]>
>     <mailto:[email-masked] <mailto:[email-masked]>>
>      >
>      >  >
>      >
>      >  > F%2Fwww.ietf.org
>     <http://2Fwww.ietf.org>%2Fmailman%2Flistinfo%2Fspring
>      >
>      > [email-masked] <mailto:[email-masked]> <mailto:[email-masked]
>     <mailto:[email-masked]>>
>      >
>      >

---

From: Andrew Alston <[email-masked]>
Date: Mon, 3 Aug 2020 21:46:05 +0000

So –

One of the use cases, in fact, some very major use cases in any spring technology for us revolve around the following

  1.  The explicit avoidance of certain nodes
  2.  The explicit avoidance of certain sections of the network

Anything that could result in that explicit avoidance being violated – would create, shall we say significant problems.

Much of the use case is not a case of which nodes the packets flow through – but rather – which nodes / network segments it can never touch or flow through.  Effectively, to be used as a technology to avoid certain things for specific reasons.

This is also one of the reasons for needing such deep label stacks – this kind of detailed path programming tends to deepen the stack because you sometimes have to be pretty explicit.

It is absolutely critical to us that this functionality is there – and that we can avoid situations which could cause traffic to accidently hit things explicitly avoided.

I wish I could be more specific than this, but it is what it is.

Thanks

Andrew

From: spring <[email-masked]> On Behalf Of Joel M. Halpern
Sent: Monday, 3 August 2020 21:36
To: Robert Raszuk <[email-masked]>
Cc: [email-masked]
Subject: Re: [spring] Spring protection - determining applicability

Yours,
Joel

<mailto:[email-masked]%20%0b>> <mailto:[email-masked]>> wrote:
> <https://datatracker.ietf.org/doc/html/draft-ietf-bess-srv6-services-04<https://datatracker.ietf.org/doc/html/draft-ietf-bess-srv6-services-04>>
>
> > <https://tools.ietf.org/html/rfc8402<https://tools.ietf.org/html/rfc8402>> that says in Section 1:
> >
> <https://datatracker.ietf.org/doc/html/draft-hegde-spring-node-protection-for-sr-te-paths-07#section-3.4<https://datatracker.ietf.org/doc/html/draft-hegde-spring-node-protection-for-sr-te-paths-07#section-3.4>>
>
> > draft that says:
> >
> >     [RFC8679 <https://datatracker.ietf.org/doc/html/rfc8679<https://datatracker.ietf.org/doc/html/rfc8679>>] is
> > Email: [email-masked]<mailto:[email-masked]>
<mailto:[email-masked]%0b>> <mailto:[email-masked]>> On Behalf Of Mach Chen
> > To: Joel M. Halpern <[email-masked]
<mailto:[email-masked]%0b>> <mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]> <mailto:[email-masked]>
> >  > From: spring [mailto:[email-masked]
> <mailto:[email-masked]><mailto:[email-masked]%0b%3e%20%3cmailto:[email-masked]%3e>] On Behalf Of Joel M.
> >
> >  > Halpern
> >
> >  > To: [email-masked]<mailto:[email-masked]> <mailto:[email-masked]>
> <mailto:[email-masked] <mailto:[email-masked]<mailto:[email-masked]%20%3cmailto:[email-masked]>>>
> >
> >  > [email-masked]<mailto:[email-masked]> <mailto:[email-masked]>
> <mailto:[email-masked] <mailto:[email-masked]<mailto:[email-masked]%20%3cmailto:[email-masked]>>>
> >
> >  >
> >
> https://clicktime.symantec.com/367qhU4KiUkzW9uGC4eAvP46H2?u=https%3A%2<https://clicktime.symantec.com/367qhU4KiUkzW9uGC4eAvP46H2?u=https%3A%2>
> >
> <https://clicktime.symantec.com/367qhU4KiUkzW9uGC4eAvP46H2?u=https%3A%252<https://clicktime.symantec.com/367qhU4KiUkzW9uGC4eAvP46H2?u=https%3A%252>>
> >
> >  > F%2Fwww.ietf.org
> <http://2Fwww.ietf.org<http://2Fwww.ietf.org>>%2Fmailman%2Flistinfo%2Fspring
> >
> > [email-masked]<mailto:[email-masked]> <mailto:[email-masked]> <mailto:[email-masked]
<mailto:[email-masked]%0b>> <mailto:[email-masked]>>
> >
> >
> https://clicktime.symantec.com/367qhU4KiUkzW9uGC4eAvP46H2?u=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring<https://clicktime.symantec.com/367qhU4KiUkzW9uGC4eAvP46H2?u=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring>
> >
> >
> >
> >
> > [email-masked]<mailto:[email-masked]> <mailto:[email-masked]>
> > https://www.ietf.org/mailman/listinfo/spring<https://www.ietf.org/mailman/listinfo/spring>
> >
>
> [email-masked]<mailto:[email-masked]> <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/spring<https://www.ietf.org/mailman/listinfo/spring>
>

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

---

From: "UTTARO, JAMES" <[email-masked]>
Date: Mon, 3 Aug 2020 22:02:56 +0000

+1

Thanks,
              Jim Uttaro

From: spring <[email-masked]> On Behalf Of Andrew Alston
Sent: Monday, August 03, 2020 5:46 PM
To: Joel M. Halpern <[email-masked]>; Robert Raszuk <[email-masked]>
Cc: [email-masked]
Subject: Re: [spring] Spring protection - determining applicability

So –

Thanks

Andrew

From: spring <[email-masked]<mailto:[email-masked]>> On Behalf Of Joel M. Halpern
Sent: Monday, 3 August 2020 21:36
To: Robert Raszuk <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [spring] Spring protection - determining applicability

Yours,
Joel

<mailto:[email-masked]%20%0b>> <mailto:[email-masked]>> wrote:
> <https://datatracker.ietf.org/doc/html/draft-ietf-bess-srv6-services-04<https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_html_draft-2Dietf-2Dbess-2Dsrv6-2Dservices-2D04&d=DwMGaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=s7ZzB4JbPv3nYuoSx5Gy8Q&m=FomLBuMUcVQf2q2rohFCbxSojq0YIeDz0csnBF1lA9M&s=N98B9wvs_qQxGN_Q-bpcGGB0u8sLexqPgNDLIMjlxk0&e=>>
>
> > <https://tools.ietf.org/html/rfc8402<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc8402&d=DwMGaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=s7ZzB4JbPv3nYuoSx5Gy8Q&m=FomLBuMUcVQf2q2rohFCbxSojq0YIeDz0csnBF1lA9M&s=79-VYyiQvpcVMNSFXBRpJQPj7R2BjRWyIx7NrCGr35c&e=>> that says in Section 1:
> >
> <https://datatracker.ietf.org/doc/html/draft-hegde-spring-node-protection-for-sr-te-paths-07#section-3.4<https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_html_draft-2Dhegde-2Dspring-2Dnode-2Dprotection-2Dfor-2Dsr-2Dte-2Dpaths-2D07-23section-2D3.4&d=DwMGaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=s7ZzB4JbPv3nYuoSx5Gy8Q&m=FomLBuMUcVQf2q2rohFCbxSojq0YIeDz0csnBF1lA9M&s=VUUvbTclKPAzwCaBj_rAEf03_JaXr8J9zEd8OCuiTDs&e=>>
>
> > draft that says:
> >
> >     [RFC8679 <https://datatracker.ietf.org/doc/html/rfc8679<https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_html_rfc8679&d=DwMGaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=s7ZzB4JbPv3nYuoSx5Gy8Q&m=FomLBuMUcVQf2q2rohFCbxSojq0YIeDz0csnBF1lA9M&s=mFqmr1UKGtI-EBZZRZfguXQNDppAZQ9mJPtBOXPPorI&e=>>] is
> https://clicktime.symantec.com/367qhU4KiUkzW9uGC4eAvP46H2?u=https%3A%2<https://urldefense.proofpoint.com/v2/url?u=https-3A__clicktime.symantec.com_367qhU4KiUkzW9uGC4eAvP46H2-3Fu-3Dhttps-253A-252&d=DwMGaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=s7ZzB4JbPv3nYuoSx5Gy8Q&m=FomLBuMUcVQf2q2rohFCbxSojq0YIeDz0csnBF1lA9M&s=7IRodulxqHYvyvKEKSXxlYFke_6uo7BxVbcX9klc758&e=>
> >
> <https://clicktime.symantec.com/367qhU4KiUkzW9uGC4eAvP46H2?u=https%3A%252<https://urldefense.proofpoint.com/v2/url?u=https-3A__clicktime.symantec.com_367qhU4KiUkzW9uGC4eAvP46H2-3Fu-3Dhttps-253A-25252&d=DwMGaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=s7ZzB4JbPv3nYuoSx5Gy8Q&m=FomLBuMUcVQf2q2rohFCbxSojq0YIeDz0csnBF1lA9M&s=H0fBjPTlyrSxz_hDIuF7zq8xTF_HjxQK1H-y20RKkhU&e=>>
> >
> >  > F%2Fwww.ietf.org<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.ietf.org&d=DwQGaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=s7ZzB4JbPv3nYuoSx5Gy8Q&m=FomLBuMUcVQf2q2rohFCbxSojq0YIeDz0csnBF1lA9M&s=4x-ss-H5UtriDZJLWPBF08uCkri_HwjIOnyoRgcrucs&e=>
> <http://2Fwww.ietf.org<https://urldefense.proofpoint.com/v2/url?u=http-3A__2Fwww.ietf.org&d=DwMGaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=s7ZzB4JbPv3nYuoSx5Gy8Q&m=FomLBuMUcVQf2q2rohFCbxSojq0YIeDz0csnBF1lA9M&s=KCne45tIqQvf61H-HCmuOr1kk9MMwTWr7SiyUlYXeBM&e=>>%2Fmailman%2Flistinfo%2Fspring
> >
> >
> >
> https://clicktime.symantec.com/367qhU4KiUkzW9uGC4eAvP46H2?u=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring<https://urldefense.proofpoint.com/v2/url?u=https-3A__clicktime.symantec.com_367qhU4KiUkzW9uGC4eAvP46H2-3Fu-3Dhttps-253A-252F-252Fwww.ietf.org-252Fmailman-252Flistinfo-252Fspring&d=DwMGaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=s7ZzB4JbPv3nYuoSx5Gy8Q&m=FomLBuMUcVQf2q2rohFCbxSojq0YIeDz0csnBF1lA9M&s=BqEEcOfh6Ag93yzT7ucn8g_Xs_7R8EkG4ER0qNryr5M&e=>
> >
> >
> >
> >
> > https://www.ietf.org/mailman/listinfo/spring<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_spring&d=DwMGaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=s7ZzB4JbPv3nYuoSx5Gy8Q&m=FomLBuMUcVQf2q2rohFCbxSojq0YIeDz0csnBF1lA9M&s=bPm_wPefURZbSV_gpVFiDvNjfVIYSbHtx4SRFYAH3ig&e=>
> >
>
> https://www.ietf.org/mailman/listinfo/spring<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_spring&d=DwMGaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=s7ZzB4JbPv3nYuoSx5Gy8Q&m=FomLBuMUcVQf2q2rohFCbxSojq0YIeDz0csnBF1lA9M&s=bPm_wPefURZbSV_gpVFiDvNjfVIYSbHtx4SRFYAH3ig&e=>
>

_______________________________________________
spring mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/spring<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_spring&d=DwMGaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=s7ZzB4JbPv3nYuoSx5Gy8Q&m=FomLBuMUcVQf2q2rohFCbxSojq0YIeDz0csnBF1lA9M&s=bPm_wPefURZbSV_gpVFiDvNjfVIYSbHtx4SRFYAH3ig&e=>

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 4 Aug 2020 00:26:39 +0200

Is this a common use case ie.  "but rather – which nodes / network segments
it can never touch or flow through."

If so perhaps its time to define notion of *negative-SID* ie. list in the
packet resources which given packet MUST not ever traverse.

Put in the packet set of nodes or links which the packet should never
traverse.

That goes in line of recent wave of negative routing implementations (RIFT)
or discussions (LSR)

Best,
R.

On Mon, Aug 3, 2020 at 11:46 PM Andrew Alston <
[email-masked]> wrote:

> So –
>
>
>
> One of the use cases, in fact, some very major use cases in any spring
> technology for us revolve around the following
>
>
>
> Anything that could result in that explicit avoidance being violated –
> would create, shall we say significant problems.
>
>
>
> Much of the use case is not a case of which nodes the packets flow through
> – but rather – which nodes / network segments it can never touch or flow
> through.  Effectively, to be used as a technology to avoid certain things
> for specific reasons.
>
>
>
> This is also one of the reasons for needing such deep label stacks – this
> kind of detailed path programming tends to deepen the stack because you
> sometimes have to be pretty explicit.
>
>
>
> It is absolutely critical to us that this functionality is there – and
> that we can avoid situations which could cause traffic to accidently hit
> things explicitly avoided.
>
>
>
> *From:* spring <[email-masked]> *On Behalf Of *Joel M. Halpern
> *Sent:* Monday, 3 August 2020 21:36
> *To:* Robert Raszuk <[email-masked]>
> *Cc:* [email-masked]
> *Subject:* Re: [spring] Spring protection - determining applicability
>
>
>
> <[email-masked]%20%0b>> <mailto:[email-masked]
> <[email-masked]>>> wrote:
> >
> https://datatracker.ietf.org/doc/html/draft-hegde-spring-node-protection-for-sr-te-paths-07#section-3.4
> >
> >
> > > draft that says:
> > >
> > <mailto:[email-masked]
> <[email-masked]>>
> > >
> <[email-masked]%0b>> <mailto:[email-masked]
> <[email-masked]>>> On Behalf Of Mach Chen
> <[email-masked]%0b>> <mailto:[email-masked]
> <[email-masked]>>>; [email-masked] <mailto:[email-masked]
> <[email-masked]>>
> > <mailto:[email-masked]>
> <[email-masked]%0b%3e%20%3cmailto:[email-masked]%3e>]
> On Behalf Of Joel M.
> > >
> > >  > Halpern
> > >
> > >  > To: [email-masked] <mailto:[email-masked] <[email-masked]>>
> > <mailto:[email-masked] <mailto:[email-masked]
> <[email-masked]%20%3cmailto:[email-masked]>>>
> > >
> > >  > [email-masked] <mailto:[email-masked] <[email-masked]>>
> > <mailto:[email-masked] <mailto:[email-masked]
> <[email-masked]%20%3cmailto:[email-masked]>>>
> > >
> > >  >
> > >
> > > [email-masked] <mailto:[email-masked] <[email-masked]>> <
> mailto:[email-masked]
> <[email-masked]%0b>> <mailto:[email-masked] <[email-masked]>>>
> > >
> > >
> >
> > > [email-masked] <mailto:[email-masked] <[email-masked]>>
> > [email-masked] <mailto:[email-masked] <[email-masked]>>

---

From: Greg Mirsky <[email-masked]>
Date: Mon, 3 Aug 2020 15:39:59 -0700

Hi Andrew,
would such requirements support using e2e protection?

Regards,
Greg

---

From: Andrew Alston <[email-masked]>
Date: Tue, 4 Aug 2020 00:05:30 +0000

Greg we effectively get this using sbfd and fall back paths at the moment – far from ideal – but it does work.

There are also other methods of detecting end to end reachability to do blackhole detection etc – particularly in the face of the fact that I’ve yet to see a functional implication of the sid verification flag.

Could things be improved this regard? 100% but for now – the deep seated and critical need for the requirement overrides the drawbacks of the protection mechanisms we are forced to use at this point

Andrew

From: Greg Mirsky <[email-masked]>
Sent: Tuesday, 4 August 2020 01:40
To: Andrew Alston <[email-masked]>
Cc: Joel M. Halpern <[email-masked]>; Robert Raszuk <[email-masked]>; [email-masked]
Subject: Re: [spring] Spring protection - determining applicability

Hi Andrew,

Regards,
Greg

On Mon, Aug 3, 2020 at 2:46 PM Andrew Alston <[email-masked]<mailto:[email-masked]>> wrote:
So –

a.      The explicit avoidance of certain nodes

b.      The explicit avoidance of certain sections of the network

Thanks

Andrew

Yours,
Joel

> >  > F%2Fwww.ietf.org<http://2Fwww.ietf.org>

---

From: Andrew Alston <[email-masked]>
Date: Tue, 4 Aug 2020 00:10:59 +0000

Robert this is actually far more difficult when – it can be an entire (long) series of nodes that need to be avoided.

It could potentially be made to work but I’d worry that to do this – you’d have to stack 10 – 20 – 30 negative labels – and that wouldn’t be viable.

It’s easier to use algorithms and adjacency sids and other such things to calculate paths – the biggest trick is about the stack depth.  When you have this need for node avoidance – the need for 10+ label depth is critical – unless you wanna be applying one hell of a lot of binding labels along the way which is a nightmare.

But to answer your question, is this a common use case – it’s a use case that most of the people I discuss this with certain have – I cant  comment on a global scale, or for anyone else, but every indication I have is that yes – its something people need, and want

Andrew

From: Robert Raszuk <[email-masked]>
Sent: Tuesday, 4 August 2020 01:27
To: Andrew Alston <[email-masked]>
Cc: Joel M. Halpern <[email-masked]>; [email-masked]
Subject: Re: [spring] Spring protection - determining applicability

Is this a common use case ie.  "but rather – which nodes / network segments it can never touch or flow through."

If so perhaps its time to define notion of negative-SID ie. list in the packet resources which given packet MUST not ever traverse.

Put in the packet set of nodes or links which the packet should never traverse.

That goes in line of recent wave of negative routing implementations (RIFT) or discussions (LSR)

Best,
R.

On Mon, Aug 3, 2020 at 11:46 PM Andrew Alston <[email-masked]<mailto:[email-masked]>> wrote:
So –

Thanks

Andrew

Yours,
Joel

---

From: Greg Mirsky <[email-masked]>
Date: Mon, 3 Aug 2020 17:18:26 -0700

Hi Andrew,
thank you for your expedient response. I understand why operators are using
S-BFD to monitor the continuity of p2p SR-MPLS tunnel. But I'd note that
S-BFD does not support monitoring of multicast trees, ones that now can be
realized using the Replication SID defined in
draft-voyer-spring-sr-replication-segment
<https://tools.ietf.org/html/draft-voyer-spring-sr-replication-segment-02>.
But that can be achieved using RFC 8563
<https://tools.ietf.org/html/rfc8563>. Multicast and Composite polling
methods might not provide the required defect detection by the head of the
multicast tree. There's a faster option mentioned in RFC 8563, Unsolicited
notification. Applicability of the Unsolicited mode to SR-MPLS is described
in draft-mirsky-spring-bfd
<https://datatracker.ietf.org/doc/draft-mirsky-spring-bfd/?include_text=1>.

Regards,
Greg

On Mon, Aug 3, 2020 at 5:05 PM Andrew Alston <
[email-masked]> wrote:

> There are also other methods of detecting end to end reachability to do
> blackhole detection etc – particularly in the face of the fact that I’ve
> yet to see a functional implication of the sid verification flag.
>
>
>
> Could things be improved this regard? 100% but for now – the deep seated
> and critical need for the requirement overrides the drawbacks of the
> protection mechanisms we are forced to use at this point
>
>
>
> Andrew
>
>
>
>
>
> *From:* Greg Mirsky <[email-masked]>
> *Sent:* Tuesday, 4 August 2020 01:40
> *To:* Andrew Alston <[email-masked]>
> *Cc:* Joel M. Halpern <[email-masked]>; Robert Raszuk <
> [email-masked]>; [email-masked]

---

From: Andrew Alston <[email-masked]>
Date: Tue, 4 Aug 2020 00:23:34 +0000

Have to confess,

We’ve had no need what so ever to consider that in our use case planning – and don’t see one in the near future.  Not something we’re concerned about – which doesn’t diminish the fact that others may be and there may well be a case to be made here, just – kinda out of scope of what we’ve looked at due to our rather urgent needs to first meet our current critical requirements.  This is one of the reasons why I have said that irrespective of what occurs within the IETF as regards CRH – we’re going ahead – the need for deep label stack and the need for running production ready code is of an urgency that no longer allows us to wait for months – thankfully we get what we need as a result of CRH and it does work – and work well

Thanks

Andrew

Sent: Tuesday, 4 August 2020 03:18

Hi Andrew,
thank you for your expedient response. I understand why operators are using S-BFD to monitor the continuity of p2p SR-MPLS tunnel. But I'd note that S-BFD does not support monitoring of multicast trees, ones that now can be realized using the Replication SID defined in draft-voyer-spring-sr-replication-segment<https://tools.ietf.org/html/draft-voyer-spring-sr-replication-segment-02>. But that can be achieved using RFC 8563<https://tools.ietf.org/html/rfc8563>. Multicast and Composite polling methods might not provide the required defect detection by the head of the multicast tree. There's a faster option mentioned in RFC 8563, Unsolicited notification. Applicability of the Unsolicited mode to SR-MPLS is described in draft-mirsky-spring-bfd<https://datatracker.ietf.org/doc/draft-mirsky-spring-bfd/?include_text=1>.

Regards,
Greg

On Mon, Aug 3, 2020 at 5:05 PM Andrew Alston <[email-masked]<mailto:[email-masked]>> wrote:
Greg we effectively get this using sbfd and fall back paths at the moment – far from ideal – but it does work.

Andrew

From: Greg Mirsky <[email-masked]<mailto:[email-masked]>>
Sent: Tuesday, 4 August 2020 01:40
To: Andrew Alston <[email-masked]<mailto:[email-masked]>>
Cc: Joel M. Halpern <[email-masked]<mailto:[email-masked]>>; Robert Raszuk <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [spring] Spring protection - determining applicability

Hi Andrew,

Regards,
Greg

Thanks

Andrew

Yours,
Joel

---

From: "[email-masked]" <[email-masked]>
Date: Tue, 4 Aug 2020 12:14:09 +0800

Hi Joel and All,

I think TE path should be coupled with end to end protection. It is not prudent to allow node or link protection in a TE path since the local protection may not satisfy the SLA requirements or the path constrains. In fact the node en-route except the headend and the controller has no idea about the SLA requirements and the path constrains. TE path only can be reoptimized or rebuilt end to end by the headend or the controller if you want your SLA requirements and path contrains be satisfied. 

In my opinion, it is more appropriate to use local protection in IP fowarding scenarios rather than TE or policy paths.

Best Regards,
Zhenqiang Li

[email-masked]
 
From: Joel M. Halpern
Date: 2020-08-04 02:35
To: Robert Raszuk
CC: [email-masked]

 
Yours,
Joel

---

From: Shraddha Hegde <[email-masked]>
Date: Tue, 4 Aug 2020 06:40:39 +0000

All,

This is a very interesting discussion and thanks to Joel for starting this discussion. IMO, when there are strict requirements of avoiding certain nodes/links it can be realized  either by defining a flex-algo avoiding those
Nodes and links or by using a stack of unprotected adj-sids that avoid restricted nodes and links. When a stack of adj-sids is used to realize the path, the head-end based (sBFD) protection mechanisms can be applied.

If Node-sids/prefix-sid/anycast-sids are used to build the stack, the failure events may cause traffic to go through restricted nodes and links. This would happen regardless of whether any kind of protection is in use or not.

Rgds
Shraddha

Juniper Business Use Only
From: spring <[email-masked]> On Behalf Of Andrew Alston
Sent: Tuesday, August 4, 2020 5:41 AM
To: Robert Raszuk <[email-masked]>
Cc: [email-masked]; Joel M. Halpern <[email-masked]>
Subject: Re: [spring] Spring protection - determining applicability

[External Email. Be cautious of content]

Robert this is actually far more difficult when - it can be an entire (long) series of nodes that need to be avoided.

It could potentially be made to work but I'd worry that to do this - you'd have to stack 10 - 20 - 30 negative labels - and that wouldn't be viable.

It's easier to use algorithms and adjacency sids and other such things to calculate paths - the biggest trick is about the stack depth.  When you have this need for node avoidance - the need for 10+ label depth is critical - unless you wanna be applying one hell of a lot of binding labels along the way which is a nightmare.

But to answer your question, is this a common use case - it's a use case that most of the people I discuss this with certain have - I cant  comment on a global scale, or for anyone else, but every indication I have is that yes - its something people need, and want

Andrew

From: Robert Raszuk <[email-masked]<mailto:[email-masked]>>
Sent: Tuesday, 4 August 2020 01:27
To: Andrew Alston <[email-masked]<mailto:[email-masked]>>
Cc: Joel M. Halpern <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [spring] Spring protection - determining applicability

Is this a common use case ie.  "but rather - which nodes / network segments it can never touch or flow through."

Best,
R.

So -

Anything that could result in that explicit avoidance being violated - would create, shall we say significant problems.

Much of the use case is not a case of which nodes the packets flow through - but rather - which nodes / network segments it can never touch or flow through.  Effectively, to be used as a technology to avoid certain things for specific reasons.

This is also one of the reasons for needing such deep label stacks - this kind of detailed path programming tends to deepen the stack because you sometimes have to be pretty explicit.

It is absolutely critical to us that this functionality is there - and that we can avoid situations which could cause traffic to accidently hit things explicitly avoided.

Thanks

Andrew

Yours,
Joel

<mailto:[email-masked]%20%0b>> <mailto:[email-masked]>> wrote:
> <https://datatracker.ietf.org/doc/html/draft-ietf-bess-srv6-services-04<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-ietf-bess-srv6-services-04__;!!NEt6yMaO-gk!S0Yusx9FYNE8E_R1oiQAtQxgm0x0wxqguoZHgwp6vpRHOGt8AkTRDuiDo4T-L0nl$>>
>
> > draft) unsurprisingly represent "service" instructions
> >
> > <https://tools.ietf.org/html/rfc8402<https://urldefense.com/v3/__https:/tools.ietf.org/html/rfc8402__;!!NEt6yMaO-gk!S0Yusx9FYNE8E_R1oiQAtQxgm0x0wxqguoZHgwp6vpRHOGt8AkTRDuiDo0I4Ybtm$>> that says in Section 1:
> >
> <https://datatracker.ietf.org/doc/html/draft-hegde-spring-node-protection-for-sr-te-paths-07#section-3.4<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-hegde-spring-node-protection-for-sr-te-paths-07*section-3.4__;Iw!!NEt6yMaO-gk!S0Yusx9FYNE8E_R1oiQAtQxgm0x0wxqguoZHgwp6vpRHOGt8AkTRDuiDo9wO-Ssn$>>
>
> > draft that says:
> >
> >     [RFC8679 <https://datatracker.ietf.org/doc/html/rfc8679<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/rfc8679__;!!NEt6yMaO-gk!S0Yusx9FYNE8E_R1oiQAtQxgm0x0wxqguoZHgwp6vpRHOGt8AkTRDuiDo8MGipXc$>>] is
> > The scenarios in which  differentiation between "topological" and
> > "service" instructions is broken are indeed problematic. E.g.,
> consider
> > I am not sure if usage of such "combined" SIDs could be prevented
> or at
> > least discouraged.
> >
> https://clicktime.symantec.com/367qhU4KiUkzW9uGC4eAvP46H2?u=https%3A%2<https://urldefense.com/v3/__https:/clicktime.symantec.com/367qhU4KiUkzW9uGC4eAvP46H2?u=https*3A*2__;JSU!!NEt6yMaO-gk!S0Yusx9FYNE8E_R1oiQAtQxgm0x0wxqguoZHgwp6vpRHOGt8AkTRDuiDo6HwPLil$>
> >
> <https://clicktime.symantec.com/367qhU4KiUkzW9uGC4eAvP46H2?u=https%3A%252<https://urldefense.com/v3/__https:/clicktime.symantec.com/367qhU4KiUkzW9uGC4eAvP46H2?u=https*3A*252__;JSU!!NEt6yMaO-gk!S0Yusx9FYNE8E_R1oiQAtQxgm0x0wxqguoZHgwp6vpRHOGt8AkTRDuiDozoQiAHk$>>
> >
> >  > F%2Fwww.ietf.org<https://urldefense.com/v3/__http:/2Fwww.ietf.org__;!!NEt6yMaO-gk!S0Yusx9FYNE8E_R1oiQAtQxgm0x0wxqguoZHgwp6vpRHOGt8AkTRDuiDo-pPCjvR$>
> <http://2Fwww.ietf.org<https://urldefense.com/v3/__http:/2Fwww.ietf.org__;!!NEt6yMaO-gk!S0Yusx9FYNE8E_R1oiQAtQxgm0x0wxqguoZHgwp6vpRHOGt8AkTRDuiDo-pPCjvR$>>%2Fmailman%2Flistinfo%2Fspring
> >
> >
> >
> https://clicktime.symantec.com/367qhU4KiUkzW9uGC4eAvP46H2?u=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring<https://urldefense.com/v3/__https:/clicktime.symantec.com/367qhU4KiUkzW9uGC4eAvP46H2?u=https*3A*2F*2Fwww.ietf.org*2Fmailman*2Flistinfo*2Fspring__;JSUlJSUl!!NEt6yMaO-gk!S0Yusx9FYNE8E_R1oiQAtQxgm0x0wxqguoZHgwp6vpRHOGt8AkTRDuiDo-hR3gAD$>
> >
> >
> >
> >
> > https://www.ietf.org/mailman/listinfo/spring<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/spring__;!!NEt6yMaO-gk!S0Yusx9FYNE8E_R1oiQAtQxgm0x0wxqguoZHgwp6vpRHOGt8AkTRDuiDo5KlPnbj$>
> >
>
> https://www.ietf.org/mailman/listinfo/spring<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/spring__;!!NEt6yMaO-gk!S0Yusx9FYNE8E_R1oiQAtQxgm0x0wxqguoZHgwp6vpRHOGt8AkTRDuiDo5KlPnbj$>
>

_______________________________________________
spring mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/spring<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/spring__;!!NEt6yMaO-gk!S0Yusx9FYNE8E_R1oiQAtQxgm0x0wxqguoZHgwp6vpRHOGt8AkTRDuiDo5KlPnbj$>

---

From: "Dongjie (Jimmy)" <[email-masked]>
Date: Tue, 4 Aug 2020 06:50:36 +0000

Hi all,

In my understanding, the objective and constraint with SR explicit path (aka. TE) and SR loose path may be different.

As Zhenqiang mentioned, an SR-TE path with a list of adj/End.X SIDs reflects the policy of the controller or the headend node, which may imply that a backup path that can meet the same policy usually is also provided by the controller or headend node. While depends on the policy, local protection may still be helpful.

If an SR path is built with one or a list of prefix-SIDs, the prefix/End SIDs are used to represent some policy/constraints which can be understood by both the controller, the headend, and at least some intermediate nodes, thus it is possible an intermediate node can provide a local protection which still meet the policy/constraints.

Best regards,
Jie

From: spring [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Tuesday, August 4, 2020 12:14 PM
To: Joel M. Halpern <[email-masked]>; Robert Raszuk <[email-masked]>
Cc: [email-masked]
Subject: Re: [spring] Spring protection - determining applicability

Hi Joel and All,

Best Regards,
Zhenqiang Li
________________________________
[email-masked]<mailto:[email-masked]>

From: Joel M. Halpern<mailto:[email-masked]>
Date: 2020-08-04 02:35
To: Robert Raszuk<mailto:[email-masked]>
CC: [email-masked]<mailto:[email-masked]>
Subject: Re: [spring] Spring protection - determining applicability
(Since the thread has gotten long enough, reiterating that this is as a
participant, not a WG chair.)

have this tool (protective rerouting) that is intended to preserve QoS..

Yours,
Joel

On 8/3/2020 2:30 PM, Robert Raszuk wrote:
>     <mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]> <mailto:[email-masked]>

---

From: Alexander Vainshtein <[email-masked]>
Date: Tue, 4 Aug 2020 07:54:48 +0000

Hi all,
I am still not sure that the problem of bypass going thru undesirable links/nodes exists in the case of topological SIDs.

AFAIK, Facility Protection in RSVP-TE FRR (RFC 4090<https://tools.ietf.org/html/rfc4090>) has been successfully deployed for many years before SR-MPLS has been introduced. What's more, signaling of bypass tunnels he PLR usually did not include any of the constraints used for computing of any specific LSP that the bypass LSP would protect - because in the Facility Protection mode the same bypass LSP would be used to protect multiple LSPs passing thru the failed link/node.

>From my POV the only difference between this behavior and that introduced by the "bypassing" drafts in SR is that, in the case of RSVP-TE, the operator would explicitly indicate, as part of LSP signaling, whether it would or would not use FRR; LSPs that would not use FRR would then drop traffic rather than delivering it the wrong way.

Such an option indeed does not exist in SR-TE today, but would be easy to provide if so desired IMHO.

Did I miss something substantial?

Regards, and lots of thanks in advance,
Sasha

Office: +972-39266302
Cell:      +972-549266302

From: spring <[email-masked]> On Behalf Of Shraddha Hegde
Sent: Tuesday, August 4, 2020 9:41 AM
To: [email-masked] <[email-masked]>; Robert Raszuk <[email-masked]>
Cc: [email-masked]; Joel M. Halpern <[email-masked]>
Subject: Re: [spring] Spring protection - determining applicability

All,

Rgds
Shraddha

Juniper Business Use Only
From: spring <[email-masked]<mailto:[email-masked]>> On Behalf Of Andrew Alston
Sent: Tuesday, August 4, 2020 5:41 AM
To: Robert Raszuk <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; Joel M. Halpern <[email-masked]<mailto:[email-masked]>>
Subject: Re: [spring] Spring protection - determining applicability

Andrew

Best,
R.

Thanks

Andrew

Cc: spring@ietf..org<mailto:[email-masked]>

Yours,
Joel

<mailto:[email-masked]%20%0b>> <mailto:[email-masked]>> wrote:
> <https://datatracker.ietf.org/doc/html/draft-ietf-bess-srv6-services-04<https://clicktime.symantec.com/3GC5af2z3JzphZDkPncHAQi6H2?u=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-bess-srv6-services-04__%3B%21%21NEt6yMaO-gk%21S0Yusx9FYNE8E_R1oiQAtQxgm0x0wxqguoZHgwp6vpRHOGt8AkTRDuiDo4T-L0nl%24>>
>
> > <https://tools.ietf.org/html/rfc8402<https://clicktime.symantec.com/37PzUKAD82cjSvmVcGvpkhF6H2?u=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Ftools.ietf.org%2Fhtml%2Frfc8402__%3B%21%21NEt6yMaO-gk%21S0Yusx9FYNE8E_R1oiQAtQxgm0x0wxqguoZHgwp6vpRHOGt8AkTRDuiDo0I4Ybtm%24>> that says in Section 1:
> >
> <https://datatracker.ietf.org/doc/html/draft-hegde-spring-node-protection-for-sr-te-paths-07#section-3.4<https://clicktime.symantec.com/3CrUgARW8somAbw6TisjgJ16H2?u=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-hegde-spring-node-protection-for-sr-te-paths-07%2Asection-3.4__%3BIw%21%21NEt6yMaO-gk%21S0Yusx9FYNE8E_R1oiQAtQxgm0x0wxqguoZHgwp6vpRHOGt8AkTRDuiDo9wO-Ssn%24>>
>
> > draft that says:
> >
> >     [RFC8679 <https://datatracker.ietf.org/doc/html/rfc8679<https://clicktime.symantec.com/36dMAjuYTQovo8jHwmm3eJw6H2?u=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Frfc8679__%3B%21%21NEt6yMaO-gk%21S0Yusx9FYNE8E_R1oiQAtQxgm0x0wxqguoZHgwp6vpRHOGt8AkTRDuiDo8MGipXc%24>>] is
> https://clicktime.symantec.com/367qhU4KiUkzW9uGC4eAvP46H2?u=https%3A%2<https://clicktime.symantec.com/3Q7vX2qWSUdWVc892XuXy2H6H2?u=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Fclicktime.symantec.com%2F367qhU4KiUkzW9uGC4eAvP46H2%3Fu%3Dhttps%2A3A%2A2__%3BJSU%21%21NEt6yMaO-gk%21S0Yusx9FYNE8E_R1oiQAtQxgm0x0wxqguoZHgwp6vpRHOGt8AkTRDuiDo6HwPLil%24>
> >
> <https://clicktime.symantec.com/367qhU4KiUkzW9uGC4eAvP46H2?u=https%3A%252<https://clicktime.symantec.com/3A5B8H2Fm1rPnaZ3Supjwr6H2?u=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Fclicktime.symantec.com%2F367qhU4KiUkzW9uGC4eAvP46H2%3Fu%3Dhttps%2A3A%2A252__%3BJSU%21%21NEt6yMaO-gk%21S0Yusx9FYNE8E_R1oiQAtQxgm0x0wxqguoZHgwp6vpRHOGt8AkTRDuiDozoQiAHk%24>>
> >
> >  > F%2Fwww.ietf.org<https://clicktime.symantec.com/39NznmYBtRuHARhGJ5W5dGB6H2?u=https%3A%2F%2Furldefense.com%2Fv3%2F__http%3A%2F2Fwww.ietf.org__%3B%21%21NEt6yMaO-gk%21S0Yusx9FYNE8E_R1oiQAtQxgm0x0wxqguoZHgwp6vpRHOGt8AkTRDuiDo-pPCjvR%24>
> <http://2Fwww.ietf.org<https://clicktime.symantec.com/39NznmYBtRuHARhGJ5W5dGB6H2?u=https%3A%2F%2Furldefense.com%2Fv3%2F__http%3A%2F2Fwww.ietf.org__%3B%21%21NEt6yMaO-gk%21S0Yusx9FYNE8E_R1oiQAtQxgm0x0wxqguoZHgwp6vpRHOGt8AkTRDuiDo-pPCjvR%24>>%2Fmailman%2Flistinfo%2Fspring
> >
> >
> >
> https://clicktime.symantec.com/367qhU4KiUkzW9uGC4eAvP46H2?u=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring<https://clicktime.symantec.com/3BhyEtx4Q7n74BhiRnfMJtT6H2?u=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Fclicktime.symantec.com%2F367qhU4KiUkzW9uGC4eAvP46H2%3Fu%3Dhttps%2A3A%2A2F%2A2Fwww.ietf.org%2A2Fmailman%2A2Flistinfo%2A2Fspring__%3BJSUlJSUl%21%21NEt6yMaO-gk%21S0Yusx9FYNE8E_R1oiQAtQxgm0x0wxqguoZHgwp6vpRHOGt8AkTRDuiDo-hR3gAD%24>
> >
> >
> >
> >
> > https://www.ietf.org/mailman/listinfo/spring<https://clicktime.symantec.com/3NrDnSTReXh671G79BVGEq16H2?u=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring__%3B%21%21NEt6yMaO-gk%21S0Yusx9FYNE8E_R1oiQAtQxgm0x0wxqguoZHgwp6vpRHOGt8AkTRDuiDo5KlPnbj%24>
> >
>
> https://www.ietf.org/mailman/listinfo/spring<https://clicktime.symantec.com/3NrDnSTReXh671G79BVGEq16H2?u=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring__%3B%21%21NEt6yMaO-gk%21S0Yusx9FYNE8E_R1oiQAtQxgm0x0wxqguoZHgwp6vpRHOGt8AkTRDuiDo5KlPnbj%24>
>

_______________________________________________
spring mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/spring<https://clicktime.symantec.com/3NrDnSTReXh671G79BVGEq16H2?u=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring__%3B%21%21NEt6yMaO-gk%21S0Yusx9FYNE8E_R1oiQAtQxgm0x0wxqguoZHgwp6vpRHOGt8AkTRDuiDo5KlPnbj%24>

---

From: Huzhibo <[email-masked]>
Date: Tue, 4 Aug 2020 13:32:36 +0000

Hi Joel and all:

    I think node protected is used when the SLA of a path cannot be quickly repaired. E2E detection cannot be deployed in some scenarios. As a result, the faulty path cannot be repaired at the headend. 
    To prevent SR policy from bypassing Service Sid, if the Per Sid forwarding state is not introduced on other nodes, the advertise Sid Not Bypass Flag is useless. Therefore, extending the Not Bypass Flag in the SRH Flag may be an effective method. The following document is trying to solve such problem.https://datatracker.ietf.org/doc/draft-li-rtgwg-enhanced-ti-lfa/?include_text=1

Thanks

Zhibo

-----Original Message-----
From: spring [mailto:[email-masked]] On Behalf Of Joel M. Halpern
Sent: Monday, August 3, 2020 7:51 AM
To: [email-masked]
Subject: [spring] Spring protection - determining applicability

I have been reading the various repair drafts, and the various networks programming and service programming draft, and I am trying to figure out one aspect of the combination.

How does a node that is doing some form of bypass (suppose, for simplicity, it is Node N2 deciding to bypass the next SID for a failed node N3) know that it is safe to do so?

If the path was just for TE, then it is "safe" if the new path meets the TE criteria.  or maybe it is safe if it is even close, as long as it is not used for too long.

But what if the node were a Firewall, included to meet legal requirements?
Or was some other necessary programmatic transform (wince we are deliberately vague about what nodes can do when asked suitably.)

Is there some "can be bypassed" indication in the routing advertisements that I missed?

Thank you,
Yours,
Joel

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 4 Aug 2020 10:55:14 -0400

There are, as far as I can tell, a number of ways to address this family 
of related questions.
What struck me, and prompted the starting question, was that none of 
them were spelled out.  I see lots of interesting ideas / proposals.
Some of them are compatible with others.   Some are not.
It would be good if we could reach agreement on how we thought it should 
be handled.

Thank you,
Joel

On 8/4/2020 3:54 AM, Alexander Vainshtein wrote:
> Hi all,
> 
> I am still not sure that the problem of bypass going thru undesirable 
> links/nodes exists in the case of topological SIDs.
> 
> AFAIK, Facility Protection in RSVP-TE FRR (RFC 4090 
> <https://tools.ietf.org/html/rfc4090>) has been successfully deployed 
> for many years before SR-MPLS has been introduced. What’s more, 
> signaling of bypass tunnels he PLR usually did not include any of the 
> constraints used for computing of any specific LSP that the bypass LSP 
> would protect – because in the Facility Protection mode the same bypass 
> LSP would be used to protect multiple LSPs passing thru the failed 
> link/node.
> 
>  From my POV the only difference between this behavior and that 
> introduced by the “bypassing” drafts in SR is that, in the case of 
> RSVP-TE, the operator would explicitly indicate, as part of LSP 
> signaling, whether it would or would not use FRR; LSPs that would not 
> use FRR would then drop traffic rather than delivering it the wrong way.
> 
> *From:* spring <[email-masked]> *On Behalf Of *Shraddha Hegde
> *Sent:* Tuesday, August 4, 2020 9:41 AM
> *To:* [email-masked] 
> <[email-masked]>; Robert Raszuk <[email-masked]>
> *Cc:* [email-masked]; Joel M. Halpern <[email-masked]>
> This is a very interesting discussion and thanks to Joel for starting 
> this discussion. IMO, when there are strict requirements of avoiding 
> certain nodes/links it can be realized  either by defining a flex-algo 
> avoiding those
> 
> Nodes and links or by using a stack of unprotected adj-sids that avoid 
> restricted nodes and links. When a stack of adj-sids is used to realize 
> the path, the head-end based (sBFD) protection mechanisms can be applied.
> 
> If Node-sids/prefix-sid/anycast-sids are used to build the stack, the 
> failure events may cause traffic to go through restricted nodes and 
> links. This would happen regardless of whether any kind of protection is 
> in use or not.
> 
> Rgds
> 
> Shraddha
> 
> *From:* spring <[email-masked] 
> <mailto:[email-masked]>> *On Behalf Of *Andrew Alston
> *Sent:* Tuesday, August 4, 2020 5:41 AM
> *To:* Robert Raszuk <[email-masked] <mailto:[email-masked]>>
> *Cc:* [email-masked] <mailto:[email-masked]>; Joel M. Halpern 
> <[email-masked] <mailto:[email-masked]>>
> *[External Email. Be cautious of content]*
> 
> Robert this is actually far more difficult when – it can be an entire 
> (long) series of nodes that need to be avoided.
> 
> It could potentially be made to work but I’d worry that to do this – 
> you’d have to stack 10 – 20 – 30 negative labels – and that wouldn’t be 
> viable.
> 
> It’s easier to use algorithms and adjacency sids and other such things 
> to calculate paths – the biggest trick is about the stack depth.  When 
> you have this need for node avoidance – the need for 10+ label depth is 
> critical – unless you wanna be applying one hell of a lot of binding 
> labels along the way which is a nightmare.
> 
> But to answer your question, is this a common use case – it’s a use case 
> that most of the people I discuss this with certain have – I cant  
> comment on a global scale, or for anyone else, but every indication I 
> have is that yes – its something people need, and want
> 
> Andrew
> 
> *From:* Robert Raszuk <[email-masked] <mailto:[email-masked]>>
> *Sent:* Tuesday, 4 August 2020 01:27
> *To:* Andrew Alston <[email-masked] 
> <mailto:[email-masked]>>
> *Cc:* Joel M. Halpern <[email-masked] 
> Is this a common use case ie.  "but rather – which nodes / network 
> segments it can never touch or flow through."
> 
> If so perhaps its time to define notion of *negative-SID* ie. list in 
> the packet resources which given packet MUST not ever traverse.
> 
> On Mon, Aug 3, 2020 at 11:46 PM Andrew Alston 
> <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
>     So –
> 
>     One of the use cases, in fact, some very major use cases in any
>     spring technology for us revolve around the following
> 
>     a.The explicit avoidance of certain nodes
> 
>     b.The explicit avoidance of certain sections of the network
> 
>     Anything that could result in that explicit avoidance being violated
>     – would create, shall we say significant problems.
> 
>     Much of the use case is not a case of which nodes the packets flow
>     through – but rather – which nodes / network segments it can never
>     touch or flow through.  Effectively, to be used as a technology to
>     avoid certain things for specific reasons.
> 
>     This is also one of the reasons for needing such deep label stacks –
>     this kind of detailed path programming tends to deepen the stack
>     because you sometimes have to be pretty explicit.
> 
>     It is absolutely critical to us that this functionality is there –
>     and that we can avoid situations which could cause traffic to
>     accidently hit things explicitly avoided.
> 
>     *From:* spring <[email-masked]
>     <mailto:[email-masked]>> *On Behalf Of *Joel M. Halpern
>     *To:* Robert Raszuk <[email-masked] <mailto:[email-masked]>>
>     *Cc:* spring@ietf..org <mailto:[email-masked]>
>     <https://datatracker.ietf.org/doc/html/draft-ietf-bess-srv6-services-04
>     <https://clicktime.symantec.com/3GC5af2z3JzphZDkPncHAQi6H2?u=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-bess-srv6-services-04__%3B%21%21NEt6yMaO-gk%21S0Yusx9FYNE8E_R1oiQAtQxgm0x0wxqguoZHgwp6vpRHOGt8AkTRDuiDo4T-L0nl%24>>
>      >
>      > > <https://tools.ietf.org/html/rfc8402
>     <https://clicktime.symantec.com/37PzUKAD82cjSvmVcGvpkhF6H2?u=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Ftools.ietf.org%2Fhtml%2Frfc8402__%3B%21%21NEt6yMaO-gk%21S0Yusx9FYNE8E_R1oiQAtQxgm0x0wxqguoZHgwp6vpRHOGt8AkTRDuiDo0I4Ybtm%24>>
>     that says in Section 1:
>      > >
>     <https://datatracker.ietf.org/doc/html/draft-hegde-spring-node-protection-for-sr-te-paths-07#section-3.4
>     <https://clicktime.symantec.com/3CrUgARW8somAbw6TisjgJ16H2?u=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-hegde-spring-node-protection-for-sr-te-paths-07%2Asection-3.4__%3BIw%21%21NEt6yMaO-gk%21S0Yusx9FYNE8E_R1oiQAtQxgm0x0wxqguoZHgwp6vpRHOGt8AkTRDuiDo9wO-Ssn%24>>
>      >
>      > > draft that says:
>      > >
>      > >     [RFC8679 <https://datatracker.ietf.org/doc/html/rfc8679
>     <https://clicktime.symantec.com/36dMAjuYTQovo8jHwmm3eJw6H2?u=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Frfc8679__%3B%21%21NEt6yMaO-gk%21S0Yusx9FYNE8E_R1oiQAtQxgm0x0wxqguoZHgwp6vpRHOGt8AkTRDuiDo8MGipXc%24>>]
>     is
>     <mailto:[email-masked]%0b>>
>     <mailto:[email-masked]%0b>> <mailto:[email-masked]>>;
>     [email-masked] <mailto:[email-masked]> <mailto:[email-masked]>
>     <mailto:[email-masked]%0b%3e%20%3cmailto:[email-masked]%3e>]
>     On Behalf Of Joel M.
>      > >
>      > >  > Halpern
>      > >
>     <mailto:[email-masked]>
>     <mailto:[email-masked]%20%3cmailto:[email-masked]>>>
>      > >
>     <mailto:[email-masked]>
>     <mailto:[email-masked]%20%3cmailto:[email-masked]>>>
>      > >
>      > >  >
>      > >
>      >
>     <https://clicktime.symantec.com/3Q7vX2qWSUdWVc892XuXy2H6H2?u=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Fclicktime.symantec.com%2F367qhU4KiUkzW9uGC4eAvP46H2%3Fu%3Dhttps%2A3A%2A2__%3BJSU%21%21NEt6yMaO-gk%21S0Yusx9FYNE8E_R1oiQAtQxgm0x0wxqguoZHgwp6vpRHOGt8AkTRDuiDo6HwPLil%24>
>      > >
>      >
>     <https://clicktime.symantec.com/367qhU4KiUkzW9uGC4eAvP46H2?u=https%3A%252
>     <https://clicktime.symantec.com/3A5B8H2Fm1rPnaZ3Supjwr6H2?u=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Fclicktime.symantec.com%2F367qhU4KiUkzW9uGC4eAvP46H2%3Fu%3Dhttps%2A3A%2A252__%3BJSU%21%21NEt6yMaO-gk%21S0Yusx9FYNE8E_R1oiQAtQxgm0x0wxqguoZHgwp6vpRHOGt8AkTRDuiDozoQiAHk%24>>
>      > >
>      > >  > F%2Fwww.ietf.org
>     <https://clicktime.symantec.com/39NznmYBtRuHARhGJ5W5dGB6H2?u=https%3A%2F%2Furldefense.com%2Fv3%2F__http%3A%2F2Fwww.ietf.org__%3B%21%21NEt6yMaO-gk%21S0Yusx9FYNE8E_R1oiQAtQxgm0x0wxqguoZHgwp6vpRHOGt8AkTRDuiDo-pPCjvR%24>
>      > <http://2Fwww.ietf.org
>     <https://clicktime.symantec.com/39NznmYBtRuHARhGJ5W5dGB6H2?u=https%3A%2F%2Furldefense.com%2Fv3%2F__http%3A%2F2Fwww.ietf.org__%3B%21%21NEt6yMaO-gk%21S0Yusx9FYNE8E_R1oiQAtQxgm0x0wxqguoZHgwp6vpRHOGt8AkTRDuiDo-pPCjvR%24>>%2Fmailman%2Flistinfo%2Fspring
>      > >
>     <mailto:[email-masked]> <mailto:[email-masked]
>     <https://clicktime.symantec.com/3BhyEtx4Q7n74BhiRnfMJtT6H2?u=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Fclicktime.symantec.com%2F367qhU4KiUkzW9uGC4eAvP46H2%3Fu%3Dhttps%2A3A%2A2F%2A2Fwww.ietf.org%2A2Fmailman%2A2Flistinfo%2A2Fspring__%3BJSUlJSUl%21%21NEt6yMaO-gk%21S0Yusx9FYNE8E_R1oiQAtQxgm0x0wxqguoZHgwp6vpRHOGt8AkTRDuiDo-hR3gAD%24>
>      > >
>      > >
>      > >
>      > >
>      >
>      > > [email-masked] <mailto:[email-masked]> <mailto:[email-masked]>
>     <https://clicktime.symantec.com/3NrDnSTReXh671G79BVGEq16H2?u=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring__%3B%21%21NEt6yMaO-gk%21S0Yusx9FYNE8E_R1oiQAtQxgm0x0wxqguoZHgwp6vpRHOGt8AkTRDuiDo5KlPnbj%24>
>      > >
>      >
>      > [email-masked] <mailto:[email-masked]> <mailto:[email-masked]>
>     <https://clicktime.symantec.com/3NrDnSTReXh671G79BVGEq16H2?u=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring__%3B%21%21NEt6yMaO-gk%21S0Yusx9FYNE8E_R1oiQAtQxgm0x0wxqguoZHgwp6vpRHOGt8AkTRDuiDo5KlPnbj%24>
>      >
> 
>     <https://clicktime.symantec.com/3NrDnSTReXh671G79BVGEq16H2?u=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring__%3B%21%21NEt6yMaO-gk%21S0Yusx9FYNE8E_R1oiQAtQxgm0x0wxqguoZHgwp6vpRHOGt8AkTRDuiDo5KlPnbj%24>
> 
> 
>

---

From: "Ketan Talaulikar (ketant)" <[email-masked]>
Date: Fri, 14 Aug 2020 12:00:06 +0000

Hi All,

I would like to share a different perspective on this.

First, thanks to Joel for bringing up the discussion. Clearly we need a well-defined applicability statement for determining applicability of protection for segment used in an SR Policy. Some of this is captured in [1].

This is about local repair at a PLR. By it's very nature, the PLR does not have a notion of how "strict or not" is the SLA that is being provided by the SR Policy. Awareness of that notion exists at the SR Policy headend and/or computation-node.

We have protected and un-protected variants of adjacency SIDs to enable the computation to pick or the other based on the "strictness" of the SLA requirement for picking that link. We do not have such a notion for Prefix SIDs. One can say that we could introduce signalling (e.g. a B flag) to indicate whether a Prefix SID can be bypassed or not. This provides the opportunity for the computation to use one or the other flavor depending on the nature of the SLA for the SR Policy.

I have a problem and a concern in the assumption that PLRs can assume that the currently defined variant of Prefix SIDs in RFC8402 (and IGP specs) are "bypass-able".

As Joel and others have brought out, the Prefix SID could be just a topological instruction or may also be used to steer the flow to a node which is applying a service function to it. In order to support a mix of SR Policies of different SLAs (strict and not-strict), we need to enable the choice of SIDs that indicates to the PLR whether they are "bypass-able" or not.

For the cases, where the SR Policy has a specific SLA, it is required for nodes to drop the packets meant for the "active segment" than to bypass it. When this mechanism is used along side SRTE path monitoring mechanisms, it enables the headend to detect the failure and fallback to an alternate path using the path protection approach. This is something that is described and in use in deployments today [1].

Thanks,
Ketan

[1] https://tools.ietf.org/html/draft-ietf-spring-segment-routing-policy-08#section-9
[2] https://tools.ietf.org/html/draft-ietf-spring-segment-routing-policy-08#section-9.3

-----Original Message-----
From: spring <[email-masked]> On Behalf Of Joel M. Halpern
Sent: 04 August 2020 20:25
To: Alexander Vainshtein <[email-masked]>; Shraddha Hegde <shraddha=[email-masked]>; [email-masked] <[email-masked]>; Robert Raszuk <[email-masked]>
Cc: [email-masked]; Joel M. Halpern <[email-masked]>
Subject: Re: [spring] Spring protection - determining applicability

There are, as far as I can tell, a number of ways to address this family of related questions.
What struck me, and prompted the starting question, was that none of them were spelled out.  I see lots of interesting ideas / proposals.
Some of them are compatible with others.   Some are not.
It would be good if we could reach agreement on how we thought it should be handled.

Thank you,
Joel

On 8/4/2020 3:54 AM, Alexander Vainshtein wrote:
> would protect – because in the Facility Protection mode the same 
> bypass LSP would be used to protect multiple LSPs passing thru the 
> failed link/node.
> 
> restricted nodes and links. When a stack of adj-sids is used to 
> realize the path, the head-end based (sBFD) protection mechanisms can be applied.
> 
> links. This would happen regardless of whether any kind of protection 
> is in use or not.
> 
> Rgds
> 
> Shraddha
> 
> you’d have to stack 10 – 20 – 30 negative labels – and that wouldn’t 
> be viable.
> 
> you have this need for node avoidance – the need for 10+ label depth 
> is critical – unless you wanna be applying one hell of a lot of 
> binding labels along the way which is a nightmare.
> 
> But to answer your question, is this a common use case – it’s a use 
> case that most of the people I discuss this with certain have – I cant 
> <https://clicktime.symantec.com/3NrDnSTReXh671G79BVGEq16H2?u=https%3A%
> 2F%2Furldefense.com%2Fv3%2F__https%3A%2Fwww.ietf.org%2Fmailman%2Flisti
> nfo%2Fspring__%3B%21%21NEt6yMaO-gk%21S0Yusx9FYNE8E_R1oiQAtQxgm0x0wxqgu
> oZHgwp6vpRHOGt8AkTRDuiDo5KlPnbj%24>
> 
> 
>

---

From: Alexander Vainshtein <[email-masked]>
Date: Fri, 14 Aug 2020 12:54:27 +0000

Hi all,
Regarding the statement "Prefix SID could be just a topological instruction or may also be used to steer the flow to a node which is applying a service function to it":

I think that in SR-MPLS a Node SID that is advertised with PHP aciton can be safely considered as "just a topological instruction" by the PLR because the originating node will not receive it.
The same applies to Adj-SDIs.

My 2c.

Get Outlook for Android<https://aka.ms/ghei36>

________________________________
From: spring <[email-masked]> on behalf of Ketan Talaulikar (ketant) <ketant=[email-masked]>
Sent: Friday, August 14, 2020, 15:00
To: Joel M. Halpern; Alexander Vainshtein; Shraddha Hegde; [email-masked]; Robert Raszuk
Cc: [email-masked]
Subject: Re: [spring] Spring protection - determining applicability

Hi All,

Thanks,
Ketan

[1] https://clicktime.symantec.com/3Y3fWuNFYCjMJUiiAiWwUms6H2?u=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-ietf-spring-segment-routing-policy-08%23section-9
[2] https://clicktime.symantec.com/36fCMrgmEewC4a4AJRrmn7H6H2?u=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-ietf-spring-segment-routing-policy-08%23section-9.3

-----Original Message-----
From: spring <[email-masked]> On Behalf Of Joel M. Halpern
Sent: 04 August 2020 20:25
To: Alexander Vainshtein <[email-masked]>; Shraddha Hegde <shraddha=[email-masked]>; [email-masked] <[email-masked]>; Robert Raszuk <[email-masked]>
Cc: [email-masked]; Joel M. Halpern <[email-masked]>
Subject: Re: [spring] Spring protection - determining applicability

Thank you,
Joel

On 8/4/2020 3:54 AM, Alexander Vainshtein wrote:
> <https://clicktime.symantec.com/3Q92knE9XJujrf8Bk7oJvs6H2?u=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Frfc4090>) has been successfully deployed
>     <https://clicktime.symantec.com/3CCcy9mY6cMfbk7QfjhiA3R6H2?u=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-bess-srv6-services-04
>      > > <https://clicktime.symantec.com/345NLCB6TydxuuqUjtcDRZy6H2?u=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Frfc8402
>     <https://clicktime.symantec.com/3JbSWGx5DAfNPsZdhpExxx96H2?u=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-hegde-spring-node-protection-for-sr-te-paths-07%23section-3.4
>      > >     [RFC8679 <https://clicktime.symantec.com/3JfvtBAmaQPN1jA3pM6TdCE6H2?u=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Frfc8679
>      > <https://clicktime.symantec.com/3GWT9fyjaFi3FcvHDvoodvS6H2?u=http%3A%2F%2F2Fwww.ietf.org
>      > > https://clicktime.symantec.com/3Q1xsKGyMzNJCKyVPByhqLq6H2?u=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring
>      > https://clicktime.symantec.com/3Q1xsKGyMzNJCKyVPByhqLq6H2?u=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring
>     https://clicktime.symantec.com/3Q1xsKGyMzNJCKyVPByhqLq6H2?u=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring
>

_______________________________________________
spring mailing list
[email-masked]
https://clicktime.symantec.com/3Q1xsKGyMzNJCKyVPByhqLq6H2?u=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring
_______________________________________________
spring mailing list
[email-masked]
https://clicktime.symantec.com/3Q1xsKGyMzNJCKyVPByhqLq6H2?u=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring

---

From: "Ketan Talaulikar (ketant)" <[email-masked]>
Date: Fri, 14 Aug 2020 13:23:26 +0000

Hi Sasha,

If the service does not need any additional context (e.g. a firewall that just applies locally configured default rules on it), then I don’t see why PHP could not be done for a Prefix SID associated with a service node.

Also, I didn’t follow the point that you were trying to make about Adj-SIDs.

Thanks,
Ketan

From: Alexander Vainshtein <[email-masked]>
Sent: 14 August 2020 18:24
To: Ketan Talaulikar (ketant) <[email-masked]>; Joel M. Halpern <[email-masked]>; Alexander Vainshtein <[email-masked]>; Shraddha Hegde <[email-masked]>; [email-masked] <[email-masked]>; Robert Raszuk <[email-masked]>
Cc: [email-masked]
Subject: Re: [spring] Spring protection - determining applicability

Hi all,

My 2c.

________________________________
From: spring <[email-masked]<mailto:[email-masked]>> on behalf of Ketan Talaulikar (ketant) <ketant=[email-masked]<mailto:ketant=[email-masked]>>
Sent: Friday, August 14, 2020, 15:00
To: Joel M. Halpern; Alexander Vainshtein; Shraddha Hegde; [email-masked]<mailto:[email-masked]>; Robert Raszuk
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [spring] Spring protection - determining applicability

Hi All,

For the cases, where the SR Policy has a specific SLA, it is required for nodes to drop the packets meant for the "active segment" than to bypass it. When this mechanism is used along side SRTE path monitoring mechanisms, it enables the headend to detect the failure and fallback to an alternate path using the path protection approach. This is something that is described and in use in deployments today [1]..

Thanks,
Ketan

-----Original Message-----
From: spring <[email-masked]<mailto:[email-masked]>> On Behalf Of Joel M. Halpern
Sent: 04 August 2020 20:25
To: Alexander Vainshtein <[email-masked]<mailto:[email-masked]>>; Shraddha Hegde <shraddha=[email-masked]<mailto:shraddha=[email-masked]>>; [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>; Robert Raszuk <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; Joel M. Halpern <[email-masked]<mailto:[email-masked]>>
Subject: Re: [spring] Spring protection - determining applicability

Thank you,
Joel

On 8/4/2020 3:54 AM, Alexander Vainshtein wrote:
> *From:* spring <[email-masked]<mailto:[email-masked]>> *On Behalf Of *Shraddha Hegde
> *To:* [email-masked]<mailto:[email-masked]>
> <[email-masked]<mailto:[email-masked]>>; Robert Raszuk <[email-masked]<mailto:[email-masked]>>
> *Cc:* [email-masked]<mailto:[email-masked]>; Joel M. Halpern <[email-masked]<mailto:[email-masked]>>
<mailto:[email-masked]%20%0b>> <mailto:[email-masked]>> *On Behalf Of *Andrew Alston
> *Cc:* [email-masked]<mailto:[email-masked]> <mailto:[email-masked]>; Joel M. Halpern
<mailto:[email-masked]%20%0b>> <mailto:[email-masked]>>
> *Cc:* Joel M. Halpern <[email-masked]
<mailto:[email-masked]%20%0b>> <mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
>     *From:* spring <[email-masked]
<mailto:[email-masked]%0b>>     <mailto:[email-masked]>> *On Behalf Of *Joel M. Halpern
>     *Cc:* spring@ietf..org<mailto:spring@ietf..org> <mailto:[email-masked]>
>      > apply IP encapsulation to that node.. I don't think IP
>     encapsulation can
>     <https://clicktime.symantec.com/3CCcy9mY6cMfbk7QfjhiA3R6H2?u=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-bess-srv6-services-04
<https://clicktime.symantec.com/3CCcy9mY6cMfbk7QfjhiA3R6H2?u=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-bess-srv6-services-04%0b>>     <https://clicktime.symantec.com/3GC5af2z3JzphZDkPncHAQi6H2?u=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-bess-srv6-services-04__%3B%21%21NEt6yMaO-gk%21S0Yusx9FYNE8E_R1oiQAtQxgm0x0wxqguoZHgwp6vpRHOGt8AkTRDuiDo4T-L0nl%24>>
>      > > <https://clicktime.symantec.com/345NLCB6TydxuuqUjtcDRZy6H2?u=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Frfc8402
<https://clicktime.symantec.com/345NLCB6TydxuuqUjtcDRZy6H2?u=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Frfc8402%0b>>     <https://clicktime.symantec.com/37PzUKAD82cjSvmVcGvpkhF6H2?u=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Ftools.ietf.org%2Fhtml%2Frfc8402__%3B%21%21NEt6yMaO-gk%21S0Yusx9FYNE8E_R1oiQAtQxgm0x0wxqguoZHgwp6vpRHOGt8AkTRDuiDo0I4Ybtm%24>>
>     <https://clicktime.symantec.com/3JbSWGx5DAfNPsZdhpExxx96H2?u=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-hegde-spring-node-protection-for-sr-te-paths-07%23section-3.4
<https://clicktime.symantec.com/3JbSWGx5DAfNPsZdhpExxx96H2?u=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-hegde-spring-node-protection-for-sr-te-paths-07%23section-3.4%0b>>     <https://clicktime.symantec.com/3CrUgARW8somAbw6TisjgJ16H2?u=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-hegde-spring-node-protection-for-sr-te-paths-07%2Asection-3.4__%3BIw%21%21NEt6yMaO-gk%21S0Yusx9FYNE8E_R1oiQAtQxgm0x0wxqguoZHgwp6vpRHOGt8AkTRDuiDo9wO-Ssn%24>>
>      > >     [RFC8679 <https://clicktime.symantec.com/3JfvtBAmaQPN1jA3pM6TdCE6H2?u=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Frfc8679
<https://clicktime.symantec.com/3JfvtBAmaQPN1jA3pM6TdCE6H2?u=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Frfc8679%0b>>     <https://clicktime.symantec.com/36dMAjuYTQovo8jHwmm3eJw6H2?u=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Frfc8679__%3B%21%21NEt6yMaO-gk%21S0Yusx9FYNE8E_R1oiQAtQxgm0x0wxqguoZHgwp6vpRHOGt8AkTRDuiDo8MGipXc%24>>]
>      > > From: spring <[email-masked]
<mailto:[email-masked]%0b>>     <mailto:[email-masked]%0b>>
>      > > To: Joel M. Halpern <[email-masked]
<mailto:[email-masked]%0b>>     <mailto:[email-masked]%0b>> <mailto:[email-masked]>>;
>     [email-masked]<mailto:[email-masked]> <mailto:[email-masked]> <mailto:[email-masked]>
<mailto:[email-masked]%20%3cmailto:[email-masked]%0b>>     <mailto:[email-masked]%20%3cmailto:[email-masked]>>>
>      > <mailto:[email-masked] <mailto:[email-masked]
<mailto:[email-masked]%20%3cmailto:[email-masked]%0b>>     <mailto:[email-masked]%20%3cmailto:[email-masked]>>>
>     <https://clicktime.symantec.com/367qhU4KiUkzW9uGC4eAvP46H2?u=https%3A%252
<https://clicktime.symantec.com/367qhU4KiUkzW9uGC4eAvP46H2?u=https%3A%252%0b>>     <https://clicktime.symantec.com/3A5B8H2Fm1rPnaZ3Supjwr6H2?u=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Fclicktime.symantec.com%2F367qhU4KiUkzW9uGC4eAvP46H2%3Fu%3Dhttps%2A3A%2A252__%3BJSU%21%21NEt6yMaO-gk%21S0Yusx9FYNE8E_R1oiQAtQxgm0x0wxqguoZHgwp6vpRHOGt8AkTRDuiDozoQiAHk%24>>
>      > <https://clicktime.symantec.com/3GWT9fyjaFi3FcvHDvoodvS6H2?u=http%3A%2F%2F2Fwww.ietf.org
<https://clicktime.symantec.com/3GWT9fyjaFi3FcvHDvoodvS6H2?u=http%3A%2F%2F2Fwww.ietf.org%0b>>     <https://clicktime.symantec.com/39NznmYBtRuHARhGJ5W5dGB6H2?u=https%3A%2F%2Furldefense.com%2Fv3%2F__http%3A%2F2Fwww.ietf.org__%3B%21%21NEt6yMaO-gk%21S0Yusx9FYNE8E_R1oiQAtQxgm0x0wxqguoZHgwp6vpRHOGt8AkTRDuiDo-pPCjvR%24>>%2Fmailman%2Flistinfo%2Fspring
>     <mailto:[email-masked]> <mailto:[email-masked]
<mailto:[email-masked]%0b>>     <mailto:[email-masked]%0b>> <mailto:[email-masked]>>
>      > > [email-masked]<mailto:[email-masked]> <mailto:[email-masked]> <mailto:[email-masked]>
>      > [email-masked]<mailto:[email-masked]> <mailto:[email-masked]> <mailto:[email-masked]>
<https://clicktime.symantec.com/3NrDnSTReXh671G79BVGEq16H2?u=https%3A%25%0b>> 2F%2Furldefense.com%2Fv3%2F__https%3A%2Fwww.ietf.org%2Fmailman%2Flisti

________________________________
Notice: This e-mail together with any attachments may contain information of Ribbon Communications Inc. that is confidential and/or proprietary for the sole use of the intended recipient. Any review, disclosure, reliance or distribution by others or forwarding without express permission is strictly prohibited. If you are not the intended recipient, please notify the sender immediately and then delete all copies, including any attachments.
________________________________

---

From: Alexander Vainshtein <[email-masked]>
Date: Fri, 14 Aug 2020 14:54:01 +0000

Ketan, and all,
I have stated that, IMHO and FWIW, both Adj-SIDs and Prefix SIDs that are advertised with PHP can  ONLY represent topological instructions in SR-MPLS - because the advertising node will not receive them and therefore can hardly be expected to associate any service function with them.

This is complementary to what you have said.

Hope this clarifies my position.
What, if anything, did I miss?

Regards,
Sasha

________________________________
From: Ketan Talaulikar (ketant) <[email-masked]>
Sent: Friday, August 14, 2020, 16:23
To: Alexander Vainshtein; Joel M. Halpern; Shraddha Hegde; [email-masked]; Robert Raszuk
Cc: [email-masked]
Subject: RE: [spring] Spring protection - determining applicability

________________________________
NOTICE: This email was received from an EXTERNAL sender
________________________________

Hi Sasha,

Thanks,
Ketan

Hi all,

My 2c.

Get Outlook for Android<https://clicktime.symantec.com/375c5YYBeEbaEZwUcHpCY1m6H2?u=https%3A%2F%2Faka.ms%2Fghei36>

Hi All,

Thanks,
Ketan

-----Original Message-----
From: spring <[email-masked]<mailto:[email-masked]>> On Behalf Of Joel M. Halpern
Sent: 04 August 2020 20:25
To: Alexander Vainshtein <[email-masked]<mailto:[email-masked]>>; Shraddha Hegde <shraddha=[email-masked]<mailto:shraddha=[email-masked]>>; [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>; Robert Raszuk <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; Joel M. Halpern <[email-masked]<mailto:[email-masked]>>
Subject: Re: [spring] Spring protection - determining applicability

Thank you,
Joel

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 14 Aug 2020 11:09:52 -0400

From what I have seen in this discussion, we have a number of different 
views, all reasonable, mostly non-document.  It would seem helpful to 
write down our assumptions about meaning and get WG agreement??

Yours,
Joel

On 8/14/2020 10:54 AM, Alexander Vainshtein wrote:
> Ketan, and all,
> I have stated that, IMHO and FWIW, both Adj-SIDs and Prefix SIDs that 
> are advertised with PHP can  ONLY represent topological instructions in 
> SR-MPLS - because the advertising node will not receive them and 
> therefore can hardly be expected to associate any service function with 
> them.
> 
> Get Outlook for Android <https://aka.ms/ghei36>
> 
> *From:* Ketan Talaulikar (ketant) <[email-masked]>
> *Sent:* Friday, August 14, 2020, 16:23
> *To:* Alexander Vainshtein; Joel M. Halpern; Shraddha Hegde; 
> [email-masked]; Robert Raszuk
> *Cc:* [email-masked]
> *Subject:* RE: [spring] Spring protection - determining applicability
> 
> If the service does not need any additional context (e.g. a firewall 
> that just applies locally configured default rules on it), then I don’t 
> see why PHP could not be done for a Prefix SID associated with a service 
> node.
> 
> *From:*Alexander Vainshtein <[email-masked]>
> *Sent:* 14 August 2020 18:24
> *To:* Ketan Talaulikar (ketant) <[email-masked]>; Joel M. Halpern 
> <[email-masked]>; Alexander Vainshtein 
> <[email-masked]>; Shraddha Hegde <[email-masked]>; 
> [email-masked] <[email-masked]>; 
> Robert Raszuk <[email-masked]>
> *Cc:* [email-masked]
> Regarding the statement "Prefix SID could be just a topological 
> instruction or may also be used to steer the flow to a node which is 
> applying a service function to it":
> 
> I think that in SR-MPLS a Node SID that is advertised with PHP aciton 
> can be safely considered as "just a topological instruction" by the PLR 
> because the originating node will not receive it.
> 
> Get Outlook for Android 
> <https://clicktime.symantec.com/375c5YYBeEbaEZwUcHpCY1m6H2?u=https%3A%2F%2Faka.ms%2Fghei36>
> 
> <mailto:[email-masked]>> on behalf of Ketan Talaulikar (ketant) 
> <ketant=[email-masked] 
> <mailto:ketant=[email-masked]>>
> *Sent:* Friday, August 14, 2020, 15:00
> *To:* Joel M. Halpern; Alexander Vainshtein; Shraddha Hegde; 
> [email-masked] 
> <mailto:[email-masked]>; Robert Raszuk
> *Cc:* [email-masked] <mailto:[email-masked]>
> First, thanks to Joel for bringing up the discussion. Clearly we need a 
> well-defined applicability statement for determining applicability of 
> protection for segment used in an SR Policy. Some of this is captured in 
> [1].
> 
> This is about local repair at a PLR. By it's very nature, the PLR does 
> not have a notion of how "strict or not" is the SLA that is being 
> provided by the SR Policy. Awareness of that notion exists at the SR 
> Policy headend and/or computation-node.
> 
> We have protected and un-protected variants of adjacency SIDs to enable 
> the computation to pick or the other based on the "strictness" of the 
> SLA requirement for picking that link. We do not have such a notion for 
> Prefix SIDs. One can say that we could introduce signalling (e.g. a B 
> flag) to indicate whether a Prefix SID can be bypassed or not. This 
> provides the opportunity for the computation to use one or the other 
> flavor depending on the nature of the SLA for the SR Policy.
> 
> I have a problem and a concern in the assumption that PLRs can assume 
> that the currently defined variant of Prefix SIDs in RFC8402 (and IGP 
> specs) are "bypass-able".
> 
> As Joel and others have brought out, the Prefix SID could be just a 
> topological instruction or may also be used to steer the flow to a node 
> which is applying a service function to it. In order to support a mix of 
> SR Policies of different SLAs (strict and not-strict), we need to enable 
> the choice of SIDs that indicates to the PLR whether they are 
> "bypass-able" or not.
> 
> For the cases, where the SR Policy has a specific SLA, it is required 
> for nodes to drop the packets meant for the "active segment" than to 
> bypass it. When this mechanism is used along side SRTE path monitoring 
> mechanisms, it enables the headend to detect the failure and fallback to 
> an alternate path using the path protection approach. This is something 
> that is described and in use in deployments today [1]..
> 
> Thanks,
> Ketan
> 
> [1] 
> https://clicktime.symantec.com/3Y3fWuNFYCjMJUiiAiWwUms6H2?u=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-ietf-spring-segment-routing-policy-08%23section-9
> [2] 
> https://clicktime.symantec.com/36fCMrgmEewC4a4AJRrmn7H6H2?u=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-ietf-spring-segment-routing-policy-08%23section-9.3
> 
> From: spring <[email-masked] <mailto:[email-masked]>> 
> On Behalf Of Joel M. Halpern
> To: Alexander Vainshtein <[email-masked] 
> <mailto:[email-masked]>>; Shraddha Hegde 
> <shraddha=[email-masked] 
> <mailto:shraddha=[email-masked]>>; 
> [email-masked] 
> <mailto:[email-masked]> 
> <mailto:[email-masked]>>; Robert Raszuk 
> <[email-masked] <mailto:[email-masked]>>
> Cc: [email-masked] <mailto:[email-masked]>; Joel M. Halpern 
> <mailto:[email-masked]>> *On Behalf Of *Shraddha Hegde
> <mailto:[email-masked]>
> <mailto:[email-masked]>>; Robert Raszuk 
> <[email-masked] <mailto:[email-masked]>>
> <mailto:[email-masked]%20%0b>> 
>  > *Cc:* [email-masked] <mailto:[email-masked]> 
> <mailto:[email-masked]>; Joel M. Halpern
> <mailto:[email-masked]%20%0b>> 
> <mailto:[email-masked]%20%0b>> <mailto:[email-masked]>>; 
> <mailto:[email-masked]%20%0b>> 
>  >     *Cc:* spring@ietf..org <mailto:spring@ietf..org> 
> <mailto:[email-masked]>
>  >      > Joel,
>  >      > Are we still talking about IP networks here ? Or perhaps some hard
>  >      > slicing with real resource reservations or detnets ?
>  >      >
>  >      > Because if we are talking about IP networking I have two
>  >     observations:
>  >      >
>  >      > A) If you need to traverse via a specific node (ie. firewall) you
>  >     better
>  >      > apply IP encapsulation to that node.. I don't think IP
>  >     encapsulation can
>  >      > be hijacked today such that destination address of the packet is
>  >     ignored.
>  >      >
>  >      > B) Have you seen any IP network where upon topology change (link
>  >     or node
>  >      > failure) you suddenly start dropping flows in spite of SPT 
> offering
>  >      > perhaps few ms longer path with 10 ms more jitter ?
>  >      >
>  >      > Or are some SR marketing slides promise to turn IP networks in
>  >      > something new ? Worse ... do they mention path quality guarantees,
>  >      > resource reservations ? I hope not.
>  >      >
>  >      > Thx,
>  >      > R.
>  >      >
>  >      >
>  >      >
>  >      >
>  >      >
>  >      >
>  >      >
>  >      >
>  >      >
>  >      > On Mon, Aug 3, 2020 at 8:10 PM Joel M. Halpern 
> <[email-masked]
>  >      > Well less serious for TE SIDs, I am not sure the problem is
>  >     restricted
>  >      > to just service SIDs.
>  >      >
>  >      > Suppose that the PCE has specified the path to meet some 
> complex te
>  >      > objective.  The bypass node has no way of knowing what those
>  >      > constraints
>  >      > were.  And for some kinds of traffic, it is better to drop the 
> packet
>  >      > than to deliver it outside the envelop.  I suspect that the right
>  >      > answer
>  >      > to this is "too bad".  If so, as with the distinction regarding
>  >     service
>  >      > nodes, we should say so, shouldn't we?
>  >      >
>  >      > Yours,
>  >      > Joel
>  >      >
>  >      > On 8/3/2020 2:36 AM, Alexander Vainshtein wrote:
>  >      > > Mach, Joel and all,
>  >      > >
>  >      > > I think that in most cases:
>  >      > >
>  >      > > 1.There is clear differentiation between "topological" and
>  >     "service"
>  >      > > instructions in SID advertisements. E.g.:
>  >      > >
>  >      > > oIGP Prefix Node SIDs IGP Adj-SIDs (identified as such in the
>  >      > > corresponding IGP advertisements) represent topological
>  >     instructions
>  >      > >
>  >      > > oService SIDs for SRv6 (see SRv6 BGP-Based Overlay Services
>  >      > >
>  >      >
>  >     
> <https://clicktime.symantec.com/3CCcy9mY6cMfbk7QfjhiA3R6H2?u=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-bess-srv6-services-04%0b>>     
>  >      > > draft) unsurprisingly represent “service” instructions
>  >      > >
>  >      > > 2.Segments that represent topological instructions can be 
> bypassed,
>  >      > > while segments that represent service instructions require
>  >      > alternative
>  >      > > protection mechanisms.
>  >      > >
>  >      > > This view seems to be aligned with RFC 8402
>  >      > > 
> <https://clicktime.symantec.com/345NLCB6TydxuuqUjtcDRZy6H2?u=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Frfc8402%0b>>     
>  >      > >
>  >      > >     In the context of an IGP-based distributed control 
> plane, two
>  >      > >
>  >      > > topological segments are defined: the IGP-Adjacency segment 
> and the
>  >      > >
>  >      > >     IGP-Prefix segment.
>  >      > >
>  >      > >     In the context of a BGP-based distributed control plane, two
>  >      > >
>  >      > > topological segments are defined: the BGP peering segment 
> and the
>  >      > >
>  >      > >     BGP-Prefix segment.
>  >      > >
>  >      > > In the case of SR-MPLS this differentiation is assumed in 
> Section
>  >      > 3.4 of
>  >      > > the Node Protection for SR-TE Path
>  >      > >
>  >      >
>  >     
> <https://clicktime.symantec.com/3JbSWGx5DAfNPsZdhpExxx96H2?u=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-hegde-spring-node-protection-for-sr-te-paths-07%23section-3.4%0b>>     
>  >      > > draft that says:
>  >      > >
>  >      > >     The node protection mechanism described in the previous
>  >     sections
>  >      > >
>  >      > >     depends on the assumption that the label immediately below
>  >      > the top
>  >      > >
>  >      > > label in the label stack is understood in the IGP domain.  
> When the
>  >      > >
>  >      > >     provider edge routers exchange service labels via BGP or 
> some
>  >      > other
>  >      > >
>  >      > >     non-IGP mechanism the bottom label is not understood in 
> the IGP
>  >      > >
>  >      > >     domain.
>  >      > >
>  >      > >     The egress node protection mechanisms described in the draft
>  >      > >
>  >      > >     [RFC8679 
> <https://clicktime.symantec.com/3JfvtBAmaQPN1jA3pM6TdCE6H2?u=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Frfc8679
> <https://clicktime.symantec.com/3JfvtBAmaQPN1jA3pM6TdCE6H2?u=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Frfc8679%0b>>     
>  >      > > applicable to this use case and no additional changes
>  >      > >
>  >      > >     will be required for SR based networks
>  >      > >
>  >      > > The scenarios in which  differentiation between 
> “topological” and
>  >      > > “service” instructions is broken are indeed problematic. E.g.,
>  >      > consider
>  >      > > the use case in which a Node SID in the ERO of a SR-TE path
>  >      > identifies a
>  >      > > node that acts as a firewall for all packets it receives, i.e.,
>  >      > provides
>  >      > > the firewall service without any dedicated service SID
>  >      > identifying it.
>  >      > > One could say that the Node SID of such a node would combine
>  >      > topological
>  >      > > and service instructions thus breaking the differentiation
>  >      > between the two.
>  >      > >
>  >      > > I am not sure if usage of such “combined” SIDs could be 
> prevented
>  >      > or at
>  >      > > least discouraged.
>  >      > >
>  >      > > If not, providing an ability to identify such SIDs in the
>  >      > advertisement
>  >      > > mechanisms would be useful IMHO.
>  >      > >
>  >      > > My 2c,
>  >      > >
>  >      > > Sasha
>  >      > >
>  >      > > Office: +972-39266302
>  >      > >
>  >      > > Cell:      +972-549266302
>  >      > >
>  >      > > Email: [email-masked] 
>  >      > <mailto:[email-masked]>
>  >      > >
>  >      > > -----Original Message-----
>  >      > > From: spring <[email-masked]
>  >      > > Sent: Monday, August 3, 2020 6:30 AM
>  >      > > To: Joel M. Halpern <[email-masked]
>  >      > > Subject: Re: [spring] Spring protection - determining 
> applicability
>  >      > >
>  >      > > Hi Joel,
>  >      > >
>  >      > > I think this is a good point that may not be discussed in the
>  >      > past. And
>  >      > > I also don't think there is a "can be bypassed" indication 
> in the
>  >      > > routing advertisement for now.
>  >      > >
>  >      > > IMHO, the information advertised by routing is neutral, such
>  >      > information
>  >      > > (can or cannot be bypassed) is more path specific, thus
>  >     normally the
>  >      > > controller should be responsible for deciding whether/which SID
>  >      > can be
>  >      > > bypassed.
>  >      > >
>  >      > > Best regards,
>  >      > >
>  >      > > Mach
>  >      > >
>  >      > >  > -----Original Message-----
>  >      > >
>  >      > >  > From: spring [mailto:[email-masked]
>  >      > <mailto:[email-masked]>
>  >     
>  >      > >
>  >      > >  > Halpern
>  >      > >
>  >      > >  > Sent: Monday, August 3, 2020 7:51 AM
>  >      > >
>  >      > >  > To: [email-masked] <mailto:[email-masked]> 
> <mailto:[email-masked]>
>  >     <mailto:[email-masked]>
>  >      > <mailto:[email-masked] <mailto:[email-masked]
> <mailto:[email-masked]%20%3cmailto:[email-masked]%0b>>     
>  >      > >
>  >      > >  > Subject: [spring] Spring protection - determining 
> applicability
>  >      > >
>  >      > >  >
>  >      > >
>  >      > >  > (WG Chair hat Off, this is merely a note from a slightly
>  >      > confused WG
>  >      > >
>  >      > >  > participant.)
>  >      > >
>  >      > >  >
>  >      > >
>  >      > >  > I have been reading the various repair drafts, and the 
> various
>  >      > >
>  >      > >  > networks programming and service programming draft, and I am
>  >      > trying to
>  >      > >
>  >      > >  > figure out one aspect of the combination.
>  >      > >
>  >      > >  >
>  >      > >
>  >      > >  > How does a node that is doing some form of bypass 
> (suppose, for
>  >      > >
>  >      > >  > simplicity, it is Node N2 deciding to bypass the next SID for
>  >      > a failed
>  >      > >
>  >      > >  > node N3) know that it is safe to do so?
>  >      > >
>  >      > >  >
>  >      > >
>  >      > >  > If the path was just for TE, then it is "safe" if the new 
> path
>  >      > meets
>  >      > >
>  >      > >  > the TE criteria.  or maybe it is safe if it is even close, as
>  >      > long as
>  >      > >
>  >      > >  > it is not used for too long.
>  >      > >
>  >      > >  >
>  >      > >
>  >      > >  > But what if the node were a Firewall, included to meet legal
>  >      > > requirements?
>  >      > >
>  >      > >  > Or was some other necessary programmatic transform (wince 
> we are
>  >      > >
>  >      > >  > deliberately vague about what nodes can do when asked 
> suitably.)
>  >      > >
>  >      > >  >
>  >      > >
>  >      > >  > Is there some "can be bypassed" indication in the routing
>  >      > >
>  >      > >  > advertisements that I missed?
>  >      > >
>  >      > >  >
>  >      > >
>  >      > >  > Thank you,
>  >      > >
>  >      > >  > Yours,
>  >      > >
>  >      > >  > Joel
>  >      > >
>  >      > >  >
>  >      > >
>  >      > >  > _______________________________________________
>  >      > >
>  >      > >  > spring mailing list
>  >      > >
>  >      > >  > [email-masked] <mailto:[email-masked]> 
> <mailto:[email-masked]>
>  >     <mailto:[email-masked]>
>  >      > <mailto:[email-masked] <mailto:[email-masked]
> <mailto:[email-masked]%20%3cmailto:[email-masked]%0b>>     
>  >      > >
>  >      > >  >
>  >      > >
>  >      > >
> <https://clicktime.symantec.com/367qhU4KiUkzW9uGC4eAvP46H2?u=https%3A%252%0b>>     
>  >      > >
>  >      > >  > F%2Fwww.ietf.org
> <https://clicktime.symantec.com/3GWT9fyjaFi3FcvHDvoodvS6H2?u=http%3A%2F%2F2Fwww.ietf.org%0b>>     
>  >      > >
>  >      > > _______________________________________________
>  >      > >
>  >      > > spring mailing list
>  >      > >
>  >      > > [email-masked] <mailto:[email-masked]> 
> <mailto:[email-masked]>
>  >      > >
>  >      > >
>  >      > >
>  >      > >
>  >      > >
>  >      > >
>  >      > > Notice: This e-mail together with any attachments may contain
>  >      > > information of Ribbon Communications Inc. that is confidential
>  >      > and/or
>  >      > > proprietary for the sole use of the intended recipient. Any 
> review,
>  >      > > disclosure, reliance or distribution by others or forwarding
>  >     without
>  >      > > express permission is strictly prohibited. If you are not the
>  >      > intended
>  >      > > recipient, please notify the sender immediately and then 
> delete all
>  >      > > copies, including any attachments.
>  >      > >
>  >      >
>  >     
>  >      > >
>  >      > > _______________________________________________
>  >      > > spring mailing list
>  >      > > [email-masked] <mailto:[email-masked]> 
> <mailto:[email-masked]> <mailto:[email-masked]>
>  >      > > 
>  >      > >
> <mailto:[email-masked]> <mailto:[email-masked]>
>  >      > 
> <https://clicktime.symantec.com/3NrDnSTReXh671G79BVGEq16H2?u=https%3A%25%0b>>

---

From: "Ketan Talaulikar (ketant)" <[email-masked]>
Date: Fri, 14 Aug 2020 15:32:07 +0000

Hi Sasha,

The service node advertises its own Prefix SID. The service function that this service node implements does not require any context (i.e. all packets arriving at the node are subjected to that service). Therefore the service node does not need to receive a packet with it's own Prefix SID.

Thus, we cannot assume that when PHP is used, then the SID is only associated with a topological instruction.

Hope that clarifies?

Thanks,
Ketan

From: Alexander Vainshtein <[email-masked]>
Sent: 14 August 2020 20:24
To: Ketan Talaulikar (ketant) <[email-masked]>; Joel M. Halpern <[email-masked]>; Shraddha Hegde <[email-masked]>; [email-masked] <[email-masked]>; Robert Raszuk <[email-masked]>
Cc: [email-masked]
Subject: Re: [spring] Spring protection - determining applicability

Ketan, and all,

Regards,
Sasha

________________________________
From: Ketan Talaulikar (ketant) <[email-masked]<mailto:[email-masked]>>
Sent: Friday, August 14, 2020, 16:23
To: Alexander Vainshtein; Joel M. Halpern; Shraddha Hegde; [email-masked]<mailto:[email-masked]>; Robert Raszuk
Cc: [email-masked]<mailto:[email-masked]>
Subject: RE: [spring] Spring protection - determining applicability

Hi Sasha,

If the service does not need any additional context (e.g. a firewall that just applies locally configured default rules on it), then I don't see why PHP could not be done for a Prefix SID associated with a service node.

Also, I didn't follow the point that you were trying to make about Adj-SIDs.

Thanks,
Ketan

From: Alexander Vainshtein <[email-masked]<mailto:[email-masked]>>
Sent: 14 August 2020 18:24
To: Ketan Talaulikar (ketant) <[email-masked]<mailto:[email-masked]>>; Joel M. Halpern <[email-masked]<mailto:[email-masked]>>; Alexander Vainshtein <[email-masked]<mailto:[email-masked]>>; Shraddha Hegde <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>; Robert Raszuk <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [spring] Spring protection - determining applicability

Hi all,

My 2c.

Hi All,

Thanks,
Ketan

-----Original Message-----
From: spring <[email-masked]<mailto:[email-masked]>> On Behalf Of Joel M. Halpern
Sent: 04 August 2020 20:25
To: Alexander Vainshtein <[email-masked]<mailto:[email-masked]>>; Shraddha Hegde <shraddha=[email-masked]<mailto:shraddha=[email-masked]>>; [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>; Robert Raszuk <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; Joel M. Halpern <[email-masked]<mailto:[email-masked]>>
Subject: Re: [spring] Spring protection - determining applicability

Thank you,
Joel

On 8/4/2020 3:54 AM, Alexander Vainshtein wrote:
> for many years before SR-MPLS has been introduced. What's more,
> would protect - because in the Facility Protection mode the same
> introduced by the "bypassing" drafts in SR is that, in the case of
> Robert this is actually far more difficult when - it can be an entire
> It could potentially be made to work but I'd worry that to do this -
> you'd have to stack 10 - 20 - 30 negative labels - and that wouldn't
> be viable.
>
> It's easier to use algorithms and adjacency sids and other such things
> to calculate paths - the biggest trick is about the stack depth.  When
> you have this need for node avoidance - the need for 10+ label depth
> is critical - unless you wanna be applying one hell of a lot of
> But to answer your question, is this a common use case - it's a use
> case that most of the people I discuss this with certain have - I cant
> have is that yes - its something people need, and want
>
> Andrew
>
> Is this a common use case ie.  "but rather - which nodes / network
<mailto:[email-masked]%20%0b>> <mailto:[email-masked]>> wrote:
>     - would create, shall we say significant problems.
>
>     through - but rather - which nodes / network segments it can never
>     This is also one of the reasons for needing such deep label stacks -
>     It is absolutely critical to us that this functionality is there -

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 14 Aug 2020 17:42:36 +0200

Hi Ketan,

While I completely agree with your note the consequences of it are pretty
sevre.

Unless we signal which prefix SID is protection eligible and which is not
how would other nodes know if they can protect it or not ?

It seems that today's safe thing is not to apply any node protection on SR
flows at the PLRs then.

And link protection MUST assure that packets will arrive at the neighbor
node via some other link regardless of further path towards destination.

Is it correct ?

Thx
R

On Fri, Aug 14, 2020 at 5:32 PM Ketan Talaulikar (ketant) <[email-masked]>
wrote:

> Hi Sasha,
>
>
>
> The service node advertises its own Prefix SID. The service function that
> this service node implements does not require any context (i.e. all packets
> arriving at the node are subjected to that service). Therefore the service
> node does not need to receive a packet with it’s own Prefix SID.
>
>
>
> Thus, we cannot assume that when PHP is used, then the SID is only
> associated with a topological instruction.
>
>
>
> Hope that clarifies?
>
>
>
> Thanks,
>
> Ketan
>
>
>
> *From:* Alexander Vainshtein <[email-masked]>
> *Sent:* 14 August 2020 20:24
> *To:* Ketan Talaulikar (ketant) <[email-masked]>; Joel M. Halpern <
> [email-masked]>; Shraddha Hegde <[email-masked]>;
> I have stated that, IMHO and FWIW, both Adj-SIDs and Prefix SIDs that are
> advertised with PHP can  ONLY represent topological instructions in SR-MPLS
> - because the advertising node will not receive them and therefore can
> hardly be expected to associate any service function with them.
>
>
>
> ------------------------------
>
> ------------------------------
>
> ------------------------------
>
>
>
> Hi Sasha,
>
>
>
> If the service does not need any additional context (e.g. a firewall that
> just applies locally configured default rules on it), then I don’t see why
> PHP could not be done for a Prefix SID associated with a service node.
>
>
>
> *From:* Alexander Vainshtein <[email-masked]>
> *To:* Ketan Talaulikar (ketant) <[email-masked]>; Joel M. Halpern <
> [email-masked]>; Alexander Vainshtein <[email-masked]>;
> Shraddha Hegde <[email-masked]>; [email-masked]
> I think that in SR-MPLS a Node SID that is advertised with PHP aciton can
> be safely considered as "just a topological instruction" by the PLR because
> the originating node will not receive it.
>
> ------------------------------
>
> *From:* spring <[email-masked]> on behalf of Ketan Talaulikar
> (ketant) <ketant=[email-masked]>
> This is about local repair at a PLR. By it's very nature, the PLR does not
> have a notion of how "strict or not" is the SLA that is being provided by
> the SR Policy. Awareness of that notion exists at the SR Policy headend
> and/or computation-node.
>
> the computation to pick or the other based on the "strictness" of the SLA
> requirement for picking that link. We do not have such a notion for Prefix
> SIDs. One can say that we could introduce signalling (e.g. a B flag) to
> indicate whether a Prefix SID can be bypassed or not. This provides the
> opportunity for the computation to use one or the other flavor depending on
> the nature of the SLA for the SR Policy.
>
> I have a problem and a concern in the assumption that PLRs can assume that
> the currently defined variant of Prefix SIDs in RFC8402 (and IGP specs) are
> "bypass-able".
>
> which is applying a service function to it. In order to support a mix of SR
> Policies of different SLAs (strict and not-strict), we need to enable the
> choice of SIDs that indicates to the PLR whether they are "bypass-able" or
> not.
>
> For the cases, where the SR Policy has a specific SLA, it is required for
> nodes to drop the packets meant for the "active segment" than to bypass it.
> When this mechanism is used along side SRTE path monitoring mechanisms, it
> enables the headend to detect the failure and fallback to an alternate path
> using the path protection approach. This is something that is described and
> in use in deployments today [1]..
>
> Thanks,
> Ketan
>
> [1]
> To: Alexander Vainshtein <[email-masked]>; Shraddha Hegde <
> shraddha=[email-masked]>;
> What struck me, and prompted the starting question, was that none of them
> were spelled out.  I see lots of interesting ideas / proposals.
> https://clicktime.symantec.com/3Q92knE9XJujrf8Bk7oJvs6H2?u=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Frfc4090>)
> has been successfully deployed
> <[email-masked]%20%0b>> <mailto:[email-masked]
> <[email-masked]>>> *On Behalf Of *Andrew Alston
> > *To:* Robert Raszuk <[email-masked] <mailto:[email-masked]
> <[email-masked]>>>
> > *Cc:* [email-masked] <mailto:[email-masked] <[email-masked]>>; Joel
> M. Halpern
> > <[email-masked] <mailto:[email-masked] <[email-masked]>>>
> > *From:* Robert Raszuk <[email-masked] <mailto:[email-masked]
> <[email-masked]>>>
> <[email-masked]%20%0b>> <
> mailto:[email-masked] <[email-masked]>>>
> <[email-masked]>>>; [email-masked]
> > <mailto:[email-masked] <[email-masked]>>
> <[email-masked]%20%0b>> <
> mailto:[email-masked] <[email-masked]>>>
> wrote:
> >
> >     So –
> >
> <[email-masked]>>> *On Behalf Of *Joel M. Halpern
> >     *To:* Robert Raszuk <[email-masked] <mailto:[email-masked]
> <[email-masked]>>>
> >     *Cc:* spring@ietf..org <mailto:[email-masked] <[email-masked]>>
> <[email-masked]%0b>>     <mailto:[email-masked]%20%0b
> <[email-masked]%20%0b>>> <mailto:[email-masked]
> https://clicktime.symantec.com/3CCcy9mY6cMfbk7QfjhiA3R6H2?u=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-bess-srv6-services-04
>
> https://clicktime.symantec.com/3GC5af2z3JzphZDkPncHAQi6H2?u=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-bess-srv6-services-04__%3B%21%21NEt6yMaO-gk%21S0Yusx9FYNE8E_R1oiQAtQxgm0x0wxqguoZHgwp6vpRHOGt8AkTRDuiDo4T-L0nl%24
> >>
> >      >
> https://clicktime.symantec.com/345NLCB6TydxuuqUjtcDRZy6H2?u=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Frfc8402
>
> https://clicktime.symantec.com/37PzUKAD82cjSvmVcGvpkhF6H2?u=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Ftools.ietf.org%2Fhtml%2Frfc8402__%3B%21%21NEt6yMaO-gk%21S0Yusx9FYNE8E_R1oiQAtQxgm0x0wxqguoZHgwp6vpRHOGt8AkTRDuiDo0I4Ybtm%24
> >>
> >     that says in Section 1:
> >      > >
> >      > > In the case of SR-MPLS this differentiation is assumed in
> Section
> >      > 3.4 of
> https://clicktime.symantec.com/3JbSWGx5DAfNPsZdhpExxx96H2?u=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-hegde-spring-node-protection-for-sr-te-paths-07%23section-3.4
>
> https://clicktime.symantec.com/3CrUgARW8somAbw6TisjgJ16H2?u=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-hegde-spring-node-protection-for-sr-te-paths-07%2Asection-3.4__%3BIw%21%21NEt6yMaO-gk%21S0Yusx9FYNE8E_R1oiQAtQxgm0x0wxqguoZHgwp6vpRHOGt8AkTRDuiDo9wO-Ssn%24
> >>
> >      >
> >      > > draft that says:
> >      > >
> >      > >     provider edge routers exchange service labels via BGP or
> some
> >      > other
> >      > >
> >      > >     [RFC8679 <
> https://clicktime.symantec.com/3JfvtBAmaQPN1jA3pM6TdCE6H2?u=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Frfc8679
>
> https://clicktime.symantec.com/36dMAjuYTQovo8jHwmm3eJw6H2?u=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Frfc8679__%3B%21%21NEt6yMaO-gk%21S0Yusx9FYNE8E_R1oiQAtQxgm0x0wxqguoZHgwp6vpRHOGt8AkTRDuiDo8MGipXc%24
> >>]
> >     is
> >      > > I am not sure if usage of such “combined” SIDs could be
> prevented
> >      > or at
> >      > > least discouraged.
> >      > >
> <[email-masked]%0b>>     <mailto:[email-masked]%0b
> <[email-masked]%0b>>>
> >     <mailto:[email-masked] <[email-masked]>>> On
> Behalf Of Mach Chen
> <[email-masked]%0b>>     <mailto:[email-masked]%0b
> <[email-masked]%0b>>> <mailto:[email-masked]
> <[email-masked]>>>;
> mailto:[email-masked] <[email-masked]>>
> >      > <mailto:[email-masked] <[email-masked]>>
> >     <
> mailto:[email-masked]%0b%3e%20%3cmailto:[email-masked]%3e
> <[email-masked]%0b%3e%20%3cmailto:[email-masked]%3e>>]
> >     On Behalf Of Joel M.
> >      > >
> >      > >  > Halpern
> >      > >
> >     <mailto:[email-masked] <[email-masked]>>
> <[email-masked]%20%3cmailto:[email-masked]%0b>>     <
> mailto:[email-masked]%20%3cmailto:[email-masked]
> <[email-masked]%20%3cmailto:[email-masked]>>>>
> >      > >
> >      > >  > If the path was just for TE, then it is "safe" if the new
> path
> >      > meets
> >      > >
> >     <mailto:[email-masked] <[email-masked]>>
> <[email-masked]%20%3cmailto:[email-masked]%0b>>     <
> mailto:[email-masked]%20%3cmailto:[email-masked]
> <[email-masked]%20%3cmailto:[email-masked]>>>>
> >      > >
> >      > >  >
> >      > >
> >      >
> >
> https://clicktime.symantec.com/3Q7vX2qWSUdWVc892XuXy2H6H2?u=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Fclicktime.symantec.com%2F367qhU4KiUkzW9uGC4eAvP46H2%3Fu%3Dhttps%2A3A%2A2__%3BJSU%21%21NEt6yMaO-gk%21S0Yusx9FYNE8E_R1oiQAtQxgm0x0wxqguoZHgwp6vpRHOGt8AkTRDuiDo6HwPLil%24
> >
> >      > >
> >      >
> >     <
> https://clicktime.symantec.com/367qhU4KiUkzW9uGC4eAvP46H2?u=https%3A%252
>
> https://clicktime.symantec.com/3A5B8H2Fm1rPnaZ3Supjwr6H2?u=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Fclicktime.symantec.com%2F367qhU4KiUkzW9uGC4eAvP46H2%3Fu%3Dhttps%2A3A%2A252__%3BJSU%21%21NEt6yMaO-gk%21S0Yusx9FYNE8E_R1oiQAtQxgm0x0wxqguoZHgwp6vpRHOGt8AkTRDuiDozoQiAHk%24
> >>
> >      > >
> >      > >  > F%2Fwww.ietf.org
> >     <
> https://clicktime.symantec.com/39NznmYBtRuHARhGJ5W5dGB6H2?u=https%3A%2F%2Furldefense.com%2Fv3%2F__http%3A%2F2Fwww.ietf.org__%3B%21%21NEt6yMaO-gk%21S0Yusx9FYNE8E_R1oiQAtQxgm0x0wxqguoZHgwp6vpRHOGt8AkTRDuiDo-pPCjvR%24
> >
> >      > <
> https://clicktime.symantec.com/3GWT9fyjaFi3FcvHDvoodvS6H2?u=http%3A%2F%2F2Fwww.ietf.org
>
> https://clicktime.symantec.com/39NznmYBtRuHARhGJ5W5dGB6H2?u=https%3A%2F%2Furldefense.com%2Fv3%2F__http%3A%2F2Fwww.ietf.org__%3B%21%21NEt6yMaO-gk%21S0Yusx9FYNE8E_R1oiQAtQxgm0x0wxqguoZHgwp6vpRHOGt8AkTRDuiDo-pPCjvR%24
> >>%2Fmailman%2Flistinfo%2Fspring
> >      > >
> >     <mailto:[email-masked] <[email-masked]>> <mailto:[email-masked]
> <[email-masked]%0b>>     <mailto:[email-masked]%0b <[email-masked]%0b>>>
> <mailto:[email-masked] <[email-masked]>>>
> >      > >
> >      > >
> >      >
> >
> https://clicktime.symantec.com/3BhyEtx4Q7n74BhiRnfMJtT6H2?u=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Fclicktime.symantec.com%2F367qhU4KiUkzW9uGC4eAvP46H2%3Fu%3Dhttps%2A3A%2A2F%2A2Fwww.ietf.org%2A2Fmailman%2A2Flistinfo%2A2Fspring__%3BJSUlJSUl%21%21NEt6yMaO-gk%21S0Yusx9FYNE8E_R1oiQAtQxgm0x0wxqguoZHgwp6vpRHOGt8AkTRDuiDo-hR3gAD%24
> >
> >      > >
> >      > >
> >      > >
> >      > >
> >      >
> >
> >      > > recipient, please notify the sender immediately and then delete
> all
> >      > > copies, including any attachments.
> >      > >
> >      >
> >
> mailto:[email-masked] <[email-masked]>>
> >      > >
> https://clicktime.symantec.com/3NrDnSTReXh671G79BVGEq16H2?u=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring__%3B%21%21NEt6yMaO-gk%21S0Yusx9FYNE8E_R1oiQAtQxgm0x0wxqguoZHgwp6vpRHOGt8AkTRDuiDo5KlPnbj%24
> >
> >      > >
> >      >
> mailto:[email-masked] <[email-masked]>>
> >      >
> https://clicktime.symantec.com/3NrDnSTReXh671G79BVGEq16H2?u=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring__%3B%21%21NEt6yMaO-gk%21S0Yusx9FYNE8E_R1oiQAtQxgm0x0wxqguoZHgwp6vpRHOGt8AkTRDuiDo5KlPnbj%24
> >
> >      >
> >
> ------------------------------
>
> Notice: This e-mail together with any attachments may contain information
> of Ribbon Communications Inc. that is confidential and/or proprietary for
> the sole use of the intended recipient. Any review, disclosure, reliance or
> distribution by others or forwarding without express permission is strictly
> prohibited. If you are not the intended recipient, please notify the sender
> immediately and then delete all copies, including any attachments.
> ------------------------------
>
>
>

---

From: "Ketan Talaulikar (ketant)" <[email-masked]>
Date: Fri, 14 Aug 2020 16:16:59 +0000

Hi Robert,

Please check inline below.

From: Robert Raszuk <[email-masked]>
Sent: 14 August 2020 21:13
To: Ketan Talaulikar (ketant) <[email-masked]>
Cc: Alexander Vainshtein <[email-masked]>; Joel M. Halpern <[email-masked]>; Shraddha Hegde <[email-masked]>; [email-masked] <[email-masked]>; [email-masked]
Subject: Re: [spring] Spring protection - determining applicability

Hi Ketan,

While I completely agree with your note the consequences of it are pretty sevre.
[KT] I understand. We need to be mindful of implications of protection schemes for the SLAs/intent of SR Policies.

Unless we signal which prefix SID is protection eligible and which is not how would other nodes know if they can protect it or not ?
[KT] Correct. To be more accurate, we need to consider this more in the context of SLA or “intent” of SR Policies and which segments may be “bypass-able” for local protection for some of those SR Policies. We also have path-protection mechanisms.

It seems that today's safe thing is not to apply any node protection on SR flows at the PLRs then.

And link protection MUST assure that packets will arrive at the neighbor node via some other link regardless of further path towards destination.
[KT] Yes. We have a mechanism to indicate which adj-SIDs have protection (that mechanism only provides link protection to get to the neighbor node) so the SR Policy computation is able to indicate whether that specific link is “bypass-able” or not by its choice of protected or unprotected adj-SIDs respectively.

Thanks,
Ketan

Is it correct ?

Thx
R

On Fri, Aug 14, 2020 at 5:32 PM Ketan Talaulikar (ketant) <[email-masked]<mailto:[email-masked]>> wrote:
Hi Sasha,

The service node advertises its own Prefix SID. The service function that this service node implements does not require any context (i.e. all packets arriving at the node are subjected to that service). Therefore the service node does not need to receive a packet with it’s own Prefix SID.

Hope that clarifies?

Thanks,
Ketan

To: Ketan Talaulikar (ketant) <[email-masked]<mailto:[email-masked]>>; Joel M. Halpern <[email-masked]<mailto:[email-masked]>>; Shraddha Hegde <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>; Robert Raszuk <[email-masked]<mailto:[email-masked]>>

Ketan, and all,

Regards,
Sasha

Hi Sasha,

Thanks,
Ketan

Hi all,

My 2c.

Hi All,

Thanks,
Ketan

-----Original Message-----
From: spring <[email-masked]<mailto:[email-masked]>> On Behalf Of Joel M. Halpern
Sent: 04 August 2020 20:25
To: Alexander Vainshtein <[email-masked]<mailto:[email-masked]>>; Shraddha Hegde <shraddha=[email-masked]<mailto:shraddha=[email-masked]>>; [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>; Robert Raszuk <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; Joel M. Halpern <[email-masked]<mailto:[email-masked]>>
Subject: Re: [spring] Spring protection - determining applicability

Thank you,
Joel

> *To:* Robert Raszuk <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]>>
> <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]>>
> *From:* Robert Raszuk <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]>>
>     *To:* Robert Raszuk <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]>>
>      > >  > From: spring [mailto:[email-masked]<mailto:[email-masked]>
>     <https://clicktime.symantec.com/3NrDnSTReXh671G79BVGEq16H2?u=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring__%3B%21%21NEt6yMaO-gk%21S0Yusx9FYNE8E_R1…
<https://clicktime.symantec.com/3NrDnSTReXh671G79BVGEq16H2?u=https%3A%25%0b>> 2F%2Furldefense.com%2Fv3%2F__https%3A%2Fwww.ietf.org<http://2Fwww.ietf.org>%2Fmailman%2Flisti

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 14 Aug 2020 19:33:39 +0200

Ketan,

Looks like we are pretty much in sync here.

But let me just observe that I purposely did not mention about SR policies
as we are not able to signal the intent with the packets itself.

So all we have there is SIDs. BSIDs or prefix SIDs need to be flooded with
information if policies build with using them are bypass eligible or not.

I was actually under the impression that this is already there and I am
just not aware, but looking deeper indeed I do not see this marking neither
in ISIS nor OSPF for prefix SIDs.

Is there some work in progress to add it to those protocols or have we just
documented need for a short LSR draft  ?

Thx,
R.

On Fri, Aug 14, 2020 at 6:17 PM Ketan Talaulikar (ketant) <[email-masked]>
wrote:

> *From:* Robert Raszuk <[email-masked]>
> *Sent:* 14 August 2020 21:13
> *To:* Ketan Talaulikar (ketant) <[email-masked]>
> *Cc:* Alexander Vainshtein <[email-masked]>; Joel M.
> Halpern <[email-masked]>; Shraddha Hegde <[email-masked]>;
> *[KT] I understand. We need to be mindful of implications of protection
> schemes for the SLAs/intent of SR Policies.*
>
>
>
> *[KT] Correct. To be more accurate, we need to consider this more in the
> context of SLA or “intent” of SR Policies and which segments may be
> “bypass-able” for local protection for some of those SR Policies. We also
> have path-protection mechanisms.*
>
>
>
> *[KT] Yes. We have a mechanism to indicate which adj-SIDs have protection
> (that mechanism only provides link protection to get to the neighbor node)
> so the SR Policy computation is able to indicate whether that specific link
> is “bypass-able” or not by its choice of protected or unprotected adj-SIDs
> respectively.*
>
>
>
> *Thanks,*
>
> *Ketan*
>
>
>
> Is it correct ?
>
>
>
> Thx
>
> R
>
>
>
> On Fri, Aug 14, 2020 at 5:32 PM Ketan Talaulikar (ketant) <
> [email-masked]> wrote:
>
> Hi Sasha,
>
>
>

---

From: "Ketan Talaulikar (ketant)" <[email-masked]>
Date: Fri, 14 Aug 2020 17:45:48 +0000

Hi Robert,

We do not have a signalling mechanism in IGPs today to indicate a “bypass-able” indication for Prefix SIDs. If there was a desire for it, an IGP extension would be required (there is none in progress AFAIK). Note that this results in doubling the prefix SID scale (global labels) in the network. So I would not go about this trivially.

I think it helps to get more inputs and perspectives from operators on their views for doing a bypass via local protection for segments in an SR Policy. There may be those that prefer end-to-end path protection using a fallback path that is say disjoint with the primary but provides an appropriate SLA/intent?

Thanks,
Ketan

Sent: 14 August 2020 23:04

Ketan,

But let me just observe that I purposely did not mention about SR policies as we are not able to signal the intent with the packets itself.

So all we have there is SIDs. BSIDs or prefix SIDs need to be flooded with information if policies build with using them are bypass eligible or not.

I was actually under the impression that this is already there and I am just not aware, but looking deeper indeed I do not see this marking neither in ISIS nor OSPF for prefix SIDs.

Is there some work in progress to add it to those protocols or have we just documented need for a short LSR draft  ?

Thx,
R.

On Fri, Aug 14, 2020 at 6:17 PM Ketan Talaulikar (ketant) <[email-masked]<mailto:[email-masked]>> wrote:
Hi Robert,

From: Robert Raszuk <[email-masked]<mailto:[email-masked]>>
Sent: 14 August 2020 21:13
To: Ketan Talaulikar (ketant) <[email-masked]<mailto:[email-masked]>>
Cc: Alexander Vainshtein <[email-masked]<mailto:[email-masked]>>; Joel M. Halpern <[email-masked]<mailto:[email-masked]>>; Shraddha Hegde <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [spring] Spring protection - determining applicability

Hi Ketan,

Thanks,
Ketan

Is it correct ?

Thx
R

Hope that clarifies?

Thanks,
Ketan

Ketan, and all,

Regards,
Sasha

Hi Sasha,

Thanks,
Ketan

Hi all,

My 2c.

Hi All,

Thanks,
Ketan

-----Original Message-----
From: spring <[email-masked]<mailto:[email-masked]>> On Behalf Of Joel M. Halpern
Sent: 04 August 2020 20:25
To: Alexander Vainshtein <[email-masked]<mailto:[email-masked]>>; Shraddha Hegde <shraddha=[email-masked]<mailto:shraddha=[email-masked]>>; [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>; Robert Raszuk <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; Joel M. Halpern <[email-masked]<mailto:[email-masked]>>
Subject: Re: [spring] Spring protection - determining applicability

Thank you,
Joel

---

From: Jeff Tantsura <[email-masked]>
Date: Fri, 14 Aug 2020 14:15:25 -0700

This is very similar to RSVP-TE, path vs link/node protection and usually dictated by the business logic, the triggers are obviously very different, head-end being notified of the failure on a path and switching to the backup path vs reaction to a local failure, so same considerations apply:
-more state
-pre-reserved resources
while
-predictable
-meets SLA (as good as primary)
vs
-less state
-local
-best effort / can cause congestions

Cheers,
Jeff
On Aug 14, 2020, 10:46 AM -0700, Ketan Talaulikar (ketant) <ketant=[email-masked]>, wrote:
> On Fri, Aug 14, 2020 at 6:17 PM Ketan Talaulikar (ketant) <[email-masked]> wrote:
> > quote_type
> > Hi Robert,
> >
> > On Fri, Aug 14, 2020 at 5:32 PM Ketan Talaulikar (ketant) <[email-masked]> wrote:
> > > quote_type
> > > Hi Sasha,
> > >
> > > >      > failure) you suddenly start dropping flows in spite of SPT offering
> > > >      > On Mon, Aug 3, 2020 at 8:10 PM Joel M. Halpern <[email-masked]
> > > >      > Suppose that the PCE has specified the path to meet some complex te
> > > >      > were.  And for some kinds of traffic, it is better to drop the packet
> > > >      > > 2.Segments that represent topological instructions can be bypassed,
> > > >      > > <https://clicktime.symantec.com/345NLCB6TydxuuqUjtcDRZy6H2?u=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Frfc8402
> > > >      > >     In the context of an IGP-based distributed control plane, two
> > > >      > >
> > > >      > > topological segments are defined: the IGP-Adjacency segment and the
> > > >      > >
> > > >      > >     IGP-Prefix segment.
> > > >      > >
> > > >      > > topological segments are defined: the BGP peering segment and the
> > > >      > >
> > > >      > >     BGP-Prefix segment.
> > > >      > >
> > > >      > > In the case of SR-MPLS this differentiation is assumed in Section
> > > >      > 3.4 of
> > > >      > > label in the label stack is understood in the IGP domain.  When the
> > > >      > >
> > > >      > >     provider edge routers exchange service labels via BGP or some
> > > >      > other
> > > >      > >
> > > >      > >     non-IGP mechanism the bottom label is not understood in the IGP
> > > >      > >
> > > >      > >     domain.
> > > >      > >
> > > >      > >     [RFC8679 <https://clicktime.symantec.com/3JfvtBAmaQPN1jA3pM6TdCE6H2?u=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Frfc8679
> > > >      > > The scenarios in which  differentiation between “topological” and
> > > >      > > I am not sure if usage of such “combined” SIDs could be prevented
> > > >      > or at
> > > >      > > least discouraged.
> > > >      > >
> > > >      > > Subject: Re: [spring] Spring protection - determining applicability
> > > >      > >
> > > >      > > Hi Joel,
> > > >      > >
> > > >      > > I also don't think there is a "can be bypassed" indication in the
> > > >      > >  > Subject: [spring] Spring protection - determining applicability
> > > >      > >
> > > >      > >  >
> > > >      > >
> > > >      > >  > I have been reading the various repair drafts, and the various
> > > >      > >
> > > >      > >  > How does a node that is doing some form of bypass (suppose, for
> > > >      > >
> > > >      > >  > If the path was just for TE, then it is "safe" if the new path
> > > >      > meets
> > > >      > >
> > > >      > >  > Or was some other necessary programmatic transform (wince we are
> > > >      > >
> > > >      > >  > deliberately vague about what nodes can do when asked suitably.)
> > > >      > >
> > > >      > >  >
> > > >      > >
> > > >      > <https://clicktime.symantec.com/3GWT9fyjaFi3FcvHDvoodvS6H2?u=http%3A%2F%2F2Fwww.ietf.org
> > > >      > > proprietary for the sole use of the intended recipient. Any review,
> > > >      > > recipient, please notify the sender immediately and then delete all
> > > >      > > [email-masked] <mailto:[email-masked]> <mailto:[email-masked]>
> > > >      > > https://clicktime.symantec.com/3Q1xsKGyMzNJCKyVPByhqLq6H2?u=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring
> > > >      > [email-masked] <mailto:[email-masked]> <mailto:[email-masked]>
> > > >      > https://clicktime.symantec.com/3Q1xsKGyMzNJCKyVPByhqLq6H2?u=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 14 Aug 2020 23:30:39 +0200

Jeff,

> This is very similar to RSVP-TE

I would rather differ on that statement.

See if you are using SR just for TE you are 100% right.

But if your SIDs embed additional local SR node processing functions this
suddenly becomes a completely different game. Let's keep this in mind in
this thread/topic.

Kind regards,
R.

On Fri, Aug 14, 2020 at 11:15 PM Jeff Tantsura <[email-masked]>
wrote:

> This is very similar to RSVP-TE, path vs link/node protection and usually
> dictated by the business logic, the triggers are obviously very different,
> head-end being notified of the failure on a path and switching to the
> backup path vs reaction to a local failure, so same considerations apply:
> -more state
> -pre-reserved resources
> while
> -predictable
> We do not have a signalling mechanism in IGPs today to indicate a
> “bypass-able” indication for Prefix SIDs. If there was a desire for it, an
> IGP extension would be required (there is none in progress AFAIK). Note
> that this results in doubling the prefix SID scale (global labels) in the
> network. So I would not go about this trivially.
>
>
>
> I think it helps to get more inputs and perspectives from operators on
> their views for doing a bypass via local protection for segments in an SR
> Policy. There may be those that prefer end-to-end path protection using a
> fallback path that is say disjoint with the primary but provides an
> appropriate SLA/intent?
>
>
>
> Thanks,
>
> Ketan
>
>
>
> *Sent:* 14 August 2020 23:04
> Is there some work in progress to add it to those protocols or have we
> just documented need for a short LSR draft  ?
>
>
>
> Thx,
>
> R.
>
>
>
>
>
> <[email-masked]%20%0b> > <mailto:[email-masked]
> <[email-masked]%20%0b> > <
> <[email-masked]%20%0b> > <mailto:[email-masked]
> <[email-masked]%20%0b> > <
> <[email-masked]%0b> >     <mailto:[email-masked]
> <[email-masked]%0b> >     <mailto:[email-masked]%20%0b
> <https://clicktime.symantec.com/3CCcy9mY6cMfbk7QfjhiA3R6H2?u=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-bess-srv6-services-04%0b>
> >     <
> <https://clicktime.symantec.com/345NLCB6TydxuuqUjtcDRZy6H2?u=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Frfc8402%0b>
> >     <
> <https://clicktime.symantec.com/3JbSWGx5DAfNPsZdhpExxx96H2?u=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-hegde-spring-node-protection-for-sr-te-paths-07%23section-3.4%0b>
> >     <
> <https://clicktime.symantec.com/3JfvtBAmaQPN1jA3pM6TdCE6H2?u=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Frfc8679%0b>
> >     <
> <[email-masked]%0b> >     <mailto:[email-masked]%0b
> <[email-masked]%0b> >     <mailto:[email-masked]%0b
> <[email-masked]%20%3cmailto:[email-masked]%0b> >     <
> <[email-masked]%20%3cmailto:[email-masked]%0b> >     <
> <https://clicktime.symantec.com/367qhU4KiUkzW9uGC4eAvP46H2?u=https%3A%252%0b>
> >     <
> <https://clicktime.symantec.com/3GWT9fyjaFi3FcvHDvoodvS6H2?u=http%3A%2F%2F2Fwww.ietf.org%0b>
> >     <
> <[email-masked]%0b> >     <mailto:[email-masked]%0b <[email-masked]%0b>>>
> <https://clicktime.symantec.com/3NrDnSTReXh671G79BVGEq16H2?u=https%3A%25%0b>

---

From: Jeff Tantsura <[email-masked]>
Date: Fri, 14 Aug 2020 14:44:17 -0700

Robert,

Agreed and apologies, hit send before finishing the email (it is Friday) ;-)

Path protection in this case make more sense and is much less complex,
if in the pathA (A->B->C) node B is a service node, it can’t be bypassed (node protected) if the link between A and B breaks
however it could have a backup pathB (A->X->C) where X is the service node, potentially synchronizing its state with the node B.

To my previous email - at expense of more state, we provide path and service protection, hence the similarity with RSVP-TE trade-offs.

Cheers,
Jeff
On Aug 14, 2020, 2:30 PM -0700, Robert Raszuk <[email-masked]>, wrote:
> But if your SIDs embed additional local SR node processing functions this suddenly becomes a completely different game. Let's keep this in mind in this thread/topic.
>
> Kind regards,
> R.
>
>
> > On Fri, Aug 14, 2020 at 11:15 PM Jeff Tantsura <[email-masked]> wrote:

---

From: Jeff Tantsura <[email-masked]>
Date: Fri, 14 Aug 2020 14:47:21 -0700

PCE computation in this case is trivial too(must traverse node B or node X) else FAIL.

Cheers,
Jeff

---

From: Gyan Mishra <[email-masked]>
Date: Fri, 14 Aug 2020 22:44:34 -0400

Catching up on this thread as it is a interesting topic as FRR 1:N link
protection, node protection and path protection is critical to operators.

There are multiple somewhat orthogonal topics brought up in the discussion.

Excluding SR SFC from “bypass” capable node such for appliances such as
firewalls and load balancer.  Makes sense.  I would not think SFC would be
in a PLR path to merger point but I could be mistaken.

The goal of SR is eliminating state and so having TE like state is
undesirable.

Intent based instantiation of bypass via SR-TE from network feedback at PLR
detection node of a failure and make before break pre computed backup paths
that can.

It would make sense that SR-TE binding SID policy would be appropriate for
RSVP like FRR link node or path protection.

My thoughts on this topic of SR protection is that don’t we already have
FRR protection natively without requiring SR-TE BSID or any additional
undesirable state maintenance with TI-LFA.

Thanks

Gyan

On Fri, Aug 14, 2020 at 5:47 PM Jeff Tantsura <[email-masked]>
wrote:

> if in the pathA (A->B->C) node B is a service node, it can’t be bypassed
> (node protected) if the link between A and B breaks
>
>
> however it could have a backup pathB (A->X->C) where X is the service
> node, potentially synchronizing its state with the node B.
>
>
>
>
>
> To my previous email - at expense of more state, we provide path and
> service protection, hence the similarity with RSVP-TE trade-offs.
>
>
>
>
>
>
>
> Cheers,
>
> Jeff
>
>
>
>
>
>
>> But let me just observe that I purposely did not mention about SR
>> policies as we are not able to signal the intent with the packets itself.
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> So all we have there is SIDs. BSIDs or prefix SIDs need to be flooded
>> with information if policies build with using them are bypass eligible or
>> not.
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> The service node advertises its own Prefix SID.. The service function
>> that this service node implements does not require any context (i.e. all
>> packets arriving at the node are subjected to that service). Therefore the
>> service node does not need to receive a packet with it’s own Prefix SID.
>>
>>
>>
>>
>>
>> Shraddha Hegde <[email-masked]>;
>> not have a notion of how "strict or not" is the SLA that is being provided
>> by the SR Policy. Awareness of that notion exists at the SR Policy headend
>> and/or computation-node.
>>
>>
>>
>>
>>
>> To: Alexander Vainshtein <[email-masked]>; Shraddha Hegde
>> <shraddha=[email-masked]>;
>> > Such an option indeed does not exist in SR-TE today, but would be easy
>>
>>
>> > to provide if so desired IMHO.
>>
>>
>> >
>>
>>
>> > <[email-masked] <mailto:[email-masked] <[email-masked]>
>> >>
>>
>>
>> mailto:[email-masked] <[email-masked]>
>> >>
>>
>>
>> > That goes in line of recent wave of negative routing implementations
>>
>>
>> > (RIFT) or discussions (LSR)
>>
>>
>> >
>>
>>
>> > Best,
>>
>>
>> > R.
>>
>>
>> >
>>
>>
>> >     *Subject:* Re: [spring] Spring protection - determining
>>
>>
>> > applicability
>>
>>
>> >
>>
>>
>> >      > Because if we are talking about IP networking I have two
>>
>>
>> >     observations:
>>
>>
>> >      >
>>
>>
>> >      > A) If you need to traverse via a specific node (ie. firewall) you
>>
>>
>> >     better
>>
>>
>> >      > be hijacked today such that destination address of the packet is
>>
>>
>> >     ignored.
>>
>>
>> >      >
>>
>>
>> >      > B) Have you seen any IP network where upon topology change (link
>>
>>
>> >     or node
>>
>>
>> >      > Well less serious for TE SIDs, I am not sure the problem is
>>
>>
>> >     restricted
>>
>>
>> >      > to just service SIDs.
>>
>>
>> >      >
>>
>>
>> >      > objective.  The bypass node has no way of knowing what those
>>
>>
>> >      > constraints
>>
>>
>> >      > than to deliver it outside the envelop.  I suspect that the right
>>
>>
>> >      > answer
>>
>>
>> >      > to this is "too bad"..  If so, as with the distinction regarding
>>
>>
>> >     service
>>
>>
>> >      > > 1.There is clear differentiation between "topological" and
>>
>>
>> >     "service"
>>
>>
>> >      > > corresponding IGP advertisements) represent topological
>>
>>
>> >     instructions
>>
>>
>> >      > >
>>
>>
>> >      > > while segments that represent service instructions require
>>
>>
>> >      > alternative
>>
>>
>> >      > > protection mechanisms.
>>
>>
>> >      > >
>>
>>
>> >      > >     The node protection mechanism described in the previous
>>
>>
>> >     sections
>>
>>
>> >      > >
>>
>>
>> >      > >     depends on the assumption that the label immediately below
>>
>>
>> >      > the top
>>
>>
>> >      > >
>>
>>
>> >      > > “service” instructions is broken are indeed problematic. E.g.,
>>
>>
>> >      > consider
>>
>>
>> >      > > the use case in which a Node SID in the ERO of a SR-TE path
>>
>>
>> >      > identifies a
>>
>>
>> >      > > node that acts as a firewall for all packets it receives, i.e.,
>>
>>
>> >      > provides
>>
>>
>> >      > > the firewall service without any dedicated service SID
>>
>>
>> >      > identifying it.
>>
>>
>> >      > > One could say that the Node SID of such a node would combine
>>
>>
>> >      > topological
>>
>>
>> >      > > and service instructions thus breaking the differentiation
>>
>>
>> >      > between the two.
>>
>>
>> >      > >
>>
>>
>> >      > > I think this is a good point that may not be discussed in the
>>
>>
>> >      > past. And
>>
>>
>> >      > > IMHO, the information advertised by routing is neutral, such
>>
>>
>> >      > information
>>
>>
>> >      > > (can or cannot be bypassed) is more path specific, thus
>>
>>
>> >     normally the
>>
>>
>> >      > > controller should be responsible for deciding whether/which SID
>>
>>
>> >      > can be
>>
>>
>> >      > > bypassed.
>>
>>
>> >      > >
>>
>>
>> >      > > Best regards,
>>
>>
>> >      > >
>>
>>
>> >      > > Mach
>>
>>
>> >      > >
>>
>>
>> >      > >  > (WG Chair hat Off, this is merely a note from a slightly
>>
>>
>> >      > confused WG
>>
>>
>> >      > >
>>
>>
>> >      > >  > participant.)
>>
>>
>> >      > >
>>
>>
>> >      > >  >
>>
>>
>> >      > >
>>
>>
>> >      > >  > networks programming and service programming draft, and I am
>>
>>
>> >      > trying to
>>
>>
>> >      > >
>>
>>
>> >      > >  > simplicity, it is Node N2 deciding to bypass the next SID
>> for
>>
>>
>> >      > a failed
>>
>>
>> >      > >
>>
>>
>> >      > >  > the TE criteria.  or maybe it is safe if it is even close,
>> as
>>
>>
>> >      > long as
>>
>>
>> >      > >
>>
>>
>> >      > >  > But what if the node were a Firewall, included to meet legal
>>
>>
>> >      > > requirements?
>>
>>
>> >      > >
>>
>>
>> >      > >  > spring@ietf..org <[email-masked]> <mailto:[email-masked]
>> <[email-masked]>>
>>
>>
>> <https://clicktime.symantec.com/3Q7vX2qWSUdWVc892XuXy2H6H2?u=https%3A%2F%2Furldefense..com%2Fv3%2F__https%3A%2Fclicktime.symantec.com%2F367qhU4KiUkzW9uGC4eAvP46H2%3Fu%3Dhttps%2A3A%2A2__%3BJSU%21%21NEt6yMaO-gk%21S0Yusx9FYNE8E_R1oiQAtQxgm0x0wxqguoZHgwp6vpRHOGt8AkTRDuiDo6HwPLil%24>
>> >
>>
>>
>> >      > >
>>
>>
>> >      >
>>
>>
>> >     <
>> <https://clicktime.symantec.com/39NznmYBtRuHARhGJ5W5dGB6H2?u=https%3A%2F%2Furldefense..com%2Fv3%2F__http%3A%2F2Fwww.ietf.org__%3B%21%21NEt6yMaO-gk%21S0Yusx9FYNE8E_R1oiQAtQxgm0x0wxqguoZHgwp6vpRHOGt8AkTRDuiDo-pPCjvR%24>
>> >
>>
>>
>> >      > <
>> <[email-masked]%0b> >     <mailto:[email-masked]%0b
>> <[email-masked]%0b>>> <mailto:[email-masked] <[email-masked]>>>
>>
>>
>> >      > >
>>
>>
>> >      > >
>>
>>
>> >      >
>>
>>
>> >
>> <https://clicktime.symantec.com/3BhyEtx4Q7n74BhiRnfMJtT6H2?u=https%3A%2F%2Furldefense..com%2Fv3%2F__https%3A%2Fclicktime.symantec.com%2F367qhU4KiUkzW9uGC4eAvP46H2%3Fu%3Dhttps%2A3A%2A2F%2A2Fwww.ietf.org%2A2Fmailman%2A2Flistinfo%2A2Fspring__%3BJSUlJSUl%21%21NEt6yMaO-gk%21S0Yusx9FYNE8E_R1oiQAtQxgm0x0wxqguoZHgwp6vpRHOGt8AkTRDuiDo-hR3gAD%24>
>> >
>>
>>
>> >      > >
>>
>>
>> >      > >
>>
>>
>> >      > >
>>
>>
>> >      > >
>>
>>
>> >      >
>>
>>
>> >
>> >      > > information of Ribbon Communications Inc. that is confidential
>>
>>
>> >      > and/or
>>
>>
>> >      > > disclosure, reliance or distribution by others or forwarding
>>
>>
>> >     without
>>
>>
>> >      > > express permission is strictly prohibited. If you are not the
>>
>>
>> >      > intended
>>
>>
>> >      > > recipient, please notify the sender immediately and then
>> delete all
>>
>>
>> <https://clicktime.symantec.com/3NrDnSTReXh671G79BVGEq16H2?u=https%3A%2F%2Furldefense..com%2Fv3%2F__https%3A%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring__%3B%21%21NEt6yMaO-gk%21S0Yusx9FYNE8E_R1oiQAtQxgm0x0wxqguoZHgwp6vpRHOGt8AkTRDuiDo5KlPnbj%24>
>> >
>>
>>
>> >      > >
>>
>>
>> >      >
>>
>>
>> <https://clicktime.symantec.com/3NrDnSTReXh671G79BVGEq16H2?u=https%3A%2F%2Furldefense..com%2Fv3%2F__https%3A%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring__%3B%21%21NEt6yMaO-gk%21S0Yusx9FYNE8E_R1oiQAtQxgm0x0wxqguoZHgwp6vpRHOGt8AkTRDuiDo5KlPnbj%24>
>> >
>>
>>
>> >      >
>>
>>
>> >
>>
>>
>> > 2F%2Furldefense.com%2Fv3%2F__https%3A%2Fwww.ietf.org
>> <http://2Fwww..ietf.org>%2Fmailman%2Flisti
>>
>>
>> > ----------------------------------------------------------------------
>>
>>
>> > --
>>
>>
>> > recipient, please notify the sender immediately and then delete all
>>
>>
>> > ----------------------------------------------------------------------
>>
>>
>> > --
>>
>>
>>
>>
>>
> --

<http://www.verizon.com/>

*Gyan Mishra*

*Network Solutions A**rchitect *

*M 301 502-134713101 Columbia Pike *Silver Spring, MD

---

From: Jeff Tantsura <[email-masked]>
Date: Mon, 17 Aug 2020 14:03:32 -0700

Gyan,

TI-LFA computation is local to the PLR and is topology dependent, e.g change in downstream topology could/would influence the choice of MP (PQ) node.
While an implementation could take into consideration some additional meta-data (e.g. locally provisioned SRLG, usually used to avoid protected and protecting ports on the same line card), this is not a standardized method.
If a service node must be included in a backup path, there’s a state associated with it as well as distribution of the state involved.

Back to my point, removing state and introducing services in the network (at the very least at the computational logic and head-end level) are mutually exclusive, trade-offs are inevitable (You can't eat your cake and have it).
Keeping the state limited to:
- a logically centralized computational logic (aka PCE) - off path, scales horizontally, could use additional business logic for the path computation, example - CPU/memory consumption on a service node
- head-end - anchor to primary/backup paths
seems like a reasonable set of trade-offs.

Cheers,
Jeff
On Aug 14, 2020, 7:44 PM -0700, Gyan Mishra <[email-masked]>, wrote:
>
> Catching up on this thread as it is a interesting topic as FRR 1:N link protection, node protection and path protection is critical to operators.
>
> Excluding SR SFC from “bypass” capable node such for appliances such as firewalls and load balancer.  Makes sense.  I would not think SFC would be in a PLR path to merger point but I could be mistaken.
>
> The goal of SR is eliminating state and so having TE like state is undesirable.
>
> Intent based instantiation of bypass via SR-TE from network feedback at PLR detection node of a failure and make before break pre computed backup paths that can.
>
> It would make sense that SR-TE binding SID policy would be appropriate for RSVP like FRR link node or path protection.
>
> My thoughts on this topic of SR protection is that don’t we already have FRR protection natively without requiring SR-TE BSID or any additional undesirable state maintenance with TI-LFA.
>
> Thanks
>
> Gyan
>
> > On Fri, Aug 14, 2020 at 5:47 PM Jeff Tantsura <[email-masked]> wrote:
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > > > > > > > > The service node advertises its own Prefix SID.. The service function that this service node implements does not require any context (i.e. all packets arriving at the node are subjected to that service). Therefore the service node does not need to receive a packet with it’s own Prefix SID.
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > > <mailto:[email-masked]>>; [email-masked]
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > > <mailto:[email-masked]>
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > >      > to this is "too bad"..  If so, as with the distinction regarding
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > >     service
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > >      > >  > spring@ietf..org <mailto:[email-masked]>
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > >     <mailto:[email-masked]>
> > > > > > > > > >
> > > > > > > > > >
> Gyan Mishra
> Network Solutions Architect
> M 301 502-1347
> 13101 Columbia Pike
> Silver Spring, MD
>

---

From: Robert Raszuk <[email-masked]>
Date: Mon, 17 Aug 2020 23:25:19 +0200

Hi Jeff,

This is not about more state in the network nor about including mirror
service node in the backup path for some flows.

The thread is about possession of enough information in PLR to either take
the packet and shift it over backup path or just drop it.

- - -

Btw - path protection is completely orthogonal to the above.

Cheers,
Robert.

On Mon, Aug 17, 2020 at 11:03 PM Jeff Tantsura <[email-masked]>
wrote:

> Gyan,
>
> TI-LFA computation is local to the PLR and is topology dependent, e.g
> change in downstream topology could/would influence the choice of MP (PQ)
> node.
> While an implementation could take into consideration some additional
> meta-data (e.g. locally provisioned SRLG, usually used to avoid protected
> and protecting ports on the same line card), this is not a standardized
> method.
> If a service node must be included in a backup path, there’s a state
> associated with it as well as distribution of the state involved.
>
> Back to my point, removing state and introducing services in the network
> (at the very least at the computational logic and head-end level) are
> mutually exclusive, trade-offs are inevitable (You can't eat your cake and
> have it).
> - a logically centralized computational logic (aka PCE) - off path, scales
> horizontally, could use additional business logic for the path computation,
> example - CPU/memory consumption on a service node
> Intent based instantiation of bypass via SR-TE from network feedback at
> PLR detection node of a failure and make before break pre computed backup
> paths that can.
>
>>> This is very similar to RSVP-TE, path vs link/node protection and
>>> usually dictated by the business logic, the triggers are obviously very
>>> different, head-end being notified of the failure on a path and switching
>>> to the backup path vs reaction to a local failure, so same considerations
>>> apply:
>>>
>>>
>>> -more state
>>>
>>>
>>> -pre-reserved resources
>>>
>>>
>>> while
>>>
>>>
>>> -predictable
>>>
>>>
>>> Unless we signal which prefix SID is protection eligible and which is
>>> not how would other nodes know if they can protect it or not ?
>>>
>>>
>>> *[KT] Yes. We have a mechanism to indicate which adj-SIDs have
>>> protection (that mechanism only provides link protection to get to the
>>> neighbor node) so the SR Policy computation is able to indicate whether
>>> that specific link is “bypass-able” or not by its choice of protected or
>>> unprotected adj-SIDs respectively.*
>>>
>>>
>>>
>>>
>>>
>>> *Thanks,*
>>>
>>>
>>> *Ketan*
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> Is it correct ?
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> Thx
>>>
>>>
>>>
>>>
>>>
>>>
>>> R
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> SR-MPLS - because the advertising node will not receive them and therefore
>>> can hardly be expected to associate any service function with them.
>>>
>>>
>>>
>>>
>>>
>>> that just applies locally configured default rules on it), then I don’t see
>>> why PHP could not be done for a Prefix SID associated with a service node.
>>>
>>>
>>>
>>>
>>>
>>> [email-masked]>; Alexander Vainshtein <
>>> [email-masked]>; Shraddha Hegde <[email-masked]>;
>>> for nodes to drop the packets meant for the "active segment" than to bypass
>>> it. When this mechanism is used along side SRTE path monitoring mechanisms,
>>> it enables the headend to detect the failure and fallback to an alternate
>>> path using the path protection approach. This is something that is
>>> described and in use in deployments today [1]..
>>>
>>>
>>>
>>>
>>>
>>> Thanks,
>>>
>>>
>>> Ketan
>>>
>>>
>>>
>>>
>>>
>>> [1]
>>> To: Alexander Vainshtein <[email-masked]>; Shraddha
>>> Hegde <shraddha=[email-masked]>;
>>> > *Cc:* [email-masked] <mailto:[email-masked] <[email-masked]>>;
>>> Joel M. Halpern
>>>
>>>
> *M 301 502-1347 13101 Columbia Pike *Silver Spring, MD
>
>

---

From: Jeff Tantsura <[email-masked]>
Date: Mon, 17 Aug 2020 14:54:27 -0700

Hi Robert,

"possession of enough information in PLR” what do you call this, if not more state, given this information is not present there today?

Cheers,
Jeff
On Aug 17, 2020, 2:25 PM -0700, Robert Raszuk <[email-masked]>, wrote:
> Hi Jeff,
>
> This is not about more state in the network nor about including mirror service node in the backup path for some flows.
>
> The thread is about possession of enough information in PLR to either take the packet and shift it over backup path or just drop it.
>
> - - -
>
> > On Mon, Aug 17, 2020 at 11:03 PM Jeff Tantsura <[email-masked]> wrote:
> > > Gyan,
> > >

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 18 Aug 2020 00:15:14 +0200

Hi Jeff,

If one would allocate SIDs in a smart way they can include algorithmically
encoded information if packets are FRR eligible. No increase in IGP
flooding. No duplication of SID space. Just local behaviour.

For SRv6 - trivial. For SR-MPLS, also pretty simple provided one would be
keen on using MPLS forwarding paradigm for some time :)

Hint: think even/odd (1 bit in the SID) - well known in a domain - and used
correctly by your vendor.

Best,
R.

On Mon, Aug 17, 2020 at 11:54 PM Jeff Tantsura <[email-masked]>
wrote:

> Hi Robert,
>
> "possession of enough information in PLR” what do you call this, if not
> more state, given this information is not present there today?
>
> Cheers,
> Jeff
>> - a logically centralized computational logic (aka PCE) - off path,
>> scales horizontally, could use additional business logic for the path
>> computation, example - CPU/memory consumption on a service node
>> It would make sense that SR-TE binding SID policy would be appropriate
>> for RSVP like FRR link node or path protection.
>>
>>> But if your SIDs embed additional local SR node processing functions
>>> this suddenly becomes a completely different game. Let's keep this in mind
>>> in this thread/topic.
>>>
>>>
>>>
>>>
>>>
>>> Kind regards,
>>>
>>>
>>> R.
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>> *[KT] Correct. To be more accurate, we need to consider this more in
>>>> the context of SLA or “intent” of SR Policies and which segments may be
>>>> And link protection MUST assure that packets will arrive at the
>>>> neighbor node via some other link regardless of further path towards
>>>> destination.
>>>>
>>>>
>>>> mailto:[email-masked]
>>>> <[email-masked]>>> wrote:
>>>>
>>>>
>>>> >
>>>>
>>>>
>>>> >     So –
>>>>
>>>>
>>>> >
>>>>
>>>>
>>>> >      > >  > the TE criteria.  or maybe it is safe if it is even
>>>> close, as
>>>>
>>>>
>>>> >      > long as
>>>>
>>>>
>>>> >      > >
>>>>
>>>>
>>>> >      > >  > spring@ietf..org <[email-masked]> <
>>>> https://clicktime.symantec.com/3NrDnSTReXh671G79BVGEq16H2?u=https%3A%
>>>>

---

From: Jeff Tantsura <[email-masked]>
Date: Mon, 17 Aug 2020 16:42:24 -0700

Ahh, overloading addressing semantics, odd addresses/labels go left while even go right, and you want this to be standardized ;-)

Cheers,
Jeff
On Aug 17, 2020, 3:15 PM -0700, Robert Raszuk <[email-masked]>, wrote:
> Hi Jeff,
>
> If one would allocate SIDs in a smart way they can include algorithmically encoded information if packets are FRR eligible. No increase in IGP flooding. No duplication of SID space. Just local behaviour.
>
> For SRv6 - trivial. For SR-MPLS, also pretty simple provided one would be keen on using MPLS forwarding paradigm for some time :)
>
> Hint: think even/odd (1 bit in the SID) - well known in a domain - and used correctly by your vendor.
>
> Best,
> R.
>
> > On Mon, Aug 17, 2020 at 11:54 PM Jeff Tantsura <[email-masked]> wrote:
> > > Hi Robert,
> > >

---

From: Martin Horneffer <[email-masked]>
Date: Tue, 18 Aug 2020 16:50:41 +0200

A few thoughts from my (operator's) PoV:

  - The disussion is a very good and important one. It probably should 
be discussed and documented well in order to justify the proposed 
protections mechanisms.

  - Not all operators seem to have the same requirements.
     (A somewhat similar discussion might be the one for disjoint paths. 
Those are often equired by voice signalling applications. In some cases 
the voice service demands that traffic is blackholed rather than on 
forwarded on the wrong path. In other cases disjoint paths are just 
required for the "good case". Traffic MAY be forwarded on the wrong 
path, as long as the network just makes sure the traffic on the other 
path is never affected by the same failure.)

  - Personally I would hate to see yet another IGP extension for this 
purpose.

  - I would rather prefer a good discussion of what can be achieved by 
using easy to make switches:
     - The protection behaviour could be switched on or off per node.
        - An operator with strict "some traffic may never touch certain 
parts of the network" requirements might switch off the behaviour, while 
others might switch it on.
     - A node could allow a switch even individually for every port or 
neighbor.
        - If a node knows that one of it's neighbours is a service node 
rather than a plain topological one, it could switch off protection. 
This is how I would prefer to solve the problem with serrvice nodes.

Should this be discussed in the protection document, or in a separate one?

Best regards, Martin

Am 14.08.20 um 19:45 schrieb Ketan Talaulikar (ketant):
> “bypass-able” indication for Prefix SIDs. If there was a desire for 
> it, an IGP extension would be required (there is none in progress 
> AFAIK). Note that this results in doubling the prefix SID scale 
> (global labels) in the network. So I would not go about this trivially.
>
> their views for doing a bypass via local protection for segments in an 
> SR Policy. There may be those that prefer end-to-end path protection 
> using a fallback path that is say disjoint with the primary but 
> provides an appropriate SLA/intent?
>
> Thanks,
>
> Ketan
>
> *From:*Robert Raszuk <[email-masked]>
> with information if policies build with using them are bypass eligible 
> or not.
>
> I was actually under the impression that this is already there and I 
> am just not aware, but looking deeper indeed I do not see this marking 
> neither in ISIS nor OSPF for prefix SIDs.
>
> On Fri, Aug 14, 2020 at 6:17 PM Ketan Talaulikar (ketant) 
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>     Hi Robert,
>
>     *From:*Robert Raszuk <[email-masked] <mailto:[email-masked]>>
>     *To:* Ketan Talaulikar (ketant) <[email-masked]
>     <mailto:[email-masked]>>
>     *Cc:* Alexander Vainshtein <[email-masked]
>     <mailto:[email-masked]>>; Joel M. Halpern
>     <[email-masked] <mailto:[email-masked]>>; Shraddha Hegde
>     <[email-masked] <mailto:[email-masked]>>;
>     <mailto:[email-masked]>>; [email-masked]
>     <mailto:[email-masked]>
>     */[KT] I understand. We need to be mindful of implications of
>     protection schemes for the SLAs/intent of SR Policies./*
>
>     Unless we signal which prefix SID is protection eligible and which
>     is not how would other nodes know if they can protect it or not ?
>
>     */[KT] Correct. To be more accurate, we need to consider this more
>     in the context of SLA or “intent” of SR Policies and which
>     segments may be “bypass-able” for local protection for some of
>     those SR Policies. We also have path-protection mechanisms./*
>
>     neighbor node via some other link regardless of further path
>     towards destination.
>
>     */[KT] Yes. We have a mechanism to indicate which adj-SIDs have
>     protection (that mechanism only provides link protection to get to
>     the neighbor node) so the SR Policy computation is able to
>     indicate whether that specific link is “bypass-able” or not by its
>     choice of protected or unprotected adj-SIDs respectively./*
>
>     *//*
>
>     */Thanks,/*
>
>     */Ketan/*
>
>     Is it correct ?
>
>     Thx
>
>     R
>
>     On Fri, Aug 14, 2020 at 5:32 PM Ketan Talaulikar (ketant)
>     <[email-masked] <mailto:[email-masked]>> wrote:
>
>         Hi Sasha,
>
>         The service node advertises its own Prefix SID. The service
>         function that this service node implements does not require
>         any context (i.e. all packets arriving at the node are
>         subjected to that service). Therefore the service node does
>         not need to receive a packet with it’s own Prefix SID.
>
>         Thus, we cannot assume that when PHP is used, then the SID is
>         only associated with a topological instruction.
>
>         Hope that clarifies?
>
>         Thanks,
>
>         Ketan
>
>         *From:*Alexander Vainshtein <[email-masked]
>         <mailto:[email-masked]>>
>         *To:* Ketan Talaulikar (ketant) <[email-masked]
>         <mailto:[email-masked]>>; Joel M. Halpern
>         <[email-masked] <mailto:[email-masked]>>; Shraddha
>         Hegde <[email-masked] <mailto:[email-masked]>>;
>         I have stated that, IMHO and FWIW, both Adj-SIDs and Prefix
>         SIDs that are advertised with PHP can  ONLY represent
>         topological instructions in SR-MPLS - because the advertising
>         node will not receive them and therefore can hardly be
>         expected to associate any service function with them.
>
>         *From:* Ketan Talaulikar (ketant) <[email-masked]
>         <mailto:[email-masked]>>
>         If the service does not need any additional context (e.g. a
>         firewall that just applies locally configured default rules on
>         it), then I don’t see why PHP could not be done for a Prefix
>         SID associated with a service node.
>
>         *From:*Alexander Vainshtein <[email-masked]
>         <mailto:[email-masked]>>
>         *To:* Ketan Talaulikar (ketant) <[email-masked]
>         <mailto:[email-masked]>>; Joel M. Halpern
>         <[email-masked] <mailto:[email-masked]>>; Alexander
>         Vainshtein <[email-masked]
>         <[email-masked] <mailto:[email-masked]>>;
>         Regarding the statement "Prefix SID could be just a
>         topological instruction or may also be used to steer the flow
>         to a node which is applying a service function to it":
>
>         I think that in SR-MPLS a Node SID that is advertised with PHP
>         aciton can be safely considered as "just a topological
>         instruction" by the PLR because the originating node will not
>         receive it.
>
>         <mailto:[email-masked]>> on behalf of Ketan
>         Talaulikar (ketant) <ketant=[email-masked]
>         First, thanks to Joel for bringing up the discussion. Clearly
>         we need a well-defined applicability statement for determining
>         applicability of protection for segment used in an SR Policy.
>         Some of this is captured in [1].
>
>         This is about local repair at a PLR. By it's very nature, the
>         PLR does not have a notion of how "strict or not" is the SLA
>         that is being provided by the SR Policy. Awareness of that
>         notion exists at the SR Policy headend and/or computation-node.
>
>         We have protected and un-protected variants of adjacency SIDs
>         to enable the computation to pick or the other based on the
>         "strictness" of the SLA requirement for picking that link. We
>         do not have such a notion for Prefix SIDs. One can say that we
>         could introduce signalling (e.g. a B flag) to indicate whether
>         a Prefix SID can be bypassed or not. This provides the
>         opportunity for the computation to use one or the other flavor
>         depending on the nature of the SLA for the SR Policy.
>
>         I have a problem and a concern in the assumption that PLRs can
>         assume that the currently defined variant of Prefix SIDs in
>         RFC8402 (and IGP specs) are "bypass-able".
>
>         As Joel and others have brought out, the Prefix SID could be
>         just a topological instruction or may also be used to steer
>         the flow to a node which is applying a service function to it.
>         In order to support a mix of SR Policies of different SLAs
>         (strict and not-strict), we need to enable the choice of SIDs
>         that indicates to the PLR whether they are "bypass-able" or not.
>
>         For the cases, where the SR Policy has a specific SLA, it is
>         required for nodes to drop the packets meant for the "active
>         segment" than to bypass it. When this mechanism is used along
>         side SRTE path monitoring mechanisms, it enables the headend
>         to detect the failure and fallback to an alternate path using
>         the path protection approach. This is something that is
>         <mailto:[email-masked]>> On Behalf Of Joel M. Halpern
>         What struck me, and prompted the starting question, was that
>         none of them were spelled out.  I see lots of interesting
>         ideas / proposals.
>         > *Cc:* [email-masked] <mailto:[email-masked]>; Joel M.
>         Halpern <[email-masked] <mailto:[email-masked]>>
>         > *To:* Robert Raszuk <[email-masked]
>         <mailto:[email-masked]> <mailto:[email-masked]>>
>         > <[email-masked] <mailto:[email-masked]>
>         <mailto:[email-masked]>>
>         > *From:* Robert Raszuk <[email-masked]
>         <mailto:[email-masked]> <mailto:[email-masked]>>
>         <mailto:[email-masked]%20%0b>>
>         >     *To:* Robert Raszuk <[email-masked]
>         <mailto:[email-masked]> <mailto:[email-masked]>>
>         <mailto:[email-masked]%0b>>    
>         <mailto:[email-masked]%0b>>    
>         >      > >  > F%2Fwww.ietf.org <http://2Fwww.ietf.org>
>         >    
>         <http://2Fwww.ietf.org>%2Fmailman%2Flisti
>         >
>         and/or proprietary for the sole use of the intended recipient.
>         Any review, disclosure, reliance or distribution by others or
>         forwarding without express permission is strictly prohibited.
>         If you are not the intended recipient, please notify the
>         sender immediately and then delete all copies, including any
>         attachments.
>

---

From: Alexander Vainshtein <[email-masked]>
Date: Tue, 18 Aug 2020 15:44:25 +0000

Martin,
Lots of thanks for an important input to this discussion.

I fully agree with you that ability to turn off the node protection scheme for a specific PLR neighbor (i.e., on a specific PLR port) by suitable local configuration in the PLR is definitely required. Such an ability would probably address most (if not all) scenarios associated with the so-called “service nodes” that cannot be bypassed.

I also think that service nodes that cannot be bypassed typically would advertise themselves as “stub nodes” in IGP in order to prevent inadvertent application of their service function to transit traffic (which could otherwise pass thru the service node due to some topology change). Therefore a local policy that would exclude IGP neighbors advertising  themselves as stub nodes in IGP from the node protection scheme could be also useful.

Last but not least, ability of the node to advertise a specific Prefix SID it originates as “not eligible for bypass protection” (e.g., using a new flag in the Prefix Node TLV for IS-IS or OSPF) should be considered.

My 2c,
Sasha

Office: +972-39266302
Cell:      +972-549266302

From: spring <[email-masked]> On Behalf Of Martin Horneffer
Sent: Tuesday, August 18, 2020 5:51 PM
To: [email-masked]
Cc: Alexander Vainshtein <[email-masked]>; Robert Raszuk <[email-masked]>; [email-masked] <[email-masked]>; Shraddha Hegde <[email-masked]>; Ketan Talaulikar (ketant) <ketant=[email-masked]>; Joel M. Halpern <[email-masked]>
Subject: Re: [spring] Spring protection - determining applicability

 - The disussion is a very good and important one. It probably should be discussed and documented well in order to justify the proposed protections mechanisms.

 - Not all operators seem to have the same requirements.
    (A somewhat similar discussion might be the one for disjoint paths. Those are often equired by voice signalling applications. In some cases the voice service demands that traffic is blackholed rather than on forwarded on the wrong path. In other cases disjoint paths are just required for the "good case". Traffic MAY be forwarded on the wrong path, as long as the network just makes sure the traffic on the other path is never affected by the same failure.)

 - Personally I would hate to see yet another IGP extension for this purpose.

 - I would rather prefer a good discussion of what can be achieved by using easy to make switches:
    - The protection behaviour could be switched on or off per node.
       - An operator with strict "some traffic may never touch certain parts of the network" requirements might switch off the behaviour, while others might switch it on.
    - A node could allow a switch even individually for every port or neighbor.
       - If a node knows that one of it's neighbours is a service node rather than a plain topological one, it could switch off protection. This is how I would prefer to solve the problem with serrvice nodes.

Best regards, Martin

Thanks,
Ketan

From: Robert Raszuk <[email-masked]><mailto:[email-masked]>
Sent: 14 August 2020 23:04
To: Ketan Talaulikar (ketant) <[email-masked]><mailto:[email-masked]>
Cc: Alexander Vainshtein <[email-masked]><mailto:[email-masked]>; Joel M. Halpern <[email-masked]><mailto:[email-masked]>; Shraddha Hegde <[email-masked]><mailto:[email-masked]>; [email-masked]<mailto:[email-masked]> <[email-masked]><mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [spring] Spring protection - determining applicability

Ketan,

Thx,
R.

Hi Ketan,

Thanks,
Ketan

Is it correct ?

Thx
R

Hope that clarifies?

Thanks,
Ketan

Ketan, and all,

Regards,
Sasha

Get Outlook for Android<https://clicktime.symantec.com/33Gi7zptDyRpRkx4RcDpbUC6H2?u=https%3A%2F%2Faka.ms%2Fghei36>

Hi Sasha,

Thanks,
Ketan

Hi all,

My 2c.

Hi All,

Thanks,
Ketan

-----Original Message-----
From: spring <[email-masked]<mailto:[email-masked]>> On Behalf Of Joel M. Halpern
Sent: 04 August 2020 20:25
To: Alexander Vainshtein <[email-masked]<mailto:[email-masked]>>; Shraddha Hegde <shraddha=[email-masked]<mailto:shraddha=[email-masked]>>; [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>; Robert Raszuk <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; Joel M. Halpern <[email-masked]<mailto:[email-masked]>>
Subject: Re: [spring] Spring protection - determining applicability

Thank you,
Joel

>      > >
>      > >  > F%2Fwww.ietf.org<https://clicktime.symantec.com/32yCkPKRruRj1ZfCvKgL2Gq6H2?u=http%3A%2F%2F2Fwww.ietf.org>
>     <https://clicktime.symantec.com/3NrDnSTReXh671G79BVGEq16H2?u=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring__%3B%21%21NEt6yMaO-gk%21S0Yusx9FYNE8E_R1…
<https://clicktime.symantec.com/3NrDnSTReXh671G79BVGEq16H2?u=https%3A%25%0b>> 2F%2Furldefense.com%2Fv3%2F__https%3A%2Fwww.ietf.org<https://clicktime.symantec.com/32yCkPKRruRj1ZfCvKgL2Gq6H2?u=http%3A%2F%2F2Fwww.ietf.org>%2Fmailman%2Flisti

spring mailing list

https://www.ietf.org/mailman/listinfo/spring<https://clicktime.symantec.com/35PXkKKT6EzLUVfDT443Qoy6H2?u=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring>

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 18 Aug 2020 18:02:27 +0200

> I also think that service nodes that cannot be bypassed typically would
advertise themselves as “stub nodes” in IGP

That is not always possible without extra cost. I guess "service" means
many things to various people :)

I have real production case where only a small subset of traffic should be
subject to firewall check or even subject to heavy interface ACL processing
on a transit node.

I guess the hope I have seen in this thread was ability to indicate such
mandate with different prefix SID.

If not of course there is few alternatives (within and outside of SR
domain) to use so this is not like end of the world. I guess here we are
sort of discussing how to handle various use cases.

Cheers,
R.

On Tue, Aug 18, 2020 at 5:44 PM Alexander Vainshtein <
[email-masked]> wrote:

> I fully agree with you that ability to turn off the node protection scheme
> for a specific PLR neighbor (i.e., on a specific PLR port) by suitable
> local configuration in the PLR is definitely required. Such an ability
> would probably address most (if not all) scenarios associated with the
> so-called “service nodes” that cannot be bypassed.
>
>
>
> I also think that service nodes that cannot be bypassed typically would
> advertise themselves as “stub nodes” in IGP in order to prevent inadvertent
> application of their service function to transit traffic (which could
> otherwise pass thru the service node due to some topology change).
> Therefore a local policy that would exclude IGP neighbors advertising
>  themselves as stub nodes in IGP from the node protection scheme could be
> also useful.
>
>
>
> Last but not least, ability of the node to advertise a specific Prefix SID
> it originates as “not eligible for bypass protection” (e.g., using a new
> flag in the Prefix Node TLV for IS-IS or OSPF) should be considered.
>
>
>
> My 2c,
>
> Sasha
>
>
>
> Office: +972-39266302
>
> Cell:      +972-549266302
>
> *From:* spring <[email-masked]> *On Behalf Of *Martin Horneffer
> *Sent:* Tuesday, August 18, 2020 5:51 PM
> *To:* [email-masked]
> *Cc:* Alexander Vainshtein <[email-masked]>; Robert Raszuk
> <[email-masked]>; [email-masked] <
> [email-masked]>; Shraddha Hegde <[email-masked]>;
> Ketan Talaulikar (ketant) <ketant=[email-masked]>; Joel M.
> Halpern <[email-masked]>
>  - The disussion is a very good and important one. It probably should be
> discussed and documented well in order to justify the proposed protections
> mechanisms.
>
> Those are often equired by voice signalling applications. In some cases the
> voice service demands that traffic is blackholed rather than on forwarded
> on the wrong path. In other cases disjoint paths are just required for the
> "good case". Traffic MAY be forwarded on the wrong path, as long as the
> network just makes sure the traffic on the other path is never affected by
> the same failure.)
>
> rather than a plain topological one, it could switch off protection. This
> is how I would prefer to solve the problem with serrvice nodes.
>
> *From:* Robert Raszuk <[email-masked]> <[email-masked]>
> *To:* Ketan Talaulikar (ketant) <[email-masked]> <[email-masked]>
> *Cc:* Alexander Vainshtein <[email-masked]>
> <[email-masked]>; Joel M. Halpern <[email-masked]>
> <[email-masked]>; Shraddha Hegde <[email-masked]>
> <[email-masked]>; [email-masked]
> <[email-masked]> <[email-masked]>;
> [email-masked]
> <https://clicktime.symantec.com/33Gi7zptDyRpRkx4RcDpbUC6H2?u=https%3A%2F%2Faka.ms%2Fghei36>
>
>
> <https://clicktime.symantec.com/32yCkPKRruRj1ZfCvKgL2Gq6H2?u=http%3A%2F%2F2Fwww.ietf.org>
> >     <
> <https://clicktime.symantec.com/32yCkPKRruRj1ZfCvKgL2Gq6H2?u=http%3A%2F%2F2Fwww.ietf.org>
> %2Fmailman%2Flisti
> https://www.ietf.org/mailman/listinfo/spring <https://clicktime.symantec.com/35PXkKKT6EzLUVfDT443Qoy6H2?u=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring>
>
>
>

---

From: Shraddha Hegde <[email-masked]>
Date: Tue, 18 Aug 2020 16:16:33 +0000

Martin,

Ability to turn off node protection on a per neighbor/port basis is a useful input.
I'll add a "operational consideration" section in the node-protection draft to include this point.

Rgds
Shraddha

Juniper Business Use Only
From: Martin Horneffer <[email-masked]>
Sent: Tuesday, August 18, 2020 8:21 PM
To: [email-masked]
Cc: Ketan Talaulikar (ketant) <ketant=[email-masked]>; Robert Raszuk <[email-masked]>; Alexander Vainshtein <[email-masked]>; Joel M. Halpern <[email-masked]>; Shraddha Hegde <[email-masked]>; [email-masked] <[email-masked]>
Subject: Re: [spring] Spring protection - determining applicability

Best regards, Martin

We do not have a signalling mechanism in IGPs today to indicate a "bypass-able" indication for Prefix SIDs. If there was a desire for it, an IGP extension would be required (there is none in progress AFAIK). Note that this results in doubling the prefix SID scale (global labels) in the network. So I would not go about this trivially.

Thanks,
Ketan

Ketan,

Thx,
R.

Hi Ketan,

Unless we signal which prefix SID is protection eligible and which is not how would other nodes know if they can protect it or not ?
[KT] Correct. To be more accurate, we need to consider this more in the context of SLA or "intent" of SR Policies and which segments may be "bypass-able" for local protection for some of those SR Policies. We also have path-protection mechanisms.

And link protection MUST assure that packets will arrive at the neighbor node via some other link regardless of further path towards destination.
[KT] Yes. We have a mechanism to indicate which adj-SIDs have protection (that mechanism only provides link protection to get to the neighbor node) so the SR Policy computation is able to indicate whether that specific link is "bypass-able" or not by its choice of protected or unprotected adj-SIDs respectively.

Thanks,
Ketan

Is it correct ?

Thx
R

Hope that clarifies?

Thanks,
Ketan

Ketan, and all,

Regards,
Sasha

Get Outlook for Android<https://urldefense.com/v3/__https:/aka.ms/ghei36__;!!NEt6yMaO-gk!T6-xiDIr_hoqn4GSahs0W-chksGDc6ls62TaER3dGURTnqH4s1DCS4XyHPc9fQ4l$>

Hi Sasha,

Thanks,
Ketan

Hi all,

My 2c.

Get Outlook for Android<https://urldefense.com/v3/__https:/clicktime.symantec.com/375c5YYBeEbaEZwUcHpCY1m6H2?u=https*3A*2F*2Faka.ms*2Fghei36__;JSUlJQ!!NEt6yMaO-gk!T6-xiDIr_hoqn4GSahs0W-chksGDc6ls62TaER3dGURTnqH4s1DCS4XyHEID_Kny$>

Hi All,

Thanks,
Ketan

[1] https://clicktime.symantec.com/3Y3fWuNFYCjMJUiiAiWwUms6H2?u=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-ietf-spring-segment-routing-policy-08%23section-9<https://urldefense.com/v3/__https:/clicktime.symantec.com/3Y3fWuNFYCjMJUiiAiWwUms6H2?u=https*3A*2F*2Ftools.ietf.org*2Fhtml*2Fdraft-ietf-spring-segment-routing-policy-08*23section-9__;JSUlJSUl!!NEt6yMaO-gk!T6-xiDIr_hoqn4GSahs0W-chksGDc6ls62TaER3dGURTnqH4s1DCS4XyHFT2o0Db$>
[2] https://clicktime.symantec.com/36fCMrgmEewC4a4AJRrmn7H6H2?u=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-ietf-spring-segment-routing-policy-08%23section-9.3<https://urldefense.com/v3/__https:/clicktime.symantec.com/36fCMrgmEewC4a4AJRrmn7H6H2?u=https*3A*2F*2Ftools.ietf.org*2Fhtml*2Fdraft-ietf-spring-segment-routing-policy-08*23section-9.3__;JSUlJSUl!!NEt6yMaO-gk!T6-xiDIr_hoqn4GSahs0W-chksGDc6ls62TaER3dGURTnqH4s1DCS4XyHCSyZG9Y$>

-----Original Message-----
From: spring <[email-masked]<mailto:[email-masked]>> On Behalf Of Joel M. Halpern
Sent: 04 August 2020 20:25
To: Alexander Vainshtein <[email-masked]<mailto:[email-masked]>>; Shraddha Hegde <shraddha=[email-masked]<mailto:shraddha=[email-masked]>>; [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>; Robert Raszuk <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; Joel M. Halpern <[email-masked]<mailto:[email-masked]>>
Subject: Re: [spring] Spring protection - determining applicability

Thank you,
Joel

On 8/4/2020 3:54 AM, Alexander Vainshtein wrote:
> <https://clicktime.symantec.com/3Q92knE9XJujrf8Bk7oJvs6H2?u=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Frfc4090<https://urldefense.com/v3/__https:/clicktime.symantec.com/3Q92knE9XJujrf8Bk7oJvs6H2?u=https*3A*2F*2Ftools.ietf.org*2Fhtml*2Frfc4090__;JSUlJSU!!NEt6yMaO-gk!T6-xiDIr_hoqn4GSahs0W-chksGDc6ls62TaER3dGURTnqH4s1DCS4XyHPqvtiVA$>>) has been successfully deployed
>     <https://clicktime.symantec.com/3CCcy9mY6cMfbk7QfjhiA3R6H2?u=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-bess-srv6-services-04
<https://urldefense.com/v3/__https:/clicktime.symantec.com/3CCcy9mY6cMfbk7QfjhiA3R6H2?u=https*3A*2F*2Fdatatracker.ietf.org*2Fdoc*2Fhtml*2Fdraft-ietf-bess-srv6-services-04*0b__;JSUlJSUlJQ!!NEt6yMaO-gk!T6-xiDIr_hoqn4GSahs0W-chksGDc6ls62TaER3dGURTnqH4s1DCS4XyHIv9TlLj$>>     <https://clicktime.symantec.com/3GC5af2z3JzphZDkPncHAQi6H2?u=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-bess-srv6-services-04__%3B%21%21NEt6yMaO-gk%21S0Yusx9FYNE8E_R1oiQAtQxgm0x0wxqguoZHgwp6vpRHOGt8AkTRDuiDo4T-L0nl%24<https://urldefense.com/v3/__https:/clicktime.symantec.com/3GC5af2z3JzphZDkPncHAQi6H2?u=https*3A*2F*2Furldefense.com*2Fv3*2F__https*3A*2Fdatatracker.ietf.org*2Fdoc*2Fhtml*2Fdraft-ietf-bess-srv6-services-04__*3B*21*21NEt6yMaO-gk*21S0Yusx9FYNE8E_R1oiQAtQxgm0x0wxqguoZHgwp6vpRHOGt8AkTRDuiDo4T-L0nl*24__;JSUlJSUlJSUlJSUlJSUl!!NEt6yMaO-gk!T6-xiDIr_hoqn4GSahs0W-chksGDc6ls62TaER3dGURTnqH4s1DCS4XyHFTJ2uj2$>>>
>      > > <https://clicktime.symantec.com/345NLCB6TydxuuqUjtcDRZy6H2?u=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Frfc8402
<https://urldefense.com/v3/__https:/clicktime.symantec.com/345NLCB6TydxuuqUjtcDRZy6H2?u=https*3A*2F*2Ftools.ietf.org*2Fhtml*2Frfc8402*0b__;JSUlJSUl!!NEt6yMaO-gk!T6-xiDIr_hoqn4GSahs0W-chksGDc6ls62TaER3dGURTnqH4s1DCS4XyHArKdY_W$>>     <https://clicktime.symantec.com/37PzUKAD82cjSvmVcGvpkhF6H2?u=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Ftools.ietf.org%2Fhtml%2Frfc8402__%3B%21%21NEt6yMaO-gk%21S0Yusx9FYNE8E_R1oiQAtQxgm0x0wxqguoZHgwp6vpRHOGt8AkTRDuiDo0I4Ybtm%24<https://urldefense.com/v3/__https:/clicktime.symantec.com/37PzUKAD82cjSvmVcGvpkhF6H2?u=https*3A*2F*2Furldefense.com*2Fv3*2F__https*3A*2Ftools.ietf.org*2Fhtml*2Frfc8402__*3B*21*21NEt6yMaO-gk*21S0Yusx9FYNE8E_R1oiQAtQxgm0x0wxqguoZHgwp6vpRHOGt8AkTRDuiDo0I4Ybtm*24__;JSUlJSUlJSUlJSUlJSU!!NEt6yMaO-gk!T6-xiDIr_hoqn4GSahs0W-chksGDc6ls62TaER3dGURTnqH4s1DCS4XyHDcTdTB9$>>>
>     <https://clicktime.symantec.com/3JbSWGx5DAfNPsZdhpExxx96H2?u=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-hegde-spring-node-protection-for-sr-te-paths-07%23section-3.4
<https://urldefense.com/v3/__https:/clicktime.symantec.com/3JbSWGx5DAfNPsZdhpExxx96H2?u=https*3A*2F*2Fdatatracker.ietf.org*2Fdoc*2Fhtml*2Fdraft-hegde-spring-node-protection-for-sr-te-paths-07*23section-3.4*0b__;JSUlJSUlJSU!!NEt6yMaO-gk!T6-xiDIr_hoqn4GSahs0W-chksGDc6ls62TaER3dGURTnqH4s1DCS4XyHFgFKnfL$>>     <https://clicktime.symantec.com/3CrUgARW8somAbw6TisjgJ16H2?u=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-hegde-spring-node-protection-for-sr-te-paths-07%2Asection-3.4__%3BIw%21%21NEt6yMaO-gk%21S0Yusx9FYNE8E_R1oiQAtQxgm0x0wxqguoZHgwp6vpRHOGt8AkTRDuiDo9wO-Ssn%24<https://urldefense.com/v3/__https:/clicktime.symantec.com/3CrUgARW8somAbw6TisjgJ16H2?u=https*3A*2F*2Furldefense.com*2Fv3*2F__https*3A*2Fdatatracker.ietf.org*2Fdoc*2Fhtml*2Fdraft-hegde-spring-node-protection-for-sr-te-paths-07*2Asection-3.4__*3BIw*21*21NEt6yMaO-gk*21S0Yusx9FYNE8E_R1oiQAtQxgm0x0wxqguoZHgwp6vpRHOGt8AkTRDuiDo9wO-Ssn*24__;JSUlJSUlJSUlJSUlJSUlJQ!!NEt6yMaO-gk!T6-xiDIr_hoqn4GSahs0W-chksGDc6ls62TaER3dGURTnqH4s1DCS4XyHAPuZD-6$>>>
>      > >     [RFC8679 <https://clicktime.symantec.com/3JfvtBAmaQPN1jA3pM6TdCE6H2?u=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Frfc8679
<https://urldefense.com/v3/__https:/clicktime.symantec.com/3JfvtBAmaQPN1jA3pM6TdCE6H2?u=https*3A*2F*2Fdatatracker.ietf.org*2Fdoc*2Fhtml*2Frfc8679*0b__;JSUlJSUlJQ!!NEt6yMaO-gk!T6-xiDIr_hoqn4GSahs0W-chksGDc6ls62TaER3dGURTnqH4s1DCS4XyHP0vl_f0$>>     <https://clicktime.symantec.com/36dMAjuYTQovo8jHwmm3eJw6H2?u=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Frfc8679__%3B%21%21NEt6yMaO-gk%21S0Yusx9FYNE8E_R1oiQAtQxgm0x0wxqguoZHgwp6vpRHOGt8AkTRDuiDo8MGipXc%24<https://urldefense.com/v3/__https:/clicktime.symantec.com/36dMAjuYTQovo8jHwmm3eJw6H2?u=https*3A*2F*2Furldefense.com*2Fv3*2F__https*3A*2Fdatatracker.ietf.org*2Fdoc*2Fhtml*2Frfc8679__*3B*21*21NEt6yMaO-gk*21S0Yusx9FYNE8E_R1oiQAtQxgm0x0wxqguoZHgwp6vpRHOGt8AkTRDuiDo8MGipXc*24__;JSUlJSUlJSUlJSUlJSUl!!NEt6yMaO-gk!T6-xiDIr_hoqn4GSahs0W-chksGDc6ls62TaER3dGURTnqH4s1DCS4XyHFKStLiT$>>>]
>      > >
>      > >  >
>      > >
>      >
>     https://clicktime.symantec.com/367qhU4KiUkzW9uGC4eAvP46H2?u=https%3A%2<https://urldefense.com/v3/__https:/clicktime.symantec.com/367qhU4KiUkzW9uGC4eAvP46H2?u=https*3A*252__;JSU!!NEt6yMaO-gk!T6-xiDIr_hoqn4GSahs0W-chksGDc6ls62TaER3dGURTnqH4s1DCS4XyHIHV9d4X$>
>     <https://clicktime.symantec.com/3Q7vX2qWSUdWVc892XuXy2H6H2?u=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Fclicktime.symantec.com%2F367qhU4KiUkzW9uGC4eAvP46H2%3Fu%3Dhttps%2A3A%2A2__%3BJSU%21%21NEt6yMaO-gk%21S0Yusx9FYNE8E_R1oiQAtQxgm0x0wxqguoZHgwp6vpRHOGt8AkTRDuiDo6HwPLil%24<https://urldefense.com/v3/__https:/clicktime.symantec.com/3Q7vX2qWSUdWVc892XuXy2H6H2?u=https*3A*2F*2Furldefense.com*2Fv3*2F__https*3A*2Fclicktime.symantec.com*2F367qhU4KiUkzW9uGC4eAvP46H2*3Fu*3Dhttps*2A3A*2A2__*3BJSU*21*21NEt6yMaO-gk*21S0Yusx9FYNE8E_R1oiQAtQxgm0x0wxqguoZHgwp6vpRHOGt8AkTRDuiDo6HwPLil*24__;JSUlJSUlJSUlJSUlJSUlJSU!!NEt6yMaO-gk!T6-xiDIr_hoqn4GSahs0W-chksGDc6ls62TaER3dGURTnqH4s1DCS4XyHCAWC-QD$>>
>      > >
>      >
<https://urldefense.com/v3/__https:/clicktime.symantec.com/367qhU4KiUkzW9uGC4eAvP46H2?u=https*3A*252*0b__;JSUl!!NEt6yMaO-gk!T6-xiDIr_hoqn4GSahs0W-chksGDc6ls62TaER3dGURTnqH4s1DCS4XyHA-bvjNO$>>     <https://clicktime.symantec.com/3A5B8H2Fm1rPnaZ3Supjwr6H2?u=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Fclicktime.symantec.com%2F367qhU4KiUkzW9uGC4eAvP46H2%3Fu%3Dhttps%2A3A%2A252__%3BJSU%21%21NEt6yMaO-gk%21S0Yusx9FYNE8E_R1oiQAtQxgm0x0wxqguoZHgwp6vpRHOGt8AkTRDuiDozoQiAHk%24<https://urldefense.com/v3/__https:/clicktime.symantec.com/3A5B8H2Fm1rPnaZ3Supjwr6H2?u=https*3A*2F*2Furldefense.com*2Fv3*2F__https*3A*2Fclicktime.symantec.com*2F367qhU4KiUkzW9uGC4eAvP46H2*3Fu*3Dhttps*2A3A*2A252__*3BJSU*21*21NEt6yMaO-gk*21S0Yusx9FYNE8E_R1oiQAtQxgm0x0wxqguoZHgwp6vpRHOGt8AkTRDuiDozoQiAHk*24__;JSUlJSUlJSUlJSUlJSUlJSU!!NEt6yMaO-gk!T6-xiDIr_hoqn4GSahs0W-chksGDc6ls62TaER3dGURTnqH4s1DCS4XyHAWaiMUw$>>>
>      > >
>      > >  > F%2Fwww.ietf.org<https://urldefense.com/v3/__http:/2Fwww.ietf.org__;!!NEt6yMaO-gk!T6-xiDIr_hoqn4GSahs0W-chksGDc6ls62TaER3dGURTnqH4s1DCS4XyHFg78Q3H$>
>     <https://clicktime.symantec.com/39NznmYBtRuHARhGJ5W5dGB6H2?u=https%3A%2F%2Furldefense.com%2Fv3%2F__http%3A%2F2Fwww.ietf.org__%3B%21%21NEt6yMaO-gk%21S0Yusx9FYNE8E_R1oiQAtQxgm0x0wxqguoZHgwp6vpRHOGt8AkTRDuiDo-pPCjvR%24<https://urldefense.com/v3/__https:/clicktime.symantec.com/39NznmYBtRuHARhGJ5W5dGB6H2?u=https*3A*2F*2Furldefense.com*2Fv3*2F__http*3A*2F2Fwww.ietf.org__*3B*21*21NEt6yMaO-gk*21S0Yusx9FYNE8E_R1oiQAtQxgm0x0wxqguoZHgwp6vpRHOGt8AkTRDuiDo-pPCjvR*24__;JSUlJSUlJSUlJSUl!!NEt6yMaO-gk!T6-xiDIr_hoqn4GSahs0W-chksGDc6ls62TaER3dGURTnqH4s1DCS4XyHHQqPAak$>>
<https://urldefense.com/v3/__https:/clicktime.symantec.com/3GWT9fyjaFi3FcvHDvoodvS6H2?u=http*3A*2F*2F2Fwww.ietf.org*0b__;JSUlJQ!!NEt6yMaO-gk!T6-xiDIr_hoqn4GSahs0W-chksGDc6ls62TaER3dGURTnqH4s1DCS4XyHBRPKf7n$>>     <https://clicktime.symantec.com/39NznmYBtRuHARhGJ5W5dGB6H2?u=https%3A%2F%2Furldefense.com%2Fv3%2F__http%3A%2F2Fwww.ietf.org__%3B%21%21NEt6yMaO-gk%21S0Yusx9FYNE8E_R1oiQAtQxgm0x0wxqguoZHgwp6vpRHOGt8AkTRDuiDo-pPCjvR%24<https://urldefense.com/v3/__https:/clicktime.symantec.com/39NznmYBtRuHARhGJ5W5dGB6H2?u=https*3A*2F*2Furldefense.com*2Fv3*2F__http*3A*2F2Fwww.ietf.org__*3B*21*21NEt6yMaO-gk*21S0Yusx9FYNE8E_R1oiQAtQxgm0x0wxqguoZHgwp6vpRHOGt8AkTRDuiDo-pPCjvR*24__;JSUlJSUlJSUlJSUl!!NEt6yMaO-gk!T6-xiDIr_hoqn4GSahs0W-chksGDc6ls62TaER3dGURTnqH4s1DCS4XyHHQqPAak$>>>%2Fmailman%2Flistinfo%2Fspring
>      > >
>      > >
>      >
>     https://clicktime.symantec.com/367qhU4KiUkzW9uGC4eAvP46H2?u=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring<https://urldefense.com/v3/__https:/clicktime.symantec.com/367qhU4KiUkzW9uGC4eAvP46H2?u=https*3A*2F*2Fwww.ietf.org*2Fmailman*2Flistinfo*2Fspring__;JSUlJSUl!!NEt6yMaO-gk!T6-xiDIr_hoqn4GSahs0W-chksGDc6ls62TaER3dGURTnqH4s1DCS4XyHL8epLu6$>
>     <https://clicktime.symantec.com/3BhyEtx4Q7n74BhiRnfMJtT6H2?u=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Fclicktime.symantec.com%2F367qhU4KiUkzW9uGC4eAvP46H2%3Fu%3Dhttps%2A3A%2A2F%2A2Fwww.ietf.org%2A2Fmailman%2A2Flistinfo%2A2Fspring__%3BJSUlJSUl%21%21NEt6yMaO-gk%21S0Yusx9FYNE8E_R1oiQAtQxgm0x0wxqguoZHgwp6vpRHOGt8AkTRDuiDo-hR3gAD%24<https://urldefense.com/v3/__https:/clicktime.symantec.com/3BhyEtx4Q7n74BhiRnfMJtT6H2?u=https*3A*2F*2Furldefense.com*2Fv3*2F__https*3A*2Fclicktime.symantec.com*2F367qhU4KiUkzW9uGC4eAvP46H2*3Fu*3Dhttps*2A3A*2A2F*2A2Fwww.ietf.org*2A2Fmailman*2A2Flistinfo*2A2Fspring__*3BJSUlJSUl*21*21NEt6yMaO-gk*21S0Yusx9FYNE8E_R1oiQAtQxgm0x0wxqguoZHgwp6vpRHOGt8AkTRDuiDo-hR3gAD*24__;JSUlJSUlJSUlJSUlJSUlJSUlJSUl!!NEt6yMaO-gk!T6-xiDIr_hoqn4GSahs0W-chksGDc6ls62TaER3dGURTnqH4s1DCS4XyHNFkV5Q4$>>
>      > >
>      > >
>      > >
>      > >
>      >
>      > > https://clicktime.symantec.com/3Q1xsKGyMzNJCKyVPByhqLq6H2?u=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring<https://urldefense.com/v3/__https:/clicktime.symantec.com/3Q1xsKGyMzNJCKyVPByhqLq6H2?u=https*3A*2F*2Fwww.ietf.org*2Fmailman*2Flistinfo*2Fspring__;JSUlJSUl!!NEt6yMaO-gk!T6-xiDIr_hoqn4GSahs0W-chksGDc6ls62TaER3dGURTnqH4s1DCS4XyHOd1sKS-$>
>     <https://clicktime.symantec.com/3NrDnSTReXh671G79BVGEq16H2?u=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring__%3B%21%21NEt6yMaO-gk%21S0Yusx9FYNE8E_R1oiQAtQxgm0x0wxqguoZHgwp6vpRHOGt8AkTRDuiDo5KlPnbj%24<https://urldefense.com/v3/__https:/clicktime.symantec.com/3NrDnSTReXh671G79BVGEq16H2?u=https*3A*2F*2Furldefense.com*2Fv3*2F__https*3A*2Fwww.ietf.org*2Fmailman*2Flistinfo*2Fspring__*3B*21*21NEt6yMaO-gk*21S0Yusx9FYNE8E_R1oiQAtQxgm0x0wxqguoZHgwp6vpRHOGt8AkTRDuiDo5KlPnbj*24__;JSUlJSUlJSUlJSUlJSUl!!NEt6yMaO-gk!T6-xiDIr_hoqn4GSahs0W-chksGDc6ls62TaER3dGURTnqH4s1DCS4XyHOukqHbG$>>
>      > >
>      >
>      > https://clicktime.symantec.com/3Q1xsKGyMzNJCKyVPByhqLq6H2?u=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring<https://urldefense.com/v3/__https:/clicktime.symantec.com/3Q1xsKGyMzNJCKyVPByhqLq6H2?u=https*3A*2F*2Fwww.ietf.org*2Fmailman*2Flistinfo*2Fspring__;JSUlJSUl!!NEt6yMaO-gk!T6-xiDIr_hoqn4GSahs0W-chksGDc6ls62TaER3dGURTnqH4s1DCS4XyHOd1sKS-$>
>     <https://clicktime.symantec.com/3NrDnSTReXh671G79BVGEq16H2?u=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring__%3B%21%21NEt6yMaO-gk%21S0Yusx9FYNE8E_R1oiQAtQxgm0x0wxqguoZHgwp6vpRHOGt8AkTRDuiDo5KlPnbj%24<https://urldefense.com/v3/__https:/clicktime.symantec.com/3NrDnSTReXh671G79BVGEq16H2?u=https*3A*2F*2Furldefense.com*2Fv3*2F__https*3A*2Fwww.ietf.org*2Fmailman*2Flistinfo*2Fspring__*3B*21*21NEt6yMaO-gk*21S0Yusx9FYNE8E_R1oiQAtQxgm0x0wxqguoZHgwp6vpRHOGt8AkTRDuiDo5KlPnbj*24__;JSUlJSUlJSUlJSUlJSUl!!NEt6yMaO-gk!T6-xiDIr_hoqn4GSahs0W-chksGDc6ls62TaER3dGURTnqH4s1DCS4XyHOukqHbG$>>
>      >
>
>     https://clicktime.symantec.com/3Q1xsKGyMzNJCKyVPByhqLq6H2?u=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring<https://urldefense.com/v3/__https:/clicktime.symantec.com/3Q1xsKGyMzNJCKyVPByhqLq6H2?u=https*3A*2F*2Fwww.ietf.org*2Fmailman*2Flistinfo*2Fspring__;JSUlJSUl!!NEt6yMaO-gk!T6-xiDIr_hoqn4GSahs0W-chksGDc6ls62TaER3dGURTnqH4s1DCS4XyHOd1sKS-$>
>
<https://urldefense.com/v3/__https:/clicktime.symantec.com/3NrDnSTReXh671G79BVGEq16H2?u=https*3A*25*0b__;JSUl!!NEt6yMaO-gk!T6-xiDIr_hoqn4GSahs0W-chksGDc6ls62TaER3dGURTnqH4s1DCS4XyHHf9TDPP$>> 2F%2Furldefense.com%2Fv3%2F__https%3A%2Fwww.ietf.org<https://urldefense.com/v3/__http:/2Fwww.ietf.org__;!!NEt6yMaO-gk!T6-xiDIr_hoqn4GSahs0W-chksGDc6ls62TaER3dGURTnqH4s1DCS4XyHFg78Q3H$>%2Fmailman%2Flisti

_______________________________________________
spring mailing list
[email-masked]<mailto:[email-masked]>
https://clicktime.symantec.com/3Q1xsKGyMzNJCKyVPByhqLq6H2?u=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring<https://urldefense.com/v3/__https:/clicktime.symantec.com/3Q1xsKGyMzNJCKyVPByhqLq6H2?u=https*3A*2F*2Fwww.ietf.org*2Fmailman*2Flistinfo*2Fspring__;JSUlJSUl!!NEt6yMaO-gk!T6-xiDIr_hoqn4GSahs0W-chksGDc6ls62TaER3dGURTnqH4s1DCS4XyHOd1sKS-$>
_______________________________________________
spring mailing list
[email-masked]<mailto:[email-masked]>
https://clicktime.symantec.com/3Q1xsKGyMzNJCKyVPByhqLq6H2?u=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring<https://urldefense.com/v3/__https:/clicktime.symantec.com/3Q1xsKGyMzNJCKyVPByhqLq6H2?u=https*3A*2F*2Fwww.ietf.org*2Fmailman*2Flistinfo*2Fspring__;JSUlJSUl!!NEt6yMaO-gk!T6-xiDIr_hoqn4GSahs0W-chksGDc6ls62TaER3dGURTnqH4s1DCS4XyHOd1sKS-$>

spring mailing list

https://www.ietf.org/mailman/listinfo/spring<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/spring__;!!NEt6yMaO-gk!T6-xiDIr_hoqn4GSahs0W-chksGDc6ls62TaER3dGURTnqH4s1DCS4XyHHwmjYbd$>

---

From: "Chengli (Cheng Li)" <[email-masked]>
Date: Fri, 28 Aug 2020 06:25:41 +0000

Hi Ketan and Robert,

I think we need to signal bypass-able indication for prefix SIDs in IGP, and I think this has been written in [1]. But in this draft, we also add No-bypass flag for adj-SID as well. We may need to discuss that do we need it or not since B flag is there already.

Also, operators’ POVs are always important, we can reach out to some operators ASAP.

Thanks,
Cheng

[1]. https://tools.ietf.org/html/draft-li-rtgwg-enhanced-ti-lfa-02

From: spring [mailto:[email-masked]] On Behalf Of Ketan Talaulikar (ketant)
Sent: Saturday, August 15, 2020 1:46 AM
To: Robert Raszuk <[email-masked]>
Cc: Alexander Vainshtein <[email-masked]>; [email-masked]; Joel M. Halpern <[email-masked]>; Shraddha Hegde <[email-masked]>; [email-masked] <[email-masked]>
Subject: Re: [spring] Spring protection - determining applicability

Hi Robert,

Thanks,
Ketan

Ketan,

Thx,
R.

Hi Ketan,

Thanks,
Ketan

Is it correct ?

Thx
R

Hope that clarifies?

Thanks,
Ketan

Ketan, and all,

Regards,
Sasha

Hi Sasha,

Thanks,
Ketan

Hi all,

My 2c.

Hi All,

Thanks,
Ketan

-----Original Message-----
From: spring <[email-masked]<mailto:[email-masked]>> On Behalf Of Joel M. Halpern
Sent: 04 August 2020 20:25
To: Alexander Vainshtein <[email-masked]<mailto:[email-masked]>>; Shraddha Hegde <shraddha=[email-masked]<mailto:shraddha=[email-masked]>>; [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>; Robert Raszuk <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; Joel M. Halpern <[email-masked]<mailto:[email-masked]>>
Subject: Re: [spring] Spring protection - determining applicability

Thank you,
Joel

---

From: "Chengli (Cheng Li)" <[email-masked]>
Date: Fri, 28 Aug 2020 06:36:55 +0000

Hi Sasha and Martin,

Many thanks for your input. I fully agree with your point of we need to consider to advertise the ability of the node to advertise a specific Prefix SID it originates as “not eligible for bypass protection”.

Also, this extension should be written in a protection document like Martin said. We have a strawman draft posed 1 year ago [1], but it has not been discussed yet.  The main idea of the draft is to add a no-bypass flag into SID(including Prefix SID, and adj-SID). But we are discussing with some experts that do we need the No-bypass flag for Adj-SID or not, it seems like we have a B flag already.

It is so nice to see this point is raised and discussed. Also, welcome to review the document, and hope to have your valuable comments.

Respect,
Cheng

From: spring [mailto:[email-masked]] On Behalf Of Alexander Vainshtein
Sent: Tuesday, August 18, 2020 11:44 PM
To: Martin Horneffer <[email-masked]>
Cc: [email-masked]; Robert Raszuk <[email-masked]>; [email-masked] <[email-masked]>; Shraddha Hegde <[email-masked]>; Ketan Talaulikar (ketant) <ketant=[email-masked]>; Joel M. Halpern <[email-masked]>
Subject: Re: [spring] Spring protection - determining applicability

Martin,

My 2c,
Sasha

Office: +972-39266302
Cell:      +972-549266302

From: spring <[email-masked]<mailto:[email-masked]>> On Behalf Of Martin Horneffer
Sent: Tuesday, August 18, 2020 5:51 PM
To: [email-masked]<mailto:[email-masked]>
Cc: Alexander Vainshtein <[email-masked]<mailto:[email-masked]>>; Robert Raszuk <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>; Shraddha Hegde <[email-masked]<mailto:[email-masked]>>; Ketan Talaulikar (ketant) <ketant=[email-masked]<mailto:ketant=[email-masked]>>; Joel M. Halpern <[email-masked]<mailto:[email-masked]>>
Subject: Re: [spring] Spring protection - determining applicability

Best regards, Martin

Thanks,
Ketan

Ketan,

Thx,
R.

Hi Ketan,

Thanks,
Ketan

Is it correct ?

Thx
R

Hope that clarifies?

Thanks,
Ketan

Ketan, and all,

Regards,
Sasha

Hi Sasha,

Thanks,
Ketan

Hi all,

My 2c.

Hi All,

Thanks,
Ketan

-----Original Message-----
From: spring <[email-masked]<mailto:[email-masked]>> On Behalf Of Joel M. Halpern
Sent: 04 August 2020 20:25
To: Alexander Vainshtein <[email-masked]<mailto:[email-masked]>>; Shraddha Hegde <shraddha=[email-masked]<mailto:shraddha=[email-masked]>>; [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>; Robert Raszuk <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; Joel M. Halpern <[email-masked]<mailto:[email-masked]>>
Subject: Re: [spring] Spring protection - determining applicability

Thank you,
Joel

spring mailing list

---

From: Alexander Vainshtein <[email-masked]>
Date: Fri, 28 Aug 2020 07:41:09 +0000

Cheng and all,
A few short comments.

  1.  I support the idea to mark some IGP Prefix SIDs as "not bypassable"
  2.  I think that, while such marking is not yet available  the neighbors of a node that advertises itself as a "stub node" in IGP MAY use this as a hint that Node SIDs advertised by this node are "not bypassable".
  3.  I do not think that B-flag in the advertisment of Adj-SIDs can be used as n indication that it can be bypassed - the current semantics of this flag is different.
  4.  At the same time I do not think  that ability to advertise a certain Adj-SID as leading to a not bypassable node is needed or would be useful. Ability of the operator to exclude acific neighbor from protection would suffice, especially in the case of local Adj-SID.
  5.  Last bot not  least, I think that none of the above must be addressed befire adoption of the draft as a SPRING WG document.

My 2c,
Sasha

________________________________
From: spring <[email-masked]> on behalf of Chengli (Cheng Li) <[email-masked]>
Sent: Friday, August 28, 2020, 09:37
To: Alexander Vainshtein; Martin Horneffer
Cc: [email-masked]; Robert Raszuk; [email-masked]; Shraddha Hegde; Ketan Talaulikar (ketant); Joel M. Halpern
Subject: Re: [spring] Spring protection - determining applicability

Hi Sasha and Martin,

Respect,
Cheng

[1]. https://tools.ietf.org/html/draft-li-rtgwg-enhanced-ti-lfa-02<https://clicktime.symantec.com/3ANymMuqpegxP1sVdAwdLWH6H2?u=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-li-rtgwg-enhanced-ti-lfa-02>

Martin,

My 2c,
Sasha

Office: +972-39266302
Cell:      +972-549266302

Best regards, Martin

Thanks,
Ketan

Ketan,

Thx,
R.

Hi Ketan,

Thanks,
Ketan

Is it correct ?

Thx
R

Hope that clarifies?

Thanks,
Ketan

Ketan, and all,

Regards,
Sasha

Hi Sasha,

Thanks,
Ketan

Hi all,

My 2c.

Hi All,

Thanks,
Ketan

-----Original Message-----
From: spring <[email-masked]<mailto:[email-masked]>> On Behalf Of Joel M. Halpern
Sent: 04 August 2020 20:25
To: Alexander Vainshtein <[email-masked]<mailto:[email-masked]>>; Shraddha Hegde <shraddha=[email-masked]<mailto:shraddha=[email-masked]>>; [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>; Robert Raszuk <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; Joel M. Halpern <[email-masked]<mailto:[email-masked]>>
Subject: Re: [spring] Spring protection - determining applicability

Thank you,
Joel

spring mailing list

---

From: "Chengli (Cheng Li)" <[email-masked]>
Date: Sat, 29 Aug 2020 03:46:10 +0000

Hi Sasha,

Agree. This is not the topic about to adopt a draft or not. I also support the adoption. :)

Regarding the not bypassable flag for prefix SID, thanks for your input. Will update the draft after we have enough discussion in the mailing list. Seems like we are heading to the same direction, that is wonderful!

Thanks,
Cheng

From: spring [mailto:[email-masked]] On Behalf Of Alexander Vainshtein
Sent: Friday, August 28, 2020 3:41 PM
To: Chengli (Cheng Li) <[email-masked]>; Alexander Vainshtein <[email-masked]>; Martin Horneffer <[email-masked]>
Cc: [email-masked]; Robert Raszuk <[email-masked]>; [email-masked] <[email-masked]>; Shraddha Hegde <[email-masked]>; Ketan Talaulikar (ketant) <ketant=[email-masked]>; Joel M. Halpern <[email-masked]>
Subject: Re: [spring] Spring protection - determining applicability

Cheng and all,
A few short comments.

My 2c,
Sasha

________________________________
From: spring <[email-masked]<mailto:[email-masked]>> on behalf of Chengli (Cheng Li) <[email-masked]<mailto:[email-masked]>>
Sent: Friday, August 28, 2020, 09:37
To: Alexander Vainshtein; Martin Horneffer
Cc: [email-masked]<mailto:[email-masked]>; Robert Raszuk; [email-masked]<mailto:[email-masked]>; Shraddha Hegde; Ketan Talaulikar (ketant); Joel M. Halpern
Subject: Re: [spring] Spring protection - determining applicability

Hi Sasha and Martin,

Many thanks for your input. I fully agree with your point of we need to consider to advertise the ability of the node to advertise a specific Prefix SID it originates as "not eligible for bypass protection".

Respect,
Cheng

From: spring [mailto:[email-masked]] On Behalf Of Alexander Vainshtein
Sent: Tuesday, August 18, 2020 11:44 PM
To: Martin Horneffer <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; Robert Raszuk <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>; Shraddha Hegde <[email-masked]<mailto:[email-masked]>>; Ketan Talaulikar (ketant) <ketant=[email-masked]<mailto:ketant=[email-masked]>>; Joel M. Halpern <[email-masked]<mailto:[email-masked]>>
Subject: Re: [spring] Spring protection - determining applicability

Martin,

I fully agree with you that ability to turn off the node protection scheme for a specific PLR neighbor (i.e., on a specific PLR port) by suitable local configuration in the PLR is definitely required. Such an ability would probably address most (if not all) scenarios associated with the so-called "service nodes" that cannot be bypassed.

I also think that service nodes that cannot be bypassed typically would advertise themselves as "stub nodes" in IGP in order to prevent inadvertent application of their service function to transit traffic (which could otherwise pass thru the service node due to some topology change). Therefore a local policy that would exclude IGP neighbors advertising  themselves as stub nodes in IGP from the node protection scheme could be also useful.

Last but not least, ability of the node to advertise a specific Prefix SID it originates as "not eligible for bypass protection" (e.g., using a new flag in the Prefix Node TLV for IS-IS or OSPF) should be considered.

My 2c,
Sasha

Office: +972-39266302
Cell:      +972-549266302

Best regards, Martin

Thanks,
Ketan

Ketan,

Thx,
R.

Hi Ketan,

Thanks,
Ketan

Is it correct ?

Thx
R

Hope that clarifies?

Thanks,
Ketan

Ketan, and all,

Regards,
Sasha

Hi Sasha,

Thanks,
Ketan

Hi all,

My 2c.

Hi All,

Thanks,
Ketan

-----Original Message-----
From: spring <[email-masked]<mailto:[email-masked]>> On Behalf Of Joel M. Halpern
Sent: 04 August 2020 20:25
To: Alexander Vainshtein <[email-masked]<mailto:[email-masked]>>; Shraddha Hegde <shraddha=[email-masked]<mailto:shraddha=[email-masked]>>; [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>; Robert Raszuk <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; Joel M. Halpern <[email-masked]<mailto:[email-masked]>>
Subject: Re: [spring] Spring protection - determining applicability

Thank you,
Joel

spring mailing list