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" <j...@joelhalpern.com> wrote:
Thank you for your replies. Further in line, marked <jmh></jmh>
Yours,
Joel
On 4/20/18 1:36 PM, Harish Sitaraman wrote:
>
> Hi Joel,
>
> Thanks for the review comments. Comments are inline with [HS].
>
> On 4/19/18, 3:15 AM, "Joel Halpern" <j...@joelhalpern.com> wrote:
>
> 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.
>
> [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).
<jmh>I think the document would be helped if this were described more
explicitly. </jmh>
<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.
>
> 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.
>
> [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.
<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> 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] 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.
<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> 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:
> 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.
>
> [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.
<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> Added " The measured SR traffic includes all labelled SR traffic and any
traffic entering the SR network over that TE interface."
Harish
_______________________________________________
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art