Subject: Re: [IPFIX] WG Last Call for Implementation Guidelines starts today (2)

From: "Boschi, Elisa" <[email-masked]>
Date: Thu, 15 Mar 2007 16:00:07 -0000

Hi Gerhard,

> 
> 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?

ok, so:

If no Template becomes available, the event SHOULD be logged and, unless UDP is used, the Transport Session reset, which will cause the Templates to be resent.

> 
> 
> 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 :( ).
> 

would someone object to remove it?

> 
> 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.
> 

yes, we should modiy the last sentence to "Such information SHOULD be exported in an IPFIX Message with Observation Domain ID 0"

> 
> 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.
> 

done.

> 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!
> 
>

6.1 has changed quite a bit and the new version should address your concerns... more about this in the next days

Regards,
Elisa

> 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
> 
> 
> On Wed, February 28, 2007 9:42 pm, Nevil Brownlee said:
>> 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: Gerhard Muenz <[email-masked]>
Date: Fri, 23 Mar 2007 12:19:56 +0100

Hi Elisa, Benoit,

Boschi, Elisa wrote:
> 6.1 has changed quite a bit and the new version should address your
> concerns... more about this in the next days

What is the reason for separating Templates from the corresponding Data
Sets and for sending them over a separate stream (zero)?

I've been talking to Michael Tüxen, who was working on PR-SCTP. It seems
that the sentence

    stream zero.

from the protocol draft is a relict from very early days of PR-SCTP when
reliability options were assumed to be a per-stream setting. Actually,
it is a per-message property, i.e. in the same stream, one message can
be sent fully reliable and another one partially reliable. The effect of
a stream is that the message order is preserved and that head-of-line
blocking at the receiver does not exist between different streams.

Therefore, it seems to be more appropriate to have a separate stream for
each Template, and to send the Template as well as the corresponding
Data Sets over this stream. This ensures that the Template arrives
before the Data Sets. Templates would be sent in reliable messages, Data
Sets in partially reliable messages.

Am I missing the point here?

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
_______________________________________________
IPFIX mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ipfix

---

From: Gerhard Muenz <[email-masked]>
Date: Fri, 23 Mar 2007 12:19:56 +0100

Hi Elisa, Benoit,

Regards,
Gerhard