Re: [tsv-dir] Re: Transport Directorate review of draft-ietf-ipfix-implementation-guidelines-06.txt

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]