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

"Rakesh Gandhi (rgandhi)" <> Tue, 25 February 2014 00:34 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 78B871A0238; Mon, 24 Feb 2014 16:34:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -15.048
X-Spam-Status: No, score=-15.048 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Zvt8ETdDWGfY; Mon, 24 Feb 2014 16:34:09 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 7CE341A0200; Mon, 24 Feb 2014 16:34:09 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=6944; q=dns/txt; s=iport; t=1393288449; x=1394498049; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=I+FVRZJgXEwPh3IWpClGqZRWGAkyZMPJkKVIa9Z8bB4=; b=OyeZjbME3Wdsj7CpeLOoz+6uHaHqd3RYr77CsUMQfYv2IOkTpzPFYOkX 9SsaAzGhMwxvwQKxfr67uoqG0uQ/TywTjmnWlfJt0eQrZOw7egdF8T6vl 3TqSKQui9SDnTbIyFKvUWQr/t636Ix3xGTXMdbg7wjxsMsgeqZAJo5xMJ c=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="4.97,537,1389744000"; d="scan'208";a="306316023"
Received: from ([]) by with ESMTP; 25 Feb 2014 00:34:08 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id s1P0Y8wZ024365 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 25 Feb 2014 00:34:08 GMT
Received: from ([]) by ([]) with mapi id 14.03.0123.003; Mon, 24 Feb 2014 18:34:08 -0600
From: "Rakesh Gandhi (rgandhi)" <>
To: Gregory Mirsky <>, 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//8aFggAAehID//+/34IAAGtSA
Date: Tue, 25 Feb 2014 00:34:07 +0000
Message-ID: <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/
x-originating-ip: []
Content-Type: text/plain; charset="us-ascii"
Content-ID: <>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
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: Tue, 25 Feb 2014 00:34:12 -0000

Hi Gert,

Not sure why IETF would abondan widely deployed protocol [RFC4090] and
associated technology for bidirectional Packet LSPs. I like to hear
comments from the WGs.


On 2014-02-24 7:05 PM, "Gregory Mirsky" <>

>Hi Rakesh,
>for the NNHOP bypass you'll not have truly local protection. One would
>either have to monitor segment between Upstream and Downstream PLRs or
>use some sort of PSC between the two. In any of these cases, Segment
>protection based on RFC 6378 offers the solution.
>	Regards,
>		Greg
>-----Original Message-----
>From: Rakesh Gandhi (rgandhi) []
>Sent: Monday, February 24, 2014 3:55 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
>Hi Greg,
>Two issues being addressed in this draft apply equally to the link
>protection case when using [RFC4090]:
>1. bypass assignment co-ordination and
>2. sending Resv (from upstream PLR) over reverse bypass to avoid state
>For NNHOP bypass, this just corrects the asymmetry of co-routed LSP
>forward and reverse paths.
>FYI, this draft was originally published to MPLS WG but then moved to
>CCAMP WG. Not sure which is the right WG for this work.
>BTW, [RFC4873] does not state that one can not use [RFC4090] with GMPLS
>signalling. Pleas see [RFC4873] Section 2:
>When [RFC4090] isn't being used, the association between segment recovery
>LSPs with other LSPs is indicated using the ASSOCIATION  object defined
>in [RFC4872]. "
>This draft simply addresses the gaps when using [RFC4090] for GMPLS
>packet LSPs.
>On 2014-02-24 6:16 PM, "Gregory Mirsky" <>
>>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.
>>	Regards,
>>		Greg
>>-----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
>>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 networks 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 Bhatia
>>>Cc: CCAMP
>>>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.
>>>>   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
>>>>   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