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

"Mirja Kuehlewind (IETF)" <ietf@kuehlewind.net> Mon, 26 November 2018 14:43 UTC

Return-Path: <ietf@kuehlewind.net>
X-Original-To: tsv-art@ietfa.amsl.com
Delivered-To: tsv-art@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B898B130E03; Mon, 26 Nov 2018 06:43:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BAMDo6h7orQG; Mon, 26 Nov 2018 06:43:24 -0800 (PST)
Received: from wp513.webpack.hosteurope.de (wp513.webpack.hosteurope.de [IPv6:2a01:488:42:1000:50ed:8223::]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 616D4130E01; Mon, 26 Nov 2018 06:43:24 -0800 (PST)
Received: from 200116b82cca700008c734d09529d7fa.dip.versatel-1u1.de ([2001:16b8:2cca:7000:8c7:34d0:9529:d7fa]); authenticated by wp513.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) id 1gRI6b-0004Hs-LT; Mon, 26 Nov 2018 15:43:21 +0100
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: "Mirja Kuehlewind (IETF)" <ietf@kuehlewind.net>
In-Reply-To: <CAHd-QWveYGMbgYptuKq0Yte894FfX4za=uXOj+fcKgA3BHq2dg@mail.gmail.com>
Date: Mon, 26 Nov 2018 15:43:20 +0100
Cc: Gaurav Dawra <gdawra.ietf@gmail.com>, SPRING WG List <spring@ietf.org>, Alvaro Retana <aretana.ietf@gmail.com>, draft-ietf-spring-segment-routing-msdc@ietf.org, Martin Stiemerling <mls.ietf@gmail.com>, tsv-art@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <9C54ECE9-9143-485D-B42B-4D762140CD21@kuehlewind.net>
References: <a77a198c-2a5a-d754-8725-6d6685338f6c@gmail.com> <6dd41180-83bd-c02e-1783-df873e749941@gmail.com> <ACD3CA27-2B92-4BD9-9D2B-A22FE20A65E7@gmail.com> <EC4C550B-05D7-4E6D-A1FD-ED48ECDC3059@gmail.com> <465981C7-7AB1-43AF-8A80-69D835871077@gmail.com> <CAMMESszPMdjpFLjY7aMVaaPbP0GVVZgB_n6hu4gQt6fSbGOi8A@mail.gmail.com> <d0d88a49-9cd8-fad4-9a8f-af45f1a8da2c@gmail.com> <CAMMESsxXhdXGd3k9qzPWqdnLyJb+m50K0y4-U9G=R_E1heoZ-Q@mail.gmail.com> <CAMOQah81UHX0HZM98cyjv50N1hzUqgUi8tUn96HVwPqPvKxW=w@mail.gmail.com> <8652B1BB-C2E7-4324-8E79-E3092362AE1A@gmail.com> <CAMOQah-qL6MxEQKXzEzXN8b3ToSTnX1uJ5AZafh=8E35qv1DZQ@mail.gmail.com> <c4bbf256-9552-ca47-812e-d60838c301c8@kuehlewind.net> <2120B719-EB92-4A47-A26C-0E2E810F1CA8@gmail.com> <CAMOQah9s57vgjUVynBqZim=7fx0745uQeOKARu8DtKdiFU36ng@mail.gmail.com> <3b257a8a-0455-cd1b-6e95-0e03ab3f1830@kuehlewind.net> <CAMOQah9vxzNMqXqKY-YNM1LLBMyryx=bFoDeBp4Da7MCt39Uxg@mail.gmail.com> <CAMOQah_YGkkwcwd3sepNy_7iU+mjAjgESLwekbQnNmKesJYJbQ@mail.gmail.com> <870b223b-5fa7-e5f3-919f-f36521d69d68@kuehlewind.net> <AF02069C-A2C0-497E-A0F3-1F6217274650@gmail.com> <C28FE61D-0354-4A2C-B5CA-AAB00D84FB79@kuehlewind.net> <CAMMESsxdB4+5yWfCY2huh1eqvAEU-+Nz-0VhJvdHohZ4ffCUdQ@mail.gmail.com> <CAMOQah93LJYdroRZQa0-y4eWxE-coUFbkm9n+_eQgAqcdQzZWA@mail.gmail.com> <CAHd-QWsMjGVD4doCV4OfwSrKA3ChnrDBd4DYA6VNp3EiqQ32ww@mail.gmail.com> <24740D0F-E0A0-4AD2-9D0A-DC38F98B1498@gmail.com> <CAHd-QWveYGMbgYptuKq0Yte894FfX4za=uXOj+fcKgA3BHq2dg@mail.gmail.com>
To: Rob Shakir <robjs=40google.com@dmarc.ietf.org>
X-Mailer: Apple Mail (2.3445.9.1)
X-bounce-key: webpack.hosteurope.de;ietf@kuehlewind.net;1543243404;a03d6a84;
X-HE-SMSGID: 1gRI6b-0004Hs-LT
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsv-art/k7xSuShamcHeQtJoI1c92Fa5S6Y>
Subject: Re: [Tsv-art] [spring] TSV-ART review of draft-ietf-spring-segment-routing-msdc-08
X-BeenThere: tsv-art@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Transport Area Review Team <tsv-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tsv-art>, <mailto:tsv-art-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tsv-art/>
List-Post: <mailto:tsv-art@ietf.org>
List-Help: <mailto:tsv-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsv-art>, <mailto:tsv-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 26 Nov 2018 14:43:27 -0000

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=40google.com@dmarc.ietf.org>:
> 
> 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 <gdawra.ietf@gmail.com> 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 <robjs@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.ietf@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.ietf@gmail.com> wrote:
>> On October 29, 2018 at 11:34:13 AM, Mirja Kuehlewind (IETF) (ietf@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
> _______________________________________________
> Tsv-art mailing list
> Tsv-art@ietf.org
> https://www.ietf.org/mailman/listinfo/tsv-art