Subject: Genart last call review of draft-ietf-teas-sr-rsvp-coexistence-rec-02

From: Joel Halpern <[email-masked]>
Date: Thu, 19 Apr 2018 03:15:45 -0700

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.

---

From: Harish Sitaraman <[email-masked]>
Date: Fri, 20 Apr 2018 17:36:38 +0000

Hi Joel,

Thanks for the review comments. Comments are inline with [HS].

On 4/19/18, 3:15 AM, "Joel Halpern" <[email-masked]> wrote:
   
    Summary:
    
    Major issues:
        in these interworking cases. 

[HS] In the first paragraph of section 3.5, there is text referring to SR having highest preemption priority but the SR traffic could have different QoS markings i.e. within SR there could be different classes of traffic which is accordingly handled by the forwarding plane (e.g. defined operator policy).

        Second, and more importantly, this solution

[HS] Even with RSVP-TE LSPs where explicit admission-control is done to reserve bandwidth, the bandwidth that is reserved on the RSVP-TE LSP may differ from how much traffic actually arrives on the LSP (assuming no edge policing). As the traffic changes, auto-bandwidth implementation procedures might be there to adjust the LSP reservation at periodic intervals. This relies on short term LSP traffic measurement to achieve change in reservation. 

[HS] SR traffic can preempt RSVP LSPs to make room for itself based on short term SR traffic measurement. The frequency at which SR statistics is collected for a TE interface and how often the Maximum-Reservable-Bandwidth is adjusted so that path computation engines for RSVP-TE LSPs get the updated TED information is implementation and deployment dependent (it could be aggressive to reflect SR traffic utilization in the TED often or done less frequently due to other deployment parameters). In the penultimate paragraph of section 3.5, there is text referring to the implementation choice.
    
    Minor issues:

[HS] Fair point. However, the measured traffic is not just from SR labels (transit traffic) but also any traffic entering the SR domain over that outgoing interface. An implementation should be capable of measuring all the SR traffic going out of an interface. The text generically refers to needing ability to measure SR traffic statistics across the TE interface.
    
    Nits/editorial comments:

[HS] Thanks - noted also as part of OPsDir review comments. The 2nd repeated sentence will be removed.

[HS] Ok, the aim was to offer a summary of the behavior separately so that its clear. If its ok, we can retain it.

--
Harish

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 20 Apr 2018 14:25:02 -0400

Thank you for your replies.  Further in line, marked <jmh></jmh>
Yours,
Joel

> [HS] In the first paragraph of section 3.5, there is text referring to SR having highest preemption priority but the SR traffic could have different QoS markings i.e. within SR there could be diffe…

<jmh>I think the document would be helped if this were described more 
explicitly.  </jmh>

> [HS] Even with RSVP-TE LSPs where explicit admission-control is done to reserve bandwidth, the bandwidth that is reserved on the RSVP-TE LSP may differ from how much traffic actually arrives on the…

<jmh>A reference or two to other work on auto-reservation of bandwidth 
based on measurement, particularly for RSVP-TE, would help the reader 
understand the assumptions that lead to this being seen as workable.  It 
would likely also help the reader know about any relevant limitations.</jmh>

> [HS] SR traffic can preempt RSVP LSPs to make room for itself based on short term SR traffic measurement. The frequency at which SR statistics is collected for a TE interface and how often the Maxi…

<jmh>The point of reservations is to try to anticipate future 
conditions.  The fact that SR can preempt RSVP-TE is useful, but does 
not really address the question.  If it could, then a simpler 
recommendation would be to observe how much RSVP-TE trafic had to be 
dropped, and redirect that much traffic elsewhere. </jmh>

> [HS] Fair point. However, the measured traffic is not just from SR labels (transit traffic) but also any traffic entering the SR domain over that outgoing interface. An implementation should be cap…

<jmh>My point is that it would help the reader if the text were explicit 
about what traffic needs to be recognized and how it is recognized. </jmh>

> [HS] Ok, the aim was to offer a summary of the behavior separately so that its clear. If its ok, we can retain it.

<jmh>If the duplication is intentional, then it is up to you as to 
whether it is doing what you want. </jmh>

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 26 Apr 2018 11:13:50 -0400

You have made the changes you have said you would make.
I do not think the document is as clear as it should be about the 
assumptions that make this workable (for example that it can not handle 
SR LSP that are not intended to have reserved bandwidth).
I will leave it to the judgment of others whether this is a show stopper.

Yours,
Joel

On 4/26/18 11:01 AM, Harish Sitaraman wrote:
> 
> Hi Joel,
> 
> We've posted a -03 version of the draft. Let us know if it helps with the comments. See inline <HS>...
> 
> On 4/20/18, 11:25 AM, "Joel M. Halpern" <[email-masked]> wrote:
> 
> <HS> The first paragraph in section 3.5 explains the preemption priority and forwarding plane priority as follows:
> 
>     The solution relies on dynamically measuring SR traffic utilization
>     on each TE interface and reducing the bandwidth allowed for use by
>     RSVP-TE.  It is assumed that SR traffic receives precedence in terms
>     of the placement on the path over RSVP traffic (that is, RSVP traffic
>     can be preempted from the path in case of insufficient resources).
>     This is logically equivalent to SR traffic having the best preemption
>     priority in the network.  Note that this does not necessarily mean
>     that SR traffic has higher QoS priority, in fact, SR and RSVP traffic
>     may be in the same QoS class.
>      
>      >
> <HS> Regarding the IETF reference for auto-bandwidth, I could only find the following PCE WG document: https://tools.ietf.org/html/draft-ietf-pce-stateful-pce-auto-bandwidth-06#page-8 (section 4) other than public references to vendor implementation documentation.
> 
>      >
> <HS> We added the following in section 3.5: "This method of sampling traffic statistics and adjusting bandwidth reservation accordingly is similar to how bandwidth gets adjusted for auto-bandwidth RSVP-TE LSPs". The sentences preceding this explain the procedure and this is similar to auto-bandwidth for RSVP-TE.
>      
>      >
>      >      Minor issues:
> <HS> Added " The measured SR traffic includes all labelled SR traffic and any traffic entering the SR network over that TE interface."
> 
> Harish
>

---

From: Harish Sitaraman <[email-masked]>
Date: Thu, 26 Apr 2018 15:01:36 +0000

Hi Joel,

    

    

    

    

Harish