Re: [mpls] MPLS-RT review of draft-chandra-mpls-ri-rsvp-frr

Chandrasekar Ramachandran <> Sun, 29 November 2015 13:19 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id B590E1ACE30; Sun, 29 Nov 2015 05:19:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.003
X-Spam-Status: No, score=-0.003 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id m65KN7vBzRoF; Sun, 29 Nov 2015 05:19:40 -0800 (PST)
Received: from ( [IPv6:2a01:111:f400:fc10::757]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D1ABF1ACE2E; Sun, 29 Nov 2015 05:19:39 -0800 (PST)
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.1.331.20; Sun, 29 Nov 2015 13:19:23 +0000
Received: from ([]) by ([]) with mapi id 15.01.0331.023; Sun, 29 Nov 2015 13:19:23 +0000
From: Chandrasekar Ramachandran <>
To: Guijuan Wang 3 <>, "" <>, "" <>
Thread-Topic: MPLS-RT review of draft-chandra-mpls-ri-rsvp-frr
Thread-Index: AQHRF2S33nSvFxxJdUWKBLWJ31yyKp6NjuCAgCV7zzA=
Date: Sun, 29 Nov 2015 13:19:22 +0000
Message-ID: <>
References: <> <> <> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
authentication-results: spf=none (sender IP is );
x-originating-ip: []
x-microsoft-exchange-diagnostics: 1; BN3PR0501MB1379; 5:usNgqBe3iRFFrY9a9BrtaQP67o0tx4hFe/dnjuL0YW0y548WlyZmUquzy+sM3X0nx3sY9w4y0fRUBsf55E7nk5lK+PmPvzGqF433Bc0Eg/Vsv+EnCJE2WL9oH4V7a869/nWeGpSY59AJ5jQufVTDQQ==; 24:tTLm35fQgrGx0N3StyPBr8yE2OXOp72WpBysgsQtbJGKdFxQ2tB8v+np24XbjJDU/UqI/3vDflPV/8WVq4jTeqQS4qAxB0vh6OWYbnSAfew=
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN3PR0501MB1379;
x-microsoft-antispam-prvs: <>
x-exchange-antispam-report-test: UriScan:(37575265505322);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(520078)(10201501046)(3002001); SRVR:BN3PR0501MB1379; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0501MB1379;
x-forefront-prvs: 0775716B9D
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(37854004)(50944005)(13464003)(189002)(52604005)(199003)(164054003)(377454003)(15975445007)(92566002)(5001960100002)(1220700001)(19580395003)(586003)(101416001)(66066001)(76576001)(10400500002)(5008740100001)(102836003)(19580405001)(122556002)(6116002)(1096002)(11100500001)(33656002)(3846002)(2501003)(86362001)(99286002)(106356001)(40100003)(2201001)(77096005)(87936001)(105586002)(5003600100002)(50986999)(5004730100002)(189998001)(54356999)(5002640100001)(76176999)(93886004)(81156007)(5001770100001)(97736004)(2900100001)(230783001)(74316001)(2950100001)(106116001)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0501MB1379;; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en;
received-spf: None ( does not designate permitted sender hosts)
spamdiagnosticoutput: 1:23
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Nov 2015 13:19:22.2917 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0501MB1379
Archived-At: <>
Cc: "" <>
Subject: Re: [mpls] MPLS-RT review of draft-chandra-mpls-ri-rsvp-frr
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multi-Protocol Label Switching WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 29 Nov 2015 13:19:42 -0000

Hello Jean,
Thanks for your comments. Please find the responses inline.

> -----Original Message-----
> From: Guijuan Wang 3 []
> Sent: Thursday, November 05, 2015 9:00 PM
> To:;
> Cc:; Loa Andersson <>
> Subject: RE: MPLS-RT review of draft-chandra-mpls-ri-rsvp-frr
> Dear Authors,
> Thanks for drafting this solution, It would be useful if the FRR can be
> completely independent of refresh.
> I read through it and here is my comment.
> Section 3, page 6, Problem Description:
> Per RFC 4090, section 7.2 section Handling Failures, it has required the
> postpone of sending PathClear, wait another 30s by default. Then the
> possibility for the first consequence should be lower than the following
> consequence, better to move it back based on the logic that the major issue
> comes first.

[Chandra] Yes, we will clarify that the references to "router C timing out LSP states" in Section 3 to indicate that as per RFC 4090 the state time out on C would occur after an additional time out cycle.
> Section 4, page 7, Solution Aspects:
>   Read through the whole solution, it requires the supporting of serval other
> RFCs and also two working-in-progresses RFCs. Better to add “Pre-
> Requisites” introduction in the beginning of this chapter, then the user for
> this document know it has to read/implement the prerequisite firstly.
> At the other hand, the major change in the cited [Summary-FRR] and [TE-
> SCALE-REC] may be monitored and brought back to this document. For
> example a comment has been raised for the new sub-object definition in
> [Summary-FRR], it may be changed.

[Chandra] Yes, we will introduce a new section or sub-section to clarify the pre-requisites. It is true that the bypass association procedure in Summary-FRR draft will be re-specified to use Association object. As the update to that draft has not yet been uploaded, we have not yet modified our draft.

> Section 4.1.1, page 9, PLR Behavior
> Is below paragraph parallel to its former and following paragraphs? If so,
> please change its format style, that is adding “-“ in the beginning and use
> same indentations as others. Current style makes me feel it’s the parent of
> the following 2 paragraphs.
> In this doc, it says:
> “In parallel to the attempt made to create NP-bypass or LP-bypass, the PLR
> SHOULD initiate ...”

[Chandra] Yes, we will indent the paragraphs "While selecting the destination address ..." because that paragraph is a specific recommendation for selecting destination address.

> Section 4.1.2, page 9, Remote Signaling Adjacency:
> A new hello is introduced, via multiple hops. Better to give the suggested
> default interval, the hello interval in RFC3209 is 5 ms, it may be too quick for
> this solution.

[Chandra] Yes, you are correct that the default hello interval specified in RFC 3209 is not suitable for NodeID hello session. The TE-SCALE-REC draft ( makes the recommendation of 9 seconds for the hello interval. However, we will also explicitly state in Section 4.1.2 of our draft to follow the recommendation of TE-SCALE-REC draft. 

> 4.1.5. page 11, "Remote" state on MP
> Typo, change form to “from” for below sentence.
> “the "remote"path state is not signaled explicitly form PLR.”

[Chandra] Yes, will correct the typo in the next revision.

> Section 4.1.1, page 9, first paragraph:
> No full words for TED the first time it is mentioned, would you please add it.
> And would be great if you can give a brief introduction on using the TED to
> determine routeId.
> “If the PLR and the MP are in same area, then the PLR may Utilize the TED to
> determine the router ID from the interface address in RRO (if NodeID is not
> included in RRO).”

[Chandra] Yes, we will provide some additional text in Section 4.1.1 for this. We will also include TED in Terminology section.

> Section 4.1.1: page 9, paragraph 4:
> Whose timeout do you mean by “a timeout” in below paragraph? Also may
> be better to move the “on the other hand… “ to the paragraph above it. At
> first glance, the sentence before and after “on the other hand” seems like
> duplicated.
> In this document, it says:
> "The PLR SHOULD wait for a time out before removing
> SUMMARY_FRR_BYPASS_ASSIGNMENT sub-object in RRO and triggering
> PATH downstream. On the other hand, the PLR need not wait for a time out
> to add SUMMARY_FRR_BYPASS_ASSIGNMENT subobject in RRO and may
> immediately trigger PATH downstream."

[Chandra] Actually, the time out indicated here is not related to state time out. But I agree that this paragraph is a bit confusing. As the procedures are expected to be specified in SUMMARY-FRR draft, we will remove the last paragraph (the one starting with "After signaling protection availability ...") and combine the previous two paragraphs. That is, we will merge the two paragraphs "In parallel to the attempt made ..." and "If the bypass LSP comes up, then the PLR should include ...".

> 4.2. page 11, Impact of Failures on LSP State:
> In the last paragraph, it says implementation doesn’t need to have a way to
> distinguish “link-failure” and “node-failure”, but the following statement for
> handling does distinguish the “link-failure” and “node-failure”, such as LP-MP
> has different procedures for link and node Failure defined in 4.2.2 and 4.2.3
> separately. Is it conflicting?

[Chandra] Thanks for pointing out the conflict. The TE-SCALE-REC draft does recommend the use of NodeID based hello session and hence the paragraph "It should be noted that even though this section and the subsequent ..." is in conflict with that recommendation. We will remove this paragraph.

> Also in the optional way of using node-id based hello to distinguish them,
> better to give further details on how to distinguish.

[Chandra] Please refer to my response to your previous comment. We will remove the paragraph and possibly refer to TE-SCALE-REC to clarify regarding failure detection. 

> 4.2. page 11~14, Impact of Failures on LSP State Overall, in this section,
> several conditions are mentioned and different handling need to be taken
> based on different conditions combinations, and 7 handling cases are
> introduced. Is it possible to category them, or simply the combinations based
> on below 3 considerations?
> a.	Distinguishing and understanding 7 cases is a little complex for
> implementation.
> b.	There may be conditions combination that is not enumerated in this
> document.
> c.	Some case handling are very similar such as section 4.2.2 and 4.2.4.

[Chandra] We will classify the 7 sub-sections into 3 categories - LP-MP behavior, NP-MP behavior and Router that is simultaneously LP-MP and NP-MP. Each category will contain the procedures to handle different types of failures, so that it would be clear that all possible combinations are enumerated. The behavior of non-MP should be obvious and does not require the explicit specification.

> 4.5.1, page 19, Detecting Support for Refresh interval Independent FRR
> Seems the detection mainly counts on the detection procedure for [TE-
> SCALE-REC] and [SUMMARY-FRR], but this document introduces extra
> extensions, such as multiple-hop hello, and condition object, there should
> also a new way to detect the support for them.

[Chandra] Section 2.2 of TE-SCALE-REC contains the following recommendation.

    - (If Bypass FRR [RFC4090] is supported,) MUST implement procedures
      specified in [RI-RSVP-FRR] which describes methods to facilitate
      FRR that works independently of the refresh-interval.

Hence the definition of I-bit in Section 2.2.1 of TE-SCALE-REC should include the support for the procedures in RI-RSVP-FRR draft. It should be noted that TE-SCALE-REC has specified a separate flag F-bit to enable implementations to support per-peer flow control without supporting Refresh-independent RSVP.

We will explicitly add the above clarification in Section 4.5.1.