Early Review of draft-ietf-opsawg-ipfix-bgp-community-04
|Requested rev.||04 (document currently at 11)|
|Team||General Area Review Team (Gen-ART) (genart)|
|Requested by||Tianran Zhou|
Opsdir Telechat review of -10 by Al Morton (diff)
Rtgdir Early review of -06 by Joel Halpern (diff)
Secdir Last Call review of -07 by Shawn Emery (diff)
Genart Last Call review of -07 by Joel Halpern (diff)
Opsdir Last Call review of -08 by Al Morton (diff)
Genart Telechat review of -11 by Joel Halpern
This document is in working group LC. Not many review comments received. So we would like to request review from related DIRs to help the quality of the draft. Thank you.
|Reviewed rev.||04 (document currently at 11)|
|Review result||Not Ready|
|Draft last updated||2018-02-09|
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.