Return-Path: 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 EBDC13A6A38 for ; Tue, 27 Jul 2010 00:28:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.265 X-Spam-Level: X-Spam-Status: No, score=-3.265 tagged_above=-999 required=5 tests=[AWL=-0.667, 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 lh-PjO4ic2PO for ; Tue, 27 Jul 2010 00:27:59 -0700 (PDT) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by core3.amsl.com (Postfix) with ESMTP id 1D0583A69F9 for ; Tue, 27 Jul 2010 00:27:59 -0700 (PDT) Received: from eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id o6R7S92N006787 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 27 Jul 2010 02:28:14 -0500 Received: from EUSAACMS0703.eamcs.ericsson.se ([169.254.1.134]) by eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) with mapi; Tue, 27 Jul 2010 03:28:09 -0400 From: Sriganesh Kini To: Alexander Vainshtein Date: Tue, 27 Jul 2010 03:28:08 -0400 Thread-Topic: [mpls] Scalability of the "effective FRR" approach in draft-kini-mpls-ring-frr-facility-backup-00.txt Thread-Index: Acss451Rwl5jkjLdTWWmLbBSEMenUAAAJKaAABzm8kAAAGaFoA== Message-ID: <5A5E55DF96F73844AF7DFB0F48721F0F567DB80E82@EUSAACMS0703.eamcs.ericsson.se> References: <5A5E55DF96F73844AF7DFB0F48721F0F567DB80AFB@EUSAACMS0703.eamcs.ericsson.se> In-Reply-To: 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_5A5E55DF96F73844AF7DFB0F48721F0F567DB80E82EUSAACMS0703e_" MIME-Version: 1.0 Cc: "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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jul 2010 07:28:06 -0000 --_000_5A5E55DF96F73844AF7DFB0F48721F0F567DB80E82EUSAACMS0703e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Sasha, you are welcome. It should be noted that path computation for e-backup is trivial when route= d along the backup. That should not impact operational experience. Setup/ma= intenance of e-backup should be fairly straightforward. It would be helpful= if you can quantify a 'proliferation'. Bandwidth can be shared between the e-backup and the backup tunnel. When th= e e-backup is routed along the backup, there should not be any extra bandwi= dth consumed compared to [MPLS-FRR]. The benefit is that the problematic U-= turn goes away. Thanks - Sri ________________________________ From: Alexander Vainshtein [mailto:Alexander.Vainshtein@ecitele.com] Sent: Monday, July 26, 2010 11:55 PM To: Sriganesh Kini Cc: mpls@ietf.org Subject: RE: [mpls] Scalability of the "effective FRR" approach in draft-ki= ni-mpls-ring-frr-facility-backup-00.txt Sri, Lots of thanks for a prompt response. It seems that we more or less agree o= n 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 als= o 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 i= s that they are competing for BW with other LSPs, not with ones they are pr= otecting. 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-ki= ni-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-b= ackup tunnels? E-backup tunnels should be setup based on protected LSP's {ring-ingress, ri= ng-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-he= ad-end'. This is order(n). Even for cases where protected LSPs have many possible combinations for {ri= ng-ingress, ring-egress}, for typical ring sizes, the number of tunnels req= uired 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 o= n what is being protected. ________________________________ From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Ale= xander 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-m= pls-ring-frr-facility-backup-00.txt Sriganesh and all, If I understood you correctly, your proposal requires a dedicated backup tu= nnel for all LSPs with the given {head-end, tail-end} pair of LSRs in the r= ing. (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 --_000_5A5E55DF96F73844AF7DFB0F48721F0F567DB80E82EUSAACMS0703e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Sasha, you are welcome.
 
It=20 should be noted that path computation for e-backup is trivial when routed a= long=20 the backup. That should not impact operational experience.=20 Setup/maintenance of e-backup should be fairly straightforward. I= t=20 would be helpful if you can quantify a 'proliferation'.<= /DIV>
 
Bandwidth can be shared between the e-backup and the bac= kup=20 tunnel. When the e-backup is routed along the backup, there should not= be=20 any extra bandwidth consumed compared to [MPLS-FRR]. The benefit is that th= e=20 problematic U-turn goes away.
 
Thanks

- Sri

 

From: Alexander Vainshtein=20 [mailto:Alexander.Vainshtein@ecitele.com]
Sent: Monday, July 2= 6,=20 2010 11:55 PM
To: Sriganesh Kini
Cc:=20 mpls@ietf.org
Subject: RE: [mpls] Scalability of the "effective= FRR"=20 approach in=20 draft-kini-mpls-ring-frr-facility-backup-00.txt

Sri,

Lots of thanks for a = prompt=20 response. It seems that we more or less agree on the facts (proliferation= of=20 e-backup LSPs) but we differ in interpreting  the impact  of th= ese=20 facts  on the actual operational experience.

 

However, I’d li= ke to notice=20 that “BW effectiveness” of e-backup LSPs is also somewhat pro= blematic=20 IMO.

Please note that both= the=20 regular backup and e-backup bypass tunnels cross multiple links that are = not=20 involved with the original set of LSPs they are protecting. And they both= =20 consume BW on these links. The only difference is that they are competing= for=20 BW with other LSPs, not with ones they are protecting. But the overall ef= fect=20 is exactly the same IMO.

 

My 2c,

   &nb= sp;=20 Sasha

 

From: Sriganesh = Kini=20 [mailto:sriganesh.kini@ericsson.com]
Sent: Monday, July 26, 20= 10=20 8:01 PM
To: Alexander Vainshtein
Cc:=20 mpls@ietf.org
Subject: RE: [mpls] Scalability of the "effective= FRR"=20 approach in=20 draft-kini-mpls-ring-frr-facility-backup-00.txt

 

Sasha,

 <= o:p>

As you=20 noted the e-backup tunnel protects all LSPs that have a common {head= -end,=20 tail-end} pair. More precisely, the e-backup can be shared to protect&nbs= p;all=20 LSPs that have a common {ring-ingress-LSR, ring-egress-LSR} pair (th= at is=20 path is disjoint with the e-backup).

 <= o:p>

If I=20 understood correctly your concern is about the number of number of e-back= up=20 tunnels?

 <= o:p>

E-backup=20 tunnels should be setup based on protected LSP's {ring-ingress, ring-egre= ss}=20 LSRs. Consider a typical case where in a ring, there is a 'ring-head-end'= and=20 LSPs are setup from other LSRs on the ring to the 'ring-head-end'. An e-b= ackup=20 should be setup from each LSR on the ring to the 'ring-head-end'. This is= =20 order(n).

 <= o:p>

Even for=20 cases where protected LSPs have many possible combinations = ;for=20 {ring-ingress, ring-egress}, for typical ring sizes, the number=20 of tunnels required should not be a concern=20 for today's implementations.

 <= o:p>

Also,=20 in many topologies an LSR that is purely a transit for protected=20 LSPs, does not have to originate any e-backup.

 <= o:p>

Thanks

-=20 Sri

PS:=20 Regular facility FRR requires more that two backup tunnels, depending on = what=20 is being protected.

=  

From:=20 mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of=20 Alexander Vainshtein
Sent: Monday, July 26, 2010 9:57=20 AM
To: Sriganesh Kini
Cc:=20 mpls@ietf.org
Subject: [mpls] Scalability of the "effective F= RR"=20 approach in draft-kini-mpls-ring-frr-facility-backup-00.txt=

Sriganesh and=20 all,

If I understood yo= u=20 correctly, your proposal requires a dedicated backup tunnel for all LSP= s=20 with the given {head-end, tail-end} pair of LSRs in the ring. (Regular= =20 facility FRR requires just two backup tunnels).

If this understand= ing is=20 correct, this looks to like a serious scalability issue with your=20 approach.

 

Regards,

     Sasha

 

--_000_5A5E55DF96F73844AF7DFB0F48721F0F567DB80E82EUSAACMS0703e_--