Hi Benoit，
Thanks a lot for taking the discussion to the list and providing your thoughts.
Current I couldn't see a perfect solution of this problem. Please see my reply
inline with [Yao].
Regards,
Yao
From: [email protected] <[email protected]>
To: [email protected] <[email protected]>;
Cc: [email protected] <[email protected]>;[email protected] <[email protected]>;Brian
Trammell <[email protected]>;
Date: 2025年11月15日 20:17
Subject: [OPSAWG]Semantic of one IPFIX IE depends on the semantic of another
IPFIX IE (draft-liu-opsawg-ipfix-muti-layer)
_______________________________________________
OPSAWG mailing list -- [email protected]
To unsubscribe send an email to [email protected]
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.
[Yao] Yes, encapLayer2 on different exporters might not produce the same
results, the encapLayer2 is the layer2 information on each exportor locally.
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
[Yao] Yes, following the solution of our draft, if one day there're packets
with four or five or more encapsulation layers in the network and people wants
to export the packet header information of each layer, the encapLayer4,
encapLayer5 are needed.
- have a generic solution draft with topIPFIXIE, secondIPFIXIE, etc.
[Yao] Do you mean defining new IEs such as
topSourceIPv6Address,secondSourceIPv6Address, thirdSourceIPv6Address...? It's a
generic solution, but there're many fields in the packet header, so a large
amount of new IEs needs to be defined for each field of each layer.
- impose the structure data RFC 6313 (I am not sure many collector
supports this RFC)
[Yao] From my understanding, the structure
data(basicList/subTemplateList/subTemplateMultiList) in RFC6313 is more
suitable for the data with a fixed structure. In the multi-layer encapsulation
scenario, there're different data collection requirements, which leads to many
different data structures, e.g, outer DA& inner SA, outer SA&inner DA, outer DA
& inner SRH, and etc. I'm still trying to figure out how to use RFC6313 to
fulfill the multi-layer encapsulation collection requirement.
- update 7011 with this change:
[Yao] Just updating RFC7011 can only fulfill the requirements of collecting the
same fields from both the outer and inner packet headers(Req-a in the drart),
but Req-b/c/d still can't be fulfilled, e.g, for a packet with three IPv6
headers encapsulated, the monitor only wants to collect the information of the
innermost IPv6 header.
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
[Yao] About the order of the IEs in the Template,
https://datatracker.ietf.org/doc/html/rfc6313#section-2.2 says that "some
encoding optimizations are based on the permutation of Information Element
order". So I'm not sure whether 7011 can be updated to say that the order of
the IEs in the Template Records is guaranteed if there're implementations that
don't guarantee the order . But if solutions similar to our draft are used,
maybe just to specify in the solution draft that the order of the IEs in the
Template Records MUST be guaranteed when encapLayerTop/encapLayer2/encapLayer3
are used can make the solution work.
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]
