Adding to this as a contributor, Jason Livingood has requested the IETF NOC provide some stats on L4S/ECN. He hinted that he’s using IPFIX today in Comcast to do this. It might be worth reaching out to him to see what he’s doing and how that is working and if a new IE would be useful vs. leveraging the full 8 bits you get today.
Joe From: [email protected] <[email protected]> Date: Friday, March 27, 2026 at 07:57 To: [email protected] <[email protected]> Cc: [email protected] <[email protected]> Subject: [OPSAWG]Feedback on Export of L4S ECN in IP Flow Information Export (IPFIX), draft-song-opsawg-ipfix-ecn-01 Dear draft-song-opsawg-ipfix-ecn authors, I would like to complement what I mentioned during our OPSAWG meeting last week. There is an existing information element ipClassOfService (ID: 5) which exports the 8 bits of of IPv4 TOS or IPv6 Traffic Class field. You could be exporting the 8 bits directly and extract the bit 6 and bit 7 in collector for ECN evaluation. This ipClassOfService is a very basic IPFIX IE, implemented by most IPFIX Metering Processes. On top of that, it's typically a key field, along with src/dst IP address, src/dst port, IP protocol, and input interface. So asking a router to meter the full ipClassOfService, to substract the last 2 bits, insert it into the new ipv4HeaderEcn IFPIX IE before exporting is a big job. Especially if it's a key field, as this implies "touching" the ipClassOfService for every single packet. 0 1 2 3 4 5 6 7 +-----+-----+-----+-----+-----+-----+-----+-----+ | DS Field, DSCP | ECN Field | +-----+-----+-----+-----+-----+-----+-----+-----+ Figure 1: ECN Fields in IPv4 IMO, this is not optimal, and you are not even saving on the export bandwidth as we speak about unsigned8 anyway. I believe your router implementation should stick to exporting the ipClassOfService. I don't want to say that you should not define this IFPIX IE in IANA (notice the double negation). There is actually one case where these ipv4HeaderEcn and ipv6HeaderEcn IFPIX IEs might be useful. Your IPFIX collector receives the ipClassOfService. From there, you extract the last 2 bits because you only care about ECN. If and only if you want to re-export the IPFIX IEs, stressing that only the last bits are relevant (maybe b/c you set the DSCP bits to 0), expressing the clear semantic, then it might make sense to export these new IPFIX IEs ... implying the request to IANA. I hope this clarifies. I did not look at the other IPFIX IEs in your draft but I advice you think along the same logic. For example, I read "The Information Element encodes only these 3 bits." for mplsHeaderEcn. We might be facing the same issue. And finally, like in RFC 9487, a section about sample use cases (https://datatracker.ietf.org/doc/html/rfc9487#name-sample-use-cases) with some appendix examples (https://datatracker.ietf.org/doc/html/rfc9487#appendix-A) would be a plus. Thanks and regards, Benoit
_______________________________________________ OPSAWG mailing list -- [email protected] To unsubscribe send an email to [email protected]
