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

Guijuan Wang 3 <> Thu, 05 November 2015 15:33 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id A04DE1B2F0E; Thu, 5 Nov 2015 07:33:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id MrVaK8PnlQ0t; Thu, 5 Nov 2015 07:33:30 -0800 (PST)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 448661B2F32; Thu, 5 Nov 2015 07:30:05 -0800 (PST)
X-AuditID: c1b4fb2d-f79626d000004282-66-563b75fa58f4
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id F6.B5.17026.AF57B365; Thu, 5 Nov 2015 16:30:03 +0100 (CET)
Received: from ([]) by ([]) with mapi id 14.03.0248.002; Thu, 5 Nov 2015 23:30:00 +0800
From: Guijuan Wang 3 <>
To: "" <>, "" <>
Thread-Topic: MPLS-RT review of draft-chandra-mpls-ri-rsvp-frr
Thread-Index: AQHRF2Sz0KZ7QZ7xu0+45OVATWOgjJ6NjA6g
Date: Thu, 05 Nov 2015 15:29:59 +0000
Message-ID: <>
References: <> <> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprIIsWRmVeSWpSXmKPExsUyM+Jvre7vUuswg2XXFCy+3lvLYvFv7hxm i3WXT7FZ3Fq6ktWBxWPJkp9MHrOmt7EFMEVx2aSk5mSWpRbp2yVwZXz80shS8EqvYt08kQbG C7pdjJwcEgImEvu3LmKGsMUkLtxbz9bFyMUhJHCEUWLOx61QziJGifkrNjOCVLEJGEjsb5nJ AmKLCFRJzLy5mA3EZhbwkVi9bw1YXFjAVmJr0152iBo7idXXFrFB2EYS3z9/BbNZBFQkHt4+ ALaZV8BXYkfLG1aIZVuZJD72NjOBJDgFVCVaVvwFG8QIdN73U2uYIJaJS9x6Mp8J4mwBiSV7 zkO9ICrx8vE/VghbQeLAoiVANRxA9ZoS63fpQ7QqSkzpfsgOsVdQ4uTMJywTGMVmIZk6C6Fj FpKOWUg6FjCyrGIULU4tLs5NNzLWSy3KTC4uzs/Ty0st2cQIjKiDW37r7mBc/drxEKMAB6MS D++HXqswIdbEsuLK3EOMEhzMSiK8U0Ktw4R4UxIrq1KL8uOLSnNSiw8xSnOwKInztjA9CBUS SE8sSc1OTS1ILYLJMnFwSjUwVt6+9VbutujaBv2XN5WNYr5Wvpc58ctT5fWrI3Pq3YJ1mpYe jtZb/XRqhMQ+luaJc28/Fli4cK6a/sJfc2P72lJ+lJk1ly3Livj4sWu27/uU7fuk/4Q+2dx6 bcJrzRm/njSuerHpgJ38hTv+DEJbSpjl3HdIKyTuTy/inxGt8CP5Mp/zOWmWuUosxRmJhlrM RcWJAMps4SmkAgAA
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: Thu, 05 Nov 2015 15:33:32 -0000

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. 

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.
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 ...”

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. 

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.”

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).”

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."

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? 

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

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.

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.