Re: [Teas] Opsdir last call review of draft-ietf-teas-rsvp-te-scaling-rec-06

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Please see inline.

Regards,
-Pavan

On Fri, Sep 22, 2017 at 8:32 AM, Dan Romascanu <dromasca@xxxxxxxxx> wrote:

Snipped..




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:

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.

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





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).

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

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


[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]