Subject: [Teas] Genart last call review of draft-ietf-teas-sr-rsvp-coexistence-rec-02
From: Joel Halpern <[email-masked]>
To: <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked]
Date: Thu, 19 Apr 2018 03:15:45 -0700
List-Id: Traffic Engineering Architecture and Signaling working group discussion list <teas.ietf.org>

Reviewer: Joel Halpern
Review result: Almost 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-sr-rsvp-coexistence-rec-02
Reviewer: Joel Halpern
Review Date: 2018-04-19
IETF LC End Date: 2018-04-20
IESG Telechat date: 2018-05-10

Summary:

Major issues:
    The focus of the draft seems to be the recommendation in section 3.5 that
    the maximum reservable bandwidth on a link be adjusted to reflect the SR
    traffic consumption.  There appear to be two issues that need to be
    discussed, both related to the difference between what the SR controller
    wants to reserve and what the router observes. First, an SR controller may
    be performing calculations without requiring that bandwidth be committed to
    the traffic.  The recommendation here assumes that all traffic using SR is
    high priority.  It may suffice to note that QoS markings in the labels
    (corresponding to diffserv markings in the underlying packet may hel with
    this.  Given the range of allowed behaviors in when RSVP-TE and SR are
    separate, it may also be necessary to restrict what the SR controllers do
    in these interworking cases. Second, and more importantly, this solution
    assumes that short term traffic measurements are a good proxy for intended
    reservation.  Even assuming edge policing so that usage is less than or
    equal to the reservation, this will frequently underestimate the traffic
    reservation.  Such underestimates would seem to be able to cause
    significant problems.

Minor issues:
    Section 3.5 assumes that the router can measure the traffic using SR.  This
    seems to rely on the unstated premise that the measurement is conditioned
    by the recognition of which labels are being used for SR.  This is
    reasonable.  It should be stated.

Nits/editorial comments:
    The second paragraph of the introduction seems to have the opening text
    repeated twice.

    The third paragraph of section 3.1 seems to be a repetition of the end of
    the second paragraph using slightly different words.