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

Gaurav Dawra <gdawra.ietf@gmail.com> Thu, 29 November 2018 23:15 UTC

Return-Path: <gdawra.ietf@gmail.com>
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 3D6D2130E03; Thu, 29 Nov 2018 15:15:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Level:
X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, NORMAL_HTTP_TO_IP=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 F10PRd5JLyyo; Thu, 29 Nov 2018 15:15:24 -0800 (PST)
Received: from mail-pg1-x530.google.com (mail-pg1-x530.google.com [IPv6:2607:f8b0:4864:20::530]) (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 F251C128766; Thu, 29 Nov 2018 15:15:23 -0800 (PST)
Received: by mail-pg1-x530.google.com with SMTP id s198so1628482pgs.2; Thu, 29 Nov 2018 15:15:23 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=EvaJA7yUhu/yFvlxeHVUEtCeeNDwJgnYPqsUA6szVQE=; b=JjlVJy1UPUj6vB7FKau+uvML6nUfrKaGAqLb3fZhM1ViisQjBrCjJpZ+uYR5lcX+4u ofHrLlkO7BWn9TUqf2zcZknag+5Sfu9wjIlursLoTDemGBVl2V58gE8yd928lQOj00tr Z12u8zl/8L1x9lX6Ru1M7dVg9hD+nhPJ6RZ5DFy0FtGl4z/p69zsSePwE/eLJ78KK6rJ xIQQpe6a+rSnEhxuPB3aM0+AqxtGMCV8ihv+6e8gzhmv6hYi51SbQNlTHgg63THaRp7h +J87DZKXZB8R7DE2O+vXidCvgXSWZ2SEni1hRxWwF2NaZo9GZ9xvqbAAVcjkrecTf9tX kyhw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=EvaJA7yUhu/yFvlxeHVUEtCeeNDwJgnYPqsUA6szVQE=; b=BjrjzQ6MI1GNRe+PC52gJIQo1VqDnishPDKzpPO5p3Tk+AaG1ydCb/LODmICcba/jR BmENM9g8jcjCm2s5g6bL+iDbAQkSk7EyBx3QL5YgGDnEJ8wnQKzjHe8tyC4VT1RyHW/Y ikQx7k68s6rTfAdc9ySTOYVL1riH6PHsbdgq/VzgSxTXsYHZyI2WN7HOL9STaB6D+bab QyMDgoEOadMUrIz7kihSF1zzCKgAdY/X0gjzH1E1CE1MMFrDq7PEwwE5ppYxEmOCKWxH Z/2q3+RSKOQlR1f2FVg02/kxJUnNsiiqm8X/zCzur3WLZRXBBdRnB3KnN/ggkbB/2LyF VTfQ==
X-Gm-Message-State: AA+aEWaVsTdGjhXjJ8txt1zLaWzzXfaRvfRx25Z62BIwLiDv9sER7ilL h+SGkGV2+l5CDkl/QjjPjqMmfPmb
X-Google-Smtp-Source: AFSGD/UZfz/ywZzORS2aHp6Ogjy7H14JFCiPDxZ5WlNFu5sflHWXRAE9/L1e2wj4UzZia915v/nYlg==
X-Received: by 2002:a63:5664:: with SMTP id g36mr2855241pgm.313.1543533323298; Thu, 29 Nov 2018 15:15:23 -0800 (PST)
Received: from ?IPv6:2620:119:5003:20c:5cb1:7b:4cfc:4f2f? ([2620:119:5003:20c:5cb1:7b:4cfc:4f2f]) by smtp.gmail.com with ESMTPSA id q187sm14548187pfq.128.2018.11.29.15.15.22 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 29 Nov 2018 15:15:22 -0800 (PST)
Content-Type: multipart/alternative; boundary="Apple-Mail-BCEE8511-62C2-4A33-86B8-598A0FA80882"
Mime-Version: 1.0
From: Gaurav Dawra <gdawra.ietf@gmail.com>
X-Mailer: iPhone Mail (15F79)
In-Reply-To: <CAHd-QWveYGMbgYptuKq0Yte894FfX4za=uXOj+fcKgA3BHq2dg@mail.gmail.com>
Date: Thu, 29 Nov 2018 15:15:21 -0800
Cc: Alvaro Retana <aretana.ietf@gmail.com>, Martin Stiemerling <mls.ietf@gmail.com>, SPRING WG <spring@ietf.org>, draft-ietf-spring-segment-routing-msdc@ietf.org, tsv-art@ietf.org, Rob Shakir <robjs@google.com>
Content-Transfer-Encoding: 7bit
Message-Id: <56D33571-A031-4375-955D-348401118CAF@gmail.com>
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: Mirja Kühlewind <ietf@kuehlewind.net>
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsv-art/RP5DwMO8uHDd9PlhspdiVXr71AU>
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: Thu, 29 Nov 2018 23:15:26 -0000

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 <robjs@google.com> 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 <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