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

[Guijuan Wang 3 <[e-mail]>]

Hi Chandra,

Glad to get your response, all of my comments are addressed, thanks!

Regards 
Jean

-----Original Message-----
From: Chandrasekar Ramachandran [mailto:[e-mail]] 
Sent: Sunday, November 29, 2015 9:19 PM
To: Guijuan Wang 3; [e-mail]; [e-mail]
Cc: [e-mail]; Loa Andersson
Subject: RE: MPLS-RT review of draft-chandra-mpls-ri-rsvp-frr

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

> -----Original Message-----
> From: Guijuan Wang 3 [mailto:[e-mail]]
> Sent: Thursday, November 05, 2015 9:00 PM
> To: [e-mail]; [e-mail]
> Cc: [e-mail]; Loa Andersson <[e-mail]>
> 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 (https://tools.ietf.org/html/draft-ietf-teas-rsvp-te-scaling-rec-00) 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.

Thanks,
Chandra.