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

Julien Meuric <julien.meuric@orange-ftgroup.com> Mon, 26 July 2010 17:41 UTC

Return-Path: <julien.meuric@orange-ftgroup.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 0FBB93A68DB for <mpls@core3.amsl.com>; Mon, 26 Jul 2010 10:41:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.568
X-Spam-Level:
X-Spam-Status: No, score=-1.568 tagged_above=-999 required=5 tests=[AWL=0.681, BAYES_00=-2.599, HELO_EQ_FR=0.35]
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 PKP9-WiKdlWk for <mpls@core3.amsl.com>; Mon, 26 Jul 2010 10:41:31 -0700 (PDT)
Received: from r-mail2.rd.francetelecom.com (r-mail2.rd.francetelecom.com [217.108.152.42]) by core3.amsl.com (Postfix) with ESMTP id 9554C3A696D for <mpls@ietf.org>; Mon, 26 Jul 2010 10:40:30 -0700 (PDT)
Received: from r-mail2.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id ABFFDFC4008; Mon, 26 Jul 2010 19:40:06 +0200 (CEST)
Received: from ftrdsmtp2.rd.francetelecom.fr (unknown [10.192.128.47]) by r-mail2.rd.francetelecom.com (Postfix) with ESMTP id A228DFC4003; Mon, 26 Jul 2010 19:40:06 +0200 (CEST)
Received: from ftrdmel10.rd.francetelecom.fr ([10.192.128.44]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Mon, 26 Jul 2010 19:40:06 +0200
Received: from [10.193.116.61] ([10.193.116.61]) by ftrdmel10.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Mon, 26 Jul 2010 19:40:06 +0200
Message-ID: <4C4DC874.6000502@orange-ftgroup.com>
Date: Mon, 26 Jul 2010 19:40:04 +0200
From: Julien Meuric <julien.meuric@orange-ftgroup.com>
Organization: France Telecom
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.11pre) Gecko/20100626 Lightning/1.0b1 Shredder/3.0.6pre
MIME-Version: 1.0
To: "sriganesh.kini@ericsson.com" <sriganesh.kini@ericsson.com>
References: <5A5E55DF96F73844AF7DFB0F48721F0F567DB80A69@EUSAACMS0703.eamcs.ericsson.se>
In-Reply-To: <5A5E55DF96F73844AF7DFB0F48721F0F567DB80A69@EUSAACMS0703.eamcs.ericsson.se>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 8bit
X-OriginalArrivalTime: 26 Jul 2010 17:40:06.0092 (UTC) FILETIME=[95B5E8C0:01CB2CE9]
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 <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: Mon, 26 Jul 2010 17:41:32 -0000

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 
protection), as enabled by RFC 4872. That is all the more similar 
because the association mechanism is already defined in there, with a 
dedicated RSVP-TE object. RFC 4872 is Standard Track: is there any 
rational for not considering it?

Regards,

Julien


Le 26/07/2010 18:59, Sriganesh Kini a écrit :
> 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
>