Subject: Opsdir last call review of draft-ietf-teas-rsvp-te-scaling-rec-06

From: Dan Romascanu <[email-masked]>
Date: Tue, 19 Sep 2017 10:47:55 -0700

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?

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?

---

From: Vishnu Pavan Beeram <[email-masked]>
Date: Fri, 22 Sep 2017 03:35:13 -0400

Dan, Hi!

Thanks for the review!
Please see inline for your responses and let us know if they address your
concerns.

Regards,
-Pavan

> configuration in deployment. Maybe the title does not really reflect the

[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?

> standards-track document? Would not just mentioning RFC 2961 compliance be

[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:
https://mailarchive.ietf.org/arch/msg/teas/FMGd8Q5mLUA2d3L2jD7bbid2atc

> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/teas
>

---

From: Dan Romascanu <[email-masked]>
Date: Fri, 22 Sep 2017 15:32:27 +0300

Hi Pavan,

Thank you for your answer and for addressing my concerns.

See in-line.

Regards,

Dan

On Fri, Sep 22, 2017 at 10:35 AM, Vishnu Pavan Beeram <[email-masked]
> wrote:

> Improve the Scalability of RSVP-TE Deployments". Would this take care of

Yes, this would be more clear. Thanks.

> https://mailarchive.ietf.org/arch/msg/teas/FMGd8Q5mLUA2d3L2jD7bbid2atc

Makes sense. Maybe a sentence in the Introduction on tle lines of 'support
of 2961 has always been vague, and this document aims bringing the needed
clarifications for implementation and deployment' would be useful.

> upgraded at the same time (the procedures in this draft are fully backwards

This is fine. A paragraph that clarifies this on the lines of your second
sentence would help.

---

From: Vishnu Pavan Beeram <[email-masked]>
Date: Tue, 26 Sep 2017 12:47:34 -0400

Please see inline.

Regards,
-Pavan

On Fri, Sep 22, 2017 at 8:32 AM, Dan Romascanu <[email-masked]> wrote:

Snipped..

> clarifications for implementation and deployment' would be useful.

[Pavan] We'll add some text in 2.1 to make this clear.

> This is fine. A paragraph that clarifies this on the lines of your second

[Pavan] We will clarify this in the Introduction Section.