Subject: Re: [IPFIX] WG Last Call for Implementation Guidelines

From: Brian Trammell <[email-masked]>
Date: Fri, 02 Mar 2007 18:14:49 -0500

Greetings, all...

I have a few comments for the guidelines:

1. In Section 6.3, TCP Transport Specific Guidelines, para 4 states that
TCP Collecting Processes SHOULD use the Sequence Number to check for
missing IPFIX Messages.

Wouldn't any condition that would cause missing messages cause a TCP
connection reset? I have no problem with multi-transport implementations
doing sequence number checks on TCP because they check sequence numbers
regardless of protocol (indeed, due to layering between transport and
message decode, our own implementation does precisely this) , but I'm
not sure the guidelines should recommend a test that will always succeed.

[In tracking down this issue, I think I've found an editorial error in
protocol-24, as well. Para 2 of section 10.4.2.1 IPFIX Message Encoding
states:

   In the case of TCP, the IPFIX Message sequence number contains the
   total number of IPFIX Data Records received for the TCP connection,
   prior to the receipt of this IPFIX Message, modulo 2^32.

which is not in parallel with section 3.1's

  Sequence Number
           Incremental sequence counter modulo 2^32 of all IPFIX Data
           Records sent on this PR-SCTP stream from the current
           Observation Domain by the Exporting Process.

(Sequence Numbers are Observation Domain scoped, and the TCP section
appears to override this, which I'm pretty sure isn't the intention.
Would it be possible to send another RFC Editor comment to correct this
point in the protocol document?)]

2. The document is in sections 4.1 and 6.2 not particularly clear about
template retransmission and expiration delays, and their
configurability. From protocol-24 section 10.3.7, we have a guideline
for Collector expiry delay to be set to at least three times Exporter
retransmission delay; from protocol-24 10.3.6 and guidelines-02 6.2 we
have a recommended retransmission delay of 10 minutes. So, I'd suggest
the following:

 - Change the language in section 4.1 para 2 "If no template becomes
available within 30 minutes...) to note that this is the expiry delay,
and is configurable.

 - Change the language in the last paragraph of section 6.2 to recommend
a 30 minute expiry time, instead of 60 minutes, in line with the 3x
guideline noted above

(This is a relatively straightforward change, but has been a point of
much discussion for the protocol document)

3. Section 4.6 Time Issues, the first sentence in the second paragraph
is a little confusing. The issues with timing as I understand them are:

 - precision of clock on the MP;

 - synchronization of clocks among MP, EP, and CP; and

 - synchronization of all of these to some global reference.

The precision of the clock on the EP and its applicability to export
time stamping would seem to be practically moot, because very few if any
EPs won't have at least a one second resolution real-time clock. So I
don't see the issue with EP resolution and export time...

(I'd suggest language here but I wanted to make sure my understanding of
how timing should be treated by implementors are correct.)

Regards,

Brian

Nevil Brownlee wrote:
> 
> Hi All:
> 
> The 'IPFIX Implementations Guidelines' draft (-02) is now ready
> for WG last call, so we'll start that today.  It will end on Saturday,
> 17 March, just before the Prague IETF meeting.
> 
> Cheers, Nevil
> 
> -----------------------------------------------------------------------
>  Nevil Brownlee                    Computer Science Department | ITS
>  Phone: +64 9 373 7599 x88941             The University of Auckland
>  FAX: +64 9 373 7453   Private Bag 92019, Auckland 1142, New Zealand
> 
> -----------------------------------------------------------------------
> This mail sent through University of Auckland http://www.auckland.ac.nz
> 
> 
> _______________________________________________
> IPFIX mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/ipfix

_______________________________________________
IPFIX mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ipfix

---

From: Brian Trammell <[email-masked]>
Date: Fri, 02 Mar 2007 18:14:49 -0500

Greetings, all...

  Sequence Number

Regards,

Brian

---

From: "Gerhard Muenz" <[email-masked]>
Date: Wed, 14 Mar 2007 19:28:54 +0100 (CET)

> point in the protocol document?)]

There are two other inconsistencies (or am I wrong?):

(i) Concerning the value of the Sequence Number:

3.1: "IPFIX Data Records sent"
10.3.2: "IPFIX Data Records received"
10.4.2.1: "IPFIX Data Records received"

I think it is better to always write "IPFIX Data Records sent" because the
field is set by the exporter and not by the collector.

(ii) There seem to be three different writings for the Sequence Number in
protocol-24:

"IPFIX Message sequence number"
"Sequence Number"
"IPFIX Sequence Number"
"sequence number"

Maybe we should only use "Sequence Number" and "IPFIX Sequence Number"
when a specific discrimination from other transport layer sequence numbers
is required.

Regards,
Gerhard

-- 
Dipl.-Ing. Gerhard Münz
Computer Networks and Internet
Wilhelm Schickard Institute for Computer Science
University of Tuebingen
Sand 13 (Room B309), D-72076 Tuebingen, Germany
Phone:  +49 7071 29-70534       Fax: +49 7071 29-5220
E-mail: [email-masked]
WWW:    http://net.informatik.uni-tuebingen.de/~muenz

---

From: "Gerhard Muenz" <[email-masked]>
Date: Wed, 14 Mar 2007 19:28:54 +0100 (CET)

Regards,
Gerhard

---

From: Brian Trammell <[email-masked]>
Date: Wed, 14 Mar 2007 15:02:42 -0400

Gerhard,

In short, I agree. Specific comments inline:

> field is set by the exporter and not by the collector.

Agreed. (Also, in 10.3.2 para 2, the document scopes the sequence number
to a "UDP association", which should be a "UDP Transport Session").

> when a specific discrimination from other transport layer sequence numbers

The protocol document does not appear to mention TCP Sequence or SCTP
Transport Sequence or Stream Sequence numbers, so omitting "IPFIX" from
"Sequence Number" within the document is acceptable (especially in
paragraphs and/or short sections mentioning the sequence number more
than once). However, "IPFIX Message sequence number" would seem to imply
that the numbers increment per message, not per record. So, yes, I'd
agree that we should use "[IPFIX] Sequence Number" everywhere.

Regards,

Brian

---

From: Brian Trammell <[email-masked]>
Date: Wed, 14 Mar 2007 15:02:42 -0400

Gerhard,

Regards,

Brian

---

From: "Gerhard Muenz" <[email-masked]>
Date: Wed, 14 Mar 2007 20:28:14 +0100 (CET)

Dear all,

Here are some more comments:

3.1/4.1:
   If no Template soon becomes available
   the event should be logged and the Transport Session reset, since the
   data cannot be interpreted.  The reset will cause Templates to be
   resent.

How can a collector reset a UDP Transport Session? UDP is probably the
transport protocol where most Templates losses occur, so does a reset
forced  by the Collector really help?

3.3:
   It is possible to specify a scope within a single Option Template
   which only affects option data corresponding to that Option Template
   and does not affect the scope of any other Option, Template or Data
   (i.e. just because some data is scoped in one Option Template doesn't
   necessarily mean that the same scope also applies for the same data
   in other Option Templates).

I do not understand this paragraph (maybe I'm too stupid :( ).

3.3:
   Note that it is sometimes necessary to export information about
   entities that exist outside any observation domain, or within
   multiple Observation Domains (e.g. information about Metering
   Processes scoped to meteringProcessID).  It is recommended to export
   such information in an IPFIX Message with Observation Domain ID 0.

Can this be a recommendation if it is already standardized by protocol-24,
sec. 3.1:

           The Observation Domain ID
           SHOULD be 0 when no specific Observation Domain ID is
           relevant for the entire IPFIX Message.  For example, when
           exporting the Exporting Process Statistics, or in case of
           hierarchy of Collector when aggregated data records are
           exported.

3.5:
   The IPFIX Protocol defines the maximum message size for IPFIX
   Messages transported over UDP to be constrained by the path MTU, or
   if the path MTU is not available, 576 bytes (the minimum datagram
   size all IP implementations MUST support).

There is an important point in 8.4 you should refer to in 3.5:
   Note that the selection of IPFIX message sizes for DTLS over UDP must
   account for overhead per packet introduced by the DTLS layer.

4.5.2:
   There isn't any means for aligning Information Element specifiers
   within Template Records, but there is a limited need for it and
   Information Element specifiers are aligned to 32-bit address
   boundaries anyway.

To me, the second half of the sentence sounds as if there was still a
certain need for this kind of alignment. Maybe:
"... but there is only a limited need for it..."
or:
"... but there is no real need for it..."

6.1:
The citation from protocol-24 has changed !!! Now it is:

   Template Sets and Option Template Sets SHOULD be sent on the SCTP
   stream zero. Template Sets and Option Template Sets MUST be sent
   reliably.

I propose to emphasize more on this important implementation aspect since
the reliable transport of Templates is one of the main advantages of SCTP!
There is a side-effect:
   "A simple system might use just one data stream for all the exported
   data."
This implies that the all IPFIX messages are sent over one reliable stream!

10.2:
   [I-D.ietf-ipfix-protocol] specifies that the Exporting Process MAY
   insert some padding octets to align Information Elements within a
   Data Record.  The padding length MUST be shorter than any allowable
   Record in that set.

Mistake! The padding octets are used to align the next Set, not the
Information Elements.

10.3:
   ... There is no way to tell that this is wrong,
   if it wasn't meant as an enterprise-specific Information Element.

So what should the implementer do to prevent this?

10.4:
   Template IDs are generated as required by the Exporting Process.
   ...  The collecting process
   does not know in advance which Template ID a particular Template will
   use.

Is this really a common implementation mistake? I think it is very clear
from the protocol draft that the collector cannot expect any specific
Template IDs.

Best regards,
Gerhard

---

From: "Gerhard Muenz" <[email-masked]>
Date: Wed, 14 Mar 2007 20:28:14 +0100 (CET)

Dear all,

3.1/4.1:

3.3:

3.3:

3.5:

4.5.2:

6.1:

10.2:

10.3:

10.4:

Best regards,
Gerhard

---

From: Benoit Claise <[email-masked]>
Date: Mon, 19 Mar 2007 15:40:13 -0700

Brian, Gerhard,

Thanks for spotting this.
Here are the changes we should be applying... to the AUTH48 IMHO.

10.3.2  Reliability 
OLD:

   The Collecting Process SHOULD deduce the loss and reordering of 
   IPFIX Data Records by looking at the discontinuities in the IPFIX 
   Message sequence number. In the case of UDP, the IPFIX Message 
   sequence number contains the total number of IPFIX Data Records 
   received for the UDP association, 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 
   Message sequence number. In the case of UDP, the IPFIX Message 
   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.  

 10.4.2.1 IPFIX Message Encoding

OLD 

NEW
    
   In the case of TCP, the IPFIX Message sequence number contains the 
   total number of IPFIX Data Records _sent from this TCP connection, 
   from the current Observation Domain by the Exporting Process, _
   prior to the receipt of this IPFIX Message, modulo 2^32.  

    protocol-24:"IPFIX Message sequence number"
    "Sequence Number"
    "IPFIX Sequence Number"
    "sequence number"

    Maybe we should only use "Sequence Number" and "IPFIX Sequence Number"
    when a specific discrimination from other transport layer sequence
    numbers
    is required.

Agreed.

Regards, Benoit

> ------------------------------------------------------------------------
>

---

From: Benoit Claise <[email-masked]>
Date: Mon, 19 Mar 2007 15:40:13 -0700

Brian, Gerhard,

10.3.2  Reliability 
OLD:

NEW:

OLD 

NEW

Agreed.

Regards, Benoit