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 <jefftant.i...@gmail.com> 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 > -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= > 40cisco....@dmarc.ietf.org>, wrote: > > 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 > > > > *From:* Robert Raszuk <rob...@raszuk.net> > *Sent:* 14 August 2020 23:04 > *To:* Ketan Talaulikar (ketant) <ket...@cisco.com> > *Cc:* Alexander Vainshtein <alexander.vainsht...@rbbn.com>; Joel M. > Halpern <j...@joelhalpern.com>; Shraddha Hegde <shrad...@juniper.net>; > ext-andrew.als...@liquidtelecom.com <andrew.als...@liquidtelecom.com>; > spring@ietf.org > *Subject:* Re: [spring] Spring protection - determining applicability > > > > 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) < > ket...@cisco.com> wrote: > > Hi Robert, > > > > Please check inline below. > > > > *From:* Robert Raszuk <rob...@raszuk.net> > *Sent:* 14 August 2020 21:13 > *To:* Ketan Talaulikar (ketant) <ket...@cisco.com> > *Cc:* Alexander Vainshtein <alexander.vainsht...@rbbn.com>; Joel M. > Halpern <j...@joelhalpern.com>; Shraddha Hegde <shrad...@juniper.net>; > ext-andrew.als...@liquidtelecom.com <andrew.als...@liquidtelecom.com>; > spring@ietf.org > *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) < > ket...@cisco.com> 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 <alexander.vainsht...@rbbn.com> > *Sent:* 14 August 2020 20:24 > *To:* Ketan Talaulikar (ketant) <ket...@cisco.com>; Joel M. Halpern < > j...@joelhalpern.com>; Shraddha Hegde <shrad...@juniper.net>; > ext-andrew.als...@liquidtelecom.com <andrew.als...@liquidtelecom.com>; > Robert Raszuk <rob...@raszuk.net> > *Cc:* spring@ietf.org > *Subject:* Re: [spring] Spring protection - determining applicability > > > > 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) <ket...@cisco.com> > *Sent:* Friday, August 14, 2020, 16:23 > *To:* Alexander Vainshtein; Joel M. Halpern; Shraddha Hegde; > ext-andrew.als...@liquidtelecom.com; Robert Raszuk > *Cc:* spring@ietf.org > *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 <alexander.vainsht...@rbbn.com> > *Sent:* 14 August 2020 18:24 > *To:* Ketan Talaulikar (ketant) <ket...@cisco.com>; Joel M. Halpern < > j...@joelhalpern.com>; Alexander Vainshtein <alexander.vainsht...@rbbn.com>; > Shraddha Hegde <shrad...@juniper.net>; ext-andrew.als...@liquidtelecom.com > <andrew.als...@liquidtelecom.com>; Robert Raszuk <rob...@raszuk.net> > *Cc:* spring@ietf.org > *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 <spring-boun...@ietf.org> on behalf of Ketan Talaulikar > (ketant) <ketant=40cisco....@dmarc.ietf.org> > *Sent:* Friday, August 14, 2020, 15:00 > *To:* Joel M. Halpern; Alexander Vainshtein; Shraddha Hegde; > ext-andrew.als...@liquidtelecom.com; Robert Raszuk > *Cc:* spring@ietf.org > *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 <spring-boun...@ietf.org> On Behalf Of Joel M. Halpern > Sent: 04 August 2020 20:25 > To: Alexander Vainshtein <alexander.vainsht...@rbbn.com>; Shraddha Hegde < > shraddha=40juniper....@dmarc.ietf.org>; > ext-andrew.als...@liquidtelecom.com <andrew.als...@liquidtelecom.com>; > Robert Raszuk <rob...@raszuk.net> > Cc: spring@ietf.org; Joel M. Halpern <j...@joelhalpern.com> > 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: +972-39266302 > > > > Cell: +972-549266302 > > > > Email: alexander.vainsht...@ecitele.com > > > > *From:* spring <spring-boun...@ietf.org> *On Behalf Of *Shraddha Hegde > > *Sent:* Tuesday, August 4, 2020 9:41 AM > > *To:* ext-andrew.als...@liquidtelecom.com > > <andrew.als...@liquidtelecom.com>; Robert Raszuk <rob...@raszuk.net> > > *Cc:* spring@ietf.org; Joel M. Halpern <j...@joelhalpern.com> > > *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 <spring-boun...@ietf.org > <spring-boun...@ietf.org%20%0b> > <mailto:spring-boun...@ietf.org > <spring-boun...@ietf.org>>> *On Behalf Of *Andrew Alston > > *Sent:* Tuesday, August 4, 2020 5:41 AM > > *To:* Robert Raszuk <rob...@raszuk.net <mailto:rob...@raszuk.net > <rob...@raszuk.net>>> > > *Cc:* spring@ietf.org <mailto:spring@ietf.org <spring@ietf.org>>; Joel > M. Halpern > > <j...@joelhalpern.com <mailto:j...@joelhalpern.com <j...@joelhalpern.com>>> > > *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 <rob...@raszuk.net <mailto:rob...@raszuk.net > <rob...@raszuk.net>>> > > *Sent:* Tuesday, 4 August 2020 01:27 > > *To:* Andrew Alston <andrew.als...@liquidtelecom.com > <andrew.als...@liquidtelecom.com%20%0b> > < > mailto:andrew.als...@liquidtelecom.com <andrew.als...@liquidtelecom.com>>> > > *Cc:* Joel M. Halpern <j...@joelhalpern.com > <j...@joelhalpern.com%20%0b> > <mailto:j...@joelhalpern.com > <j...@joelhalpern.com>>>; spring@ietf.org > > <mailto:spring@ietf.org <spring@ietf.org>> > > *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 > > <andrew.als...@liquidtelecom.com > <andrew.als...@liquidtelecom.com%20%0b> > < > mailto:andrew.als...@liquidtelecom.com <andrew.als...@liquidtelecom.com>>> > 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 <spring-boun...@ietf.org > <spring-boun...@ietf.org%0b> > <mailto:spring-boun...@ietf.org > <spring-boun...@ietf.org>>> *On Behalf Of *Joel M. Halpern > > *Sent:* Monday, 3 August 2020 21:36 > > *To:* Robert Raszuk <rob...@raszuk.net <mailto:rob...@raszuk.net > <rob...@raszuk.net>>> > > *Cc:* spr...@ietf..org <mailto:spring@ietf.org <spring@ietf.org>> > > *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 < > j...@joelhalpern.com > <j...@joelhalpern.com%0b> > <mailto:j...@joelhalpern.com%20%0b > <j...@joelhalpern.com%20%0b>>> <mailto:j...@joelhalpern.com > <j...@joelhalpern.com>>> 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: +972-39266302 > > > > > > > > Cell: +972-549266302 > > > > > > > > Email: alexander.vainsht...@ecitele.com > > <mailto:alexander.vainsht...@ecitele.com > <alexander.vainsht...@ecitele.com>> > > > <mailto:alexander.vainsht...@ecitele.com > <alexander.vainsht...@ecitele.com>> > > > > > > > > -----Original Message----- > > > > From: spring <spring-boun...@ietf.org > <spring-boun...@ietf.org%0b> > <mailto:spring-boun...@ietf.org%0b > <spring-boun...@ietf.org%0b>>> > > <mailto:spring-boun...@ietf.org <spring-boun...@ietf.org>>> On > Behalf Of Mach Chen > > > > Sent: Monday, August 3, 2020 6:30 AM > > > > To: Joel M. Halpern <j...@joelhalpern.com > <j...@joelhalpern.com%0b> > <mailto:j...@joelhalpern.com%0b > <j...@joelhalpern.com%0b>>> <mailto:j...@joelhalpern.com > <j...@joelhalpern.com>>>; > > spring@ietf.org <mailto:spring@ietf.org <spring@ietf.org>> < > mailto:spring@ietf.org <spring@ietf.org>> > > > > 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:spring-boun...@ietf.org > > > <mailto:spring-boun...@ietf.org <spring-boun...@ietf.org>> > > < > mailto:spring-boun...@ietf.org%0b%3e%20%3cmailto:spring-boun...@ietf.org%3e > <spring-boun...@ietf.org%0b%3e%20%3cmailto:spring-boun...@ietf.org%3e>>] > > On Behalf Of Joel M. > > > > > > > > > Halpern > > > > > > > > > Sent: Monday, August 3, 2020 7:51 AM > > > > > > > > > To: spring@ietf.org <mailto:spring@ietf.org > <spring@ietf.org>> > > <mailto:spring@ietf.org <spring@ietf.org>> > > > <mailto:spring@ietf.org <mailto:spring@ietf.org > <spring@ietf.org%20%3cmailto:spring@ietf.org%0b> > < > mailto:spring@ietf.org%20%3cmailto:spring@ietf.org > <spring@ietf.org%20%3cmailto:spring@ietf.org>>>> > > > > > > > > > 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 > > > > > > > > > spring@ietf.org <mailto:spring@ietf.org <spring@ietf.org>> > > <mailto:spring@ietf.org <spring@ietf.org>> > > > <mailto:spring@ietf.org <mailto:spring@ietf.org > <spring@ietf.org%20%3cmailto:spring@ietf.org%0b> > < > mailto:spring@ietf.org%20%3cmailto:spring@ietf.org > <spring@ietf.org%20%3cmailto:spring@ietf.org>>>> > > > > > > > > > > > > > > > > > > > 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 > > > > > > > > spring@ietf.org <mailto:spring@ietf.org <spring@ietf.org>> > > <mailto:spring@ietf.org <spring@ietf.org>> <mailto:spring@ietf.org > <spring@ietf.org%0b> > <mailto:spring@ietf.org%0b <spring@ietf.org%0b>>> > <mailto:spring@ietf.org <spring@ietf.org>>> > > > > > > > > > > > > > > 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 > > > > spring@ietf.org <mailto:spring@ietf.org <spring@ietf.org>> < > mailto:spring@ietf.org <spring@ietf.org>> > > > > > 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 > > > spring@ietf.org <mailto:spring@ietf.org <spring@ietf.org>> < > mailto:spring@ietf.org <spring@ietf.org>> > > > > 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 > > spring@ietf.org <mailto:spring@ietf.org <spring@ietf.org>> > > > 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 > spring@ietf.org > > https://clicktime.symantec.com/3Q1xsKGyMzNJCKyVPByhqLq6H2?u=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring > _______________________________________________ > spring mailing list > spring@ietf.org > > 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. > ------------------------------ > > > > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring > >
_______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
