David, all,
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.
OK, thanks, added. I copy below the current version of the UDP section.
Let me know if you agree with it. The last changes are the beginning of
the section.
One last open point is whether the following text, or something similar,
should be added or not:
As recommended in [I-D.ietf-tsvwg-udp-guidelines] an application
SHOULD NOT send UDP messages that result in IP packets that exceed
the MTU of the path to the destination and SHOULD enable UDP checksums
(see sections 3.2 and 3.4 of [I-D.ietf-tsvwg-udp-guidelines] respectively).
thanks,
Elisa
---
6.2. 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.
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.
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.
Since IPFIX assumes reliable transport of templates over SCTP, this
necessitates some changes for IPFIX template management over UDP.
Templates sent from the Exporting Process to the Collecting Process
over UDP MUST be resent at regular time intervals; these intervals
MUST be configurable.
We recommend a default Template resend time of 10 minutes,
configurable between 1 minute and 1 day.
Note that this could become an interoperability problem, e.g. if an
Exporter re-sends Templates once per day, while a Collector expires
Templates hourly, then they may both be IPFIX-compatible, but not be
interoperable.
Retransmission time intervals that are too short waste bandwidth on
unnecessary template retransmissions. On the other hand, time
intervals that are too long introduce additional costs or risk of
data loss by potentially requiring the Collector to cache more data
without having theTemplates available to decode it.
To increase reliability and limit the amount of potentially lost data
the Exporting Process MAY resend additional templates using a packet-
based schedule. In this case Templates are resent depending on the
number of packets sent. Similarly to the time interval, resending a
Template every few packets introduces additional overhead while
resending after a lange amount of packets have already been sent
means high costs due to the data caching and potential data loss.
We recommend a default Template resend interval of 20 packets,
configurable between 1 and 1000 packets.
Note that a sufficiently small resend time or packet interval may
cause a system to become stuck, continually re-sending templates.
e.g., if the resend packet interval is 2 (i.e., templates are to be
sent in every other packet) but more than two packets are required to
send all the templates, then the resend interval will have expired by
the time the templates have been sent, and templates will be sent
continuously - possibly preventing any data from being sent at all.
Therefore the Template resend intervals should be considered from the
last data packet, and should not be tied to specific sequence
numbers.
The Collecting Process SHOULD use the Sequence Number in the IPFIX
Message header to determine whether any messages are lost.
The following may be done to mitigate message loss:
o Move the Collector topologically closer to the Exporter.
o Increase the bandwidth of the links through which the Data Records
are exported.
o Use sampling, filtering, or aggregation in the Metering Process to
reduce the amount of exported data.
o Increase the buffer size at the Collector and/or the Exporter.
Before using a Template for the first time, the Exporter may send it
in several different IPFIX Messages spaced out over a period of time
in order to increase the likelihood that the Collector has received
the Template.
Template Withdraw messages MUST NOT be sent over UDP; the Exporter
must rely on expiration at the Collector to expire old Templates or
to reuse Template Ids.
We recommend that the collector implements a template expiry of three
times the Exporter refresh rate.
However, since the IPFIX protocol doesn't provide any mechanism for
the Exporter to convey any information about the Template expiry time
to the Collector, configuration must be done out of band.
If no out of band configuration is made, we recommend to initially
set a template expiry time at the Collector of 60 minutes. The
Collecting Process MAY estimate each Exporting Process's resend time
and adapt the expiry time for the corresponding Templates
accordingly.
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf