Last Call Review of draft-ietf-teas-sr-rsvp-coexistence-rec-02

Request Review of draft-ietf-teas-sr-rsvp-coexistence-rec
Requested rev. no specific revision (document currently at 04)
Type Last Call Review
Team General Area Review Team (Gen-ART) (genart)
Deadline 2018-04-20
Requested 2018-04-06
Authors Harish Sitaraman, Vishnu Beeram, Ina Minei, Siva Sivabalan
Draft last updated 2018-04-19
Completed reviews Rtgdir Last Call review of -01 by Manav Bhatia (diff)
Opsdir Last Call review of -02 by Al Morton (diff)
Genart Last Call review of -02 by Joel Halpern (diff)
Secdir Last Call review of -02 by Hilarie Orman (diff)
Genart Telechat review of -03 by Joel Halpern (diff)
Assignment Reviewer Joel Halpern 
State Completed
Review review-ietf-teas-sr-rsvp-coexistence-rec-02-genart-lc-halpern-2018-04-19
Reviewed rev. 02 (document currently at 04)
Review result Almost Ready
Review completed: 2018-04-19


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


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


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.