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
_______________________________________________
OPSAWG mailing list -- [email protected]
To unsubscribe send an email to [email protected]
