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:[email protected]]
Sent: Saturday, February 10, 2018 1:27 AM
To: [email protected]
Cc: [email protected]; [email protected]
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
[email protected]
https://www.ietf.org/mailman/listinfo/opsawg
