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
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
<mailto: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>>
*Cc:* spring@ietf.org <mailto:spring@ietf.org>; Joel M. Halpern
<j...@joelhalpern.com <mailto: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>>
*Sent:* Tuesday, 4 August 2020 01:27
*To:* Andrew Alston <andrew.als...@liquidtelecom.com
<mailto:andrew.als...@liquidtelecom.com>>
*Cc:* Joel M. Halpern <j...@joelhalpern.com
<mailto:j...@joelhalpern.com>>; spring@ietf.org <mailto: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
<mailto: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
<mailto: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>>
*Cc:* spr...@ietf..org <mailto: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
<mailto:j...@joelhalpern.com%20%0b>> <mailto: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://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>>
>
> > 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
<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://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:
> >
> > 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
<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>
> <mailto:alexander.vainsht...@ecitele.com>
> >
> > -----Original Message-----
> > From: spring <spring-boun...@ietf.org
<mailto:spring-boun...@ietf.org%0b>>
<mailto:spring-boun...@ietf.org>> On Behalf Of Mach Chen
> > Sent: Monday, August 3, 2020 6:30 AM
> > To: Joel M. Halpern <j...@joelhalpern.com
<mailto:j...@joelhalpern.com%0b>> <mailto:j...@joelhalpern.com>>;
spring@ietf.org <mailto:spring@ietf.org> <mailto: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>
<mailto: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>
<mailto:spring@ietf.org>
> <mailto:spring@ietf.org <mailto:spring@ietf.org
<mailto: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>
<mailto:spring@ietf.org>
> <mailto:spring@ietf.org <mailto:spring@ietf.org
<mailto:spring@ietf.org%20%3cmailto:spring@ietf.org>>>
> >
> > >
> >
>
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
> >
> > _______________________________________________
> >
> > spring mailing list
> >
> > spring@ietf.org <mailto:spring@ietf.org>
<mailto:spring@ietf.org> <mailto:spring@ietf.org
<mailto:spring@ietf.org%0b>> <mailto: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> <mailto:spring@ietf.org>
> > 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
> spring@ietf.org <mailto:spring@ietf.org> <mailto:spring@ietf.org>
> 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
spring@ietf.org <mailto:spring@ietf.org>
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>
------------------------------------------------------------------------
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.
------------------------------------------------------------------------
