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" <[email protected]> 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>
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] 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>
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>
Nits/editorial comments:
The second paragraph of the introduction seems to have the opening text
repeated twice.
[HS] Thanks - noted also as part of OPsDir review comments. The 2nd repeated
sentence will be removed.
The third paragraph of section 3.1 seems to be a repetition of the end of
the second paragraph using slightly different words.
[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>
--
Harish
_______________________________________________
Gen-art mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/gen-art
