resending with reduced number of recipients.
Cheers, Jeff Sasha, Don’t forget – RSVP-TE FRR has explicit signaling and state associated with it, as well as well defined state transitions, SR on contrary doesn’t. Changes in topology (link/node down events) are not communicated back to the head-end directly but rather flooded thru a routing protocol (for sake of this discussion lets ignore the possibility of running fast failure detection over SR tunnels). Trying to derive operation state at PLR based on transitional changes in a routing protocol is a rather complicated task. Cheers, Jeff From: spring <[email protected]> on behalf of Alexander Vainshtein <[email protected]> Date: Tuesday, May 16, 2017 at 09:23 To: Muthu Arul Mozhi Perumal <[email protected]> Cc: "[email protected]" <[email protected]>, Shell Nakash <[email protected]>, Michael Gorokhovsky <[email protected]>, "[email protected]" <[email protected]>, Sidd Aanand <[email protected]>, "Stefano Previdi (sprevidi)" <[email protected]>, Ron Sdayoor <[email protected]>, Rotem Cohen <[email protected]> Subject: Re: [spring] A belated comment on end-to-end path protection in draft-ietf-spring-resiliency-use-cases Muthu, Again lots of thanks for a prompt response. We seem to agree on the following points: · In SR some failures cannot be handled by local protection (actually, there is an expired draft that defines how this could be done, but it introduces serious complexity) · Combining local protection with end-to-end path protection is possible. In particular, such a combination speeds up handling of failures that that can be handled locally while also handling failures that could not be addressed by local protection. Whether combining both forms of protection carries with it some new problems or not is a different story. Regards, Sasha Office: +972-39266302 Cell: +972-549266302 Email: [email protected] From: Muthu Arul Mozhi Perumal [mailto:[email protected]] Sent: Tuesday, May 16, 2017 7:11 PM To: Alexander Vainshtein <[email protected]> Cc: Stefano Previdi (sprevidi) <[email protected]>; [email protected]; Shell Nakash <[email protected]>; Michael Gorokhovsky <[email protected]>; [email protected]; Sidd Aanand <[email protected]>; Ron Sdayoor <[email protected]>; Rotem Cohen <[email protected]> Subject: Re: [spring] A belated comment on end-to-end path protection in draft-ietf-spring-resiliency-use-cases Sasha, On Tue, May 16, 2017 at 4:29 PM, Alexander Vainshtein <[email protected]> wrote: Muthu, An additional clarification: · If the link BC were OK, B could pop B from the stack and send packets to C with just D in the stack · When the link BC fails, B will leave the stack as (CD) IMHO – it would be just trying to bypass the failed link BC. · If the failure of BC as perceived by B was cause by the failure of node B, such a failure could not be recovered by local protection. This is exactly the scenario where local protection for shortest SR path comprising an SR-TE path should be augmented by end-to-end path protection. If node B fails, the e2e path monitoring at node A would anyway detect the failure and switch the traffic over an alternate disjoint path... Regarding combination of local protection with end-to-end protection for RSVP-TE – AFAIK this was never used because it would not provide any added value. In SR this is not so because local protection is usually faster (and scales better) than end-to-end protection, but, as opposed to RSVP-TE, there are failures that local protection cannot fix. Agree, there are failures in SR-TE that local protection cannot fix as desired, so it calls for e2e path protection. However, enabling them together is not always the best approach since it can introduce other problems to solve. Regards, Muthu Regards, Sasha Office: +972-39266302 Cell: +972-549266302 Email: [email protected] From: Alexander Vainshtein Sent: Tuesday, May 16, 2017 1:42 PM To: 'Muthu Arul Mozhi Perumal' <[email protected]> Cc: Stefano Previdi (sprevidi) <[email protected]>; [email protected]; Shell Nakash <[email protected]>; Michael Gorokhovsky <[email protected]>; [email protected]; Sidd Aanand <[email protected]>; Ron Sdayoor <[email protected]>; Rotem Cohen <[email protected]> Subject: RE: [spring] A belated comment on end-to-end path protection in draft-ietf-spring-resiliency-use-cases Muthu, Again lots of thanks for a prompt response. I still do not think a loop would really form because: · A sends packet to its local next hop for B with the stack (B, C, D) · B receives this packet with the stack (C, D), but the link C has failed. So B sends to its next hop for it back to A with stack (C,D) · A now sends the packet to its next hop for C with the same stack. Regards, Sasha Office: +972-39266302 Cell: +972-549266302 Email: [email protected] From: Muthu Arul Mozhi Perumal [mailto:[email protected]] Sent: Tuesday, May 16, 2017 1:25 PM To: Alexander Vainshtein <[email protected]> Cc: Stefano Previdi (sprevidi) <[email protected]>; [email protected]; Shell Nakash <[email protected]>; Michael Gorokhovsky <[email protected]>; [email protected]; Sidd Aanand <[email protected]>; Ron Sdayoor <[email protected]>; Rotem Cohen <[email protected]> Subject: Re: [spring] A belated comment on end-to-end path protection in draft-ietf-spring-resiliency-use-cases On Tue, May 16, 2017 at 3:27 PM, Alexander Vainshtein <[email protected]> wrote: Muthu, Lots of thanks for a prompt response. I do not think that the loop you have described would actually appear in the scenario you’ve described. To the best of my understanding of TI-LFA, B would send the traffic back to A complete with an explicit route that says Bà Aà CàD, and no loop would be formed. Not necessarily. B was asked to send the traffic to C and knows that if it sends the traffic to A, then A will send it to C over the shortest path (i.e from B's perspective only the labeled next-hop changes). Unfortunately, A has an explicit route pointing back to B (over the SR-TE tunnel T1) that B isn't aware of. If B does strict explicit route for everything, then B can run out of its MSD.. Similar “loops” can happen also in MPLS FRR with RSVP-TE when the PLR sends some traffic back - but it sends it with the suitable label stack of the bypass tunnel so that eventually it reaches the MP. Are there existing deployments where both e2e path protection and local protection are used together with RSVP-TE? Regards, Muthu Regards, Sasha Office: +972-39266302 Cell: +972-549266302 Email: [email protected] From: Muthu Arul Mozhi Perumal [mailto:[email protected]] Sent: Tuesday, May 16, 2017 12:34 PM To: Alexander Vainshtein <[email protected]> Cc: Stefano Previdi (sprevidi) <[email protected]>; [email protected]; Shell Nakash <[email protected]>; Michael Gorokhovsky <[email protected]>; [email protected]; Sidd Aanand <[email protected]>; Ron Sdayoor <[email protected]>; Rotem Cohen <[email protected]> Subject: Re: [spring] A belated comment on end-to-end path protection in draft-ietf-spring-resiliency-use-cases Using end-to-end path protection together with local protection can result in traffic loops. Consider the foll. topology: B-----C | / \ | / \ | / \ | / \D----+ A/ Z (CE) \ F----+ \ / \ / \ / \E/ - All links are of equal cost. - A, D and F are BGP peers. - Z is a dual-homed CE. A resolves its BGP next-hop D over the SR-TE tunnel T1. T1: A->B, B->C, C->D (loosely routed) Suppose A has enabled end-to-end path protection over tunnel T1 and B has TI-LFA enabled, and the detection timers are configured as described in your previous email. If the BC link goes down, B will immediately start rerouting the traffic via A (in FRR fashion) creating a loop b/w A and B. A solution would be to make the A-B link ineligible for TI-LFA backup computation at B. However, managing this network-wide could become operational expensive. Hence, deploying one of end-to-end path protection or local protection with sufficiently short detection timers keeps things simple, IMHO. Regards, Muthu On Tue, May 16, 2017 at 1:59 PM, Alexander Vainshtein <[email protected]> wrote: Regards, Sasha Office: +972-39266302 Cell: +972-549266302 Email: [email protected] From: Alexander Vainshtein Sent: Tuesday, May 16, 2017 11:28 AM To: 'Stefano Previdi (sprevidi)' <[email protected]> Cc: [email protected]; [email protected]; Shell Nakash <[email protected]>; Michael Gorokhovsky <[email protected]>; Sidd Aanand <[email protected]>; Ron Sdayoor <[email protected]>; Rotem Cohen <[email protected]> Subject: RE: [spring] A belated comment on end-to-end path protection in draft-ietf-spring-resiliency-use-cases Stefano, Lots of thanks for a prompt response. A couple of short comments if you do not mind: Using 2119 language in a "use cases" document: 1. Going back to the source I see that “MUST NOT… mean that the definition is an absolute prohibition of the specification” 2. I agree that the use case document defines which scenarios should be addressed, but I do not see how it can impose an absolute prohibition on a certain scenario. Little sense link protection has in the case of path protection: 1. This was definitely correct for traditional traffic engineering because the “shortest traffic paths” (e.g., LDL PSPs) could be easily differentiated from the “engineered traffic paths”. 2. In addition, traditional local protection (e.g., MPLS FRR using RSVP-TE) could deal with link and node failures regardless of whether the failed link or node appeared in the ERO of the protected path. 3. IMHO and FWIW, with SR the situation is quite different: o The shortest traffic paths not only coexist with engineered traffic paths: the latter are in many cases “tunneled” within the former. o Path protection cannot be applied to shortest traffic paths so they must rely on local protection o Local protection in the case of failure of a node or link that appears in the ERO of an engineered SR path is highly non-trivial at best, so path protection for the engineered LSPs looks like a preferred solution to me. I fully agree with you that the operators deploying SR should provide feedback on this point based on actual operational experience. Meanwhile I doubt that a priori declaring some use cases as absolutely prohibited is the right thing to do. My 2c, Sasha Office: +972-39266302 Cell: +972-549266302 Email: [email protected] -----Original Message----- From: Stefano Previdi (sprevidi) [mailto:[email protected]] Sent: Monday, May 15, 2017 11:12 AM To: Alexander Vainshtein <[email protected]> Cc: [email protected]; [email protected]; Shell Nakash <[email protected]>; Michael Gorokhovsky <[email protected]>; Sidd Aanand <[email protected]>; Ron Sdayoor <[email protected]>; Rotem Cohen <[email protected]> Subject: Re: [spring] A belated comment on end-to-end path protection in draft-ietf-spring-resiliency-use-cases > On May 11, 2017, at 12:04 PM, Alexander Vainshtein > <[email protected]> wrote: > > Hi all, > I have a belated (but hopefully late is still better than never) comment on > path protection as defined in Section 2 of the draft. > > This second para in this section says: > A first protection strategy consists in excluding any local repair > > but instead use end-to-end path protection where each SPRING path > is > > protected by a second disjoint SPRING path. In this case local > > protection MUST NOT be used. > > First of all, I do not think that RFC 2119 language should be used in > Informational documents, especially in the documents that describe use cases. this document is also a requirements document for the resiliency use-case. RFC2119 terminology is perfectly usable and even more, it adds clarity on what the solution is expected to provide. > In addition, I specifically disagree with the quoted statement above, > because, from my POV: > · Local repair and end-to-end path protection can be combined for the > same path > · Such a combination may be beneficial for the operators. are you talking by experience or is it just something that came into your mind ? I’d like to hear from operators using a combination of path and link protection. This document has been deeply reviewed also by operators and it has been always obvious the little sense link protection has in case of path protection. > One possible way to combine the two is described below: > > 1. A pair of SR paths is set up between the given two nodes – later > referred to as source and destination - in the network. These paths are > “SR-disjoint” in the sense that their “explicit routes” do not have any > common elements, be they nodes or adjacencies, with exclusion of the final > destination > 2. Local repair for these paths is enabled in the network. It is > triggered by locally observed events (link failures etc.), applied by the > nodes adjacent to the failure and guarantees that, in the case of a link or > node failure that is not specified in the explicit route, traffic along the > affected path would be restored within <X> milliseconds > 3. End-to-end liveness monitoring is enabled for the two SR paths, and > detects end-to-end failures of these paths within <Y> milliseconds where Y >> > X. In other words, end-to-end liveness monitoring for these paths will ignore > any failures that local repair can fix, but will detect failures that cannot > be locally repaired (e.g., failures of nodes or links that have been > specified in the explicit route of one of the paths > 4. End-to-end liveness monitoring triggers end-to-end path protection > to be applied by the source node in the following way: > a. If it recognizes both paths as alive, one of them will carry the > customer traffic, while the other one will be idle. The rules for selecting > the active path in this scenario may vary > b. If end-to-end failure of one of these paths is detected while the > other one remains alive, traffic will be carried across the live path > c. If end-to-end failure of both paths is detected (e.g., if the final > destination node fails, or if the network is partitioned), this is recognized > as an unrecoverable failure. > > From my POV the combination of local repair and end-to-end protection for SR > paths is one of a few possibilities to protect such paths against failures of > nodes and/or links that have been specified in their explicit routes. > (Another option has been described in Node Protection for SR-TE Paths, but > this draft has expired). > > Do I miss something substantial? to my view you created a use-case that doesn’t bring much to the picture but I’d let operators to comment. s. > > Regards, > Sasha > > Office: +972-39266302 > Cell: +972-549266302 > Email: [email protected] > > > ______________________________________________________________________ > _____ > > This e-mail message is intended for the recipient only and contains > information which is CONFIDENTIAL and which may be proprietary to ECI > Telecom. If you have received this transmission in error, please > inform us by e-mail, phone or fax, and then delete the original and all > copies thereof. > ______________________________________________________________________ > _____ _______________________________________________ > spring mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/spring ___________________________________________________________________________ This e-mail message is intended for the recipient only and contains information which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received this transmission in error, please inform us by e-mail, phone or fax, and then delete the original and all copies thereof. ___________________________________________________________________________ _______________________________________________ spring mailing list [email protected] https://www.ietf.org/mailman/listinfo/spring ___________________________________________________________________________ This e-mail message is intended for the recipient only and contains information which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received this transmission in error, please inform us by e-mail, phone or fax, and then delete the original and all copies thereof. ___________________________________________________________________________ ___________________________________________________________________________ This e-mail message is intended for the recipient only and contains information which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received this transmission in error, please inform us by e-mail, phone or fax, and then delete the original and all copies thereof. ___________________________________________________________________________ ___________________________________________________________________________ This e-mail message is intended for the recipient only and contains information which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received this transmission in error, please inform us by e-mail, phone or fax, and then delete the original and all copies thereof. ___________________________________________________________________________ _______________________________________________ spring mailing list [email protected] https://www.ietf.org/mailman/listinfo/spring
_______________________________________________ spring mailing list [email protected] https://www.ietf.org/mailman/listinfo/spring
