Re: [Gen-art] Genart last call review of draft-ietf-teas-rsvp-te-scaling-rec-06

[Mirja Kühlewind <[e-mail]>]

Hi Elwyn,

thanks a lot for the detailed review! I fully agree and have mentioned your 
review in my ballot comments. I really hope they will address it and rewrite 
large parts respectively!

Mirja



On 23.09.2017 00:06, Elwyn Davies wrote:
> Reviewer: Elwyn Davies
> Review result: Not Ready
> 
> I am the assigned Gen-ART reviewer for this draft. The General Area
> Review Team (Gen-ART) reviews all IETF documents being processed
> by the IESG for the IETF Chair.  Please treat these comments just
> like any other last call comments.
> 
> For more information, please see the FAQ at
> 
> <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.
> 
> Document: draft-ietf-teas-rsvp-te-scaling-rec-06
> Reviewer: Elwyn Davies
> Review Date: 2017-09-22
> IETF LC End Date: 2017-09-22
> IESG Telechat date: 2017-09-28
> 
> Summary: Not ready, primarily because the title and presentation give the
> impression that the content is really a BCP when it isn't.  This conceals the
> considerable amount of tweaking of RFC 2961 functionality and addition of new
> RSVP Capabilities described in the document.  There are also a couple of minor
> issues that need to be sorted out.
> 
> Major issues:
> Title and way proposals are presented:  The document defines two new
> 'capabilities' for RSVP-TE and is indeed (as specified in the document header)
> correctly intended for Standards Track status.  However the title and the whole
> of the meat of the document in Section 2 presents the proposals as
> 'recommendations' which says to me that I am expecting a BCP where a profile of
> available options from existing standards is recommended as the best choice for
> implementation and deployment.  In my opinion, the title would be better as
> something like "Additional Capabilities Designed to Improve the Scalability of
> RSVP-TE Deployments".  Whilst the proposals are based on the techniques in RFC
> 2961, the document *requires* the implementor to conform to rules that were
> optional and constrains configurable values to different ranges in order to be
> able to deliver the capabilities defined in the document as well as defining
> new RSVP extensions modifying some of the behaviour defined in RFC 2961.  Thus
> although some of the rules could be met by choosing particular values within
> the RFC 2961 set, the use of MUST, tweaking of functionality and variation of
> ranges takes it well beyond a set of recommendations for RFC 2961 options
> selections.  In view of this Section 1 needs to be written as an introduction
> to the definitions of the new capabilities rather than advocacy for selection
> of RFC 2961 options and the implication that the techniques mentioned in the
> last paragraph of s1 are just a matter of selecting a profile of option values.
>   In actuality new protocol values are introduced and ss2.2 and 2.3 define novel
> extensions to RSVP beyond what is available for RFC 2961 and requiring
> modification to basic RFC 2961 functionality..
> 
> Minor issues:
> Interaction with RFC 5063:  The document does not explicitly state that an
> implementation would need to support (at least) the extra capability obect
> defined in s4.2 of RFC 5063.  Some words about interaction with RFC 5063 are
> probably required in that s4.2.1 of RFC 5063 rather assumes that if there is a
> capability object, by default its S bit will be set.
> 
> Behaviour if a node stops setting Refresh-Reduction-Capable bit:  The last para
> of s2 in RFC 2961 discusses behaviour if a node stops setting this bit in
> messages.  What would happen with the extensions defined in this document if
> this happened while either of the extensions is in use?  As a matter of
> interest, if a peer offers the capabilities defined in this draft, is it
> possible or sensible for it to stop setting the Refresh-Reduction-Capable bit
> without stopping offering the extensions?
> 
> s2.1.3, para 2: As specified, it appears that the 'slower timer' transmission
> of Path and Resv messages can go on indefinitely if no ack arrives.  What puts
> an end to this repetition?  [It may be that I have forgotten how basic RSVP
> works, but since this is altering the behaviour it would be good to explain how
> it terminates, and whether this requires any additional modification to timers.]
> 
> Nits/editorial comments:
> Abstract: RSVP-TE is not a 'well-known' abbreviation: s/RSVP-TE/RSVP Traffic
> Engineering (RSVP-TE)/
> 
> Abstract and s1, first para:  This para is not future proof.  Suggest:
> OLD:
>     The scale at which RSVP-TE [RFC3209] Label Switched Paths (LSPs) get
>     deployed is growing continually and there is considerable onus on
>     RSVP-TE implementations across the board to keep up with this
>     increasing demand in scale.
> NEW:
>     At the time of writing, networks which utilise RSVP Traffic Engineering
>     (RSVP-TE) [RFC3209] Label Switched Paths (LSPs) are encountering limitations
>     in the ability of implementations to support the growth in the number of LSPs
>     deployed.  This document defines two additional RSVP-TE extensions that
>     are intended to reduce the number of messages needed to maintain RSVP-TE
>     soft state in routers and hence allow implementations to support larger
>     scale deployments.
> ENDS
> Note:  Omit reference from Abstract.
> 
> s1, para 2: s/under certain/beyond a certain/
> 
> s1, para 3: s/makes a set of concrete implementation recommendations/defines
> two extensions/; s/- push higher/by increasing/; s/maintain LSP state./maintain
> LSP state by reducing the number of messages needed./
> 
> Abstract, para 2 and s1, last para:  [Omit reference from Abstract]
> OLD:
>     This document advocates the use of a couple of techniques - "Refresh-
>     Interval Independent RSVP (RI-RSVP)" and "Per-Peer Flow-Control" -
>     for significantly cutting down the amount of processing cycles
>     required to maintain LSP state.
> NEW:
>     This document defines two RSVP Capabilities [RFC5063] "Refresh-
>     Interval Independent RSVP (RI-RSVP)" and "Per-Peer Flow-Control"
>     that will cut down the number of messsages and processing cycles
>     required to maintain LSP state.
> ENDS
> 
> s1, last para: Add new penultimate sentence:
>     Note that the "Per-Peer Flow-Control" capability requires the "RI-RSVP"
>     capability as a prerequisite.
> 
> s1, last para: s/RECOMMENDED/recommended/ - this isn't a recommendation about
> the protocol on the wire.
> 
> Subdivision of s2:  The issues regarding the nature of the document would be
> helped by altering s2 into four top level sections, thus: s2: Requirement for
> RFC 2961 Refresh Overhead Reduction Support and Specific Option Choices (from
> s2.1) s3: Requirement for RFC 5063 Capability Object support (see Minor Issues
> above) s4: Refresh-Interval Independent RSVP Capability (from s2.3) s5:
> Per-Peer RSVP Flow Control Capability (from s2.4) Subsequent major sections
> then renumbered as s6 onwards. References to s2.x will need to be updated
> throughout.
> 
> s2.1 (would be introduction of new s2):
> OLD:
>     The implementation recommendations discussed in this section are
>     based on the proposals made in [RFC2961] and act as prerequisites for
>     implementing the techniques discussed in Sections 2.2 and 2.3.
> 
> NEW:
>     The Capabilities defined in Sections 4 and 5 of this document are based on
>     proposals made in [RFC2961].  Implementations of these Capabilities will
>     need to support the RSVP messages and techniques defined in [RFC2961] as set
>     out in Section 2.1 [was 2.1.1] with
>     some minor modifications and alterations to recommended time intervals and
>     iteration counts as defined in the remainder of this section.
> ENDS
> 
> s2.1.1, title and para 1 [will be s2.1]:
> OLD:
> 2.1.1.  Basic Prerequisites
> 
>     An implementation that supports the techniques discussed in Sections
>     2.2 and 2.3 must meet certain basic prerequisites.
> NEW:
> 2.1.  Required Functionality from RFC 2961 to be Implemented
> 
>     An implementation that supports the capabiities discussed in Sections
>     4 and 5 must provide a large subset of the functionality described
>     in [RFC2961] as follows:
> ENDS
> 
> s2.1.2, para 2 [will be s2.2]: s/techniques discussed in Sections 2.2 and
> 2.3/Capabilities defined in Sections 4 and 5/
> 
> s2.1.2, para 2: s/MESSAGE ID/MESSAGE_ID/
> 
> s2.2, para 1: s/improvement on transmission overhead/improvement of
> transmission overhead/
> 
> s2.2, para 1: s/proposes sufficient recommendations/sets out additional
> requirements/
> 
> s2.2, last bullet: Add a reference to the proposed new Section 3 that discusses
> the Capability object.
> 
> s2.2.1, last para: s/set Refresh-Reduction-Capable bit in common header/set the
> Refresh-Reduction-Capable bit in the common header/
> 
> s2.3, para 1: s/set of recommendations/functionality/; s/provide/provides/;
> s/RSVP-TE control plane congestion/a significant portion of the RSVP-TE control
> message load/
> 
> s2.3.2: s/MESSAGE ID/MESSAGE_ID/
> 
>