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@xxxxxxx Mobile: +1 (978) 394-7754
----------------------------------------------------
_______________________________________________
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf