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

[Rob Shakir <[e-mail]>]

Great. Thanks Gaurav.

Please ping Mirja once you have posted the new version, and hopefully we
can progress this document.

Cheers,
r.

On Wed, Nov 21, 2018, 11:00 AM Gaurav Dawra <[e-mail]> wrote:

> Rob -
>
> After some discussions with authors - I will remove Sec. 7. Hopefully,
> this will close out this informational doc.
>
> Will post a new version.
>
> Cheers
>
> Gaurav
>
> Sent from my iPhone
>
> On Nov 2, 2018, at 10:09 AM, Rob Shakir <[e-mail]> wrote:
>
> 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
>>
>