Early Review of draft-ietf-opsawg-ipfix-bgp-community-06
|Requested rev.||04 (document currently at 12)|
|Team||Routing Area Directorate (rtgdir)|
|Requested by||Tianran Zhou|
Opsdir Telechat review of -10 by Al Morton (diff)
Genart Early review of -04 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 (diff)
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.||06 (document currently at 12)|
|Review result||Not Ready|
|Draft last updated||2018-04-13|
This is both a gen-art re-review and a routing directorate requested review. The revisions from draft-04 to -06 show some improvement. However, I still have serious problems with this work. The primary problem is that this seems to violate the designed work distribution in the IPFIX architecture. The draft itself notes that the correlation requested could be done in the collector. Which is where correlation is designed to be done. Instead, it puts a significant new processing load on the router that is delivering the IPFIX information. For example, if one delivers IPFIX from the router data plane, one either has to modify the router architecture to include additional complex computed information in the data plane architecture (a bad place to add complexity) or one has to give up and move all the information through the control plane. And even the control plane likely has to add complexity to its RIB logic, as it has to move additional information from BGP to the common structures. The secondary problem is that this additional work is justified for the router by the claim that the unusual usage of applying community tags for geographical location of customers is a common practice. It is a legal practice. And I presume it is done somewhere or the authors would not be asking for it. But it is not common. In short, since even the draft admits that this is not needed, I recommend against publishing this document as an RFC.