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

From: Gaurav Dawra <[email-masked]>
Date: Thu, 1 Nov 2018 21:19:49 -0700

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 <[email-masked]>
wrote:

> On October 29, 2018 at 11:34:13 AM, Mirja Kuehlewind (IETF) (
> [email-masked]) 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.
>
>

---

From: Rob Shakir <[email-masked]>
Date: Fri, 2 Nov 2018 10:09:19 -0700

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 <[email-masked]> wrote:

> Thanks Alvaro.
>
> Mirja,
>
> How does this text sound? I am inclined to the discussion over the
> phone if we need further discussion :)
>
> 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.
>
>
>
> 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
>
>> very dynamically should not be used as input for routing decisions..
>>
>> _______________________________________________
> spring mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/spring
>

---

From: Gaurav Dawra <[email-masked]>
Date: Wed, 21 Nov 2018 11:00:00 -0800

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 <[email-masked]> wrote:
> 
> Gaurav,
> 
> Can we distill down (to Mirja's question earlier) what this section is trying to impart?
> 
> (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 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.
> 
>> 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 <[email-masked]> wrote:
>> 
>>> On October 29, 2018 at 11:34:13 AM, Mirja Kuehlewind (IETF) ([email-masked]) 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”.
>>> 
>>>> 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..

---

From: Rob Shakir <[email-masked]>
Date: Wed, 21 Nov 2018 12:32:18 -0800

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 <[email-masked]> 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
>
> <https://tools.ietf.org/html/rfc7855#section-3.3.1> discusses 1+2 IMHO,
> and OAM is covered in 8403. Am I missing something?
>

---

From: "Mirja Kuehlewind (IETF)" <[email-masked]>
Date: Mon, 26 Nov 2018 15:43:20 +0100

Thanks. I will remove my discuss as soon as the new version is posted.

Mirja

> Am 21.11.2018 um 21:32 schrieb Rob Shakir <robjs=[email-masked]>:
> 
> Great. Thanks Gaurav. 
> 
> Please ping Mirja once you have posted the new version, and hopefully we can progress this document. 
> 
> Cheers,
> r. 
> 
>> 	• (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.
> Tsv-art mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tsv-art

---

From: Gaurav Dawra <[email-masked]>
Date: Thu, 29 Nov 2018 15:15:21 -0800

Hi, folks,

Posted a new version. Hopefully, this help closes this document. 

Cheers,

Gaurav

> On Wed, Nov 21, 2018 at 12:32 PM Rob Shakir <[email-masked]> wrote:
> Great. Thanks Gaurav. 
>

---

From: "Mirja Kuehlewind (IETF)" <[email-masked]>
Date: Fri, 30 Nov 2018 09:07:02 +0100

Thanks! I cleared my discuss!

> Am 30.11.2018 um 00:15 schrieb Gaurav Dawra <[email-masked]>:
> 
> Hi, folks,
> 
> Posted a new version. Hopefully, this help closes this document.. 
> 
> Cheers,
> 
> Gaurav
> 
>> 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
>>