Skip to main content

Last Call Review of draft-ietf-teas-rsvp-te-scaling-rec-06
review-ietf-teas-rsvp-te-scaling-rec-06-genart-lc-davies-2017-09-22-00

Request Review of draft-ietf-teas-rsvp-te-scaling-rec
Requested revision No specific revision (document currently at 09)
Type Last Call Review
Team General Area Review Team (Gen-ART) (genart)
Deadline 2017-09-22
Requested 2017-09-08
Authors Vishnu Pavan Beeram , Ina Minei , Rob Shakir , Dante Pacella , Tarek Saad
I-D last updated 2017-09-22
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 B. Davies (diff)
Secdir Last Call review of -06 by Liang Xia (diff)
Assignment Reviewer Elwyn B. Davies
State Completed
Request Last Call review on draft-ietf-teas-rsvp-te-scaling-rec by General Area Review Team (Gen-ART) Assigned
Reviewed revision 06 (document currently at 09)
Result Not ready
Completed 2017-09-22
review-ietf-teas-rsvp-te-scaling-rec-06-genart-lc-davies-2017-09-22-00
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/