Re: [mpls] Scalability of the "effective FRR" approach in draft-kini-mpls-ring-frr-facility-backup-00.txt
Alexander Vainshtein <Alexander.Vainshtein@ecitele.com> Tue, 27 July 2010 06:55 UTC
Return-Path: <Alexander.Vainshtein@ecitele.com>
X-Original-To: mpls@core3.amsl.com
Delivered-To: mpls@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8D2EE3A68D7 for <mpls@core3.amsl.com>; Mon, 26 Jul 2010 23:55:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.192
X-Spam-Level:
X-Spam-Status: No, score=-2.192 tagged_above=-999 required=5 tests=[AWL=0.406, BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uTPJ7ws+9czv for <mpls@core3.amsl.com>; Mon, 26 Jul 2010 23:55:47 -0700 (PDT)
Received: from ilptbmg01.ecitele.com (ilptbmg01-out.ecitele.com [147.234.242.234]) by core3.amsl.com (Postfix) with ESMTP id DF5F93A67A2 for <mpls@ietf.org>; Mon, 26 Jul 2010 23:55:46 -0700 (PDT)
Received: from DLP_bound_connection ( [147.234.242.234]) by ilptbmg01.ecitele.com (Symantec Brightmail Gateway) with SMTP id 86.33.32431.7038E4C4; Tue, 27 Jul 2010 09:56:07 +0300 (IDT)
X-AuditID: 93eaf2e7-b7c6dae000007eaf-4a-4c4e82c70d66
Received: from ilptexch01.ecitele.com ( [172.31.244.40]) by ilptbmg01.ecitele.com (Symantec Brightmail Gateway) with SMTP id 92.33.32431.7C28E4C4; Tue, 27 Jul 2010 09:55:03 +0300 (IDT)
Received: from ILPTMAIL02.ecitele.com ([147.234.244.213]) by ilptexch01.ecitele.com ([172.31.244.40]) with mapi; Tue, 27 Jul 2010 09:55:02 +0300
From: Alexander Vainshtein <Alexander.Vainshtein@ecitele.com>
To: Sriganesh Kini <sriganesh.kini@ericsson.com>
Date: Tue, 27 Jul 2010 09:55:18 +0300
Thread-Topic: [mpls] Scalability of the "effective FRR" approach in draft-kini-mpls-ring-frr-facility-backup-00.txt
Thread-Index: Acss451Rwl5jkjLdTWWmLbBSEMenUAAAJKaAABzm8kA=
Message-ID: <A3C5DF08D38B6049839A6F553B331C76D5BB4A3F91@ILPTMAIL02.ecitele.com>
References: <A3C5DF08D38B6049839A6F553B331C76D5BB4A3ED3@ILPTMAIL02.ecitele.com> <5A5E55DF96F73844AF7DFB0F48721F0F567DB80AFB@EUSAACMS0703.eamcs.ericsson.se>
In-Reply-To: <5A5E55DF96F73844AF7DFB0F48721F0F567DB80AFB@EUSAACMS0703.eamcs.ericsson.se>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_A3C5DF08D38B6049839A6F553B331C76D5BB4A3F91ILPTMAIL02eci_"
MIME-Version: 1.0
X-Brightmail-Tracker: AAAAAA==
Cc: "mpls@ietf.org" <mpls@ietf.org>
Subject: Re: [mpls] Scalability of the "effective FRR" approach in draft-kini-mpls-ring-frr-facility-backup-00.txt
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mpls>
List-Post: <mailto:mpls@ietf.org>
List-Help: <mailto:mpls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 27 Jul 2010 06:55:53 -0000
Sri,
Lots of thanks for a prompt response. It seems that we more or less agree on the facts (proliferation of e-backup LSPs) but we differ in interpreting the impact of these facts on the actual operational experience.
However, I'd like to notice that "BW effectiveness" of e-backup LSPs is also somewhat problematic IMO.
Please note that both the regular backup and e-backup bypass tunnels cross multiple links that are not involved with the original set of LSPs they are protecting. And they both consume BW on these links. The only difference is that they are competing for BW with other LSPs, not with ones they are protecting. But the overall effect is exactly the same IMO.
My 2c,
Sasha
From: Sriganesh Kini [mailto:sriganesh.kini@ericsson.com]
Sent: Monday, July 26, 2010 8:01 PM
To: Alexander Vainshtein
Cc: mpls@ietf.org
Subject: RE: [mpls] Scalability of the "effective FRR" approach in draft-kini-mpls-ring-frr-facility-backup-00.txt
Sasha,
As you noted the e-backup tunnel protects all LSPs that have a common {head-end, tail-end} pair. More precisely, the e-backup can be shared to protect all LSPs that have a common {ring-ingress-LSR, ring-egress-LSR} pair (that is path is disjoint with the e-backup).
If I understood correctly your concern is about the number of number of e-backup tunnels?
E-backup tunnels should be setup based on protected LSP's {ring-ingress, ring-egress} LSRs. Consider a typical case where in a ring, there is a 'ring-head-end' and LSPs are setup from other LSRs on the ring to the 'ring-head-end'. An e-backup should be setup from each LSR on the ring to the 'ring-head-end'. This is order(n).
Even for cases where protected LSPs have many possible combinations for {ring-ingress, ring-egress}, for typical ring sizes, the number of tunnels required should not be a concern for today's implementations.
Also, in many topologies an LSR that is purely a transit for protected LSPs, does not have to originate any e-backup.
Thanks
- Sri
PS: Regular facility FRR requires more that two backup tunnels, depending on what is being protected.
________________________________
From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Alexander Vainshtein
Sent: Monday, July 26, 2010 9:57 AM
To: Sriganesh Kini
Cc: mpls@ietf.org
Subject: [mpls] Scalability of the "effective FRR" approach in draft-kini-mpls-ring-frr-facility-backup-00.txt
Sriganesh and all,
If I understood you correctly, your proposal requires a dedicated backup tunnel for all LSPs with the given {head-end, tail-end} pair of LSRs in the ring. (Regular facility FRR requires just two backup tunnels).
If this understanding is correct, this looks to like a serious scalability issue with your approach.
Regards,
Sasha
- [mpls] Scalability of the "effective FRR" approac… Alexander Vainshtein
- Re: [mpls] Scalability of the "effective FRR" app… Sriganesh Kini
- Re: [mpls] Scalability of the "effective FRR" app… Alexander Vainshtein
- Re: [mpls] Scalability of the "effective FRR" app… Sriganesh Kini
- Re: [mpls] Scalability of the "effective FRR" app… Eric Osborne (eosborne)
- Re: [mpls] Scalability of the "effective FRR" app… Sriganesh Kini
- Re: [mpls] Scalability of the "effective FRR" app… Eric Osborne (eosborne)
- Re: [mpls] Scalability of the "effective FRR" app… Sriganesh Kini
- Re: [mpls] Scalability of the "effective FRR" app… Eric Osborne (eosborne)
- Re: [mpls] Scalability of the "effective FRR" app… Sriganesh Kini
- Re: [mpls] Scalability of the "effective FRR" app… Eric Osborne (eosborne)
- Re: [mpls] Scalability of the "effective FRR" app… Sriganesh Kini
- Re: [mpls] Scalability of the "effective FRR" app… Sriganesh Kini
- Re: [mpls] Scalability of the "effective FRR" app… Greg Mirsky
- Re: [mpls] Scalability of the "effective FRR" app… Sriganesh Kini