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

[[e-mail]]

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: [e-mail] <[e-mail]>  
To: [e-mail] <[e-mail]>;  
Cc: [e-mail] <[e-mail]>;[e-mail] <[e-mail]>;Brian Trammell <[e-mail]>;
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 -- [e-mail]
To unsubscribe send an email to [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.

[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