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 <mailto:j...@joelhalpern.com>
*Date:* 2018-02-12 00:37
*To:* 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@ietf.org <mailto:opsawg@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-...@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
