Re: [IPFIX] UDP Sequence Numbers rfc 5101
Brian Trammell <[email protected]>
| Newsgroups | gmane.ietf.ipfix |
|---|---|
| Message-ID | <[email protected]> |
On 26 Mar 2013, at 5:28, Andrew Feren <[email protected]> wrote: > Hi Brian, > > I'm OK with your text as an editor note. That is how I always interpreted that section anyway. However, if we are wordsmithing I have one other nit in this section. > > The sequence number may not be "the total number of IPFIX Data Records sent for the UDP Transport Session prior to the receipt of this IPFIX Message" unless we assume in order (and instant ;) delivery. Maybe transmission instead of receipt. Hi, Andrew, Excellent point. So now we have: NEW: The Collecting Process SHOULD deduce the loss and reordering of IPFIX Data Records by looking at the discontinuities in the IPFIX Sequence Number. In the case of UDP, the IPFIX Sequence Number contains the total number of IPFIX Data Records sent for the Observation Domain in the current UDP Transport Session prior to the transmission of this IPFIX Message, modulo 2^32. A Collector SHOULD detect out-of-sequence, dropped, or duplicate IPFIX Messages by tracking the Sequence Number. Thanks, Brian > -Andrew > > On 03/24/2013 08:32 PM, Brian Trammell wrote: >> Hi, Steve, >> >> This is an error in RFC 5101; the intent of the Sequence Number is that it be Observation Domain (and in the case of SCTP, Stream) scoped (i.e., you are correct that transport independence, to the extent possible, is the intent). The language in the present revision of 5101bis still contains the same error. Thanks for the catch! >> >> I would suggest we fix this by replacing the paragraph in question as follows: >> >> OLD: >> >> The Collecting Process SHOULD deduce the loss and reordering of IPFIX >> Data Records by looking at the discontinuities in the IPFIX Sequence >> Number. In the case of UDP, the IPFIX Sequence Number contains the >> total number of IPFIX Data Records sent for the UDP Transport Session >> prior to the receipt of this IPFIX Message, modulo 2^32. A Collector >> SHOULD detect out-of-sequence, dropped, or duplicate IPFIX Messages >> by tracking the Sequence Number. >> >> NEW: >> >> The Collecting Process SHOULD deduce the loss and reordering of IPFIX >> Data Records by looking at the discontinuities in the IPFIX Sequence >> Number. In the case of UDP, the IPFIX Sequence Number contains the >> total number of IPFIX Data Records sent for the Observation Domain in the >> current UDP Transport Session prior to the receipt of this IPFIX Message, >> modulo 2^32. A Collector SHOULD detect out-of-sequence, dropped, or >> duplicate IPFIX Messages by tracking the Sequence Number. >> >> The document is presently in Publication Requested state, so I think this should be placed as an RFC editor note on the document. WG: any comments thereon? >> >> Best regards, >> >> Brian >> >> On 22 Mar 2013, at 0:45, Steve Nash <[email protected]> wrote: >> >>> Please consider the wording of the paragraph on Sequence Numbers in Section 3.1. >>> Incremental sequence counter modulo 2^32 of all IPFIX Data Records >>> sent in the current stream from the current Observation Domain by >>> the Exporting Process. Each SCTP Stream counts sequence numbers >>> separately, while all messages in a TCP connection or UDP >>> transport session are considered to be part of the same stream. >>> The phrase I have put in italics is depended on Transport protocol. >>> Section 10.3.2 Reliability says: >>> In the case of UDP, the IPFIX Sequence Number contains the >>> total number of IPFIX Data Records sent for the UDP Transport Session >>> prior to the receipt of this IPFIX Message >>> This is NOT dependent on the ObservationDomain. Nothing prohibits the Exporting Process from using the same Transport Session for multiple Observation Domains. But in UDP the Sequence number is for the Transport session, whereas in TCP and SCTP each Observation Domain has an independent sequence on the same (and on each) Transport Session. >>> The term ‘Stream’ seems to take different meanings in IPFIX, depending on the transport protocol. >>> This is not consistent with IPFIX being “Transport protocol independent “ (Section 10 first para). >>> Regards >>> Steve Nash >>> [email protected] >>> UK >>> _______________________________________________ >>> IPFIX mailing list >>> [email protected] >>> https://www.ietf.org/mailman/listinfo/ipfix >> _______________________________________________ >> IPFIX mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/ipfix > > _______________________________________________ > IPFIX mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/ipfix _______________________________________________ IPFIX mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipfix