Re: [Tsv-art] [spring] TSV-ART review of draft-ietf-spring-segment-routing-msdc-08

[Gaurav Dawra <[e-mail]>]

Thanks Alvaro.

Mirja,

How does this text sound? I am inclined to the discussion over the phone if
we need further discussion :)

"This section outlines as an example a possible solution for addressing
flow steering problem using SR.  The host which is originating an flow may
share its application observations with a centralized agent by indicating
its bandwidth requirements and the destination for the flow, that enables
the latter to keep up-to-date network bandwidth demand maps for such flows
correlated with the actual utilization of the paths in the network. The
centralized agent may use this information to make an optimal routing
decision. The end host may receive updated steering information from the
centralized agent, published via external mechanisms, of specific paths
with their bandwidth availability on which to steer its flow.



For example, an application A.1 is informed about explicit paths to Z
{16006, 16011} which has bandwidth availability such as not to degrade
other flows. The centralized agent may similarly pin flows on other
disjoint explicit paths. Over a period of time, or once the flow is gone
(as reported by the application), then the centralized agent updates the
hosts to revert back to their normal per-flow ECMP based hashing for
load-sharing. The details of how such a solution may be realized is outside
the scope of this document. However, the traffic steering mechanism using
SR allows for solving some of these problems in the data-center."


Gaurav

On Mon, Oct 29, 2018 at 12:41 PM Alvaro Retana <[e-mail]>
wrote:

> On October 29, 2018 at 11:34:13 AM, Mirja Kuehlewind (IETF) (
> [e-mail]) wrote:
>
> Hi!
>
> FWIW, I agree with Mirja and her proposal below.  Not only does it sound
> like this Informational document is talking about items that should be out
> of scope, but the first paragraph in §7 says that it talks about "how the
> problems described above (in section 3) could be solved using the segment
> routing concept.”  To me, these are examples and (as the text also
> mentions) "only parts of the solution”.
>
> Let’s please wrap this document up!
>
> Thanks!
>
> Alvaro.
>
>
> this still sounds very much like inventing a new mechanism which seem a
> bit out of scope for this document. However, after all bandwidth
> requirements might not be known or are very dynamic because of congestion
> control or adaption mechanism in the application (e.g. adaptive video
> traffic), and therefore there it is still the same problem that it is no
> reasonable to make decision based on this very dynamic metric.
>
> The text below sounds like you are rather interested to a) distinguish
> elephant from mice flows and b) understand if the elephant flow has a
> maximum bandwidth cap (because it's application-limited). These are
> different information and might be more useful for your case. However, I
> still think having this discussion in this level of details goes beyond the
> scope of the document.
>
> What’s about just saying something like, a central host can collect
> per-flow information, either from the host directly or measurement on the
> path, and use this information to impact routing. I would, however, also
> like to see a note/warning in this context that metrics that are changing
> very dynamically should not be used as input for routing decisions.
>
>