Re: [OPSAWG] Mirja Kühlewind's No Objection on draft-ietf-opsawg-ipfix-bgp-community-11: (with COMMENT)

"Joel M. Halpern" <jmh@joelhalpern.com> Tue, 04 December 2018 16:02 UTC

Return-Path: <jmh@joelhalpern.com>
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 A6DFA130E90; Tue, 4 Dec 2018 08:02:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.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 adleYZo5jdmN; Tue, 4 Dec 2018 08:02:52 -0800 (PST)
Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DBFE8130E72; Tue, 4 Dec 2018 08:02:51 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 438RTl3zsBz1Z5qv; Tue, 4 Dec 2018 08:02:51 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1543939371; bh=Q++DDzJI/ZKx2x8GMqbWZVpqK+V5nmfZ47IsGtmW+Ts=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=k90ONPK9xK182Ra5m+iEfu8ecpgJ1U6Z461PLnGiVmILp2RiVe5FhaJOL8Vq8KQPa 4N00JJgWF0TVZI9MgnN4XIiAY5DLPFDfZyO7oPucIXXrLWiwS5dDsxxSKnAL486l9h l0a+viFDuTXBfLqPiQyVKQUllPb1mtOerkNkj+oo=
X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net
Received: from Joels-MacBook-Pro.local (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 438RTk23dhz1Z5qf; Tue, 4 Dec 2018 08:02:50 -0800 (PST)
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
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>
From: "Joel M. Halpern" <jmh@joelhalpern.com>
Message-ID: <9771f7b2-751c-998f-e400-83203e3856e5@joelhalpern.com>
Date: Tue, 04 Dec 2018 11:02:49 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:52.0) Gecko/20100101 Thunderbird/52.9.1
MIME-Version: 1.0
In-Reply-To: <CAKKJt-d2VNscx5vTXr8wXcNMQ8=6gb4rd5wFUS0fFDgdQE6R4A@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/opsawg/v5_soRRIRHyrNw24l2pMWHegHeg>
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: Tue, 04 Dec 2018 16:02:54 -0000

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-community/
>>
>>
>>
>>         ----------------------------------------------------------------------
>>         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
>