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

From: "Boschi, Elisa" <[email-masked]>
Date: Thu, 8 Mar 2007 16:45:49 -0000

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

What about:

   The Collecting Process may check whether IPFIX Messages are lost by
   checking the Sequence Number in the IPFIX header.

It is similar to the guideline we give for SCTP:

   "The Collecting Process may check whether IPFIX Messages are lost by
   checking the Sequence Number in the IPFIX header.  The Collecting
   Process SHOULD use the Sequence Number in the IPFIX Message header to
   determine whether any messages are lost when using an unreliable or
   partially reliable stream.  Sequence numbers should be tracked
   independently for each stream."

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

what about changing the second paragraph of 4.1 to:

"A Data Set received with an unknown Set ID MAY be stored pending the arrival of the corresponding Template (cf. section 9 of  [IPFIX-INFO]). If no Template becomes available, the event should be logged and the Transport Session reset, which will cause the Templates to be resent. The amount of time the Collecting Process waits for a Template before resetting SHOULD be configurable.
We recommend a default of 30 minutes. Note that when using UDP as the transport protocol, this delay SHOULD be bound, when possible, by the Template Retransmit and the Template Expiry times (cf. Section 6.2)."

Regards,
Elisa

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

---

From: "Boschi, Elisa" <[email-masked]>
Date: Thu, 15 Mar 2007 14:50:48 -0000

Hi Gerhard,

...
>> "A Data Set received with an unknown Set ID MAY be stored pending the
>> arrival of the corresponding Template (cf. section 9 of  [IPFIX-INFO]). If
>> no Template becomes available, the event should be logged and the
>> Transport Session reset, which will cause the Templates to be resent. The
>> amount of time the Collecting Process waits for a Template before
>> resetting SHOULD be configurable.
>> We recommend a default of 30 minutes. Note that when using UDP as the
>> transport protocol, this delay SHOULD be bound, when possible, by the
>> Template Retransmit and the Template Expiry times (cf. Section 6.2)."
>>
> 
> The paragraph in 4.1 is a repetition of the first paragraph in 3.1. I have
> no problem with this redundancy - repeating important issues can make
> things clearer. But 3.1 is missing the timing information. So you should
> also mention the timings in 3.1 or refer to 4.1 for further information.
>

you're right. I've added the missing information to 3.1.
The first paragraph of 3.1 is now:

"The Exporting Process should always endeavour to send Template Records before the related Data Records.  However, since the Template Record may not arrive before the corresponding Data Records, the Collecting Process MAY store Data Records with an unknown Template ID pending the arrival of the corresponding Template (cf. section 9 of [I-D.ietf-ipfix-protocol]).  
If no Template becomes available, the event SHOULD be logged and the Transport Session reset, which will cause the Templates to be resent. The amount of time the Collecting Process waits for a Template before resetting SHOULD be configurable. We recommend a default of 30 minutes. 
Note that when using UDP as the transport protocol, this delay SHOULD be bound, when possible, by the Template Retransmit and the Template Expiry times (cf. Section 6.2)." 

Thanks,
Elisa

> Gerhard

---

From: "Boschi, Elisa" <[email-masked]>
Date: Thu, 15 Mar 2007 14:50:48 -0000

Hi Gerhard,

...

Thanks,
Elisa