Re: [Tsv-art] [spring] TSV-ART review of draft-ietf-spring-segment-routing-msdc-08
Gaurav Dawra <gdawra.ietf@gmail.com> Tue, 19 June 2018 00:13 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 8E63F130E5E; Mon, 18 Jun 2018 17:13:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.997
X-Spam-Level:
X-Spam-Status: No, score=-0.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, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 qswso3Vbn1aF; Mon, 18 Jun 2018 17:13:32 -0700 (PDT)
Received: from mail-pl0-x22d.google.com (mail-pl0-x22d.google.com [IPv6:2607:f8b0:400e:c01::22d]) (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 A29DC126CB6; Mon, 18 Jun 2018 17:13:32 -0700 (PDT)
Received: by mail-pl0-x22d.google.com with SMTP id w17-v6so9923174pll.9; Mon, 18 Jun 2018 17:13:32 -0700 (PDT)
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=AzZ++7X8Pqa9lhhl1ARjpMpjL5ZEAdUYTIYGL+y//ZE=; b=DeLKOhYCH+Vu8e2kzt+rcQvMdkHIn1bcLVTrqxvjXoCMR+b1miD9qZ117ruAedWnJM 19do144hjt37fYJEn5NPnhGu1iCeYYyHhGBNuHb8FgacIZR7aUvAR5Zo2+PgxHumrgMJ +3+KFtHM/k8p7W0g1ry1zh3G3BFAMAFXPTzPFbHXsKRgsv+gTDcMI8IybO8OTxgLhaK4 NiclRHQel232DySrEjmTs8S83cxcgD2sVWqpCa8yMmJwFvn1wR5I0JQuUdCMzmKoo6uv ZckzllenXOLkWg1+Mcc8sY8MrhVpnEgTIu6b7mmZfGBTiHwsUtekLNLiD3/ZTs29QDlB hNxw==
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=AzZ++7X8Pqa9lhhl1ARjpMpjL5ZEAdUYTIYGL+y//ZE=; b=EpRA6J8xPm8ejDG3CjkGzim5uWFTj8OC50bLHtKR4UF0NZ2bVaoqZdThPeQ/hXH8zX Od2JxPmryGS7I11y5nrbadZ1khhg5Q5ZtT2nN41anlOv19nowVrvzFX38yWnCgcMenpo N8SsnZ7jg8qXsl8r9h9xx+x8vnOOnHU7EFiBZT0MfGLsazuiV51MoWG1Ycsq8pe2Ndji NVtvJD6Z2vMQOEjU6GIOc9KsGUL7hMoMj2BwcaooL/AKN08FgSs4Y+z2S6TCCd9NUI5S ADbpo6KyIVPx1Brfc+b6DnV+VSEMeL47MXnd+Cg3XpN4X1zpZ+W7ltbDCSS/oEUWxPQd WTfQ==
X-Gm-Message-State: APt69E0Xr22Sqp04s/iPf5K9ul5D0aLlotA9XE77/W57XPLA8A0zxxUl 49g9PuEFoRtW7gz0C1RWevurhoBj
X-Google-Smtp-Source: ADUXVKJv4PcD+/o2OYC/Gi1DuooxtO+DH7o99lNcsZtmGHwe+SBn4R5L52F9ZNfXkZu+zwFTlMco/Q==
X-Received: by 2002:a17:902:7e07:: with SMTP id b7-v6mr16294077plm.230.1529367212173; Mon, 18 Jun 2018 17:13:32 -0700 (PDT)
Received: from ?IPv6:2607:fb90:3647:beea:41b9:b0c5:f897:55f0? ([2607:fb90:3647:beea:41b9:b0c5:f897:55f0]) by smtp.gmail.com with ESMTPSA id c191-v6sm24934673pfg.48.2018.06.18.17.13.30 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 18 Jun 2018 17:13:31 -0700 (PDT)
Content-Type: multipart/alternative; boundary="Apple-Mail-0394868E-2976-461A-8E27-9D21FB7DA906"
Mime-Version: 1.0 (1.0)
From: Gaurav Dawra <gdawra.ietf@gmail.com>
X-Mailer: iPhone Mail (15F79)
In-Reply-To: <CAMOQah81UHX0HZM98cyjv50N1hzUqgUi8tUn96HVwPqPvKxW=w@mail.gmail.com>
Date: Mon, 18 Jun 2018 17:13:30 -0700
Cc: Martin Stiemerling <mls.ietf@gmail.com>, tsv-art@ietf.org, SPRING WG <spring@ietf.org>, Mirja Kühlewind <ietf@kuehlewind.net>
Content-Transfer-Encoding: 7bit
Message-Id: <8652B1BB-C2E7-4324-8E79-E3092362AE1A@gmail.com>
References: <a77a198c-2a5a-d754-8725-6d6685338f6c@gmail.com> <40ED2C86-3403-4D89-8CA8-FBB9651BF2AB@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>
To: Alvaro Retana <aretana.ietf@gmail.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsv-art/JMvV8X1WCydfdjdWU6aci4iFg_E>
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.26
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: Tue, 19 Jun 2018 00:13:36 -0000
Hi Alvaro, Mirja Any feedback or next steps to close this? Cheers, Gaurav Sent from my iPhone > On Jun 12, 2018, at 7:06 AM, Gaurav Dawra <gdawra.ietf@gmail.com> wrote: > > Hi Mirja, > > Friendly Reminder...Could you please also advice if there is anything further to DISCUSS on this document which was also related to TCP updates below? > > Cheers, > > Gaurav > >> On Thu, Jun 7, 2018 at 9:02 AM, Alvaro Retana <aretana.ietf@gmail.com> wrote: >> Thanks Martin! >> >>> On June 6, 2018 at 3:14:45 PM, Martin Stiemerling (mls.ietf@gmail.com) wrote: >>> >>> Hi Alvaro, all, >>> >>> Thanks for addressing my concerns. >>> >>> This version is good to go from my side. >>> >>> Kind regards, >>> >>> ;Martin >>> >>> Am 30.05.18 um 21:55 schrieb Alvaro Retana: >>> > Martin: >>> > br/>> Hi!! How are you? >>> > br/>> Gaurav just posted a revision. Please takke a look and let us know if br/>> the changes address your concerrns or not. >>> > br/>> https://www.ietf.org/rfcdiff??url2=draft-ietf-spring-segment-routing-msdc-09 >>> > br/>> Thanks!!! >>> > br/>> Alvaro. < >>> > br/>> On May 25, 2018 at 12:08:46 PM, Gaurav Dawra ((gdawra.ietf@gmail.com br/>> <mailto:gdawra.ietf@@gmail.com>) wrote: >>> > br/>>> Hi Martin, < >>> >> >>> >> Thanks for review. I will post the new version. Hopefully, it will br/>>> address all your comments and we can close thhis review. >>> >> >>> >> Any updates on below response? >>> >> >>> >> Cheers, >>> >> >>> >> Gaurav >>> >> >>> >> Sent from my iPhone >>> >> >>> >> On May 23, 2018, at 4:17 AM, Gaurav Dawra <gdawra.ietf@gmail.com br/>>> <mailto:gdawra.ietf@@gmail.com>> wrote: >>> >> >>> >>> Hi Martin, >>> >>> >>> >>> Thanks for the review. Any further comments here ? I will post the br/>>>> new version soon. < >>> >>> >>> >>> Cheers, >>> >>> >>> >>> Gaurav >>> >>> >>> >>> Sent from my iPhone >>> >>> >>> >>> On May 16, 2018, at 7:44 PM, Gaurav Dawra <gdawra.ietf@gmail.com br/>>>> <mailto:gdawra.ietf@@gmail.com>> wrote: >>> >>> >>> >>>> Hi Martin, >>> >>>> >>> >>>> Apologies from my end we had few internal authors conversations on br/>>>>> the points you have raised. < >>> >>>> >>> >>>> Please find below my response. I will be happy to discuss further, br/>>>>> if needed. < >>> >>>> >>> >>>> <Gaurav> inline... >>> >>>> >>> >>>>> On Apr 9, 2018, at 7:58 AM, Martin Stiemerling <mls.ietf@gmail.com br/>>>>>> <mailto:mls.iietf@gmail.com>> wrote: >>> >>>>> >>> >>>>> Hi Gaurav, >>> >>>>> >>> >>>>> This got lost on my end, sorry for this. The filter just moved br/>>>>>> these messages out of my sight... :-/ >>> >>>>> >>> >>>>> Am 15.02.18 um 05:47 schrieb Gaurav Dawra: >>> >>>>>> Hey Martin, >>> >>>>>> Sorry for late reply. Please see some comments inline[Gaurav] >>> >>>>>>> On Jan 9, 2018, at 2:25 PM, Martin Stiemerling br/>>>>>>>> <mls.ietf@@gmail.com <mailto:mls.ietf@gmail.com> br/>>>>>>>>; <mailto:mls.ietf@gmail.com>> wrote: >>> >>>>>>> >>> >>>>>>> Hi all, >>> >>>>>>> >>> >>>>>>> I've reviewed this document as part of the transport area review br/>>>>>>>> team's ongoing effort to review key IETF documents. These br/>>>>t;>>>> comments were written primarily for the transport area directors, br/>>>>>>>> but are copied to the doocument's authors for their information br/>>>>>>>&> and to allow them to address any issues raised. When done at the >>> >>>>>>> time of IETF Last Call, the authors should consider this review br/>>>>>>>> together with any other last-call comments they receive. Please br/>>>&>>>>> always CC tsv-art@… if you reply to or forward this review. >>> >>>>>>> >>> >>>>>>> Summary: >>> >>>>>>> This draft has serious issues in Section 7.1, 7.2 and in one part br/>>>>>>>> of Secction3, described in the review, and needs to be rethought. br/>>&>>>>>> The other sections are good AFAIK. >>> >>>>>>> >>> >>>>>>> >>> >>>>>>> Technicals: >>> >>>>>>> The overall draft looks ok, but the three points below look br/>>>>>>>> strange and need a fix before publication IMHO: >>> >>>>>>> >>> >>>>>>> Both Sections, 7.1. and 7.2., are describing ideas, but not well br/>>>>>>>> proven funcationality and not even safe to use functionality. br/>>>&>>>>> Both are some sort discussing that different paths in the network br/>>>>>>>> could be used by the eend host traffic. This sounds pretty much br/>>>>>>>t;> like the Path Aware Networking Proposed Research Group br/>>t;>>>>>> (https://irtf.org/panrg) and hints to the fact that there is no br/>>>>>>>> commonly understannd and accepted engineering solution in this space. >>> >>>>>>> >>> >>>>>>> Section 7.1: >>> >>>>>>> [KANDULA04] is a really old reference that hasn't been followed br/>>>>>>>> up iin recent times and even worse there is no evidence that this br/>>t;>>>>>> is going to work good enough or stable enough under real Internet br/>>>>>>>> traffic. Additioonally, it is more than unclear how any modern TCP br/>>>>&ggt;>>> implementation will react to this >>> >>>>>> [Gaurav] Will get back on this. >>> >>>>> >>> >>>>> I will reply to the other email dicussing this. >>> >>>> <Gaurav> I have replied to other thread. >>> >>>>> >>> >>>>>>> >>> >>>>>>> Section 7.2: >>> >>>>>>> This section describes an idea without detailing too much about br/>>>>>>>> any furtther aspects. Further it changes the commonly accepted br/>>>;>>>>> notion of what an end host can do with the network. At best this br/>>>>>>>> would require a good ddefinition of what an end host in your br/>>>>>>>&ggt; setting is, e.g., a highly modified piece of (at least) software >>> >>>>>>> that usually not found in OS availble on the market (yet?) >>> >>>>>>> Further communicating instantaneous path characteristics to a br/>>>>>>>> central point is potentially a bad idea, as the data is already br/>>>;>>>>> outdated when reported by any node. >>> >>>>>> [Gaurav] I believe Authors are trying to highlight that Host which br/>>>>>>> is defineed in br/>>>>>>> (https://tools.ietf.org/html/draftt-ietf-spring-segment-routing-15) br/>>>>>>> can innfluence the traffic based on the Calculations locally or br/>>>t;>>>> jointly with the controller. Implementations can decide how much br/>>>>>>> Centralized -vs- localized coontrol is allowed at Host based on br/>>>>>>> perfoormance data collection. >>> >>>>> >>> >>>>> Performance data collection (monitoring?) isn't crucial when it br/>>>>>> comes to timely (actuaally real-time) reaction. However, this br/>>>>>> secttion isn't just about performance data collection as it is about br/>>>>>>> "Performance-aware routing" this seems to try to interact in br/>>>>>> real-time with the network behhavior of TCP. This isn't even close br/>>>>>> to acceeptable. >>> >>>>> >>> >>>>> I would be ok to say that it is useful to collect performance data br/>>>>>> for offline analysis and improvement of the data network. However, br/>>>>>&ggt; this is at completely different magnitues of time scales. >>> >>>>> >>> >>>>> I would recommend to remove the TCP part from this section entirely. >>> >>>> <Gaurav>Ack, will update in next rev: >>> >>>> >>> >>>> Section will read like this: >>> >>>> >>> >>>> ; >>> >>>> /Knowing the path associated with flows/packets, the end host may/ >>> >>>> /deduce certain characteristics of the path on its own, and/ >>> >>>> /additionally use the information supplied with path information/ >>> >>>> /pushed from the controller or received via pull request. The host/ >>> >>>> /may further share its path observations with the centralized agent,/ >>> >>>> /so that the latter may keep up-to-date network health map to assist/ >>> >>>> /other hosts with this information./ >>> >>>> // >>> >>>> /For example, an application A.1 at HostA may pin a flow destined/ >>> >>>> /to HostZ via Spine node Node5 using label stack {16005, 16011}. The/ >>> >>>> /application A.1 may collect information on packet loss, deduced from/ >>> >>>> /Other offline mechanisms. [There are some pingMesh mechanisms which / >>> >>>> /Can be used here]/ >>> >>>> /Through these mechanisms information to a centralized agent, e.g./ >>> >>>> /after a flow completes, or periodically for longer lived flows./ >>> >>>> /Next, using both local and/or global performance data, application/ >>> >>>> /A.1 as well as other applications sharing the same resources in the/ >>> >>>> /DC fabric may pick up the best path for the new flow, or update an/ >>> >>>> /existing path (e.g.: when informed of congestion on an existing/ >>> >>>> /path)./ >>> >>>> ; >>> >>>> >>> >>>>> >>> >>>>> >>> >>>>>>> >>> >>>>>>> Section 3, 3rd bullet point: >>> >>>>>>> It is the foundation of TCP that the network is regarded as a br/>>>>>>>> black box and that you infer from the transmission of packets br/>>>>;>>>> what the current state of the network path is. Inferring network br/>>>>>>>> path metrics (you mention SRTT, MSS, CWND ) is a bad idea, as br/>>>>>>>>; this would required that all paths exhibit this and if not what br//>>>>>>>> is going to happen? >>> >>>>>>> It could be an interesting research field to change many points br/>>>>>>>> in TCP'ss behavior, but this once again points to the fact that br/>>>&>>>>> this not the IETF works but IRTF or elsewhere. >>> >>>>>> [Gaurav] Martin, Authors are trying to suggest that TCP is rightly br/>>>>>>> treating Network as Black Box. Authors are implying per path br/>>>>;>>> performance metrics as not cached. Is there some change in text br/>>>>>>> you are suggesting?? >>> >>>>> >>> >>>>> >>> >>>>> I would recommend to remove the 3rd bullet point completey. TCP br/>>>>>> isn't the place to rememmber "good" or "bad" paths. This is br/>>>>>> something the network could decide, e.g., rerouting TCP flows br/>&ggt;>>>> within the network or changing the forwarding path in the network br/>>>>>> for particular flows (if it is not routed). >>> >>>> >>> >>>> <Gaurav> Ack, after discussion, we will remove the Section 3 - 3rd br/>>>>> bullet point. Willl update in next rev - coming shortly. >>> >>>> >>> >>>>> >>> >>>>> Kind regards, >>> >>>>> >>> >>>>> Martin >>> >>>>> >>> >>>> >
- Re: [Tsv-art] [spring] TSV-ART review of draft-ie… Gaurav Dawra
- Re: [Tsv-art] [spring] TSV-ART review of draft-ie… Gaurav Dawra
- Re: [Tsv-art] [spring] TSV-ART review of draft-ie… Martin Stiemerling
- Re: [Tsv-art] [spring] TSV-ART review of draft-ie… Alvaro Retana
- Re: [Tsv-art] [spring] TSV-ART review of draft-ie… Gaurav Dawra
- Re: [Tsv-art] [spring] TSV-ART review of draft-ie… Mirja Kühlewind
- [Tsv-art] TSV-ART review of draft-ietf-spring-seg… Martin Stiemerling
- Re: [Tsv-art] [spring] TSV-ART review of draft-ie… Gaurav Dawra
- Re: [Tsv-art] [spring] TSV-ART review of draft-ie… Gaurav Dawra
- Re: [Tsv-art] [spring] TSV-ART review of draft-ie… Gaurav Dawra
- Re: [Tsv-art] [spring] TSV-ART review of draft-ie… Gaurav Dawra
- Re: [Tsv-art] [spring] TSV-ART review of draft-ie… Alvaro Retana
- Re: [Tsv-art] [spring] TSV-ART review of draft-ie… Martin Stiemerling
- Re: [Tsv-art] [spring] TSV-ART review of draft-ie… Martin Stiemerling
- Re: [Tsv-art] [spring] TSV-ART review of draft-ie… Gaurav Dawra
- Re: [Tsv-art] [spring] TSV-ART review of draft-ie… Gaurav Dawra
- Re: [Tsv-art] [spring] TSV-ART review of draft-ie… Gaurav Dawra
- Re: [Tsv-art] [spring] TSV-ART review of draft-ie… Gaurav Dawra
- Re: [Tsv-art] [spring] TSV-ART review of draft-ie… Gaurav Dawra
- Re: [Tsv-art] [spring] TSV-ART review of draft-ie… Alvaro Retana
- Re: [Tsv-art] [spring] TSV-ART review of draft-ie… Gaurav Dawra
- Re: [Tsv-art] [spring] TSV-ART review of draft-ie… Gaurav Dawra
- Re: [Tsv-art] [spring] TSV-ART review of draft-ie… Gaurav Dawra
- Re: [Tsv-art] [spring] TSV-ART review of draft-ie… Mirja Kühlewind
- Re: [Tsv-art] [spring] TSV-ART review of draft-ie… Gaurav Dawra
- Re: [Tsv-art] [spring] TSV-ART review of draft-ie… Gaurav Dawra
- Re: [Tsv-art] [spring] TSV-ART review of draft-ie… Mirja Kühlewind (IETF)
- Re: [Tsv-art] [spring] TSV-ART review of draft-ie… Gaurav Dawra
- Re: [Tsv-art] [spring] TSV-ART review of draft-ie… Mirja Kuehlewind (IETF)
- Re: [Tsv-art] [spring] TSV-ART review of draft-ie… Alvaro Retana
- Re: [Tsv-art] [spring] TSV-ART review of draft-ie… Gaurav Dawra
- Re: [Tsv-art] [spring] TSV-ART review of draft-ie… Rob Shakir
- Re: [Tsv-art] [spring] TSV-ART review of draft-ie… Gaurav Dawra
- Re: [Tsv-art] [spring] TSV-ART review of draft-ie… Rob Shakir
- Re: [Tsv-art] [spring] TSV-ART review of draft-ie… Mirja Kuehlewind (IETF)
- Re: [Tsv-art] [spring] TSV-ART review of draft-ie… Gaurav Dawra
- Re: [Tsv-art] [spring] TSV-ART review of draft-ie… Mirja Kuehlewind (IETF)
- Re: [Tsv-art] [spring] TSV-ART review of draft-ie… Rob Shakir