Hi all, Also relevant to this discussion, https://datatracker.ietf.org/meeting/125/materials/minutes-125-tsvwg-00 includes the following:
"- Discussion: Gorry Fairhurst questioned why only the 2 ECN bits were being exported instead of the full 8-bit Traffic Class/DSCP field. Shueyan noted that while DSCP IEs exist, specific ECN statistical IEs are needed for L4S visibility. - Operator Feedback: Jason Livingood expressed strong support, noting that the lack of standardized IPFIX ECN reporting is currently an operational gap for ISPs deploying L4S." Cheers, Med De : Joe Clarke (jclarke) <[email protected]> Envoyé : vendredi 27 mars 2026 16:31 À : [email protected]; [email protected] Cc : [email protected] Objet : [OPSAWG]Re: Feedback on Export of L4S ECN in IP Flow Information Export (IPFIX), draft-song-opsawg-ipfix-ecn-01 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]<mailto:[email protected]> <[email protected]<mailto:[email protected]>> Date: Friday, March 27, 2026 at 07:57 To: [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>> Cc: [email protected]<mailto:[email protected]> <[email protected]<mailto:[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 ____________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you.
_______________________________________________ OPSAWG mailing list -- [email protected] To unsubscribe send an email to [email protected]
