Re: [CCAMP] New Version Notification for draft-tsaad-ccamp-rsvpte-bidir-lsp-fastreroute-03.txt

Gregory Mirsky <> Mon, 24 February 2014 23:16 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 1F09D1A0223; Mon, 24 Feb 2014 15:16:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 5RTcOb6CtCsU; Mon, 24 Feb 2014 15:16:36 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 5A1391A01D5; Mon, 24 Feb 2014 15:16:36 -0800 (PST)
X-AuditID: c6180641-b7f2f8e000002cdc-1b-530bd2d4f737
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id A9.92.11484.4D2DB035; Tue, 25 Feb 2014 00:16:36 +0100 (CET)
Received: from ([]) by ([]) with mapi id 14.02.0387.000; Mon, 24 Feb 2014 18:16:34 -0500
From: Gregory Mirsky <>
To: "Rakesh Gandhi (rgandhi)" <>, Lizhong Jin <>, Frederic Jounay <>, "Tarek Saad (tsaad)" <>, "Mike Taillon (mtaillon)" <>, "Zafar Ali (zali)" <>, Manav Bhatia <>, "" <>
Thread-Topic: New Version Notification for draft-tsaad-ccamp-rsvpte-bidir-lsp-fastreroute-03.txt
Thread-Index: AQHPIOaJqiIMOAEGrkS5EKB7Vxg2IpqjnT0AgADCvJCAINagAP//8aFg
Date: Mon, 24 Feb 2014 23:16:34 +0000
Message-ID: <>
References: <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpgkeLIzCtJLcpLzFFi42KZXLrHT/fKJe5gg1Ub9CyezLnBYnF8+gQW ixWnnzFbzLl3j9Xi1tKVrBZblxxnspja1MFm8enETyaL1zu+sjtwerQ+28vqMeX3RlaPnbPu snssWfKTyePGVsUA1igum5TUnMyy1CJ9uwSujG2v/zAXPFOpOHfnM1sD40a5LkZODgkBE4kv R/6wQdhiEhfurQeyuTiEBI4wSsw5/IwVwlnOKHF06x9mkCo2ASOJFxt72EESIgLXmST2ndnN BJJgFpCSuHurixHEFhZIlOi/cZYVxBYRSJJY+Ps/O4TtJjHl0QqwdSwCqhLPjv8C6+UV8JU4 t2gyWI2QQJHEpedbwHo5BfQlFv9tAatnBDrv+6k1ULvEJW49mc8EcbaAxJI955khbFGJl4// sULYihL7+qezQ9TrSCzY/YkNwtaWWLbwNTPEXkGJkzOfsExgFJuFZOwsJC2zkLTMQtKygJFl FSNHaXFqWW66keEmRmAsHpNgc9zBuOCT5SFGaQ4WJXHeL2+dg4QE0hNLUrNTUwtSi+KLSnNS iw8xMnFwSjUwTvixz39tgm7Qv3xuCcukY5m6b1Y8KOQ9+eSh0kmeL3Uy8d0/bm898Kjnh3nE v82KfQVrj6vLrgvRl9pt0fF7WVdE6fr8+4s7u7xmpqYFzEj3DFjTM/f1bD9u7YPSFUdKOi5e e9A7+5qqQLUYI6+16uYbNyJPtx45zcPH5v9kdiC/6L2SjzxLlFiKMxINtZiLihMB+maC3ZMC AAA=
Cc: CCAMP <>
Subject: Re: [CCAMP] New Version Notification for draft-tsaad-ccamp-rsvpte-bidir-lsp-fastreroute-03.txt
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Discussion list for the CCAMP working group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 24 Feb 2014 23:16:39 -0000

Hi Rakesh,
I understand motivation of authors. Applicability of RFC 4090 to bi-directional co-routed LSP was discussed as part of MPLS-TP survivability framework (RFC 6372). I think that we've agreed that applicability of RFC 4090 is limited to link protection and segment protection should be recommended as providing more generic coverage. Have authors considered bringing discussion and presenting the proposal to MPLS WG?
Hope you wouldn't mind me adding MPLS WG to the discussion.


-----Original Message-----
From: Rakesh Gandhi (rgandhi) [] 
Sent: Monday, February 24, 2014 2:58 PM
To: Gregory Mirsky; Lizhong Jin; Frederic Jounay; Tarek Saad (tsaad); Mike Taillon (mtaillon); Zafar Ali (zali); Manav Bhatia
Subject: Re: New Version Notification for draft-tsaad-ccamp-rsvpte-bidir-lsp-fastreroute-03.txt

Hi Greg,

Thank you for your comments.

As you know, proposed draft addresses the two issues (state timeout and bypass assignment) where FRR [RFC4090] is used for GMPLS packet tunnels.

Motivations for using FRR here is that it is widely deployed in the packet MPLS-TE network today and can leverage all existing FRR detection and restoration mechanisms and not have to deploy new protocol such as PSC [RFC6378] for protection switchover co-ordination.


On 2014-02-03 9:40 PM, "Gregory Mirsky" <>

>Hi Rakesh, et. al,
>since bi-directional co-routed LSP is MPLS-TP construct I believe that 
>if local node protection is indeed required it should not use RFC 4090 
>signaling but use ASSOCIATION object as described in Section 2.3 RFC 
>6689 and RFC 6378 MPLS-TP Linear Protection instead.
>	Regards,
>		Greg
>-----Original Message-----
>From: CCAMP [] On Behalf Of Rakesh Gandhi
>Sent: Monday, February 03, 2014 5:52 AM
>To: Lizhong Jin; Lizhong Jin; Frederic Jounay; Tarek Saad (tsaad); Mike 
>Taillon (mtaillon); Zafar Ali (zali); Manav Bhatia; Zafar Ali (zali); 
>Mike Taillon (mtaillon); Tarek Saad (tsaad); Frederic JOUNAY; Manav 
>Subject: Re: [CCAMP] New Version Notification for 
>Hi WG,
>New revision of the published draft contains following updates:
>- Remove unidirectional bypass LSP (as per previous comments)
>- Fix syntax of the BYPASS_ASSIGNMENT object.
>- Misc editorial cleanup.
>Please provide your review comments.
>On 2014-02-03 8:44 AM, ""
><> wrote:
>>A new version of I-D,
>>has been successfully submitted by Rakesh Gandhi and posted to the 
>>IETF repository.
>>Name:		draft-tsaad-ccamp-rsvpte-bidir-lsp-fastreroute
>>Revision:	03
>>Title:		Extensions to Resource Reservation Protocol For Fast Reroute of
>>Bidirectional Co-routed Traffic Engineering LSPs
>>Document date:	2014-02-03
>>Group:		Individual Submission
>>Pages:		12
>>   This document defines Resource Reservation Protocol - Traffic
>>   Engineering (RSVP-TE) signaling extensions to support Fast Reroute
>>   (FRR) of bidirectional co-routed Traffic Engineering (TE) LSPs. These
>>   extensions enable the re-direction of bidirectional traffic and
>>   signaling onto bypass tunnels that ensure co-routedness of data and
>>   signaling paths in the forward and reverse directions after FRR. In
>>   addition, the RSVP-TE signaling extensions allow the coordination of
>>   bypass tunnel assignment protecting a common facility in both forward
>>   and reverse directions prior to or post failure occurrence.
>>Please note that it may take a couple of minutes from the time of 
>>submission until the htmlized version and diff are available at 
>>The IETF Secretariat
>CCAMP mailing list