Re: [spring] A belated comment on end-to-end path protection in draft-ietf-spring-resiliency-use-cases
Muthu Arul Mozhi Perumal <muthu.arul@gmail.com> Tue, 16 May 2017 10:28 UTC
Return-Path: <muthu.arul@gmail.com>
X-Original-To: spring@ietfa.amsl.com
Delivered-To: spring@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06776129412; Tue, 16 May 2017 03:28:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.688
X-Spam-Level:
X-Spam-Status: No, score=-2.688 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ip_xAQFqoSrl; Tue, 16 May 2017 03:28:29 -0700 (PDT)
Received: from mail-oi0-x232.google.com (mail-oi0-x232.google.com [IPv6:2607:f8b0:4003:c06::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D780F129C20; Tue, 16 May 2017 03:25:15 -0700 (PDT)
Received: by mail-oi0-x232.google.com with SMTP id h4so19320539oib.3; Tue, 16 May 2017 03:25:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=3wpxECqQrIGr+3yWWJJQUZUreSIoftF0elKX0pleGME=; b=ZCWuzLoH9VNWaN0ymi6VR5zkv9JIbyqs4a/k7CdIvjAgJQUuJAknpdAeHsfHFLJJ0D 1wcR2OiJB/y+EpdUGM+7i8/bssW6BvNPbeTIGGvXf75zFuzfz41hr6Lhzn5WIsz2kK09 mD0GwFT/H1ePVLOe4v8eAx1MY5D04mSbFWEMxGbpT1zvLVdqFinRe+LExvt/Kn9qHqUH ZubGM6cWNltdFwM0S/5tGaKTaceh2RkCNYDhjDfSm+AnI9lPAFAYZp/zGdlfLXMFM6+C ZnuKbt+Ta9bz0u/xgphP+her6BPZz/LWMW6N7EuHX672LA9rKfg/Z411vpJ9is9Gbf9T Y/+w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=3wpxECqQrIGr+3yWWJJQUZUreSIoftF0elKX0pleGME=; b=fh4yoPViLkzcIoclCtY42r0YspE6hqWPVtCxX86AWCMmWkfWiysMqrIRSRTN12A24D HLurNVqpqdG8ww7XyBa7uNUlp6eMk9RGWfVxB7q2e9/nc2Xv5WklULqweFRVtJIekFPg rMi2DRxtqnQ/KNc3oe6nDFNiWaufmc8u8b83+94+t0Lfwl1XCEAkW5TTvNiDEljcQyCl 10S4TzFs+UBSr/LDEYH1qZg+uqw4Y1VFKvdfZkqtnVE4P364CycfJ8HbvVJa5yh6LhFM YXe6ieio1mzD7rGS0iH8ibJvVb0apprSi7893RV2pz3DWK5i15h9KRECzuzpDmQ6ED/o 5caw==
X-Gm-Message-State: AODbwcCPtFM6m5XOereu75IvYjhNjRhxb8eeQ9bdmWY7iy5sEH7JEmyn rT5PzVSYKY9VXgOd4D0aVIpDAkuBgg==
X-Received: by 10.202.79.197 with SMTP id d188mr1504895oib.137.1494930315161; Tue, 16 May 2017 03:25:15 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.157.25.169 with HTTP; Tue, 16 May 2017 03:25:14 -0700 (PDT)
In-Reply-To: <AM4PR03MB1713AAD69441A6C92D63B5919DE60@AM4PR03MB1713.eurprd03.prod.outlook.com>
References: <AM4PR03MB1713393C262301279EAF29039DED0@AM4PR03MB1713.eurprd03.prod.outlook.com> <4CE8B71E-1CB7-43AF-9DA3-D936E030A2CA@cisco.com> <AM4PR03MB1713F46B5662731126099CFE9DE60@AM4PR03MB1713.eurprd03.prod.outlook.com> <CAKz0y8wPO6VcMJ6Ba_m1A5L2F5bh2rv7761C8vGo51H+xSRfuA@mail.gmail.com> <AM4PR03MB1713AAD69441A6C92D63B5919DE60@AM4PR03MB1713.eurprd03.prod.outlook.com>
From: Muthu Arul Mozhi Perumal <muthu.arul@gmail.com>
Date: Tue, 16 May 2017 15:55:14 +0530
Message-ID: <CAKz0y8zHzneU4SUtH8RGp0kjKVc=XfFZ3uO6e8NNFGn0X383LQ@mail.gmail.com>
To: Alexander Vainshtein <Alexander.Vainshtein@ecitele.com>
Cc: "Stefano Previdi (sprevidi)" <sprevidi@cisco.com>, "spring@ietf.org" <spring@ietf.org>, Shell Nakash <Shell.Nakash@ecitele.com>, Michael Gorokhovsky <Michael.Gorokhovsky@ecitele.com>, "draft-ietf-spring-resiliency-use-cases@ietf.org" <draft-ietf-spring-resiliency-use-cases@ietf.org>, Sidd Aanand <Sidd.Aanand@ecitele.com>, Ron Sdayoor <Ron.Sdayoor@ecitele.com>, Rotem Cohen <Rotem.Cohen@ecitele.com>
Content-Type: multipart/alternative; boundary="001a113d73a0663552054fa196bf"
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/M3zPxSBBm_IMCdL8s5RJsAnBgIU>
Subject: Re: [spring] A belated comment on end-to-end path protection in draft-ietf-spring-resiliency-use-cases
X-BeenThere: spring@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." <spring.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/spring>, <mailto:spring-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/spring/>
List-Post: <mailto:spring@ietf.org>
List-Help: <mailto:spring-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/spring>, <mailto:spring-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 16 May 2017 10:28:33 -0000
On Tue, May 16, 2017 at 3:27 PM, Alexander Vainshtein < Alexander.Vainshtein@ecitele.com> 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: Alexander.Vainshtein@ecitele.com > > > > *From:* Muthu Arul Mozhi Perumal [mailto:muthu.arul@gmail.com] > *Sent:* Tuesday, May 16, 2017 12:34 PM > *To:* Alexander Vainshtein <Alexander.Vainshtein@ecitele.com> > *Cc:* Stefano Previdi (sprevidi) <sprevidi@cisco.com>; spring@ietf.org; > Shell Nakash <Shell.Nakash@ecitele.com>; Michael Gorokhovsky < > Michael.Gorokhovsky@ecitele.com>; draft-ietf-spring-resiliency- > use-cases@ietf.org; Sidd Aanand <Sidd.Aanand@ecitele.com>; Ron Sdayoor < > Ron.Sdayoor@ecitele.com>; Rotem Cohen <Rotem.Cohen@ecitele.com> > > *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 < > Alexander.Vainshtein@ecitele.com> wrote: > > > > > > Regards, > > Sasha > > > > Office: +972-39266302 <+972%203-926-6302> > > Cell: +972-549266302 <+972%2054-926-6302> > > Email: Alexander.Vainshtein@ecitele.com > > > > *From:* Alexander Vainshtein > *Sent:* Tuesday, May 16, 2017 11:28 AM > *To:* 'Stefano Previdi (sprevidi)' <sprevidi@cisco.com> > *Cc:* draft-ietf-spring-resliency-use-cases@ietf.org; spring@ietf.org; > Shell Nakash <Shell.Nakash@ecitele.com>; Michael Gorokhovsky < > Michael.Gorokhovsky@ecitele.com>; Sidd Aanand <Sidd.Aanand@ecitele.com>; > Ron Sdayoor <Ron.Sdayoor@ecitele.com>; Rotem Cohen < > Rotem.Cohen@ecitele.com> > *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: Alexander.Vainshtein@ecitele.com > > > > > > -----Original Message----- > From: Stefano Previdi (sprevidi) [mailto:sprevidi@cisco.com > <sprevidi@cisco.com>] > Sent: Monday, May 15, 2017 11:12 AM > To: Alexander Vainshtein <Alexander.Vainshtein@ecitele.com> > Cc: draft-ietf-spring-resliency-use-cases@ietf.org; spring@ietf.org; > Shell Nakash <Shell.Nakash@ecitele.com>; Michael Gorokhovsky < > Michael.Gorokhovsky@ecitele.com>; Sidd Aanand <Sidd.Aanand@ecitele.com>; > Ron Sdayoor <Ron.Sdayoor@ecitele.com>; Rotem Cohen < > Rotem.Cohen@ecitele.com> > 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 < > Alexander.Vainshtein@ecitele.com> 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: Alexander.Vainshtein@ecitele.com > > > > > > > > > ______________________________________________________________________ > > > _____ > > > > > > 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 > > > spring@ietf.org > > > 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 > spring@ietf.org > 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] A belated comment on end-to-end path pro… Alexander Vainshtein
- Re: [spring] A belated comment on end-to-end path… Stefano Previdi (sprevidi)
- Re: [spring] A belated comment on end-to-end path… Alexander Vainshtein
- Re: [spring] A belated comment on end-to-end path… Alexander Vainshtein
- Re: [spring] A belated comment on end-to-end path… Robert Raszuk
- Re: [spring] A belated comment on end-to-end path… stephane.litkowski
- Re: [spring] A belated comment on end-to-end path… Muthu Arul Mozhi Perumal
- Re: [spring] A belated comment on end-to-end path… Alexander Vainshtein
- Re: [spring] A belated comment on end-to-end path… Alexander Vainshtein
- Re: [spring] A belated comment on end-to-end path… Muthu Arul Mozhi Perumal
- Re: [spring] A belated comment on end-to-end path… Alexander Vainshtein
- Re: [spring] A belated comment on end-to-end path… Alexander Vainshtein
- Re: [spring] A belated comment on end-to-end path… Stefano Previdi (sprevidi)
- Re: [spring] A belated comment on end-to-end path… Alexander Vainshtein
- Re: [spring] A belated comment on end-to-end path… Muthu Arul Mozhi Perumal
- Re: [spring] A belated comment on end-to-end path… Rob Shakir
- Re: [spring] A belated comment on end-to-end path… Muthu Arul Mozhi Perumal
- Re: [spring] A belated comment on end-to-end path… Alexander Vainshtein
- Re: [spring] A belated comment on end-to-end path… Alexander Vainshtein
- Re: [spring] A belated comment on end-to-end path… Alexander Vainshtein
- Re: [spring] A belated comment on end-to-end path… Jeff Tantsura
- Re: [spring] A belated comment on end-to-end path… Stefano Previdi (sprevidi)
- Re: [spring] A belated comment on end-to-end path… Alexander Vainshtein