Elisa,
Note that we're not singling out IPFIX here. The forthcoming
revisions
to the syslog documents, for example, will have the following
statement
("TLS" is "TLS over TCP"):
Because syslog can generate unlimited amounts of data,
transferring this
data over UDP is generally problematic, because UDP lacks
congestion
control mechanisms. Congestion control mechanisms that respond to
congestion by reducing traffic rates and establish a degree of
fairness
between flows that share the same path are vital to the stable
operation
of the Internet [RFC2914]. This is why the syslog TLS transport
is
REQUIRED to implement and RECOMMENDED for general use.
The only environments where the syslog UDP transport MAY be used
as an
alternative to the TLS transport are managed networks, where the
network
path has been explicitly provisioned for UDP syslog traffic
through
traffic engineering mechanisms, such as rate limiting or capacity
reservations. In all other environments, the TLS transport SHOULD
be used.
I believe a similar statement for IPFIX would be appropriate.
we currently have the following statement for IPFIX/UDP:
---
UDP is useful in simple systems where an SCTP stack is not
available,
and where there is insufficient memory for TCP buffering.
However, UDP is not a reliable transport protocol, and IPFIX
messages
sent over UDP might be lost as with partially-reliable SCTP
streams.
UDP is not the recommended protocol for IPFIX and is intended for
use
in cases in which IPFIX is replacing an existing NetFlow
infrastructure, with the following properties:
o A dedicated network,
o within a single administrative domain,
o where SCTP is not available due to implementation constraints,
o and the collector is as close as possible to the exporter.
---
Would the addition of the text below be an acceptable solution?
---
Note that because UDP itself provides no congestion control
mechanisms, it is recommended to use UDP transport only on managed
networks, where the network path has been explicitly provisioned for
IPFIX traffic through traffic engineering mechanisms, such as rate
limiting or capacity reservations.
---
While Lars (as AD) is the final authority (e.g., on whether "it is
recommended" above is strong enough language), I'd like to add a
couple of sentences to recognize "dedicated network that hosted
a NetFlow implementation" as a common case (to help out the
network administrators who actually have to make this work):
An important example of an explicitly provisioned managed
network for IPFIX is use of IPFIX to replace a functioning
NetFlow implementation on a dedicated network. In this
situation, the dedicated network should be provisioned in
accordance with the NetFlow deployment experience that flow
export traffic generated by monitoring an interface will
amount to 2-5% of the monitored interface's bandwidth.
Thanks,
--David
----------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 176 South St., Hopkinton, MA 01748
+1 (508) 293-7953 FAX: +1 (508) 293-7786
black_david(_at_)emc(_dot_)com Mobile: +1 (978) 394-7754
----------------------------------------------------
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf