Export of BGP Community Information in IP Flow Information Export (IPFIX)
draft-ietf-opsawg-ipfix-bgp-community-12
Yes
(Ignas Bagdonas)
No Objection
Warren Kumari
(Alexey Melnikov)
(Alvaro Retana)
(Benjamin Kaduk)
(Deborah Brungard)
(Spencer Dawkins)
(Suresh Krishnan)
Note: This ballot was opened for revision 10 and is now closed.
Warren Kumari
No Objection
Ignas Bagdonas Former IESG member
Yes
Yes
(for -10)
Unknown
Alexey Melnikov Former IESG member
No Objection
No Objection
(for -11)
Not sent
Alissa Cooper Former IESG member
No Objection
No Objection
(2018-12-04 for -11)
Sent
Section 7: "BGP speakers that support the extended message SHOULD be careful to export the BGP communities in the IPFIX message properly, so that they only convey as many communities as possible in the IPFIX message. The Collector which receives an IPFIX message with maximum length and BGP communities contained in its data set SHOULD be aware that the BGP communities may be truncated due to limited message space." This uses normative language improperly. "SHOULD be careful" and "SHOULD be aware" are not actionable by implementations. It seems like in the first case this is trying to convey something more like "SHOULD only convey as many communities as possible without exceeding the 65536-byte limit of an IPFIX message." The second one seems like it should not be a normative recommendation. Section 8: "This document itself does not directly introduce any new security issues." I question whether this is true. The motivation for the document describes the use of BGP communities in IPFIX as inputs to, e.g., traffic optimization applications. Given that there are known problems associated with the integrity and authenticity of BGP communities (e.g., [1]), couldn't the propagation of false BGP communities to these other applications cause the applications to misbehave in ways above and beyond whatever damage the false communities do to the operation of BGP itself? [1] https://datatracker.ietf.org/meeting/103/materials/slides-103-grow-bgp-communities-spread-their-wings-01
Alvaro Retana Former IESG member
No Objection
No Objection
(for -11)
Not sent
Ben Campbell Former IESG member
No Objection
No Objection
(2018-12-05 for -11)
Sent
Please expand IPFIX in the abstract. §2: Is there a reason not to use the new boilerplate from RFC 8174? §8: - "does not directly introduce any new security issues" What does "directly" mean in context? Should we be concerned about indirectly introduced issues? -2nd paragraph: I am skeptical of a claim that, because private information might be available from other vectors, a mechanism has not introduced new privacy issues. Is there no possibility that someone who had not deduced privacy-sensitive information by the other means could now get it via this mechanism?
Benjamin Kaduk Former IESG member
No Objection
No Objection
(for -11)
Not sent
Deborah Brungard Former IESG member
No Objection
No Objection
(for -11)
Not sent
Martin Vigoureux Former IESG member
No Objection
No Objection
(2018-12-04 for -11)
Sent
Hello, thank you for this document. I only have a couple of minor comments: without needing to run the heavy BGP itself. I'm not sure about the need to qualify BGP as "heavy". To understand the traffic generated by different kinds of customers, from different geographical or topological regions, by different kinds of customers in different regions, It looks to me that "by different kinds of customers in different regions," is redundant here. [RFC1997] defines the BGP Communities attribute, called BGP Standard Community in this document, which describes a group of routes sharing some common properties. BGP Standard Community is treated as 32 bit value as stated in [RFC1997]. I don't understand the rationale for giving a special name ("standard") to this attribute. On top of that it could give the impression that the other attributes are not standard.
Mirja Kühlewind Former IESG member
No Objection
No Objection
(2018-11-30 for -11)
Sent
One comment on section 1: "For example, they can shift some flows from congested links to low utilized links through an SDN controller or PCE [RFC4655]." I'm not aware that ipfix information is commonly used for dynamic traffic adaptation and I'm not sure that is recommendable. Can you maybe choose a different example. E.g use of IPFIX for troubleshooting or more generally network monitoring? Thanks!
Spencer Dawkins Former IESG member
No Objection
No Objection
(for -11)
Not sent
Suresh Krishnan Former IESG member
No Objection
No Objection
(for -11)
Not sent