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

2018-03-02 Thread 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 ; Joel Halpern Direct 
; Dongjie (Jimmy) ; 
gen-art@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


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-art@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 route

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

2018-03-01 Thread 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-art@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-art@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 it is about new
> > communities whcih are expected to be defin

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

2018-03-01 Thread 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-art@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
>
---

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

2018-02-28 Thread Joel Halpern Direct 

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-art@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 it is about new
communities whcih are expected to be defined for this use.  It needs to
be clear if this is expected to be applied to communities put on by
other AS, or only to communities provided by routers of the collecting
AS.  The later leads to understandable configuration.  The former leads
to questions about hos the meaning will be known.
2) The document needs to be clear and explicit about what processing it
is expecting the router to provide, and how much configuration is
needed
to get the right things to happen.
Yours,
Joel
On 2/27/18 8:54 PM, li zhenqiang wrote:
 > Hi Joel,
 >
 > This is Zhenqiang Li from China Mobile. The purpose of this doc
is not
 > to report the well-known communities, but the operator planed
 > communities represent the groups of the customers, peers,
 > the geographical and topological related information as stated in
 > RFC4384, which is a common practice and also used in our field
network.
 >
 > 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. The
 > procedure for the exporter to get the community informaiton of a
traffic
 > flow is the same as it gets the AS information.
 >
 > Best Regards,
 > Zhenqiang Li
 >

 > li_zhenqi...@hotmail.com
 >
 > *From:* Joel M. Halpern 
 > *Date:* 2018-02-12 00:37
 > *To:* Dongjie (Jimmy)

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

2018-02-27 Thread Joel M. Halpern 
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 it is about new 
communities whcih are expected to be defined for this use.  It needs to 
be clear if this is expected to be applied to communities put on by 
other AS, or only to communities provided by routers of the collecting 
AS.  The later leads to understandable configuration.  The former leads 
to questions about hos the meaning will be known.


2) The document needs to be clear and explicit about what processing it 
is expecting the router to provide, and how much configuration is needed 
to get the right things to happen.


Yours,
Joel

On 2/27/18 8:54 PM, li zhenqiang wrote:

Hi Joel,

This is Zhenqiang Li from China Mobile. The purpose of this doc is not 
to report the well-known communities, but the operator planed 
communities represent the groups of the customers, peers, 
the geographical and topological related information as stated in 
RFC4384, which is a common practice and also used in our field network.


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. The 
procedure for the exporter to get the community informaiton of a traffic 
flow is the same as it gets the AS information.


Best Regards,
Zhenqiang Li

li_zhenqi...@hotmail.com

*From:* Joel M. Halpern 
*Date:* 2018-02-12 00:37
*To:* Dongjie (Jimmy) ; gen-art@ietf.org

*CC:* draft-ietf-opsawg-ipfix-bgp-community@ietf.org
;
ops...@ietf.org 
*Subject:* Re: Genart early review of
draft-ietf-opsawg-ipfix-bgp-community-04
This was a requested early review.  You folks can do as you deem best.
 From where I sit, it seems odd.  Most well-known communities do not
fit
the pattern of representing groups of sources or groups of destinations.
I presume the intent here is for this to be useful in some AS other
than
the one originating the communities.  Which makes it even harder to see
when it would apply.
I presume this is driven by having found that it would have helped in
some real-world situation?
I think the document would be helped by a clearer description of
when it
applies and what behavior is expected of the router (not just "the same
as that over there.")
Yours,
Joel
On 2/11/18 1:32 AM, Dongjie (Jimmy) wrote:
 > 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-art@ietf.org
 >> Cc: draft-ietf-opsawg-ipfix-bgp-community@ietf.org;
ops...@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 commu

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

2018-02-11 Thread Joel M. Halpern 

This was a requested early review.  You folks can do as you deem best.

From where I sit, it seems odd.  Most well-known communities do not fit 
the pattern of representing groups of sources or groups of destinations.
I presume the intent here is for this to be useful in some AS other than 
the one originating the communities.  Which makes it even harder to see 
when it would apply.
I presume this is driven by having found that it would have helped in 
some real-world situation?


I think the document would be helped by a clearer description of when it 
applies and what behavior is expected of the router (not just "the same 
as that over there.")


Yours,
Joel

On 2/11/18 1:32 AM, Dongjie (Jimmy) wrote:

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-art@ietf.org
Cc: draft-ietf-opsawg-ipfix-bgp-community@ietf.org; ops...@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



___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

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

2018-02-10 Thread 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-art@ietf.org
> Cc: draft-ietf-opsawg-ipfix-bgp-community@ietf.org; ops...@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
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

[Gen-art] Genart early review of draft-ietf-opsawg-ipfix-bgp-community-04

2018-02-09 Thread Joel Halpern 
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. 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.

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.


___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art