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

[Ignas Bagdonas <[e-mail]>]

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
> ------------------------------------------------------------------------
> [e-mail]
>
>     *From:* Joel Halpern Direct <mailto:[e-mail]>
>     *Date:* 2018-02-28 23:19
>     *To:* li zhenqiang <mailto:[e-mail]>; Dongjie
>     (Jimmy) <mailto:[e-mail]>; [e-mail]
>     <mailto:[e-mail]>
>     *CC:* [e-mail]
>     <mailto:[e-mail]>;
>     opsawg <mailto:[e-mail]>
>     *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
>     >
>     ------------------------------------------------------------------------
>     > [e-mail]
>     >
>     >     *From:* Joel M. Halpern <mailto:[e-mail]>
>     >     *Date:* 2018-02-28 10:13
>     >     *To:* li zhenqiang <mailto:[e-mail]>; Dongjie
>     >     (Jimmy) <mailto:[e-mail]>; [e-mail]
>     >     <mailto:[e-mail]>
>     >     *CC:* [e-mail]
>     > <mailto:[e-mail]>; opsawg
>     >     <mailto:[e-mail]>
>     >     *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
>     >      >
>     >
>     ------------------------------------------------------------------------
>     >      > [e-mail]
>     >      >
>     >      >     *From:* Joel M. Halpern <mailto:[e-mail]>
>     >      >     *Date:* 2018-02-12 00:37
>     >      >     *To:* Dongjie (Jimmy) <mailto:[e-mail]>;
>     >     [e-mail]
>     >      >     <mailto:[e-mail]>
>     >      >     *CC:* [e-mail]
>     >      > <mailto:[e-mail]>;
>     >      >     [e-mail] <mailto:[e-mail]>
>     >      >     *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:[e-mail]]
>     >      >      >> Sent: Saturday, February 10, 2018 1:27 AM
>     >      >      >> To: [e-mail]
>     >      >      >> Cc:
>     [e-mail];
>     >      >     [e-mail]
>     >      >      >> 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
>     >      >      >
>     >      >
>     >
>