Skip to main content

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