Re: [IPFIX] UDP Sequence Numbers rfc 5101

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