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

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.

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