Subject: [IPFIX] IPFIX-PROTO: template reuse

From: Paul Aitken <[email-masked]>
Date: Thu, 26 Jul 2007 22:42:06 +0100

Dear all,

While working on the IPFIX-TESTING draft, I realised that IPFIX-PROTO
doesn't specify very clearly what to do if a Template ID is reused
inside the template expiry time (ie, same Template ID, different
template definition) while TCP transport is being used.

With SCTP and TCP transports, we expect Templates only to be sent once.
Section 8 (Template Management / SCTP) and 10.4.2.2 (Templates
Management / TCP) of IPFIX-PROTO say:

    Before
    reusing a Template ID, the Template MUST be deleted.  In order to
    delete an allocated Template, the Template is withdrawn through the
    use of a Template Withdraw Message.

And in section 9 (The Collecting Process's Side):

    Template Sets and Option Template Sets are only sent once.  The
    Collecting Process MUST store the Template Record information for
    the duration of the association so that it can interpret the
    corresponding Data Records that are received in subsequent Data
    Sets.

Which is followed by a clear statement of what to do for SCTP:

    Template IDs are unique per SCTP association and per Observation
    Domain.  If the Collecting Process receives a Template which has
    already been received but which has not previously been withdrawn
    (i.e. a Template Record from the same Exporter Observation Domain
    with the same Template ID received on the SCTP association), then
    the Collecting Process MUST shutdown the association.

With UDP transport, we can expect a Template to be refreshed many times.
eg, it's possible that the Template changes because the Exporting
Process restarted. So we have to allow this.

And with TCP... well, we don't say at all.

We can't even suppose to follow the malformed message rule:

    If the Collecting Process receives a malformed IPFIX Message, it
    MUST reset the TCP connection, discard the IPFIX Message, and SHOULD
    log the error.

- because a Template reuse won't be a malformed Message itself; it'll be
a valid Message. It's only because the Collector has previously received
a different definition for the same Template ID that there's any problem
(ie, the problem is due to Collector state).

Looking at section 10 and comparing the SCTP, UDP and TCP sub-sections, 
it's clear that the TCP "Collecting Process" section is missing.

The SCTP Collecting Process section (10.2.5) simply says:

    When the transport protocol is SCTP, the default Collector
    processing described in Section 9 is used.

I would like to see a new TCP / Collecting Process section (probably 
just at the end of the existing TCP section, ie new section 10.4.3).

Without wanting to reproduce section 9 entirely, it might say:

    When the transport protocol is TCP the default Collector processing
    described in Section 9 is used, with "SCTP association" being
    substituted by "TCP connection".

When I read section 9 with that substitution, it makes sense - except 
for a couple of places where it mentions SCTP stream zero, which I hope 
will soon be fixed too.

This should be followed by a TCP / Failover section similar to the SCTP 
and UDP sections (10.2.6 and 10.3.8).

eg, it may read:

    If the Collecting Process does not acknowledge the attempt by the
    Exporting Process to establish an association the Exporting Process
    should retry using an exponential backoff.  The
    Exporter MAY log an alarm if the time to establish the association
    exceeds a specified threshold, configurable on the Exporter.

    If Collecting Process failover is supported by the Exporting Process
    a second TCP connection MAY be opened in advance.

- though we may not want to limit to "a second" (neither here, nor in 
the SCTP Failover section, 10.2.6). We may wish to say "additional..." 
instead.

Finally, a very minor correction: 10.4.2.2 "Templates Management" should 
be singular, just like 10.2.4.4 and 10.3.6.

-- 
Paul Aitken
Cisco Systems Ltd, Edinburgh, Scotland.

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