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

[Rob Shakir <[e-mail]>]

Gaurav,

Can we distill down (to Mirja's question earlier) what this section is
trying to impart?

Taking a step back, it looks to me like you basically want to say:

   - (7.1) since there are explicit label stacks associated with each
   candidate path within an ECMP, any TE mechanism inside of the datacentre
   can exploit this to target a single one of them, rather than the whole set.
   The scope of doing so requires careful consideration of the traffic being
   balanced, but SR allows this to be the case.
   - (7.2) further to 7.1, it's not only for bandwidth-aware TE that this
   is the case, it may be for other traffic engineering optimisation criteria.
   - (7.3) the ability to allow targeting of traffic means that one can
   probe individual links.

These points are not unique to the MSDC problem space that you're
discussing. 3.3.1 in 7855
<https://tools.ietf.org/html/rfc7855#section-3.3.1> discusses 1+2 IMHO, and
OAM is covered in 8403. Am I missing something?

If not, please do seriously consider (as the author group) removing this
section, or simply linking to the other documents with brief statements on
the underlying points.

Kind regards,
r.

On Thu, Nov 1, 2018 at 9:20 PM Gaurav Dawra <[e-mail]> wrote:

> 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..
>>
>> _______________________________________________
> spring mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/spring
>