Re: [CCAMP] Comments to draft-tsaad-ccamp-rsvpte-bidir-lsp-fastreroute

"Rakesh Gandhi (rgandhi)" <> Fri, 31 January 2014 13:35 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 1A7BB1A058B for <>; Fri, 31 Jan 2014 05:35:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -10.035
X-Spam-Status: No, score=-10.035 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id jL76qV2opUYk for <>; Fri, 31 Jan 2014 05:35:03 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 991951A049B for <>; Fri, 31 Jan 2014 05:35:03 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=19576; q=dns/txt; s=iport; t=1391175300; x=1392384900; h=from:to:cc:subject:date:message-id:in-reply-to: mime-version; bh=4+VssLwid8P6WFAtIOjob9E/Xzm4YSuhC3DOR9Ed8F8=; b=bbXVlZDv6uw//r0G8aayCnUJH0/kXBZDg/3/+onHuYQFiVkRw20pUTDF qefSyA5H3jjrwz13CHFUAzODsTq13pC1V6DtOIzmOhtmIgMElcFxqgtv+ NGH3f8jUb+bXqsbeugrkjmv/Z+GV0GDWYgk1HzU3GhZyM4OTed4VQVjyt M=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos; i="4.95,757,1384300800"; d="scan'208,217"; a="16989207"
Received: from ([]) by with ESMTP; 31 Jan 2014 13:34:59 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id s0VDYxhS010312 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 31 Jan 2014 13:34:59 GMT
Received: from ([]) by ([]) with mapi id 14.03.0123.003; Fri, 31 Jan 2014 07:34:59 -0600
From: "Rakesh Gandhi (rgandhi)" <>
To: Gregory Mirsky <>
Thread-Topic: Comments to draft-tsaad-ccamp-rsvpte-bidir-lsp-fastreroute
Thread-Index: AQHPHcq0mDWwgOhw0UqTGnTBbAiuYpqe56KA
Date: Fri, 31 Jan 2014 13:34:58 +0000
Message-ID: <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_CF110E9A19D0Argandhiciscocom_"
MIME-Version: 1.0
Cc: "" <>, "" <>, "" <>, CCAMP <>
Subject: Re: [CCAMP] Comments to draft-tsaad-ccamp-rsvpte-bidir-lsp-fastreroute
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: Fri, 31 Jan 2014 13:35:06 -0000

Hi Greg,

<Changing title and WG to reflect new name/WG for the draft>.

Thank you Greg for the review comments. Can't remember if we replied earlier. Please find the comments below.

From: Gregory Mirsky []
Sent: Wednesday, February 27, 2013 6:41 PM
To: Mike Taillon (mtaillon); Tarek Saad (tsaad); Rakesh Gandhi (rgandhi); Zafar Ali (zali)
Subject: Comments to draft-tsaad-mpls-rsvpte-bidir-lsp-fastreroute

Dear Authors, et al.,
Please find my comments to this document below:
·         As noted in the Introduction, bi-directional co-routed LSP can be signaled in context of GMPLS model. I recall that it was agreed that all work on GMPLS constructs will be conducted within CCAMP WG.

<RG> Agree, The draft has been moved to CCAMP WG.

·         I think that scenario described in the second paragraph of the Introduction section is not correct. I believe that protection path(s) for bi-directional co-routed LSP must be bi-directional and co-routed as well.

<RG> Agree, we are updating the draft to focus on co-routed bidirectional primary and co-routed bidirectional bypass LSPs. Will be posting a revised version soon.

Thus I don't see it possible that there will be "asymmetry of paths" after protection switchover. IMO, protection path must have the same properties as working path, i.e. be bi-directional co-routed LSP.

<RG> Yes, in case of path protection where both primary and standby LSPs are co-routed bidirectional LSPs, this problem can not happen.
However, for fast reroute for packet LSPs using RFC 4090, this issue can happen even when using co-routed bypass LSPs.

·         Asymmetry of paths may exist if working path is bi-directional associated LSP but such construct is not in scope of this document and I believe that this case fully covered by RFC 4090.

<RG> RFC 4090 does not cover the fast reroute for packet co-routed bidirectional LSPs using GMPLS signalling.

·         Problem that you alledge in the third paragraph should not exist in GMPLS with use of ASSOCIATION object (RFC 6780)
·         I'd point that local protection with node protection for bi-directional co-routed LSP turns into a case of segment protection with OAM being ran between PLRs and PSC (RFC 6378) coordinating switchover by exchanging messages over protection segment.

<RG> Right, solutions have been defined for GMPLS path protection and segment protection as you mentioned above.
The proposed draft is for extending the fast reroute procedures for packet LSPs defined in RFC 4090 for co-routed bidirectional packet LSPs. As mentioned earlier, we cover the case where both primary and FRR bypass LSPs are co-routed bidirectional LSPs and uses GMPLS signalling.