Hi Joe, Med, Benoit and all,
Thank you for the discussion. I was on a business trip last week for BBF
meeting, sorry for the late response.
I understand the point Benoit raised that using ipClassOfService is technically
feasible. However, for L4S traffic monitoring in this draft, its objective is
mainly on the ECN field. ECN is special defined for L4S as: ECT(1) is used for
L4S traffic identification and CE for congestion experienced indication. If we
reuse ipClassOfService for L4S ECN, some issues may be brought. For example,
the difference of DSCP values interferes with the aggregation of flows by ECN.
Flows that share the same L4S relevant ECN status (e.g., ECT(1)) but have
different DSCP markings are kept separate, making it impossible to directly
monitor L4S traffic as a whole. It may also complicate correlating ECN
congestion status with DSCP adjustments (such as dynamically modifying DSCP
priority based on the observed ECN status).
Currently, IANA has defined an IPFIX information element for the whole 8 bits
ipClassOfService (ID: 5), as well as a dedicated information element for the
most significant 6 bits ipDiffServCodePoint (ID: 195). A dedicated ECN
information element would allow the metering process to aggregate flows based
on ECN value, avoding unnecessary flow splitting caused by DSCP difference.
It's expected to provide a straight forward way to monitor L4S traffic, detect
congestion and enale ECN-aware policy decisions. This is why we believe a
dedicated infomation element for ECN is necessary.
BTW, BBF also initiated a project entitled "Application of L4S to Broadband
Networks" under its Network Architecture Working Area in 2025, as described in
Liaison Statement:
https://datatracker.ietf.org/liaison/1984/
Monitoring of L4S is explicitly within the scope of the project, including:
"Providing recommendations and best practices for monitoring the performance
relating to the introduction and ongoing monitoring of L4S"
I would like to ask Jonathon Newton (the Director of the Network Architecture
Area at BBF) and Joson Livingood (who explicitly expressed support during TSVWG
discussion), if they could kindly provide the benefits that designing a
dedicated IPFIX information element for L4S ECN monitoring could bring to
networks, from an operator's perspective. Thanks.
Best regards,
Xueyan (on behalf of the co-authors)
Original
From: JoeClarke(jclarke) <[email protected]>
To: [email protected]
<[email protected]>;[email protected]
<[email protected]>;[email protected]
<[email protected]>;
Cc: [email protected] <[email protected]>;
Date: 2026年03月28日 02:05
Subject: [OPSAWG]Re: Feedback on Export of L4S ECN in IP Flow Information
Export (IPFIX), draft-song-opsawg-ipfix-ecn-01
_______________________________________________
OPSAWG mailing list -- [email protected]
To unsubscribe send an email to [email protected]
There you go. Perhaps the authors could ask Jason to comment here on opsawg in
support of this work and what benefits it will provide over what is in place
now.
Joe
From: [email protected] <[email protected]>
Date: Friday, March 27, 2026 at 12:32
To: Joe Clarke (jclarke) <[email protected]>, [email protected]
<[email protected]>, [email protected]
<[email protected]>
Cc: [email protected] <[email protected]>
Subject: RE: [OPSAWG]Re: Feedback on Export of L4S ECN in IP Flow Information
Export (IPFIX), draft-song-opsawg-ipfix-ecn-01
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] <[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
____________________________________________________________________________________________________________
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]
