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 < andrew.als...@liquidtelecom.com> wrote: > 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 <gregimir...@gmail.com> > *Sent:* Tuesday, 4 August 2020 01:40 > *To:* Andrew Alston <andrew.als...@liquidtelecom.com> > *Cc:* Joel M. Halpern <j...@joelhalpern.com>; Robert Raszuk < > rob...@raszuk.net>; spring@ietf.org > *Subject:* Re: [spring] Spring protection - determining applicability > > > > Hi Andrew, > > would such requirements support using e2e protection? > > > > Regards, > > Greg > > > > On Mon, Aug 3, 2020 at 2:46 PM Andrew Alston < > 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> *On Behalf Of *Joel M. Halpern > *Sent:* Monday, 3 August 2020 21:36 > *To:* Robert Raszuk <rob...@raszuk.net> > *Cc:* 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%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://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: 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 > <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 > <j...@joelhalpern.com>>>; 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%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 <mailto: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 <mailto: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> > > > > > > > F%2Fwww.ietf.org > > <http://2Fwww.ietf.org>%2Fmailman%2Flistinfo%2Fspring > > > > > > _______________________________________________ > > > > > > spring mailing list > > > > > > spring@ietf.org <mailto:spring@ietf.org <spring@ietf.org>> < > mailto:spring@ietf.org > <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 > > > > > > > > > > > > > > ------------------------------------------------------------------------ > > > 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>> > > > https://www.ietf.org/mailman/listinfo/spring > > > > > > > _______________________________________________ > > spring mailing list > > spring@ietf.org <mailto:spring@ietf.org <spring@ietf.org>> > > https://www.ietf.org/mailman/listinfo/spring > > > > _______________________________________________ > 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 > >
_______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
