Export of BGP Community Information in IP Flow Information Export (IPFIX)
draft-ietf-opsawg-ipfix-bgp-community-12

Note: This ballot was opened for revision 10 and is now closed.

Ignas Bagdonas Yes

Deborah Brungard No Objection

(Ben Campbell) No Objection

Comment (2018-12-05 for -11)
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?

Alissa Cooper No Objection

Comment (2018-12-04 for -11)
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

(Spencer Dawkins) No Objection

Benjamin Kaduk No Objection

Suresh Krishnan No Objection

Warren Kumari No Objection

Mirja Kühlewind No Objection

Comment (2018-11-30 for -11)
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!

Alexey Melnikov No Objection

Alvaro Retana No Objection

Martin Vigoureux No Objection

Comment (2018-12-04 for -11)
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.