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

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