Re: [spring] Spring protection - determining applicability

["Joel M. Halpern" <[e-mail]>]

 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.
> 
> This is complementary to what you have said.
> 
> Hope this clarifies my position.
> What, if anything, did I miss?
> 
> Regards,
> Sasha
> 
> Get Outlook for Android <https://aka.ms/ghei36>
> 
> ------------------------------------------------------------------------
> *From:* Ketan Talaulikar (ketant) <[e-mail]>
> *Sent:* Friday, August 14, 2020, 16:23
> *To:* Alexander Vainshtein; Joel M. Halpern; Shraddha Hegde; 
> [e-mail]; Robert Raszuk
> *Cc:* [e-mail]
> *Subject:* RE: [spring] Spring protection - determining applicability
> 
> ------------------------------------------------------------------------
> NOTICE: This email was received from an EXTERNAL sender
> ------------------------------------------------------------------------
> 
> 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 <[e-mail]>
> *Sent:* 14 August 2020 18:24
> *To:* Ketan Talaulikar (ketant) <[e-mail]>; Joel M. Halpern 
> <[e-mail]>; Alexander Vainshtein 
> <[e-mail]>; Shraddha Hegde <[e-mail]>; 
> [e-mail] <[e-mail]>; 
> Robert Raszuk <[e-mail]>
> *Cc:* [e-mail]
> *Subject:* Re: [spring] Spring protection - determining applicability
> 
> 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://clicktime.symantec.com/375c5YYBeEbaEZwUcHpCY1m6H2?u=https%3A%2F%2Faka.ms%2Fghei36>
> 
> ------------------------------------------------------------------------
> 
> *From:* spring <[e-mail] 
> <mailto:[e-mail]>> on behalf of Ketan Talaulikar (ketant) 
> <ketant=[e-mail] 
> <mailto:ketant=[e-mail]>>
> *Sent:* Friday, August 14, 2020, 15:00
> *To:* Joel M. Halpern; Alexander Vainshtein; Shraddha Hegde; 
> [e-mail] 
> <mailto:[e-mail]>; Robert Raszuk
> *Cc:* [e-mail] <mailto:[e-mail]>
> *Subject:* Re: [spring] Spring protection - determining applicability
> 
> 
> 
> 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://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 <[e-mail] <mailto:[e-mail]>> 
> On Behalf Of Joel M. Halpern
> Sent: 04 August 2020 20:25
> To: Alexander Vainshtein <[e-mail] 
> <mailto:[e-mail]>>; Shraddha Hegde 
> <shraddha=[e-mail] 
> <mailto:shraddha=[e-mail]>>; 
> [e-mail] 
> <mailto:[e-mail]> 
> <[e-mail] 
> <mailto:[e-mail]>>; Robert Raszuk 
> <[e-mail] <mailto:[e-mail]>>
> Cc: [e-mail] <mailto:[e-mail]>; Joel M. Halpern 
> <[e-mail] <mailto:[e-mail]>>
> 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:
>  > 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://clicktime.symantec.com/3Q92knE9XJujrf8Bk7oJvs6H2?u=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Frfc4090>) 
> 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: [phone]
>  >
>  > Cell:      [phone]
>  >
>  > Email: [e-mail] 
> <mailto:[e-mail]>
>  >
>  > *From:* spring <[e-mail] 
> <mailto:[e-mail]>> *On Behalf Of *Shraddha Hegde
>  > *Sent:* Tuesday, August 4, 2020 9:41 AM
>  > *To:* [e-mail] 
> <mailto:[e-mail]>
>  > <[e-mail] 
> <mailto:[e-mail]>>; Robert Raszuk 
> <[e-mail] <mailto:[e-mail]>>
>  > *Cc:* [e-mail] <mailto:[e-mail]>; Joel M. Halpern 
> <[e-mail] <mailto:[e-mail]>>
>  > *Subject:* Re: [spring] Spring protection - determining applicability
>  >
>  > 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 <[e-mail]
> <mailto:[e-mail]%20%0b>> 
> <mailto:[e-mail]>> *On Behalf Of *Andrew Alston
>  > *Sent:* Tuesday, August 4, 2020 5:41 AM
>  > *To:* Robert Raszuk <[e-mail] <mailto:[e-mail]>>
>  > *Cc:* [e-mail] <mailto:[e-mail]> 
> <mailto:[e-mail]>; Joel M. Halpern
>  > <[e-mail] <mailto:[e-mail]>>
>  > *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 <[e-mail] <mailto:[e-mail]>>
>  > *Sent:* Tuesday, 4 August 2020 01:27
>  > *To:* Andrew Alston <[e-mail]
> <mailto:[e-mail]%20%0b>> 
> <mailto:[e-mail]>>
>  > *Cc:* Joel M. Halpern <[e-mail]
> <mailto:[e-mail]%20%0b>> <mailto:[e-mail]>>; 
> [e-mail] <mailto:[e-mail]>
>  > <mailto:[e-mail]>
>  > *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
>  > <[e-mail]
> <mailto:[e-mail]%20%0b>> 
> <mailto:[e-mail]>> 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.
>  >
>  >     I wish I could be more specific than this, but it is what it is.
>  >
>  >     Thanks
>  >
>  >     Andrew
>  >
>  >     *From:* spring <[e-mail]
> <mailto:[e-mail]%0b>>     
> <mailto:[e-mail]>> *On Behalf Of *Joel M. Halpern
>  >     *Sent:* Monday, 3 August 2020 21:36
>  >     *To:* Robert Raszuk <[e-mail] <mailto:[e-mail]>>
>  >     *Cc:* spring@ietf..org <mailto:spring@ietf..org> 
> <mailto:[e-mail]>
>  >     *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.)
>  >
>  >     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 ?
>  >      >
>  >      > 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 
> <[e-mail]
> <mailto:[e-mail]%0b>>     <mailto:[e-mail]%20%0b>> 
> <mailto:[e-mail]>> wrote:
>  >      >
>  >      > 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
> <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>>
>  >      >
>  >      > > 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
> <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>>
>  >     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://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>>
>  >      >
>  >      > > 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>>     
> <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
>  >      > > 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: [phone]
>  >      > >
>  >      > > Cell:      [phone]
>  >      > >
>  >      > > Email: [e-mail] 
> <mailto:[e-mail]>
>  >     <mailto:[e-mail]>
>  >      > <mailto:[e-mail]>
>  >      > >
>  >      > > -----Original Message-----
>  >      > > From: spring <[e-mail]
> <mailto:[e-mail]%0b>>     
> <mailto:[e-mail]%0b>>
>  >     <mailto:[e-mail]>> On Behalf Of Mach Chen
>  >      > > Sent: Monday, August 3, 2020 6:30 AM
>  >      > > To: Joel M. Halpern <[e-mail]
> <mailto:[e-mail]%0b>>     <mailto:[e-mail]%0b>> 
> <mailto:[e-mail]>>;
>  > [e-mail] <mailto:[e-mail]> <mailto:[e-mail]> 
> <mailto:[e-mail]>
>  >      > > 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:[e-mail]
>  >      > <mailto:[e-mail]>
>  >     
> <mailto:[e-mail]%0b%3e%20%3cmailto:[e-mail]%3e>]
>  >     On Behalf Of Joel M.
>  >      > >
>  >      > >  > Halpern
>  >      > >
>  >      > >  > Sent: Monday, August 3, 2020 7:51 AM
>  >      > >
>  >      > >  > To: [e-mail] <mailto:[e-mail]> 
> <mailto:[e-mail]>
>  >     <mailto:[e-mail]>
>  >      > <mailto:[e-mail] <mailto:[e-mail]
> <mailto:[e-mail]%20%3cmailto:[e-mail]%0b>>     
> <mailto:[e-mail]%20%3cmailto:[e-mail]>>>
>  >      > >
>  >      > >  > 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
>  >      > >
>  >      > >  > [e-mail] <mailto:[e-mail]> 
> <mailto:[e-mail]>
>  >     <mailto:[e-mail]>
>  >      > <mailto:[e-mail] <mailto:[e-mail]
> <mailto:[e-mail]%20%3cmailto:[e-mail]%0b>>     
> <mailto:[e-mail]%20%3cmailto:[e-mail]>>>
>  >      > >
>  >      > >  >
>  >      > >
>  >      >
>  > 
> https://clicktime.symantec.com/367qhU4KiUkzW9uGC4eAvP46H2?u=https%3A%2 
> <https://clicktime.symantec.com/367qhU4KiUkzW9uGC4eAvP46H2?u=https%3A%252>
>  >     
> <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/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>>
>  >      > >
>  >      > >  > 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/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
>  >      > >
>  >      > > _______________________________________________
>  >      > >
>  >      > > spring mailing list
>  >      > >
>  >      > > [e-mail] <mailto:[e-mail]> 
> <mailto:[e-mail]>
>  >     <mailto:[e-mail]> <mailto:[e-mail]
> <mailto:[e-mail]%0b>>     <mailto:[e-mail]%0b>> 
> <mailto:[e-mail]>>
>  >      > >
>  >      > >
>  >      >
>  > 
> 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>
>  >      > >
>  >      > >
>  >      > >
>  >      > >
>  >      >
>  >     
> ------------------------------------------------------------------------
>  >      > > 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
>  >      > > [e-mail] <mailto:[e-mail]> 
> <mailto:[e-mail]> <mailto:[e-mail]>
>  >      > > 
> https://clicktime.symantec.com/3Q1xsKGyMzNJCKyVPByhqLq6H2?u=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring
>  >     
> <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
>  >      > [e-mail] <mailto:[e-mail]> 
> <mailto:[e-mail]> <mailto:[e-mail]>
>  >      > 
> https://clicktime.symantec.com/3Q1xsKGyMzNJCKyVPByhqLq6H2?u=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring
>  >     
> <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
>  > [e-mail] <mailto:[e-mail]> <mailto:[e-mail]>
>  > 
> https://clicktime.symantec.com/3Q1xsKGyMzNJCKyVPByhqLq6H2?u=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring
>  >
>  > <https://clicktime.symantec.com/3NrDnSTReXh671G79BVGEq16H2?u=https%3A%
> <https://clicktime.symantec.com/3NrDnSTReXh671G79BVGEq16H2?u=https%3A%25%0b>> 
> 2F%2Furldefense.com%2Fv3%2F__https%3A%2Fwww.ietf.org%2Fmailman%2Flisti
>  > nfo%2Fspring__%3B%21%21NEt6yMaO-gk%21S0Yusx9FYNE8E_R1oiQAtQxgm0x0wxqgu
>  > oZHgwp6vpRHOGt8AkTRDuiDo5KlPnbj%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.
>  > ----------------------------------------------------------------------
>  > --
> 
> _______________________________________________
> spring mailing list
> [e-mail] <mailto:[e-mail]>
> https://clicktime.symantec.com/3Q1xsKGyMzNJCKyVPByhqLq6H2?u=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring
> _______________________________________________
> spring mailing list
> [e-mail] <mailto:[e-mail]>
> https://clicktime.symantec.com/3Q1xsKGyMzNJCKyVPByhqLq6H2?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.
> 
> ------------------------------------------------------------------------
>