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 <+972%203-926-6302> > > Cell: +972-549266302 <+972%2054-926-6302> > > 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]>; draft-ietf-spring-resiliency- > [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 <+972%203-926-6302> > > Cell: +972-549266302 <+972%2054-926-6302> > > 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 <+972%203-926-6302> > > Cell: +972-549266302 <+972%2054-926-6302> > > Email: [email protected] > > > > > > -----Original Message----- > From: Stefano Previdi (sprevidi) [mailto:[email protected] > <[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 <+972%203-926-6302> > > > Cell: +972-549266302 <+972%2054-926-6302> > > > 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. > ____________________________________________________________ > _______________ >
_______________________________________________ spring mailing list [email protected] https://www.ietf.org/mailman/listinfo/spring
