Re: [OPSAWG] Mirja Kühlewind's No Objection on draft-ietf-opsawg-ipfix-bgp-community-11: (with COMMENT)
Thanks. Much better! > Am 06.12.2018 um 15:08 schrieb Spencer Dawkins at IETF > : > > > > On Thu, Dec 6, 2018 at 7:18 AM Stewart Bryant > 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:j...@joelhalpern.com] > >> Sent: Wednesday, December 05, 2018 12:03 AM > >> To: Spencer Dawkins at IETF ; Stewart > >> Bryant > >> Cc: opsawg-cha...@ietf.org; opsawg@ietf.org; Mirja Kuehlewind > >> ; IESG ; > >> draft-ietf-opsawg-ipfix-bgp-commun...@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 > >>> mailto:stewart.bry...@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 > mailto:i...@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
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 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:j...@joelhalpern.com] > >> Sent: Wednesday, December 05, 2018 12:03 AM > >> To: Spencer Dawkins at IETF ; Stewart > >> Bryant > >> Cc: opsawg-cha...@ietf.org; opsawg@ietf.org; Mirja Kuehlewind > >> ; IESG ; > >> draft-ietf-opsawg-ipfix-bgp-commun...@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 > >>> mailto:stewart.bry...@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 > mailto:i...@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
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:j...@joelhalpern.com] Sent: Wednesday, December 05, 2018 12:03 AM To: Spencer Dawkins at IETF ; Stewart Bryant Cc: opsawg-cha...@ietf.org; opsawg@ietf.org; Mirja Kuehlewind ; IESG ; draft-ietf-opsawg-ipfix-bgp-commun...@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 mailto:stewart.bry...@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 mailto:i...@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 mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] Ben Campbell's No Objection on draft-ietf-opsawg-ipfix-bgp-community-11: (with COMMENT)
Hi Ben, Thanks for your review and comments. We will fix the boilerplate in next version. As for the security considerations, we will discuss among coauthors and come back to you. Best regards, Jie > -Original Message- > From: Ben Campbell [mailto:b...@nostrum.com] > Sent: Thursday, December 06, 2018 1:14 PM > To: The IESG > Cc: draft-ietf-opsawg-ipfix-bgp-commun...@ietf.org; Tianran Zhou > ; opsawg-cha...@ietf.org; Tianran Zhou > ; opsawg@ietf.org > Subject: Ben Campbell's No Objection on > draft-ietf-opsawg-ipfix-bgp-community-11: (with COMMENT) > > Ben Campbell 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: > -- > > Please expand IPFIX in the abstract. > > §2: Is there a reason not to use the new boilerplate from RFC 8174? > > §8: > - "does not directly introduce any new security issues" > What does "directly" mean in context? Should we be concerned about indirectly > introduced issues? > > -2nd paragraph: I am skeptical of a claim that, because private information > might be available from other vectors, a mechanism has not introduced new > privacy issues. Is there no possibility that someone who had not deduced > privacy-sensitive information by the other means could now get it via this > mechanism? > ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] Alissa Cooper's No Objection on draft-ietf-opsawg-ipfix-bgp-community-11: (with COMMENT)
Hi Alissa, Thanks for your review and comments. We will correct the improper normative language in section 7 in next version. As for the security considerations, we will discuss among coauthors and come back to you. Best regards, Jie > -Original Message- > From: Alissa Cooper [mailto:ali...@cooperw.in] > Sent: Wednesday, December 05, 2018 10:22 AM > To: The IESG > Cc: draft-ietf-opsawg-ipfix-bgp-commun...@ietf.org; Tianran Zhou > ; opsawg-cha...@ietf.org; Tianran Zhou > ; opsawg@ietf.org > Subject: Alissa Cooper's No Objection on > draft-ietf-opsawg-ipfix-bgp-community-11: (with COMMENT) > > Alissa Cooper 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: > -- > > Section 7: > > "BGP speakers that support the extended message SHOULD be careful to >export the BGP communities in the IPFIX message properly, so that >they only convey as many communities as possible in the IPFIX >message. The Collector which receives an IPFIX message with maximum >length and BGP communities contained in its data set SHOULD be aware >that the BGP communities may be truncated due to limited message >space." > > This uses normative language improperly. "SHOULD be careful" and "SHOULD > be aware" are not actionable by implementations. It seems like in the first > case > this is trying to convey something more like "SHOULD only convey as many > communities as possible without exceeding the 65536-byte limit of an IPFIX > message." The second one seems like it should not be a normative > recommendation. > > Section 8: > > "This document itself does not directly introduce any new security issues." > > I question whether this is true. The motivation for the document describes the > use of BGP communities in IPFIX as inputs to, e.g., traffic optimization > applications. Given that there are known problems associated with the > integrity and authenticity of BGP communities (e.g., [1]), couldn't the > propagation of false BGP communities to these other applications cause the > applications to misbehave in ways above and beyond whatever damage the > false communities do to the operation of BGP itself? > > [1] > https://datatracker.ietf.org/meeting/103/materials/slides-103-grow-bgp-com > munities-spread-their-wings-01 > ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
