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

Gregory Mirsky <> Tue, 25 February 2014 01:32 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 777A81A0380; Mon, 24 Feb 2014 17:32:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id oLQSb9T-nhZk; Mon, 24 Feb 2014 17:32:40 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 938191A0369; Mon, 24 Feb 2014 17:32:40 -0800 (PST)
X-AuditID: c6180641-b7f2f8e000002cdc-4d-530bf2b0001f
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id 70.D5.11484.0B2FB035; Tue, 25 Feb 2014 02:32:33 +0100 (CET)
Received: from ([]) by ([]) with mapi id 14.02.0387.000; Mon, 24 Feb 2014 20:32:31 -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//8aFggAAehID//+/34IAAGtSA///+skA=
Date: Tue, 25 Feb 2014 01:32:31 +0000
Message-ID: <>
References: <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_7347100B5761DC41A166AC17F22DF1121B772054eusaamb103erics_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprGIsWRmVeSWpSXmKPExsUyuXRPgu7GT9zBBttvsVg8mXODxeL49Aks FitOP2O2mHPvHqvFraUrWS22LjnOZDG1qYPN4tOJn0wWr3d8ZXfg9Gh9tpfVY8rvjaweO2fd ZfdYsuQnk8eNrYoBrFFcNimpOZllqUX6dglcGZs+7mcuuLKZseLyr/AGxpdzGLsYOTkkBEwk Ns85zQphi0lcuLeerYuRi0NI4AijxPrzc5khnOWMEt8ftzKBVLEJGEm82NjDDpIQEbjOJLHv zG6wBLOAlMTdW11gY4UFEiX6b5wFGysikCSx8Pd/dhh77pTVQDYHB4uAqsSdudkgJq+Ar8Tn n14gppBAkcSc2WDFnAL6EodPPmYDsRmBbvt+ag3UInGJW0/mM0HcLCCxZM95ZghbVOLl439Q vyhK7Oufzg5Rny9x/uBJsDm8AoISJ2c+YZnAKDoLyahZSMpmISmDiOtILNj9iQ3C1pZYtvA1 M4x95sBjJmTxBYzsqxg5SotTy3LTjQw3MQLj9pgEm+MOxgWfLA8xSnOwKInzfnnrHCQkkJ5Y kpqdmlqQWhRfVJqTWnyIkYmDU6qBMdp/kdGX0kI/u4bk8opTpvaxbL69Cz/+KXB8o/96ldeu JfJpqx4Xb9K5x6rwUFNMb8ryVQav2y2d+iO641+WCQR9q1108vRNjR3cU068KdusuvDjhod7 IpskVGMj9abHHvhUfWjlm63MH1o0HyxukS/9+2z3trhPSoVaexuULHlXJ/aHWq9nUmIpzkg0 1GIuKk4EAGIPwpOpAgAA
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 01:32:44 -0000

Hi Rakesh,
I don't see this as "abandon" RFC 4090 but rather clarify its applicability for bi-directional co-routed LSP case.
More comments from both WGs certainly are most welcome and appreciated.


-----Original Message-----
From: Rakesh Gandhi (rgandhi) []
Sent: Monday, February 24, 2014 4:34 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 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
>>>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