Re: [OPSAWG] Mirja Kühlewind's No Objection on draft-ietf-opsawg-ipfix-bgp-community-11: (with COMMENT)
"Mirja Kuehlewind (IETF)" <ietf@kuehlewind.net> Thu, 06 December 2018 15:46 UTC
Return-Path: <ietf@kuehlewind.net>
X-Original-To: opsawg@ietfa.amsl.com
Delivered-To: opsawg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B89CD130DFB; Thu, 6 Dec 2018 07:46:33 -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 uNad-250H00w; Thu, 6 Dec 2018 07:46:31 -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 8842A130DC6; Thu, 6 Dec 2018 07:46:30 -0800 (PST)
Received: from ict-networks-2001-067c-10ec-5785-8000-0000-0000-0430.fwd-v6.ethz.ch ([2001:67c:10ec:5785:8000::430]); authenticated by wp513.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) id 1gUvr7-0001am-5N; Thu, 06 Dec 2018 16:46:25 +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: <CAKKJt-f+X1AXN6t=-0KN3N7ieDzbjjTLZaug3G52r3rVcZTUhg@mail.gmail.com>
Date: Thu, 06 Dec 2018 16:46:22 +0100
Cc: "Dongjie (Jimmy)" <jie.dong@huawei.com>, "Joel M. Halpern" <jmh@joelhalpern.com>, opsawg-chairs@ietf.org, Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com>, opsawg@ietf.org, IESG <iesg@ietf.org>, draft-ietf-opsawg-ipfix-bgp-community@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <7A2CC184-6D72-4869-9A81-9C61D0701FC2@kuehlewind.net>
References: <154359435795.27526.8666145722848127355.idtracker@ietfa.amsl.com> <CAKKJt-fE9-8BPDaXm4e8f9coZQxHnoSZmw-E41z_Huvg43xPew@mail.gmail.com> <637e246f-9ed8-ab29-71d3-7f3ad31b9db6@gmail.com> <CAKKJt-d2VNscx5vTXr8wXcNMQ8=6gb4rd5wFUS0fFDgdQE6R4A@mail.gmail.com> <9771f7b2-751c-998f-e400-83203e3856e5@joelhalpern.com> <76CD132C3ADEF848BD84D028D243C927C2EC54B4@NKGEML515-MBX.china.huawei.com> <536a6085-c75c-4168-b9c6-d2f019f30368@gmail.com> <CAKKJt-f+X1AXN6t=-0KN3N7ieDzbjjTLZaug3G52r3rVcZTUhg@mail.gmail.com>
To: Stewart Bryant <stewart.bryant@gmail.com>
X-Mailer: Apple Mail (2.3445.9.1)
X-bounce-key: webpack.hosteurope.de;ietf@kuehlewind.net;1544111190;f5c3602f;
X-HE-SMSGID: 1gUvr7-0001am-5N
Archived-At: <https://mailarchive.ietf.org/arch/msg/opsawg/2S9GGHUPXYti1VD5uGP2b8_y33c>
Subject: Re: [OPSAWG] Mirja Kühlewind's No Objection on draft-ietf-opsawg-ipfix-bgp-community-11: (with COMMENT)
X-BeenThere: opsawg@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OPSA Working Group Mail List <opsawg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/opsawg>, <mailto:opsawg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/opsawg/>
List-Post: <mailto:opsawg@ietf.org>
List-Help: <mailto:opsawg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/opsawg>, <mailto:opsawg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 06 Dec 2018 15:46:34 -0000
Thanks. Much better! > Am 06.12.2018 um 15:08 schrieb Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com>: > > > > On Thu, Dec 6, 2018 at 7:18 AM Stewart Bryant <stewart.bryant@gmail.com> wrote: > > > On 06/12/2018 07:55, Dongjie (Jimmy) wrote: > > Hi Spencer, Stewart, Joel, > > > > Thanks for the discussion about the congestion adaptation. We agree the reactive congestion adaptation may need further investigation. > > > > Thus in order to solve Mirja's comment, we plan to make that example more generic with something like: > > > > "For example, the collected information could be used for traffic monitoring, and could optionally be used for traffic optimization according to operator's policy." > > Sounds much better. > > I defer to Mirja since this is her ballot, but that sounds much more sane to me :-) > > Thanks for considering my comment on Mirja's comment! > > Spencer > > Stewart > > > > > Best regards, > > Jie > > > >> -----Original Message----- > >> From: Joel M. Halpern [mailto:jmh@joelhalpern.com] > >> Sent: Wednesday, December 05, 2018 12:03 AM > >> To: Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com>; Stewart > >> Bryant <stewart.bryant@gmail.com> > >> Cc: opsawg-chairs@ietf.org; opsawg@ietf.org; Mirja Kuehlewind > >> <ietf@kuehlewind.net>; IESG <iesg@ietf.org>; > >> draft-ietf-opsawg-ipfix-bgp-community@ietf.org > >> Subject: Re: [OPSAWG] Mirja Kühlewind's No Objection on > >> draft-ietf-opsawg-ipfix-bgp-community-11: (with COMMENT) > >> > >> The conclusion earlier work on congestive response routing reached was that > >> one needed to pin the specific routing decision until the selected path became > >> infeasible. > >> > >> Yours, > >> Joel > >> > >> On 12/4/18 10:59 AM, Spencer Dawkins at IETF wrote: > >>> Hi, Stewart, > >>> > >>> On Tue, Dec 4, 2018 at 6:07 AM Stewart Bryant > >>> <stewart.bryant@gmail.com <mailto:stewart.bryant@gmail.com>> wrote: > >>> > >>> > >>> > >>> On 30/11/2018 19:23, Spencer Dawkins at IETF wrote: > >>>> This is Mirja's comment, but ... > >>>> > >>>> On Fri, Nov 30, 2018 at 10:12 AM Mirja Kühlewind > >>>> <ietf@kuehlewind.net <mailto:ietf@kuehlewind.net>> wrote: > >>>> > >>>> Mirja Kühlewind has entered the following ballot position for > >>>> draft-ietf-opsawg-ipfix-bgp-community-11: No Objection > >>>> > >>>> When responding, please keep the subject line intact and reply > >>>> to all > >>>> email addresses included in the To and CC lines. (Feel free to > >>>> cut this > >>>> introductory paragraph, however.) > >>>> > >>>> > >>>> Please refer to > >>>> https://www.ietf.org/iesg/statement/discuss-criteria.html > >>>> for more information about IESG DISCUSS and COMMENT > >> positions. > >>>> > >>>> The document, along with other ballot positions, can be found > >>>> here: > >>>> > >>>> https://datatracker.ietf.org/doc/draft-ietf-opsawg-ipfix-bgp-communit > >>>> y/ > >>>> > >>>> > >>>> > >>>> ---------------------------------------------------------------------- > >>>> COMMENT: > >>>> > >>>> --------------------------------------------------------------------- > >>>> - > >>>> > >>>> One comment on section 1: > >>>> "For example, they can shift some flows > >>>> from congested links to low utilized links through an SDN > >>>> controller > >>>> or PCE [RFC4655]." > >>>> I'm not aware that ipfix information is commonly used for > >>>> dynamic traffic > >>>> adaptation and I'm not sure that is recommendable. C > >>>> > >>>> > >>>> I'm agreeing with Mirja here. > >>>> > >>>> We've spent a LOT of time not recommending dynamic traffic > >>>> adaptation. Probably half my responsibility as AD for ALTO was > >>>> repeating "you can't react based on changes to that attribute > >>>> without taking chances on oscillation" like it was a mystical > >>>> incantation, and I wasn't the first AD to have that conversation > >>>> repeatedly. > >>> Yes, I understand the ARPA net had exactly that problem at one stage > >>> and had to be converted from using a delay based metric to a fixed > >>> metric. > >>> > >>>> I would be happy to hear that all those problems are solved, but I > >>>> haven't heard that yet. Do the right thing, of course. > >>>> > >>>> Even "can shift some flows from persistently congested links to > >>>> underutilized links" would cause me less heartburn. > >>> There is no such thing as permanent in network paths! > >>> > >>> Like many control problems the first order solution is to damp with > >>> a suitably long time constant, but infinity, i.e. permanent, is not > >>> a satisfactory choice either. > >>> > >>> > >>> Yeah, that's where I was headed (stated more coherently). > >>> > >>> Saying "I should do something, because the network path is STILL > >>> congested" is safer than "I should do something because the network > >>> path is congested", so now we're talking about suitable definitions of > >>> "STILL". I was shooting for that with "persistent", and agree that > >>> "permanent" path characteristics is a happy idea we aren't likely to > >>> see in practice. > >>> > >>> Do the right thing, of course ;-) > >>> > >>> Spencer > >>> > >>> - Stewart > >>> > >>>> Spencer > >>> > >>> > >>> > >>> _______________________________________________ > >>> OPSAWG mailing list > >>> OPSAWG@ietf.org > >>> https://www.ietf.org/mailman/listinfo/opsawg > >>> >
- [OPSAWG] Mirja Kühlewind's No Objection on draft-… Mirja Kühlewind
- Re: [OPSAWG] Mirja Kühlewind's No Objection on dr… Spencer Dawkins at IETF
- Re: [OPSAWG] Mirja Kühlewind's No Objection on dr… Stewart Bryant
- Re: [OPSAWG] Mirja Kühlewind's No Objection on dr… Spencer Dawkins at IETF
- Re: [OPSAWG] Mirja Kühlewind's No Objection on dr… Joel M. Halpern
- Re: [OPSAWG] Mirja Kühlewind's No Objection on dr… Dongjie (Jimmy)
- Re: [OPSAWG] Mirja Kühlewind's No Objection on dr… Dongjie (Jimmy)
- Re: [OPSAWG] Mirja Kühlewind's No Objection on dr… Stewart Bryant
- Re: [OPSAWG] Mirja Kühlewind's No Objection on dr… Spencer Dawkins at IETF
- Re: [OPSAWG] Mirja Kühlewind's No Objection on dr… Mirja Kuehlewind (IETF)