Dan, Hi!
Thanks for the review!On Tue, Sep 19, 2017 at 1:47 PM, Dan Romascanu <dromasca@xxxxxxxxx> wrote:
Reviewer: Dan Romascanu
Review result: Has Issues
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?
[VPB] Fair point. We'll go ahead and change the title to "Techniques to Improve the Scalability of RSVP-TE Deployments". Would this take care of addressing your concern?
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?
[VPB] The flag that indicates "support of 2961" has always been a little vague in terms of what recommendations are mandatory and what are not, resulting in different types of implementation behaviors. The text in Section 2.1 was added to make sure that there is no room for such ambiguities. The discussion in the WG that resulted in this text is captured in the following thread:
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?
[VPB] The expectation is that the node comes up with the new recommended default values after an upgrade to a version that supports this draft. Upgrades can be incremental -- not all nodes in the network need to be upgraded at the same time (the procedures in this draft are fully backwards compatible).
_______________________________________________
Teas mailing list
Teas@xxxxxxxx
https://www.ietf.org/mailman/listinfo/teas