Re: [OPSAWG] Ben Campbell's No Objection on draft-ietf-opsawg-ipfix-bgp-community-11: (with COMMENT)

[Dongjie (Jimmy)]

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)

[Dongjie (Jimmy)]

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

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

[Dongjie (Jimmy)]

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

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] Genart telechat review of draft-ietf-opsawg-ipfix-bgp-community-11

[Dongjie (Jimmy)]

Hi Joel, 

Thanks for your review. 

We will replace the references in abstract with text in next version. 

Best regards,
Jie

> -Original Message-
> From: Joel Halpern [mailto:j...@joelhalpern.com]
> Sent: Friday, November 30, 2018 4:38 AM
> To: gen-...@ietf.org
> Cc: draft-ietf-opsawg-ipfix-bgp-community@ietf.org; i...@ietf.org;
> opsawg@ietf.org
> Subject: Genart telechat review of draft-ietf-opsawg-ipfix-bgp-community-11
> 
> Reviewer: Joel Halpern
> Review result: Ready
> 
> I am the assigned Gen-ART reviewer for this draft. The General Area Review
> Team (Gen-ART) reviews all IETF documents being processed by the IESG for
> the IETF Chair. Please wait for direction from your document shepherd or AD
> before posting a new version of the draft.
> 
> For more information, please see the FAQ at
> 
> .
> 
> Document: draft-ietf-opsawg-ipfix-bgp-community-11
> Reviewer: Joel Halpern
> Review Date: 2018-11-29
> IETF LC End Date: 2018-09-24
> IESG Telechat date: 2018-12-06
> 
> Summary: This document is ready for publication as a Proposed Standard RFC
> 
> Major issues: N/A
> 
> Minor issues: N/A
> 
> Nits/editorial comments:
> As id-nits notes, references should not be included in the abstract.
> 

___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

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

[Dongjie (Jimmy)]

Hi Mirja, 

Thanks a lot for your review and comments. 

How about we replace that sentence 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."

Best regards,
Jie

> -Original Message-
> From: Mirja Kühlewind [mailto:i...@kuehlewind.net]
> Sent: Saturday, December 01, 2018 12:13 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: Mirja Kühlewind's No Objection on
> draft-ietf-opsawg-ipfix-bgp-community-11: (with COMMENT)
> 
> 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. Can you maybe choose a
> different example. E.g use of IPFIX for troubleshooting or more generally
> network monitoring? Thanks!
> 

___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] Rtgdir early review of draft-ietf-opsawg-ipfix-bgp-community-06

[Dongjie (Jimmy)]

Hi Joel, 

Thanks a lot for your review comments. 

Regarding your first problem, I don't think this draft introduces "significant 
new processing load on the router", as similar processing has already been done 
for the BGP AS number and BGP-nexthop based traffic collection. As described in 
the draft, the BGP-community based traffic collection is done by BGP lookup and 
correlating the BGP community with the flow data to be exported. Whether it is 
done in data plane or control plane is implementation specific and IMO does not 
belong to a IETF document. 

As for your second problem, as many operators have pointed out, it is a common 
case to use BGP communities to represent geo locations at various 
granularities. So we need to provide them the tools to meet their requirements. 
Standardizing the IEs for BGP community is a good start.

Best regards,
Jie

> -Original Message-
> From: Joel Halpern [mailto:j...@joelhalpern.com]
> Sent: Friday, April 13, 2018 10:44 PM
> To: rtg-...@ietf.org
> Cc: draft-ietf-opsawg-ipfix-bgp-community@ietf.org; i...@ietf.org;
> opsawg@ietf.org; gen-...@ietf.org
> Subject: Rtgdir early review of draft-ietf-opsawg-ipfix-bgp-community-06
> 
> Reviewer: Joel Halpern
> Review result: Not Ready
> 
> This is both a gen-art re-review and a routing directorate requested review.
> 
> The revisions from draft-04 to -06 show some improvement.  However, I still
> have serious problems with this work.
> 
> The primary problem is that this seems to violate the designed work
> distribution in the IPFIX architecture.  The draft itself notes that the
> correlation requested could be done in the collector.  Which is where
> correlation is designed to be done.  Instead, it puts a significant new
> processing load on the router that is delivering the IPFIX information.  For
> example, if one delivers IPFIX from the router data plane, one either has to
> modify the router architecture to include additional complex computed
> information in the data plane architecture (a bad place to add complexity) or
> one has to give up and move all the information through the control plane.
> And even the control plane likely has to add complexity to its RIB logic, as 
> it has
> to move additional information from BGP to the common structures.
> 
> The secondary problem is that this additional work is justified for the 
> router by
> the claim that the unusual usage of applying community tags for geographical
> location of customers is a common practice.  It is a legal practice.  And I
> presume it is done somewhere or the authors would not be asking for it.   But
> it is not common.
> 
> In short, since even the draft admits that this is not needed, I recommend
> against publishing this document as an RFC.

___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] Genart early review of draft-ietf-opsawg-ipfix-bgp-community-04

[Dongjie (Jimmy)]

Hi Ignas,

Thanks a lot for the suggestion.

The authors will work together to resolve the comments received and provide 
further clarification on the operational aspects.

Also we will try to collect more feedbacks from the operator communities and 
incorporate them into the next revision.

Some operators have joined the recent discussion on this list and gave valuable 
feedbacks (many thanks!). More feedbacks are always welcome.

Best regards,
Jie

From: Ignas Bagdonas [mailto:ibagd...@gmail.com]
Sent: Friday, March 02, 2018 12:59 AM
To: li zhenqiang <li_zhenqi...@hotmail.com>; Joel Halpern Direct 
<jmh.dir...@joelhalpern.com>; Dongjie (Jimmy) <jie.d...@huawei.com>; 
gen-...@ietf.org
Cc: draft-ietf-opsawg-ipfix-bgp-community@ietf.org; opsawg <opsawg@ietf.org>
Subject: Re: Genart early review of draft-ietf-opsawg-ipfix-bgp-community-04


Dear authors of draft-ietf-opsawg-ipfix-bgp-community document,

This document is a WG document, and you have received community feedback on it 
stating that there are unclear aspects and questionable approaches described in 
it. Please address the comments to have the document cover the concerns raised.

The comments specifically on the operational aspects of how this proposed 
mechanism is expected to be used tend to repeat - this seems to be an area that 
is not clear to the community. Please focus on addressing it in substantial 
detail.

It would be beneficial to bring this document to the attention of the 
operations community too (as any other document - there is nothing specific to 
your document in this regard). Try to talk to Apricot, RIPE, NANOG, regional 
NOGs communities to sense the need and the details of this proposed mechanism, 
and then incorporate the feedback received there to the document.

Thank you.

Ignas



On 01/03/2018 15:39, li zhenqiang wrote:
Hi Joel,

Thank you for your prompt reply and sorry for the confusing words.

Let me try to explain it clearly in simple words again. BGP community 
attributes, such as standard community, extended community, large community, 
have already  been defined by IDR working group. Operaters use those already 
defined BGP communities in their field networks with their own plans to 
represent the groups of customers, peers, geographical and topological regions. 
For example, using standard community XXX to represent fixed line customers,  
YYY for WLAN customers, and ZZZ for mobile customers, using community AAA for 
state L, BBB for state M, CCC for state N. Now we want to know the traffic 
generated by the WLAN customer in state N. So we need the community information 
related to the traffic flow exported by IPFIX. If IPFIX can export BGP 
community information using the IEs introduced in my doc, the  IPFIX collector, 
without running BGP protocol, can easily figure up the traffic in BGP community 
granularity, i.e. the traffic from different customers, from different states, 
from different customers in different states, and so on.

Best Regards,
Zhenqiang Li

li_zhenqi...@hotmail.com<mailto:li_zhenqi...@hotmail.com>

From: Joel Halpern Direct<mailto:jmh.dir...@joelhalpern.com>
Date: 2018-02-28 23:19
To: li zhenqiang<mailto:li_zhenqi...@hotmail.com>; Dongjie 
(Jimmy)<mailto:jie.d...@huawei.com>; gen-...@ietf.org<mailto:gen-...@ietf.org>
CC: 
draft-ietf-opsawg-ipfix-bgp-community@ietf.org<mailto:draft-ietf-opsawg-ipfix-bgp-community@ietf.org>;
 opsawg<mailto:opsawg@ietf.org>
Subject: Re: Genart early review of draft-ietf-opsawg-ipfix-bgp-community-04
I am having trouble reconciling two of your comments.
In you rlast email you said that this is for "planed communities
represent the groups of customers peers an geographical and topological
related information".  Planned communities is presumably a new behavior,
not existing behavior.

In this email you say that these are "already defined BGP communities".

You reference RFC 4384, which talks about several kinds of communities.
maybe you intend the regional or national communities mentioned as being
possible, but not defined, in that document.  This document's
descriptions do not align well enough with RFC 4384 for me to say.

Let's be clear.  The working group asked for an early review.  The WG
now has my review, indicating that this document is unclear in multiple
regards and could use improvement.

It is now up to the WG and the chairs.
Yours,
Joel

On 2/28/18 6:22 AM, li zhenqiang wrote:
> Hi Joel,
>
> This is not for one operator, instead it is a common practice. Please
> refer to RFC4384 and comments from Thomas who are from Swisscom.
>
> One clarification for this doc is it is not to introduce any new BGP
> communities but to report the already defined BGP communities related to
> a traffic flow through IPFIX, thus the IPFIX collector can analyze the
> traffic in BGP community granularity without run

Re: [OPSAWG] Genart early review of draft-ietf-opsawg-ipfix-bgp-community-04

[Dongjie (Jimmy)]

Hi Joel, 

Thanks a lot for your comments and discussion. 

There may be some misunderstanding about the description of the targeted use 
cases of this draft, in next revision more texts will be added to clarify this. 
We will also try to resolve the other comments you raised. 

Just some clarification about BGP communities: 

Except for a few well-known BGP communities, the meaning and behavior of most 
BGP communities are not standardized, which gives operators the flexibility to 
use them for many different purposes. RFC4384 describes one use case of BGP 
communities, RFC8195 gives some examples about the application of BGP large 
communities, and there are also many use cases which are not documented in 
RFCs. 

One typical usage of BGP communities is to represent geographical or customer 
information, this is also described in RFC 8195 for the newly defined large 
communities. In such use case, it is useful for operators to collect the 
traffic statistics based on BGP communities, as this provides the aggregation 
of traffic flows with reasonable granularity.

Best regards,
Jie

> -Original Message-
> From: Joel Halpern Direct [mailto:jmh.dir...@joelhalpern.com]
> Sent: Wednesday, February 28, 2018 11:19 PM
> To: li zhenqiang <li_zhenqi...@hotmail.com>; Dongjie (Jimmy)
> <jie.d...@huawei.com>; gen-...@ietf.org
> Cc: draft-ietf-opsawg-ipfix-bgp-community@ietf.org; opsawg
> <opsawg@ietf.org>
> Subject: Re: Genart early review of draft-ietf-opsawg-ipfix-bgp-community-04
> 
> I am having trouble reconciling two of your comments.
> In you rlast email you said that this is for "planed communities represent the
> groups of customers peers an geographical and topological related
> information".  Planned communities is presumably a new behavior, not
> existing behavior.
> 
> In this email you say that these are "already defined BGP communities".
> 
> You reference RFC 4384, which talks about several kinds of communities.
> maybe you intend the regional or national communities mentioned as being
> possible, but not defined, in that document.  This document's descriptions do
> not align well enough with RFC 4384 for me to say.
> 
> Let's be clear.  The working group asked for an early review.  The WG now
> has my review, indicating that this document is unclear in multiple regards 
> and
> could use improvement.
> 
> It is now up to the WG and the chairs.
> Yours,
> Joel
> 
> On 2/28/18 6:22 AM, li zhenqiang wrote:
> > Hi Joel,
> >
> > This is not for one operator, instead it is a common practice. Please
> > refer to RFC4384 and comments from Thomas who are from Swisscom.
> >
> > One clarification for this doc is it is not to introduce any new BGP
> > communities but to report the already defined BGP communities related
> > to a traffic flow through IPFIX, thus the IPFIX collector can analyze
> > the traffic in BGP community granularity without running BGP protocol.
> >
> > BGP community is a transitive attibute, thus the exporter can report
> > all the communities carried in the matching route entry, unless some
> > BGP communities are filtered by some routers.
> >
> > Sure I can add some text in the doc to say the proper processing of
> > the exporter, something like what I said in the previous mail, do you
> > think it is ok and enough?
> >   When the exporter, i.e. router, receives the templete to report the
> > communities, the exporter gets the information through BGP lookup
> > using the corresponding source or destination IP of a traffic flow.
> >
> > Thank you for your comments.
> >
> > Best Regards,
> > Zhenqiang Li
> > --
> > --
> > li_zhenqi...@hotmail.com
> >
> > *From:* Joel M. Halpern <mailto:j...@joelhalpern.com>
> > *Date:* 2018-02-28 10:13
> > *To:* li zhenqiang <mailto:li_zhenqi...@hotmail.com>; Dongjie
> > (Jimmy) <mailto:jie.d...@huawei.com>; gen-...@ietf.org
> > <mailto:gen-...@ietf.org>
> > *CC:* draft-ietf-opsawg-ipfix-bgp-community@ietf.org
> > <mailto:draft-ietf-opsawg-ipfix-bgp-community@ietf.org>; opsawg
> > <mailto:opsawg@ietf.org>
> > *Subject:* Re: Genart early review of
> > draft-ietf-opsawg-ipfix-bgp-community-04
> > Is this for one operator (still important, but not necessarily for
> > standardization) or are there several operators who have expressed
> > interest in this?
> > Yes, we do proactive standards.  But the IDR group, for example,
> tends
> > to be very careful to see if interest is refl

Re: [OPSAWG] [Idr] FW: WG LC for draft-ietf-opsawg-ipfix-bgp-community

[Dongjie (Jimmy)]

Hi Jeff, 

Thanks a lot for your comments and recommendation, which will be reflected in 
next revision of this document. 

Best regards,
Jie

> -Original Message-
> From: Jeffrey Haas [mailto:jh...@pfrc.org]
> Sent: Sunday, February 11, 2018 11:51 PM
> To: Dongjie (Jimmy) <jie.d...@huawei.com>; opsawg@ietf.org
> Cc: i...@ietf.org; idr-cha...@ietf.org
> Subject: Re: [Idr] FW: WG LC for draft-ietf-opsawg-ipfix-bgp-community
> 
> Authors,
> 
> Thanks for accommodating my prior comments on this draft.
> 
> I have one final issue to raise with the draft.  The information elements for
> extended community and large community by nature of their size are of type
> octetArray.  The draft correctly notes the expected size of each of these
> elements; 8 and 12 respectively.
> 
> The draft provides no guidance for when each of these elements is NOT of the
> expected size.
> 
> My recommendation is a small paragraph to the Operational Considerations
> section:
> "In the event that the bgpExtendedCommunity or bgpLargeCommunity
> Elements are not of their expected sizes (8 and 12 octets, respectively), the
> receiver SHOULD ignore them."
> 
> I'm not savvy with the general language wrapped around receiver procedure
> for IPFIX these days, so a bit of additional verbiage might be expected for
> appropriate draft boilerplate.  However, this is intended to protect
> implementations using BGP logic from calling their parsing routines with 
> invalid
> lengths.
> 
> -- Jeff
> 
> On Mon, Jan 22, 2018 at 08:26:52AM +, Dongjie (Jimmy) wrote:
> > Hi,
> >
> > Currently this BGP related draft is in WG LC in OPSAWG, their chairs suggest
> IDR to take a look at it, please send comments (if any) to OPSAWG mailing 
> list.
> >
> > Best regards,
> > Jie
> >
> > -Original Message-
> > From: Tianran Zhou
> > Sent: Thursday, January 18, 2018 11:31 AM
> > To: 'idr-cha...@ietf.org'
> > Cc: 'opsawg-cha...@ietf.org'
> > Subject: FW: WG LC for draft-ietf-opsawg-ipfix-bgp-community
> >
> > Dear IDR Chairs,
> >
> > The OPSAWG started a 2 week WG LC for the following draft:
> > https://tools.ietf.org/html/draft-ietf-opsawg-ipfix-bgp-community-04
> >
> > We got many comments and suggestions from IDR when this work is adopted.
> Now the authors believe the document is ready.
> > We really appreciate more comments from this working group.
> >
> > Could you please help to forward this information to the IDR mailing list?
> >
> > Thanks,
> > Tianran, as OPSAWG co-chair
> >
> >
> > -Original Message-
> > From: OPSAWG [mailto:opsawg-boun...@ietf.org] On Behalf Of Tianran
> > Zhou
> > Sent: Thursday, January 18, 2018 11:07 AM
> > To: opsawg@ietf.org
> > Cc: opsawg-cha...@ietf.org
> > Subject: [OPSAWG] WG LC for draft-ietf-opsawg-ipfix-bgp-community
> >
> > Hi WG,
> >
> > The authors of draft-ietf-opsawg-ipfix-bgp-community have posted the latest
> drafts to the mailing list, and believe that the document is ready for LC.
> >
> > This starts a 2 week WG LC on
> > https://tools.ietf.org/html/draft-ietf-opsawg-ipfix-bgp-community-04
> >
> > Please read the above draft and send any issues, comments, or corrections to
> this mailing list.
> > All supports and concerns are welcome and helpful for the authors.
> >
> > We are also looking for a document shepherd, best with operator background,
> to help the following procedures.
> >
> > The WG LC will close on Feb 1, 2018.
> > Authors please indicate whether you are aware of any IPR for the draft.
> >
> > Thanks,
> > Tianran, as OPSAWG co-chair
> >
> > ___
> > OPSAWG mailing list
> > OPSAWG@ietf.org
> > https://www.ietf.org/mailman/listinfo/opsawg
> >
> > ___
> > Idr mailing list
> > i...@ietf.org
> > https://www.ietf.org/mailman/listinfo/idr

___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] Genart early review of draft-ietf-opsawg-ipfix-bgp-community-04

[Dongjie (Jimmy)]

Hi Joel, 

Thanks for your review comments. Please see my replies inline: 

> -Original Message-
> From: Joel Halpern [mailto:j...@joelhalpern.com]
> Sent: Saturday, February 10, 2018 1:27 AM
> To: gen-...@ietf.org
> Cc: draft-ietf-opsawg-ipfix-bgp-community@ietf.org; opsawg@ietf.org
> Subject: Genart early review of draft-ietf-opsawg-ipfix-bgp-community-04
> 
> Reviewer: Joel Halpern
> Review result: Not Ready
> 
> This is an early gen-art review of draft-ietf-opsawg-ipfix-bgp-04.
> 
> The document is clear about what it is trying to do, and readable.  It is not
> clear about how it expects this to actually work.
> 
> However, I find the underlying concept confusing.
> 1) BGP Communities may sometimes represent subsets of traffic.  But usually
> they represent tagging intended to influence routing which is only indirectly
> related to meaningful subsets of traffic for TE purposes.  One may be able to
> make an argument that this could better enable monitoring the effects of some
> BGP communities.  But the draft does not make that argument. 

This depends on how the BGP communities are used by the operators. Except some 
well-known communities, BGP communities are used in a customized manner. In 
some cases, BGP communities indicate the source and destination information of 
a group of traffic flows. These are the major case this document is focusing 
on, as it would be helpful for operator to collect the traffic statistics based 
on BGP communities. Using BGP communities to influence routing is another 
popular use case. In that case, it may also be helpful to collect traffic 
statistic information related to the BGP communities, while the purpose may not 
be just for TE. 

2) It is
> unclear what this actually expects the router to do in generating this
> information.
> Reading between the lines, it seems that what is desired is for the router
> control process to go through the IPFIX collected information before it is
> exported, and add BGP community tags to the export information.
> (Generating such information directly from the forwarding plane would place
> significant load on the forwarding representation and processing, and on the
> control logic to generate FIB information.)  Given that off-line BGP 
> information
> collection is a common practice, and that such information is common across
> the AS, it would actually seem simpler to perform such processing and
> aggregation offline rather than in the router.

The behavior of a router would be similar to its behavior with the existing BGP 
relevant IEs, e.g. bgpSourceAsNumber, bgpDestinationAsNumber, 
bgpNextHopIPv4Address, etc. Basically this is the aggregated traffic 
information collection model, in which the router aggregates the collected 
traffic information based on the IEs specified in the template, so that it can 
export much less information to the collector without losing the information 
the collector really cares about. Exporting aggregated traffic statistics has 
been widely used in the networks.
 
Note that the purpose of this mechanism is to export the aggregated traffic 
statistics information at the granularity specified by BGP communities, while 
BMP can used to collect the detailed information of BGP RIBs and BGP events, 
IMO they are designed for different purposes. Although it is possible to export 
all the non-aggregated traffic information to the collector, and let the 
collector to correlate them with the BGP communities, this can bring heavy 
burden to both the exporter and the collector.

> 
> If the IDR working group has not been consulted about this, I would strongly
> recommend working with them as to whether this is actually useful information
> to collect, and how and where to collect it. If the IDR working group does not
> consider important to work on this, then that gives you useful information in
> and of itself.

The IDR WG has been notified about the LC of this document, so far there is no 
objection received from them. We would like to encourage IDR people to review 
and give feedbacks to help improve this document. Whether the new IEs are 
useful or not should be determined in the OPSAWG.

Best regards,
Jie
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] WG LC for draft-ietf-opsawg-ipfix-bgp-community

[Dongjie (Jimmy)]

I'm not aware of any IPR related to this document. 

-Jie

> -Original Message-
> From: OPSAWG [mailto:opsawg-boun...@ietf.org] On Behalf Of Dongjie (Jimmy)
> Sent: Monday, January 22, 2018 3:01 PM
> To: Tianran Zhou <zhoutian...@huawei.com>; opsawg@ietf.org
> Cc: opsawg-cha...@ietf.org
> Subject: Re: [OPSAWG] WG LC for draft-ietf-opsawg-ipfix-bgp-community
> 
> Hi,
> 
> I (as coauthor) support the publication of this document.
> 
> Best regards,
> Jie
> 
> > -Original Message-
> > From: OPSAWG [mailto:opsawg-boun...@ietf.org] On Behalf Of Tianran
> > Zhou
> > Sent: Thursday, January 18, 2018 11:07 AM
> > To: opsawg@ietf.org
> > Cc: opsawg-cha...@ietf.org
> > Subject: [OPSAWG] WG LC for draft-ietf-opsawg-ipfix-bgp-community
> >
> > Hi WG,
> >
> > The authors of draft-ietf-opsawg-ipfix-bgp-community have posted the
> > latest drafts to the mailing list, and believe that the document is ready 
> > for LC.
> >
> > This starts a 2 week WG LC on
> > https://tools.ietf.org/html/draft-ietf-opsawg-ipfix-bgp-community-04
> >
> > Please read the above draft and send any issues, comments, or
> > corrections to this mailing list.
> > All supports and concerns are welcome and helpful for the authors.
> >
> > We are also looking for a document shepherd, best with operator
> > background, to help the following procedures.
> >
> > The WG LC will close on Feb 1, 2018.
> > Authors please indicate whether you are aware of any IPR for the draft.
> >
> > Thanks,
> > Tianran, as OPSAWG co-chair
> >
> > ___
> > 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

___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] WG LC for draft-ietf-opsawg-ipfix-bgp-community

[Dongjie (Jimmy)]

Hi, 

I (as coauthor) support the publication of this document.

Best regards,
Jie

> -Original Message-
> From: OPSAWG [mailto:opsawg-boun...@ietf.org] On Behalf Of Tianran Zhou
> Sent: Thursday, January 18, 2018 11:07 AM
> To: opsawg@ietf.org
> Cc: opsawg-cha...@ietf.org
> Subject: [OPSAWG] WG LC for draft-ietf-opsawg-ipfix-bgp-community
> 
> Hi WG,
> 
> The authors of draft-ietf-opsawg-ipfix-bgp-community have posted the latest
> drafts to the mailing list, and believe that the document is ready for LC.
> 
> This starts a 2 week WG LC on
> https://tools.ietf.org/html/draft-ietf-opsawg-ipfix-bgp-community-04
> 
> Please read the above draft and send any issues, comments, or corrections to
> this mailing list.
> All supports and concerns are welcome and helpful for the authors.
> 
> We are also looking for a document shepherd, best with operator background, to
> help the following procedures.
> 
> The WG LC will close on Feb 1, 2018.
> Authors please indicate whether you are aware of any IPR for the draft.
> 
> Thanks,
> Tianran, as OPSAWG co-chair
> 
> ___
> 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