Received changes through RFC Editor sync (changed abstract to 'Networks that utilize RSVP-TE LSPs are encountering implementations that have a limited ability to support the growth in the number of LSPs deployed.

This document defines two techniques, Refresh-Interval Independent RSVP (RI-RSVP) and Per-Peer Flow Control, that reduce the number of processing cycles required to maintain RSVP-TE LSP state in Label Switching Routers (LSRs) and hence allow implementations to support larger scale deployments.')

Received changes through RFC Editor sync (created alias RFC 8370, changed title to 'Techniques to Improve the Scalability of RSVP-TE Deployments', changed abstract to 'Networks that utilize RSVP-TE LSPs are encountering implementations that have a limited ability to support the growth in the number of LSPs deployed.', changed pages to 11, changed standardization level to Proposed Standard, changed state to RFC, added RFC published event at 2018-05-11, changed IESG state to RFC Published)

[Ballot comment]
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!

[Ballot comment]
Thanks for 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!

[Ballot comment]
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.

[Ballot comment]
[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.

[Ballot 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!

[Ballot discuss]
I'm uncertain what section 2.1.3. actually recommends. My understanding is that it is recommend to still retransmit some message even if the Rl was reached and to do that every 30s basically forever. First of all I think this still needs a termination criteria when to stop to try to retransmit finally. And then I don't understand why this is needed, instead of e.g. just using a larger Rl value? Can you please clarify!

[Ballot comment]
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

[Ballot comment]
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

[Ballot discuss]
I'm uncertain what section 2.1.3. actually recommends. My understanding is that it is recommend to still send retransmit some message even if the Rl was reached and to that every 30s basically forever. First of all I think this still needs a termination criteria when to stop to try to retransmit finally. And the I don't understand why this is needed, instead of e.g. just using a larger Rl value? Can you please clarify!

[Ballot 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 a 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!

[Ballot comment]
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?

[Ballot comment]
(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.

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Services Operator has completed its review of draft-ietf-teas-rsvp-te-scaling-rec-06. If any part of this review is inaccurate, please let us know.

The IANA Services Operator understands that, upon approval of this document, there is a single action which we must complete.

In the Capability Object Values registry located on the Resource Reservation Protocol (RSVP) Parameters registry page at:

https://www.iana.org/assignments/rsvp-parameters

two new entries are to be added as follows:

Bit Number: [TBD-at-registration]
Hex Value: [TBD]
Name: RI-RSVP Capable (I)
Reference: [ RFC-to-be ]

Bit Number: [TBD-at-registration]
Hex Value: [TBD]
Name: Per-Peer Flow-Control Capable (F)
Reference: [ RFC-to-be ]

The IANA Services Operator understands that this is the only action required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is only to confirm what actions will be performed.


Thank you,

Sabrina Tanamal
IANA Services Specialist

The following Last Call announcement was sent out (ends 2017-09-22):

From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
CC: draft-ietf-teas-rsvp-te-scaling-rec@ietf.org, db3546@att.com, teas-chairs@ietf.org, teas@ietf.org, Lou Berger <lberger@labn.net>, lberger@labn.net
Reply-To: ietf@ietf.org
Sender: <iesg-secretary@ietf.org>
Subject: Last Call: <draft-ietf-teas-rsvp-te-scaling-rec-06.txt> (Implementation Recommendations to Improve the Scalability of RSVP-TE Deployments) to Proposed Standard


The IESG has received a request from the Traffic Engineering Architecture and
Signaling WG (teas) to consider the following document: - 'Implementation
Recommendations to Improve the Scalability of RSVP-TE
  Deployments'
  <draft-ietf-teas-rsvp-te-scaling-rec-06.txt> as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2017-09-22. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the beginning of
the Subject line to allow automated sorting.

Abstract


  The scale at which RSVP-TE Label Switched Paths (LSPs) get deployed
  is growing continually and the onus is on RSVP-TE implementations
  across the board to keep up with this increasing demand.

  This document introduces a couple of techniques - "Refresh-Interval
  Independent RSVP (RI-RSVP)" and "Per-Peer Flow-Control" - to help
  RSVP-TE deployments push the envelope on scaling.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-teas-rsvp-te-scaling-rec/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-teas-rsvp-te-scaling-rec/ballot/

The following IPR Declarations may be related to this I-D:

  https://datatracker.ietf.org/ipr/2643/

> As required by RFC 4858, this is the current template for the Document
> Shepherd Write-Up.
>
> Changes are expected over time. This version is dated 24 February 2012.
>
> (1) What type of RFC is being requested (BCP, Proposed Standard,
> Internet Standard, Informational, Experimental, or Historic)?

Standards Track

> Why is this the proper type of RFC?

It defines protocol processing rules that must be followed by multiple
nodes/independent implementations.

> Is this type of RFC indicated in the
> title page header?

Yes

> (2) The IESG approval announcement includes a Document Announcement
> Write-Up. Please provide such a Document Announcement Write-Up. Recent
> examples can be found in the "Action" announcements for approved
> documents. The approval announcement contains the following sections:
>
> Technical Summary
>
>  Relevant content can frequently be found in the abstract
>  and/or introduction of the document. If not, this may be
>  an indication that there are deficiencies in the abstract
>  or introduction.

  This document discusses Generalized Multi-Protocol Label
  Switching (GMPLS) Resource reSerVation Protocol with Traffic
  Engineering (RSVP- TE) mechanisms to improve RSVP-TE deployment
  scaling.
 
> Working Group Summary
>
>  Was there anything in WG process that is worth noting? For
>  example, was there controversy about particular points or
>  were there decisions where the consensus was particularly
>  rough?

This document was originally targeted to the MPLS WG.
This document has been fairly noncontroversial.

>
> Document Quality
>
>  Are there existing implementations of the protocol? Have a
>  significant number of vendors indicated their plan to
>  implement the specification? Are there any reviewers that
>  merit special mention as having done a thorough review,
>  e.g., one that resulted in important changes or a
>  conclusion that the document had no substantive issues? If
>  there was a MIB Doctor, Media Type or other expert review,
>  what was its course (briefly)? In the case of a Media Type
>  review, on what date was the request posted?


The extensions defined in this document are done so in a way to be
compatible with known implementations.  While there have been no
public statements on implementation, the authors represent
multiple organizations, and implementation is expected - or more
likely, already exist.

> Personnel
>
>  Who is the Document Shepherd?

Lou Berger

> Who is the Responsible Area Director?

Deborah Brungard

> (3) Briefly describe the review of this document that was performed by
> the Document Shepherd.  If this version of the document is not ready
> for publication, please explain why the document is being forwarded to
> the IESG.


The Document Shepherd has reviewed the document as part of normal WG
progress and WG last call.  The Shepherd believes this document is ready
for publication.


> (4) Does the document Shepherd have any concerns about the depth or
> breadth of the reviews that have been performed?

no

> (5) Do portions of the document need review from a particular or from
> broader perspective, e.g., security, operational complexity, AAA, DNS,
> DHCP, XML, or internationalization?

No.

> If so, describe the review that took place.

N/A.

>
> (6) Describe any specific concerns or issues that the Document Shepherd
> has with this document that the Responsible Area Director and/or the
> IESG should be aware of? For example, perhaps he or she is uncomfortable
> with certain parts of the document, or has concerns whether there really
> is a need for it. In any event, if the WG has discussed those issues and
> has indicated that it still wishes to advance the document, detail those
> concerns here.

No blocking concerns.  All areas of discomfort have been addressed
by the authors.

> (7) Has each author confirmed that any and all appropriate IPR
> disclosures required for full conformance with the provisions of BCP 78
> and BCP 79 have already been filed. If not, explain why.
>
Yes, see thread at
https://www.ietf.org/mail-archive/web/teas/current/msg02472.html

> (8) Has an IPR disclosure been filed that references this document?
> If so, summarize any WG discussion and conclusion regarding the IPR
> disclosures.

Yes, it has.  Other than the actual disclosure and referencing by
authors, there has been no specfic discussion or concerns raised within
the WG,

> (9) How solid is the WG consensus behind this document? Does it
> represent the strong concurrence of a few individuals, with others
> being silent, or does the WG as a whole understand and agree with it? 

Solid among those who are interested. "strong concurrence of a few
individuals, with others being silent" is a reasonable
characterization.

> (10) Has anyone threatened an appeal or otherwise indicated extreme
> discontent? If so, please summarise the areas of conflict in separate
> email messages to the Responsible Area Director. (It should be in a
> separate email because this questionnaire is publicly available.)

No discontent seen.

>
> (11) Identify any ID nits the Document Shepherd has found in this
> document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts
> Checklist). Boilerplate checks are not enough; this check needs to be
> thorough.

The document passes ID nits.  Although there is a comment on a
missing 2119 boiler plate, yet it is present as section 1.1.

>
> (12) Describe how the document meets any required formal review
> criteria, such as the MIB Doctor, media type, and URI type reviews.

N/A.

> (13) Have all references within this document been identified as
> either normative or informative?

Yes.

> (14) Are there normative references to documents that are not ready for
> advancement or are otherwise in an unclear state? If such normative
> references exist, what is the plan for their completion?

No.

> (15) Are there downward normative references references (see RFC 3967)?
> If so, list these downward references to support the Area Director in
> the Last Call procedure.

No.

> (16) Will publication of this document change the status of any
> existing RFCs? Are those RFCs listed on the title page header, listed
> in the abstract, and discussed in the introduction? If the RFCs are not
> listed in the Abstract and Introduction, explain why, and point to the
> part of the document where the relationship of this document to the
> other RFCs is discussed. If this information is not in the document,
> explain why the WG considers it unnecessary.

No.

> (17) Describe the Document Shepherd's review of the IANA considerations
> section, especially with regard to its consistency with the body of the
> document. Confirm that all protocol extensions that the document makes
> are associated with the appropriate reservations in IANA registries.
> Confirm that any referenced IANA registries have been clearly
> identified. Confirm that newly created IANA registries include a
> detailed specification of the initial contents for the registry, that
> allocations procedures for future registrations are defined, and a
> reasonable name for the new registry has been suggested (see RFC 5226).

The IANA section was fully reviewed by the document shepherd and is
appropriate for an this draft.


> (18) List any new IANA registries that require Expert Review for future
> allocations. Provide any public guidance that the IESG would find
> useful in selecting the IANA Experts for these new registries.

None.

> (19) Describe reviews and automated checks performed by the Document
> Shepherd to validate sections of the document written in a formal
> language, such as XML code, BNF rules, MIB definitions, etc.

N/A

IPR Missing:
Ina Minei <inaminei at google.com>,
mjork@juniper.net
exa@juniper.ne

IPR Responses:
Vishnu Beeram <vbeeram at juniper.net>,  https://www.ietf.org/mail-archive/web/teas/current/msg02474.html
rjs at rob.sh, https://www.ietf.org/mail-archive/web/teas/current/msg02490.html
dante.j.pacella at verizon.com,  https://www.ietf.org/mail-archive/web/teas/current/msg02480.html
"Tarek Saad (tsaad)" <tsaad at cisco.com> https://www.ietf.org/mail-archive/web/teas/current/msg02481.html

Pre-LC IPR Poll: https://www.ietf.org/mail-archive/web/teas/current/msg02472.html

Vishnu Beeram <vbeeram at juniper.net>,
Ina Minei <inaminei at google.com>,
rjs at rob.sh,
dante.j.pacella at verizon.com,
"Tarek Saad (tsaad)" <tsaad at cisco.com>
mjork@juniper.net
exa@juniper.net