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

[Rob Shakir <[e-mail]>]

Great. Thanks to all for driving this to a mutually acceptable outcome.

r.

On Fri, Nov 30, 2018, 12:07 AM Mirja Kuehlewind (IETF) <[e-mail]>
wrote:

> Thanks! I cleared my discuss!
>
> > Am 30.11.2018 um 00:15 schrieb Gaurav Dawra <[e-mail]>:
> >
> > 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 <[e-mail]> wrote:
> > 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 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
> > _______________________________________________
> > Tsv-art mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/tsv-art
>
>