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 9C0653A680E for ; Mon, 26 Jul 2010 12:16:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.001, 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 bVRaSHsSElfJ for ; Mon, 26 Jul 2010 12:16:31 -0700 (PDT) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by core3.amsl.com (Postfix) with ESMTP id 33AEA3A6841 for ; Mon, 26 Jul 2010 12:16:30 -0700 (PDT) Received: from eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id o6QJGoTa026673 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 26 Jul 2010 14:16:51 -0500 Received: from EUSAACMS0703.eamcs.ericsson.se ([169.254.1.134]) by eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) with mapi; Mon, 26 Jul 2010 15:16:49 -0400 From: Autumn Liu To: Greg Mirsky Date: Mon, 26 Jul 2010 15:16:47 -0400 Thread-Topic: [mpls] Updated drafts - draft-kini-mpls-ring-frr-facility-backup, draft-kini-mpls-fast-lsp-alert Thread-Index: Acss9TXD1BUT6GTOR/6YIWAuIEZjaAAAMY4g Message-ID: <60C093A41B5E45409A19D42CF7786DFD51AE519013@EUSAACMS0703.eamcs.ericsson.se> References: <5A5E55DF96F73844AF7DFB0F48721F0F567DB80A69@EUSAACMS0703.eamcs.ericsson.se> <4C4DC874.6000502@orange-ftgroup.com> <60C093A41B5E45409A19D42CF7786DFD51AE518F86@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_60C093A41B5E45409A19D42CF7786DFD51AE519013EUSAACMS0703e_" 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: Mon, 26 Jul 2010 19:16:32 -0000 --_000_60C093A41B5E45409A19D42CF7786DFD51AE519013EUSAACMS0703e_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable 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_60C093A41B5E45409A19D42CF7786DFD51AE519013EUSAACMS0703e_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi Greg,
 
 +-------L1--------L2---------L3--------L4-= ------+
  |        &nb= sp;            =             &nb= sp;            =       =20  |
 L10      &nb= sp;            =             &nb= sp;            =      =20 L5
  |      = ;            &n= bsp;            = ;            &n= bsp;         =20 |
 +-------L9--------L8---------L7--------L6-= ------+
          &nbs= p;            &= nbsp;   =20
Not all PLRs. Using the diagram in draft as an=20 example.
Bypass 1 (to protect link between L8 and L7) :=20 L8-L9-L10-L1-L2-L3-L4-L5-L6-L7
Bypass 2 (to protect node failure on L8) :=20 L9-L10-L1-L2-L3-L4-L5-L6-L7
 
e-backup tunnel L10-L1-L2-L3-L4-L5 can=20 be used instead for both cases without getting=20 traffic u-turned.
 
Regards,
Autumn

 

From: Greg Mirsky [mailto:gregimirsky@g= mail.com]=20
Sent: Monday, July 26, 2010 12:03 PM
To: Autumn=20 Liu
Cc: Julien Meuric; Sriganesh Kini;=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,
I'm quite surprised to read your reply to Julien= . My=20 understanding of your proposal is that all PLRs share the same u-PLR for gi= ven=20 ring segment of LSP. Please correct me if my understanding is different fro= m=20 authors intention.
I'd like to add to Julien's comment that RFC 4873 see= ms=20 relevant to your solution as well as RFC 4872. And I'd ask the same questio= n as=20 Julien in regard to not referencing RFC 4873.

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

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

Regards,
Autumn


-----Original Message-----
From: mpls-bounces@ietf.org [mailto:<= A=20 href=3D"mailto:mpls-bounces@ietf.org">mpls-bounces@ietf.org] On Behal= f Of=20 Julien Meuric
Sent: Monday, July 26, 2010 10:40 AM
To: Sriganesh=20 Kini
Cc: mpls@ietf.org
Subject= : Re:=20 [mpls] Updated drafts - draft-kini-mpls-ring-frr-facility-backup,=20 draft-kini-mpls-fast-lsp-alert

Hi Sriganesh.

The mechanism= =20 described in draft-kini-mpls-ring-frr-facility-backup
reminds me of en= d to=20 end recovery (or more specifically end to end protection), as enabled by = RFC=20 4872. That is all the more similar because the association mechanism 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, Srigane= sh=20 Kini a =E9crit :
> FYI - These updated version of these drafts were= =20 presented today at
> IETF78.
> http://tools.ietf.org/html/draft-kini-mpls-ring-frr-facil= ity-backup-01
>=20 http://tools.ietf.org/html/draft-kini-mpls-fast-lsp-alert= -01
>=20 Thanks
>
> - Sri
>
>
>=20 _______________________________________________
> mpls mailing=20 list
> mpls@ietf.org
> <= A=20 href=3D"https://www.ietf.org/mailman/listinfo/mpls"=20 target=3D_blank>https://www.ietf.org/mailman/listinfo/mpls
>_______________________________________________
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
<= /DIV>

--_000_60C093A41B5E45409A19D42CF7786DFD51AE519013EUSAACMS0703e_--