Tgank you for the replies. It probably would help to reference traffic sampling as the assumed behavior. This could be coupled with some discussion of why the risk of bias in the result of sampling a varying stream, likely with some patterns in its variation, is low.Yours,JoelSent via the Samsung Galaxy S20 FE 5G, an AT&T 5G smartphone -------- Original message --------From: [email protected] Date: 1/12/26 11:04 PM (GMT-05:00) To: [email protected] Cc: [email protected], [email protected], [email protected] Subject: Re: [tsvwg] Re: [OPSAWG]Fw: New Version Notification for draft-song-opsawg-ipfix-ecn-00.txt Hi Joel,Thank you for taking time to read the draft, and providing new aspects we need to consider, we will make updates to the draft to reflect your comments.Please also see my reply inline.Best regards,Xueyan (on behalf-of co-authors)OriginalFrom: JoelHalpern <[email protected]>To: 宋雪雁00038118;Cc: [email protected] <[email protected]>;[email protected] <[email protected]>;[email protected] <[email protected]>;Date: 2026年01月12日 23:56Subject: [tsvwg] Re: [OPSAWG]Fw: New Version Notification for draft-song-opsawg-ipfix-ecn-00.txtThe 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.>>Xueyan: The main consideration for L4S service is that L4S introduces a new ECN codepoint ECT(1) for traffic identification, it helps the diferenciation between classical and L4S traffic and uses CE codepoint for potential congestion mark. The monitoring of ECN can provide Operators with valuable insights, including the ratio of L4S traffic in the network, statistics of network congestion and granular visibility for the performance of L4S services.But the ECN monitoring in this draft is not limited to L4S, for example, we also provide the monitoring IEs for ECN(0) and non-ECT, with a flexible design to satisfy user's monitoring requirements.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?>>Xueyan: Yes, we agree that doing this per packets would create too much overhead. In real deployment, IPFIX performs probalistic sampling for data collection based on user requirements instead of extracting data per packet. The specifi data export is determined by IPFIX configurations and device capabilities, but the general rule is to avoid creating heavy overhead to network nodes.Best regardsXueyanYours,JoelOn 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 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:00Subject: Re: [OPSAWG]Fw: New Version Notification for draft-song-opsawg-ipfix-ecn-00.txtHi Xueyan,thank you for sharing the updated draft. A relatively new draft 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 OriginalFrom: [email protected] <[email protected]>To: 宋雪雁00038118;刘尧00165286;Date: 2025年12月26日 16:33Subject: New Version Notification for draft-song-opsawg-ipfix-ecn-00.txtA 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]
_______________________________________________ OPSAWG mailing list -- [email protected] To unsubscribe send an email to [email protected]
