Re: [IPFIX] WG Last Call for Implementation Guidelines
Brian Trammell <bht <at> cert.org>
2007-03-08 18:42:19 GMT
Boschi, Elisa wrote:
> 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.
>
yep, sounds good... We don't want to preclude the CP from checking
sequence numbers in a transport-independent way (and out of sequence
messages over TCP should be logged anyway, as an indication that the
remote EP is broken), but it's not a requirement as with SCTP-PR and UDP.
>>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)."
Also good... this makes it clear that this storage (and associated
delay) is transport-independent.
Thanks,
Brian
_______________________________________________
IPFIX mailing list
IPFIX <at> ietf.org
https://www1.ietf.org/mailman/listinfo/ipfix
RSS Feed