Techniques to Improve the Scalability of RSVP-TE Deployments
draft-ietf-teas-rsvp-te-scaling-rec-09

I have some reservations around certain aspects of the document, but they've largely been captured by other IESG members. I'll reiterate two of them here, phrased as concrete suggestions.

Change the title to something more like "Protocol Enhancements to Improve...", and rephrase all uses of the word "recommendation" to instead refer to the techniques described in the document.

Clarify that the retransmission of messages described in section 2.1.3 does not continue for years or decades: specify a limit after which retransmission ceases even without an ACK.

Please expand the following acronyms upon first use and in the title;
see https://www.rfc-editor.org/materials/abbrev.expansion.txt for guidance.

 - RSVP-TE - RSVP Traffic Engineering
 - LSR - Label Switching Router

(1) This document seems to do two things: make a series of rfc2961 recommendations, and introduce a couple of new techniques.  What is not clear to me is whether the first part is independent of the second.  Will the implementation of Section 2.1. ("RFC2961 Specific" Recommendations) provide scaling benefits on their own (i.e. without the new techniques)?  If so, please add some text (maybe in the Introduction) to indicate that.


(2) As for as the new techniques, it is confusing to me the use of rfc2119 language in Section 2.1.1. (Basic Prerequisites), which reads:

   An implementation that supports the techniques discussed in Sections
   2.2 and 2.3 must meet certain basic prerequisites.
...
   o  It SHOULD initiate all RSVP Refresh Overhead Reduction mechanisms...

I know that the leading "must" is not an RFC2119 keyword, but it may be confusing with the "SHOULD" used later...specially because it sounds as if (in some cases) it may be ok to not "initiate all RSVP Refresh Overhead Reduction mechanisms" and still use the new mechanisms described later.  What are those cases?  Maybe the mandatory prerequisites should all be listed in the same sub-section, while other recommendations can be elsewhere.

Note also that later in 2.2 and 2.3 the text says that an implementation "MUST support all the recommendations" in 2.1.  What does that MUST mean if one of the recommendations is not an absolute requirement? 


(3) Section 2.1.2 (Making Acknowledgements Mandatory) seems to also be a prerequisite, right?  At lease the text says that "an implementation that supports the techniques discussed in Sections 2.2 and 2.3...MUST...".  The fact that it is not in the actual prerequisites section may be confusing to some.


(4) Section 2.1.3. (Clarifications On Reaching Rapid Retry Limit (Rl)) is (by clarifying and using normative language) making specific changes to rfc2961.  Assuming that there is value in 2.1 being used by itself (without the new techniques), why isn't there a formal Update of rfc2961?


(5) This reminds me, please use the new RFC2119-related template: please take a look at rfc8174.


Nits:

s/interval interval/interval

When defining the new capability advertisements (in 2.2.1 and 2.3.1), it would be nice to include a reference to rfc5063.

Given the specification in the preceding sections, I think that 2.2.2 and 2.3.2 are superfluous.

It would be nice to point at the Appendix from the main text.

[Note: The authors revised this draft between the time I reviewed it and transcribed my notes. This is a review of version 06. I will not have time to re-review 07 prior to the telechat to see if my comments still apply.]

Substantive:

- General: I agree with the "major issues" comments from Elwyn's Gen-ART review.

- General: There's a fair amount of 2119 language in this draft that refers to options in prior RFCs. It's not clear which of those are new normative requirements vs restatements of existing requirements. In the former case, this draft would need to update those respective RFCs. In the latter case, this draft should use descriptive language rather than 2119 keywords (unless in the form of direct quotes.)

-1, last paragraph: "In order to reap maximum scaling benefits, it is
   strongly RECOMMENDED that implementations support both the
   techniques."

That statement seems to require updating ... something. Maybe 3209 or 2961?

-2.1.3, 2nd paragraph: Does this update RFC 2961?  Or if not, is the normative language appropriate here?

-2.2, bullet list: Are these new normative requirements or restatements of existing ones?

-6: "This document does not introduce new security issues."
Please document the reasoning behind that statement.

Editorial:

-2.1, section title: Why the quotes?

-2.2, first bullet: Section 1 already normatively states these. This text effectively says "MUST follow the MUSTs...". (Note that this pattern recurs in several places.)

-2.3, first paragraph: "The set of recommendations discussed in this section..."
As written, many of those are requirements rather than recommendations.

Thanks for the explanation and patience! Sorry for the long delay!

------------------
Old comment:

I fully agree with the gan-art review (Thanks Elwyn!) and Alvaro, that this reads from time to time like a BCP but is actually an extension specification. I would strongly recommend to apply the changes proposed by the gen-art review, and there is also a very detailed list of nits/edits that should probably be applied. Please have a look at that!

I'm confused by this SHOULD.

   The configurable periodic
   retransmission interval for this slower timer SHOULD be less than the
   regular refresh interval. 

Could you help me understand why someone would want to set the "slower timer" to be shorter than the regular refresh timer?

I agree with Ben that it is not clear which recommendations are from this document and which ones are restatements from other documents. Some of these recommendations originating from this document look like they might be updating RFC2961. Why does this draft not update RFC2961 formally? It was not immediately apparent from the shepherd write up if the WG had considered this.