Last Call Review of draft-ietf-teas-rsvp-te-scaling-rec-06
review-ietf-teas-rsvp-te-scaling-rec-06-opsdir-lc-romascanu-2017-09-19-00

Request Review of draft-ietf-teas-rsvp-te-scaling-rec
Requested rev. no specific revision (document currently at 09)
Type Last Call Review
Team Ops Directorate (opsdir)
Deadline 2017-09-22
Requested 2017-09-08
Authors Vishnu Beeram, Ina Minei, Rob Shakir, Dante Pacella, Tarek Saad
Draft last updated 2017-09-19
Completed reviews Rtgdir Last Call review of -05 by Victoria Pritchard (diff)
Opsdir Last Call review of -06 by Dan Romascanu (diff)
Genart Last Call review of -06 by Elwyn Davies (diff)
Secdir Last Call review of -06 by Liang Xia (diff)
Assignment Reviewer Dan Romascanu
State Completed
Review review-ietf-teas-rsvp-te-scaling-rec-06-opsdir-lc-romascanu-2017-09-19
Reviewed rev. 06 (document currently at 09)
Review result Has Issues
Review completed: 2017-09-19

Review
review-ietf-teas-rsvp-te-scaling-rec-06-opsdir-lc-romascanu-2017-09-19

This document describes two techniques that improve the scale of deployment of RSVP-TE LSPs. Here are a few issues operations related issues that I recommend to address: 

1. The document is titled 'Implementation Recommendations'. As such an RFC 5706 review does not apply. Yet, it aims Standards Track status, and includes a number of protocol extensions and registry definitions.  The document mixes protocol extensions, implementation recommendations and recommendations of configuration in deployment. Maybe the title does not really reflect the current content? 

2. Section 2.1 includes a number of " RFC2961 Specific" Recommendations. However, it is not clear why these are recommendations. For example, reading RFC 2961, nothing indicates that support for RSVP Refresh Overhead Reduction extensions  or the receipt of any RSVP Refresh Overhead Reduction  message (as specified in Section 2 of RFC2961) are optional. Moreover, RFC 2961 is also Standards Track. So why do we need 'recommendations' to support sections of a standards-track document? Would not just mentioning RFC 2961 compliance be sufficient? 

3. From an operational point of view it is unclear how the recommendations to set the default periodic retransmission interval
defined in section 2.1.3 and the configurable refresh interval and the configurable node hello interval defined in section 2.2 are supposed to be implemented. Is this a one time initialization required for every capable node? If so, the capability needs to be confirmed before the re-configuration. This needs to be done for every node? How, if scale is a concern?