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