[IPFIX]Semantic of one IPFIX IE depends on the semantic of another IPFIX IE (draft-liu-opsawg-ipfix-muti-layer)

["[e-mail]" <[e-mail]>]

Dear authors,

I would to add more information on draft-liu-opsawg-ipfix-muti-layer 
during the OPSAWG meeting, presented at the last IETF meeting.

In your proposal, the semantic of one IPFIX Information Element (e.g, 
the destIPv6address) relies on the content of another IE(e.g, 
encapLayerTop, encapLayer2).

We've been trying to avoid this in IPFIX. One reason: an Exporter might 
decide to include the variable length IPFIX IE 
<https://datatracker.ietf.org/doc/html/rfc7011#section-7>s at the end of 
the Template Record. However, this implicit rule was never specified in 
the IPFIX specifications but stems from this "the Information Elements 
in the Template Records is not guaranteed" sentence in RFC7011.

The only rules regarding the IPFIX IE order mentioned in RFC 7011 are
1.

    Multiple Scope Fields MAY be present in the Options Template Record,
    in which case the composite scope is the combination of the scopes.
    For example, if the two scopes are meteringProcessId and templateId,
    the combined scope is this Template for this Metering Process.  If a
    different order of Scope Fields would result in a Record having a
    different semantic meaning, then the order of Scope Fields MUST be
    preserved by the Exporting Process.

2.
    If an Information Element is required more than once in a Template,
    the different occurrences of this Information Element SHOULD follow
    the logical order of their treatments by the Metering Process.

Btw, do you see the difference between MUST for a Scope field and SHOULD 
for a normal IPFIX IE?

This is a known problem for IPFIX.
Already in MPLS, we had to define multiple IPFIX IEs in IANA 
<https://www.iana.org/assignments/ipfix/ipfix.xhtml> for that exact reason


This is not ideal but that's the way it is.
Even that MPLS-like solution is not ideal from a data interpretation 
point of view, as the networking context might be different from each 
exporter and each exporter only knows about itself. Practically, the 
encapLayer2 on different exporters might not produce the same results.
So the problem statement in your draft is a very valid one, as discussed 
on the microphone in IETF 124.

Not to sure what to do from here. Possible tracks:
- we keep the solution in your draft; and we might have more of such 
drafts, with a need for multiple different IEs which would require 
another IPFIX similar to encapLayerTop, encapLayer2, etc
- have a generic solution draft with topIPFIXIE, secondIPFIXIE, etc.
- impose the structure data RFC 6313 (I am not sure many collector 
supports this RFC)
- update 7011 with this change:

    OLD:

        If an Information Element is required more than once in a Template,
        the different occurrences of this Information Element SHOULD follow
        the logical order of their treatments by the Metering Process.


    NEW:

        If an Information Element is required more than once in a Template,
        the different occurrences of this Information Element MUST follow
        the logical order of their treatments by the Metering Process.

    OLD:
    the Information Elements in the Template Records is not guaranteed

    NEW:
    the Information Elements in the Template Records is guaranteed


Between the pragmatic solution (your draft), the perfect-but-not-widely 
implemented solution (RFC6313), the 
hopefully-very-quick-but-we-know-a-bis-RFC-is-never-quick solution 
(update RFC7101), let's discuss.

Copying the IPFIX mailing for discussion.

Regards, Benoit