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 ; Dongjie (Jimmy)
> ; gen-...@ietf.org
> Cc: draft-ietf-opsawg-ipfix-bgp-community@ietf.org; opsawg
> 
> 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 
> > *Date:* 2018-02-28 10:13
> > *To:* li zhenqiang ; Dongjie
> > (Jimmy) ; gen-...@ietf.org
> > 
> > *CC:* draft-ietf-opsawg-ipfix-bgp-community@ietf.org
> > ; opsawg
> > 
> > *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 reflected in implementation.
> > In this case, given that what is proposed is a completely different use
> > of the BGP communities, I think at least more clarity that this is only
> > expected to be used for communities that match the purpose, and of
> how
> > and why the vendors would implement the router-side logic.
> > To get back to the points I made in the review:
> > 1) The document needs to be much clearer that 

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

[Randy Bush]

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

to help readers, perhaps this flavor explanation belongs in the
introduction, or a rationale section?

randy

___
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

[Ignas Bagdonas]

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

*From:* Joel Halpern Direct 
*Date:* 2018-02-28 23:19
*To:* li zhenqiang ; Dongjie
(Jimmy) ; gen-...@ietf.org

*CC:* draft-ietf-opsawg-ipfix-bgp-community@ietf.org
;
opsawg 
*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
>