[OPSAWG]Re: Fw: New Version Notification for draft-song-op sawg-ipfix-ecn-00.txt
Joel Halpern <[email protected]> Mon, 12 Jan 2026 10:54:40 -0500
| Newsgroups | gmane.ietf.opsawg,gmane.ietf.tsvwg,gmane.ietf.mpls |
|---|---|
| Message-ID | <[email protected]> |
This is a multi-part message in MIME format. --===============2978221685993599912== Content-Type: multipart/alternative; boundary="------------OQ98cyPksmjRiBsw4F1QNWAn" Content-Language: en-US This is a multi-part message in MIME format. --------------OQ98cyPksmjRiBsw4F1QNWAn Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit The discussion prompted me to read this draft. I have two different questions about it: 1) In what way is it related to L4S? Yes, L4S uses ECN. But ECN is not restricted to L4S. 2) Even if we assume this only reports packets with ECN bits enabled (not 00), generating an IPFIX report for every data packet across many flows (in some environments, all flows) seems to be tremendous overhead. Since as I understnad it this is for management monitoring of operability, not for congestion response, that seems a massive overhead. Am I misreading the draft? Yours, Joel On 1/11/2026 9:54 PM, [email protected] wrote: > > Hi Greg, > > > Thank you for the good question. > > Yes, ECN is an end-to-end protocol, TCP sender intiates the signalling > and TCP receiver responds. And I think IPFIX works in IP layer, so the > target data extraction is at network nodes. For the information > elements proposed in this drfat, the IPFIX extraction position may be > different based on monitoring purposes. We plan to add the following > text to section 5, does it work for you? > > /The IPFIX IEs defined in this draft may have their information > extraction positions adjusted based on different ECN monitoring > purposes in the network. Among them, the basic ECN field elements are > used to reflect the ECN codepoints carried in the IPv4 header, the > IPv6 Traffic Class octet, or the MPLS EXP field. These fields can be > flexibly extracted at any node along the path that has IPFIX export > capability. For tunnel ECN negotiation status IEs, the IPFIX data can > only be provided by the specific tunnel endpoints that participate in > the negotiation. For cumulative statistics IEs, the statistical data > may be processed with a higher priority at traffic aggregation or > egress nodes./ > > > For the mpls-ecn draft you shared, it appers to define a new ECN > opcode encapsulated in MNA packets for MPLS data plane. I think it's > actually relevant to the ipfix-ecn draft, if MPLS WG adopts it, we > would like to add the ECN export from MPLS MNA packets to our draft. > > > Best regards, > > Xueyan > > > > Original > *From: *GregMirsky <[email protected]> > *To: *宋雪雁00038118;Joel Halpern <[email protected]>; > *Cc: *[email protected] <[email protected]>;[email protected] > <[email protected]>;mpls <[email protected]>; > *Date: *2026年01月11日 06:00 > *Subject: **Re: [OPSAWG]Fw: New Version Notification for > draft-song-opsawg-ipfix-ecn-00.txt* > Hi Xueyan, > thank you for sharing the updated draft. A relatively new draft > draft-halmir-mpls-ecn > <https://datatracker.ietf.org/doc/draft-halmir-mpls-ecn/> on > supporting ECN in the MPLS using MNA might be of interest to you and > others involved in the matter. And I have a question. As I understand > the ECN, it is a host that is expected to act on the information > collected in the ECN field along the path of a packet. If that is > correct, who's the intended target of the IPFIX notification about the > ECN? Is the intention to act on ECN information obtained on a segment, > e.g., a tunnel, rather than based on the e2e ECN information? I read > Section 5, but was left with these questions. > > Regards, > Greg > > On Fri, Jan 9, 2026 at 1:53 AM <[email protected]> wrote: > > Hello OPSAWG and TSVWG, > > > We submited a new draft and posted it in the IETF datatracker > https://datatracker.ietf.org/doc/draft-song-opsawg-ipfix-ecn/ > > The following IPFIX information elements are introduced for L4S > ECN monitoring: > > - ECN field capture in protocol layer, including ECN field in > IPv4/IPv6 ECN field, MPLS EXP and tunnel ECN negotiation status > > - ECN codepoint statistics, including incremenatl and total count > for non-ECT, ECT(0), ECT(1) and CE packets > > - L4S performance indicator, providing short-term and long-term > view of congestion experienced by L4S traffic > > > Your review, comments and questions are welcome. > > > Best regards, > > Xueyan > > > > Original > *From: *[email protected] <[email protected]> > *To: *宋雪雁00038118;刘尧00165286; > *Date: *2025年12月26日 16:33 > *Subject: **New Version Notification for > draft-song-opsawg-ipfix-ecn-00.txt* > A new version of Internet-Draft draft-song-opsawg-ipfix-ecn-00.txt has been > successfully submitted by Xueyan Song and posted to the > IETF repository. > > Name: draft-song-opsawg-ipfix-ecn > Revision: 00 > Title: Export of L4S ECN in IP Flow Information Export (IPFIX) > Date: 2025-12-26 > Group: Individual Submission > Pages: 14 > URL: > https://www.ietf.org/archive/id/draft-song-opsawg-ipfix-ecn-00.txt > Status: https://datatracker.ietf.org/doc/draft-song-opsawg-ipfix-ecn/ > HTML: > https://www.ietf.org/archive/id/draft-song-opsawg-ipfix-ecn-00.html > HTMLized: > https://datatracker.ietf.org/doc/html/draft-song-opsawg-ipfix-ecn > > > Abstract: > > This document defines a set of IP Flow Information Export (IPFIX) > Information Elements for monitoring the Low Latency, Low Loss, and > Scalable throughput (L4S) service. Specially, these elements enable > network operators to monitor the Explicit Congestion Notification > (ECN) information of L4S deployment and performance of traffic. > > > > The IETF Secretariat > > > _______________________________________________ > OPSAWG mailing list -- [email protected] > To unsubscribe send an email to [email protected] > > --------------OQ98cyPksmjRiBsw4F1QNWAn Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit <!DOCTYPE html> <html> <head> <meta http-equiv="Content-Type" content="text/html; charset=UTF-8"> </head> <body> <p>The discussion prompted me to read this draft. I have two different questions about it:</p> <p>1) In what way is it related to L4S? Yes, L4S uses ECN. But ECN is not restricted to L4S.</p> <p>2) Even if we assume this only reports packets with ECN bits enabled (not 00), generating an IPFIX report for every data packet across many flows (in some environments, all flows) seems to be tremendous overhead. Since as I understnad it this is for management monitoring of operability, not for congestion response, that seems a massive overhead. Am I misreading the draft?</p> <p>Yours,</p> <p>Joel</p> <div class="moz-cite-prefix">On 1/11/2026 9:54 PM, <a class="moz-txt-link-abbreviated" href="mailto:[email protected]">[email protected]</a> wrote:<br> </div> <blockquote type="cite" cite="mid:20260112105412082AjWpb6aUT4FVPtEZvi2eu-Th6q7B73Y6EnDS1+zs4M5A@public.gmane.org"> <meta http-equiv="content-type" content="text/html; charset=UTF-8"> <div class="zcontentRow"> <p style="font-size:14px;font-family:微软雅黑,Microsoft YaHei;">Hi Greg,</p> <p style="font-size:14px;font-family:微软雅黑,Microsoft YaHei;"><br> </p> <p style="font-size:14px;font-family:微软雅黑,Microsoft YaHei;">Thank you for the good question.</p> <p style="font-size:14px;font-family:微软雅黑,Microsoft YaHei;">Yes, ECN is an end-to-end protocol, TCP sender intiates the signalling and TCP receiver responds. And I think IPFIX works in IP layer, so the target data extraction is at network nodes. For the information elements proposed in this drfat, the IPFIX extraction position may be different based on monitoring purposes. We plan to add the following text to section 5, does it work for you?</p> <p><em>The IPFIX IEs defined in this draft may have their information extraction positions adjusted based on different ECN monitoring purposes in the network. Among them, the basic ECN field elements are used to reflect the ECN codepoints carried in the IPv4 header, the IPv6 Traffic Class octet, or the MPLS EXP field. These fields can be flexibly extracted at any node along the path that has IPFIX export capability. For tunnel ECN negotiation status IEs, the IPFIX data can only be provided by the specific tunnel endpoints that participate in the negotiation. For cumulative statistics IEs, the statistical data may be processed with a higher priority at traffic aggregation or egress nodes.</em></p> <p style="font-size:14px;font-family:微软雅黑,Microsoft YaHei;"><br> </p> <p style="font-size:14px;font-family:微软雅黑,Microsoft YaHei;">For the mpls-ecn draft you shared, it appers to define a new ECN opcode encapsulated in MNA packets for MPLS data plane. I think it's actually relevant to the ipfix-ecn draft, if MPLS WG adopts it, we would like to add the ECN export from MPLS MNA packets to our draft.</p> <p style="font-size:14px;font-family:微软雅黑,Microsoft YaHei;"><br> </p> <p style="font-size:14px;font-family:微软雅黑,Microsoft YaHei;">Best regards,</p> <p style="font-size:14px;font-family:微软雅黑,Microsoft YaHei;">Xueyan</p> <p style="font-size:14px;font-family:微软雅黑,Microsoft YaHei;"><br> </p> <p style="display: none;" unonameen="Song Xueyan00038118" unonamech="宋雪雁00038118" class="zMailSignTitle"><label class="sign_nameUno"></label><span class="sign_arrow"></span></p> <p style="margin:0;line-height:20px;"><br> </p> <div class="zhistoryRow" style="display:block"> <div class="zhistoryDes" style="width: 100%; height: 28px; line-height: 28px; background-color: #E0E5E9; color: #1388FF; text-align: center;">Original</div> <div id="zwriteHistoryContainer"> <div class="control-group zhistoryPanel"> <div class="zhistoryHeader" style="padding: 8px; background-color: #F5F6F8;"> <div><strong>From: </strong><span class="zreadUserName">GregMirsky <a class="moz-txt-link-rfc2396E" href="mailto:[email protected]"><[email protected]></a></span></div> <div><strong>To: </strong><span class="zreadUserName" style="display: inline;">宋雪雁00038118;</span><span class="zreadUserName" style="display: inline;">Joel Halpern <a class="moz-txt-link-rfc2396E" href="mailto:[email protected]"><[email protected]></a>;</span></div> <div><strong>Cc: </strong><span class="zreadUserName" style="display: inline;"><a class="moz-txt-link-abbreviated" href="mailto:[email protected]">[email protected]</a> <a class="moz-txt-link-rfc2396E" href="mailto:[email protected]"><[email protected]></a>;</span><span class="zreadUserName" style="display: inline;"><a class="moz-txt-link-abbreviated" href="mailto:[email protected]">[email protected]</a> <a class="moz-txt-link-rfc2396E" href="mailto:[email protected]"><[email protected]></a>;</span><span class="zreadUserName" style="display: inline;">mpls <a class="moz-txt-link-rfc2396E" href="mailto:[email protected]"><[email protected]></a>;</span></div> <div><strong>Date: </strong><span class="">2026年01月11日 06:00</span></div> <div><strong>Subject: </strong><span class="zreadTitle"><strong>Re: [OPSAWG]Fw: New Version Notification for draft-song-opsawg-ipfix-ecn-00.txt</strong></span></div> </div> <div class="zhistoryContent"> <div dir="ltr">Hi Xueyan, <div>thank you for sharing the updated draft. A relatively new draft <a href="https://datatracker.ietf.org/doc/draft-halmir-mpls-ecn/" moz-do-not-send="true">draft-halmir-mpls-ecn</a> on supporting ECN in the MPLS using MNA might be of interest to you and others involved in the matter. And I have a question. As I understand the ECN, it is a host that is expected to act on the information collected in the ECN field along the path of a packet. If that is correct, who's the intended target of the IPFIX notification about the ECN? Is the intention to act on ECN information obtained on a segment, e.g., a tunnel, rather than based on the e2e ECN information? I read Section 5, but was left with these questions.</div> <br> <div>Regards,</div> <div>Greg</div> </div> <br> <div class="gmail_quote gmail_quote_container"> <div class="gmail_attr" dir="ltr">On Fri, Jan 9, 2026 at 1:53 AM <<a href="mailto:[email protected]" moz-do-not-send="true" class="moz-txt-link-freetext">[email protected]</a>> wrote:<br> </div> <blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote"> <div> <p style="font-size:14px;font-family:微软雅黑,"Microsoft YaHei"">Hello OPSAWG and TSVWG,</p> <p style="font-size:14px;font-family:微软雅黑,"Microsoft YaHei""><br> </p> <p style="font-size:14px;font-family:微软雅黑,"Microsoft YaHei"">We submited a new draft and posted it in the IETF datatracker <a href="https://datatracker.ietf.org/doc/draft-song-opsawg-ipfix-ecn/" moz-do-not-send="true" class="moz-txt-link-freetext">https://datatracker.ietf.org/doc/draft-song-opsawg-ipfix-ecn/</a></p> <p style="font-size:14px;font-family:微软雅黑,"Microsoft YaHei"">The following IPFIX information elements are introduced for L4S ECN monitoring:</p> <p style="font-size:14px;font-family:微软雅黑,"Microsoft YaHei"">- ECN field capture in protocol layer, including ECN field in IPv4/IPv6 ECN field, MPLS EXP and tunnel ECN negotiation status</p> <p style="font-size:14px;font-family:微软雅黑,"Microsoft YaHei"">- ECN codepoint statistics, including incremenatl and total count for non-ECT, ECT(0), ECT(1) and CE packets</p> <p style="font-size:14px;font-family:微软雅黑,"Microsoft YaHei"">- L4S performance indicator, providing short-term and long-term view of congestion experienced by L4S traffic</p> <p style="font-size:14px;font-family:微软雅黑,"Microsoft YaHei""><br> </p> <p style="font-size:14px;font-family:微软雅黑,"Microsoft YaHei"">Your review, comments and questions are welcome.</p> <p style="font-size:14px;font-family:微软雅黑,"Microsoft YaHei""><br> </p> <p style="font-size:14px;font-family:微软雅黑,"Microsoft YaHei"">Best regards,</p> <p style="font-size:14px;font-family:微软雅黑,"Microsoft YaHei"">Xueyan</p> <p style="display:none"><br> </p> <p style="margin:0px;line-height:20px"><br> </p> <div style="display:block"> <div style="width:100%;height:28px;line-height:28px;background-color:rgb(224,229,233);color:rgb(19,136,255);text-align:center">Original</div> <div id="m_-3763961488533818572zwriteHistoryContainer"> <div> <div style="padding:8px;background-color:rgb(245,246,248)"> <div><strong>From: </strong><a href="mailto:[email protected]" moz-do-not-send="true" class="moz-txt-link-freetext">[email protected]</a> <<a href="mailto:[email protected]" moz-do-not-send="true" class="moz-txt-link-freetext">[email protected]</a>></div> <div><strong>To: </strong><span style="display:inline">宋雪雁00038118;</span><span style="display:inline">刘尧00165286;</span></div> <div><strong>Date: </strong>2025年12月26日 16:33</div> <div><strong>Subject: </strong><strong>New Version Notification for draft-song-opsawg-ipfix-ecn-00.txt</strong></div> </div> <div>A new version of Internet-Draft draft-song-opsawg-ipfix-ecn-00.txt has been<br> successfully submitted by Xueyan Song and posted to the<br> IETF repository.<br> <br> Name: draft-song-opsawg-ipfix-ecn<br> Revision: 00<br> Title: Export of L4S ECN in IP Flow Information Export (IPFIX)<br> Date: 2025-12-26<br> Group: Individual Submission<br> Pages: 14<br> URL: <a href="https://www.ietf.org/archive/id/draft-song-opsawg-ipfix-ecn-00.txt" moz-do-not-send="true" class="moz-txt-link-freetext">https://www.ietf.org/archive/id/draft-song-opsawg-ipfix-ecn-00.txt</a><br> Status: <a href="https://datatracker.ietf.org/doc/draft-song-opsawg-ipfix-ecn/" moz-do-not-send="true" class="moz-txt-link-freetext">https://datatracker.ietf.org/doc/draft-song-opsawg-ipfix-ecn/</a><br> HTML: <a href="https://www.ietf.org/archive/id/draft-song-opsawg-ipfix-ecn-00.html" moz-do-not-send="true" class="moz-txt-link-freetext">https://www.ietf.org/archive/id/draft-song-opsawg-ipfix-ecn-00.html</a><br> HTMLized: <a href="https://datatracker.ietf.org/doc/html/draft-song-opsawg-ipfix-ecn" moz-do-not-send="true" class="moz-txt-link-freetext">https://datatracker.ietf.org/doc/html/draft-song-opsawg-ipfix-ecn</a><br> <br> <br> Abstract:<br> <br> This document defines a set of IP Flow Information Export (IPFIX)<br> Information Elements for monitoring the Low Latency, Low Loss, and<br> Scalable throughput (L4S) service. Specially, these elements enable<br> network operators to monitor the Explicit Congestion Notification<br> (ECN) information of L4S deployment and performance of traffic.<br> <br> <br> <br> The IETF Secretariat<br> <br> </div> </div> </div> </div> <p><br> </p> </div> _______________________________________________<br> OPSAWG mailing list -- <a href="mailto:[email protected]" moz-do-not-send="true" class="moz-txt-link-freetext">[email protected]</a><br> To unsubscribe send an email to <a href="mailto:[email protected]" moz-do-not-send="true" class="moz-txt-link-freetext">[email protected]</a><br> </blockquote> </div> </div> </div> </div> </div> <p><br> </p> </div> </blockquote> </body> </html> --------------OQ98cyPksmjRiBsw4F1QNWAn-- --===============2978221685993599912== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KT1BTQVdHIG1h aWxpbmcgbGlzdCAtLSBvcHNhd2dAaWV0Zi5vcmcKVG8gdW5zdWJzY3JpYmUgc2VuZCBhbiBlbWFp bCB0byBvcHNhd2ctbGVhdmVAaWV0Zi5vcmcK --===============2978221685993599912==--