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 BE8063A6979 for ; Tue, 27 Jul 2010 15:34:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, 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 zzAeF+ilz5Y7 for ; Tue, 27 Jul 2010 15:34:51 -0700 (PDT) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by core3.amsl.com (Postfix) with ESMTP id 8026828C0EF for ; Tue, 27 Jul 2010 15:34:51 -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 o6RMZCMj005197 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 27 Jul 2010 17:35:12 -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 18:35:11 -0400 From: Autumn Liu To: Greg Mirsky , Julien Meuric Date: Tue, 27 Jul 2010 18:35:10 -0400 Thread-Topic: [mpls] Updated drafts - draft-kini-mpls-ring-frr-facility-backup, draft-kini-mpls-fast-lsp-alert Thread-Index: AcstAmcuHunxF55GQeyPqim4Gp+bygA2QYrg Message-ID: <60C093A41B5E45409A19D42CF7786DFD51AE592A5E@EUSAACMS0703.eamcs.ericsson.se> References: <5A5E55DF96F73844AF7DFB0F48721F0F567DB80A69@EUSAACMS0703.eamcs.ericsson.se> <4C4DC874.6000502@orange-ftgroup.com> <60C093A41B5E45409A19D42CF7786DFD51AE518F86@EUSAACMS0703.eamcs.ericsson.se> <60C093A41B5E45409A19D42CF7786DFD51AE519013@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_60C093A41B5E45409A19D42CF7786DFD51AE592A5EEUSAACMS0703e_" MIME-Version: 1.0 Cc: "mpls@ietf.org" Subject: Re: [mpls] Updated drafts - draft-kini-mpls-ring-frr-facility-backup, draft-kini-mpls-fast-lsp-alert 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 22:34:53 -0000 --_000_60C093A41B5E45409A19D42CF7786DFD51AE592A5EEUSAACMS0703e_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Greg and Julien Thanks for pointing this out. The draft can be applied to the case when seg= ment protection is utilized as defined in 4873. We will update the draft ac= cordingly. Regards, Autumn ________________________________ From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Gre= g Mirsky Sent: Monday, July 26, 2010 1:37 PM To: Autumn Liu Cc: mpls@ietf.org Subject: Re: [mpls] Updated drafts - draft-kini-mpls-ring-frr-facility-back= up, draft-kini-mpls-fast-lsp-alert Dear Autumn, thank you for adding specific case to our discussion. In my view protecting= segment L10-L1-L2-L3-L4-L5 (e-backup tunnel) is shared by all backup tunne= ls that traverse the ring through nodes L10-L9-L8-L7-L6-L5. This e-backup t= unnel is the e-backup tunnels for all working sections/segments (in case of= link and node protection) of an LSP L10-...-L8-..-L5. I'd re-state my ques= tion to authors whether they've considered re-using RSVP-TE objects and sub= objects defined in RFC 4873. If mechanisms and objects defined in RFC 4873= not sufficient, why RFC 4873 not referenced in the draft Efficient Facilit= y Backup FRR. Regards, Greg On Mon, Jul 26, 2010 at 12:16 PM, Autumn Liu > wrote: Hi Greg, +-------L1--------L2---------L3--------L4-------+ | | L10 L5 | | +-------L9--------L8---------L7--------L6-------+ Not all PLRs. Using the diagram in draft as an example. Bypass 1 (to protect link between L8 and L7) : L8-L9-L10-L1-L2-L3-L4-L5-L6-= L7 Bypass 2 (to protect node failure on L8) : L9-L10-L1-L2-L3-L4-L5-L6-L7 e-backup tunnel L10-L1-L2-L3-L4-L5 can be used instead for both cases witho= ut getting traffic u-turned. Regards, Autumn ________________________________ From: Greg Mirsky [mailto:gregimirsky@gmail.com] Sent: Monday, July 26, 2010 12:03 PM To: Autumn Liu Cc: Julien Meuric; Sriganesh Kini; mpls@ietf.org Subject: Re: [mpls] Updated drafts - draft-kini-mpls-ring-frr-facility-back= up, draft-kini-mpls-fast-lsp-alert Dear Autumn, I'm quite surprised to read your reply to Julien. My understanding of your = proposal is that all PLRs share the same u-PLR for given ring segment of LS= P. Please correct me if my understanding is different from authors intentio= n. I'd like to add to Julien's comment that RFC 4873 seems relevant to your so= lution as well as RFC 4872. And I'd ask the same question as Julien in rega= rd to not referencing RFC 4873. Regards, Greg On Mon, Jul 26, 2010 at 11:30 AM, Autumn Liu > wrote: Hi Julien, draft-kini-mpls-ring-frr-facility-backup describes a mechanism to let the p= rimary LSP be aware of what the bypass LSP for corresponding protected faci= lity. If my understanding is correct, the association mechanism defined in = 4872 is used to associate the primary and backup LSPs. This is not good eno= ugh for the problem the draft is trying to address since each link/node alo= ng the primary LSP may have different bypass LSPs. Regards, Autumn -----Original Message----- From: mpls-bounces@ietf.org [mailto:mpls-boun= ces@ietf.org] On Behalf Of Julien Meuric Sent: Monday, July 26, 2010 10:40 AM To: Sriganesh Kini Cc: mpls@ietf.org Subject: Re: [mpls] Updated drafts - draft-kini-mpls-ring-frr-facility-back= up, draft-kini-mpls-fast-lsp-alert Hi Sriganesh. The mechanism described in draft-kini-mpls-ring-frr-facility-backup reminds me of end to end recovery (or more specifically end to end protecti= on), as enabled by RFC 4872. That is all the more similar because the assoc= iation mechanism is already defined in there, with a dedicated RSVP-TE obje= ct. RFC 4872 is Standard Track: is there any rational for not considering i= t? Regards, Julien Le 26/07/2010 18:59, Sriganesh Kini a =E9crit : > FYI - These updated version of these drafts were presented today at > IETF78. > http://tools.ietf.org/html/draft-kini-mpls-ring-frr-facility-backup-01 > http://tools.ietf.org/html/draft-kini-mpls-fast-lsp-alert-01 > Thanks > > - Sri > > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls --_000_60C093A41B5E45409A19D42CF7786DFD51AE592A5EEUSAACMS0703e_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi Greg and Julien
 
Thanks for pointing this out. The draft can be a= pplied=20 to the case when segment protection is utilized as defined in 4873. We will= =20 update the draft accordingly.
 
Regards,
Autumn
 
 

From: mpls-bounces@ietf.org=20 [mailto:mpls-bounces@ietf.org] On Behalf Of Greg Mirsky
Sent:<= /B>=20 Monday, July 26, 2010 1:37 PM
To: Autumn Liu
Cc:=20 mpls@ietf.org
Subject: Re: [mpls] Updated drafts -=20 draft-kini-mpls-ring-frr-facility-backup,=20 draft-kini-mpls-fast-lsp-alert

Dear Autumn,
thank you for adding specific case to our discus= sion.=20 In my view protecting segment L10-L1-L2-L= 3-L4-L5=20 (e-backup tunnel) is shared by all backup tunnels that traverse the ring th= rough=20 nodes L10-L9-L8-L7-L6-L5. This e-backup tunnel is the e-backup tunnels for = all=20 working sections/segments (in case of link and node protection) of an LSP=20 L10-...-L8-..-L5. I'd re-state my question to authors whether they've consi= dered=20 re-using RSVP-TE objects and subobjects defined in RFC 4873.  If mecha= nisms=20 and objects defined in RFC 4873 not sufficient, why RFC 4873 not referenced= in=20 the draft Efficient Facility Backup=20 FRR.

Regards,
Greg

On Mon, Jul 26, 2010 at 12:16 PM, Autumn Liu <autumn.liu@ericsson.com> wrote:
Hi=20 Greg,
 
 +-------L1--------L2---------L3--------L4-------+  |          &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;    =20  |
 L10        &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;   =20 L5
  |       &nb= sp;            =             &nb= sp;            =         =20 |
 +-------L9--------L8---------L7--------L6-------+            &n= bsp;            = ;  =20
Not all PLR= s. Using the=20 diagram in draft as an example.
Bypass 1 (t= o protect=20 link between L8 and L7) : L8-L9-L10-L1-L2-L3-L4-L5-L6-L7
Bypass 2 (t= o protect=20 node failure on L8) : L9-L10-L1-L2-L3-L4-L5-L6-L7
 
e-backup tu= nnel=20 L10-L1-L2-L3-L4-L5 can be used instead for both cases without=20 getting traffic u-turned.
 
Regards,
Autumn

 

From: Greg Mirsky [mailto:gregimirsky@gmail.c= om]=20
Sent: Monday, July 26, 2010 12:03 PM
To: Autumn=20 Liu
Cc: Julien Meuric; Sriganesh Kini; mpls@ietf.org

Subject: Re: [mpls] Updated drafts -=20 draft-kini-mpls-ring-frr-facility-backup,=20 draft-kini-mpls-fast-lsp-alert

Dear Autumn,
I'm quite surprised to read your reply to Juli= en.=20 My understanding of your proposal is that all PLRs share the same u-PLR f= or=20 given ring segment of LSP. Please correct me if my understanding is diffe= rent=20 from authors intention.
I'd like to add to Julien's comment that RFC 4= 873=20 seems relevant to your solution as well as RFC 4872. And I'd ask the same= =20 question as Julien in regard to not referencing RFC=20 4873.

Regards,
Greg

On Mon, Jul 26, 2010 at 11:30 AM, Autumn Liu <autumn.liu@ericsson.com> wrote:
Hi=20 Julien,

draft-kini-mpls-ring-frr-facility-backup describes a=20 mechanism to let the primary LSP be aware of what the bypass LSP for=20 corresponding protected facility. If my understanding is correct, the=20 association mechanism defined in 4872 is used to associate the primary = and=20 backup LSPs. This is not good enough for the problem the draft is tryin= g to=20 address since each link/node along the primary LSP may have different b= ypass=20 LSPs.

Regards,
Autumn


-----Original Message-----
From: mpls-bounces@ietf= .org=20 [mailto:mpls-bounces@ietf.org] On Behalf Of Julien MeuricSent:=20 Monday, July 26, 2010 10:40 AM
To: Sriganesh Kini
Cc: mpls@ietf.org
Subj= ect: Re:=20 [mpls] Updated drafts - draft-kini-mpls-ring-frr-facility-backup,=20 draft-kini-mpls-fast-lsp-alert

Hi Sriganesh.

The mechanis= m=20 described in draft-kini-mpls-ring-frr-facility-backup
reminds me of = end=20 to end recovery (or more specifically end to end protection), as enable= d by=20 RFC 4872. That is all the more similar because the association mechanis= m is=20 already defined in there, with a dedicated RSVP-TE object. RFC 4872 is= =20 Standard Track: is there any rational for not considering=20 it?

Regards,

Julien


Le 26/07/2010 18:59, Sriga= nesh=20 Kini a =E9crit :
> FYI - These updated version of these drafts we= re=20 presented today at
> IETF78.
> http://tools.ietf.org/html/draft-kini-mpls-ring-frr-fac= ility-backup-01
>=20 http://tools.ietf.org/html/draft-kini-mpls-fast-lsp-ale= rt-01
>=20 Thanks
>
> - Sri
>
>
>=20 _______________________________________________
> mpls mailing=20 list
> mpls@ietf.org
> https://www.ietf.org/mailman/listinfo/mpls
><= BR>_______________________________________________
mpls=20 mailing list
mpls@ietf.org
https://www.ietf.org/mailman/listinfo/mpls
_____= __________________________________________
mpls=20 mailing list
mpls@ietf.org
https://www.ietf.org/mailman/listinfo/mpls


--_000_60C093A41B5E45409A19D42CF7786DFD51AE592A5EEUSAACMS0703e_--