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 <ro...@google.com> 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 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 <gdawra.i...@gmail.com> 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 <aretana.i...@gmail.com>
>>> wrote:
>>
>>> On October 29, 2018 at 11:34:13 AM, Mirja Kuehlewind (IETF)
>>> (i...@kuehlewind.net) 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
>> spring@ietf.org
>> https://www.ietf.org/mailman/listinfo/spring
_______________________________________________
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring
