Hi Haoyu, Thanks for your review and comments, please see some clarification replies inline with [Jie]:
-----Original Message----- From: Haoyu Song <[email protected]> Sent: Thursday, January 8, 2026 4:36 AM To: Dongjie (Jimmy) <[email protected]>; RTGWG <[email protected]> Cc: FANTEL <[email protected]> Subject: RE: New Version Notification for draft-dong-fantel-problem-statement-03.txt Jimmy, Thank you for updating the draft. I just reviewed it and think it addresses a practical gap in today's network. I have a few questions and comments. 1. Regarding to the term, my feeling is that the proposal gist is not providing "faster" notifications, but more informative and more targeted active notifications to allow faster and more precise reactions. After all, most existing notifications are also immediate, and limited only by forwarding delay. [Jie] We agree that more informative is also an important aspect of the notification, while "fast" is the core characteristic of the network notification mechanism we would like to emphasize. To my understanding it contains two aspects: the first is the notification needs to be generated timely from the originating node, the second is to reduce the delivery time to the targeted recipient, so that they can take action within the required time scale. Section 4 of this draft gives analysis about the slow dissemination issue of the existing mechanisms, and shows the need for fast network notification. 2. Conventionally, network devices only deal with link/device failures and leave the temporal congestion to end host transport. The draft suggests including rich information such as congestion status in the notifications. It's not clear how network devices will deal with this without interfering with the e2e flow control which could be faster to react. i.e., the recipient determines the information needed in the notification. This should be considered when designing the information model otherwise it could be a security/operational concern. [Jie] The awareness of dynamic network status (such as congestion status) on network nodes allow the network to take some action at the network layer (e.g., traffic engineering and load balancing) to address or mitigate the problem in a timely manner, so that in some cases the e2e based mechanism (e.g., congestion control) does not need to be triggered frequently. IMO the mechanisms in the network layer and other layers can coexist, and some coordination may be needed. I agree this needs to be considered in the information model. 3. It's not clear from the documents if the response mechanism for the notification is in scope or not? For example, FRR is a response mechanism. If it's flawed as said in the draft, is the solution in scope of FANTEL? [Jie] Although there is one sub-section describing the possible actions to the fast notifications, the detailed action mechanisms are considered out of scope. We can make this clearer in next revision. 4. It seems that the subscription-based notifications will require involving the network control plane of the notification sender. Will that affect the "fast" promise and incur too much complexity? [Jie]The subscription-based mechanism is given as an example of the possible approaches to reduce the overhead of notification. If later it is considered that subscription is needed, the detailed subscription mechanism will be specified in a separate document. In my opinion the subscription could be done in advance, so that it will not impact the speed of notification. Best regards, Jie Best regards, Haoyu -----Original Message----- From: Dongjie (Jimmy) <[email protected]> Sent: Wednesday, January 7, 2026 1:19 AM To: RTGWG <[email protected]> Cc: FANTEL <[email protected]> Subject: [rtgwg] Re: New Version Notification for draft-dong-fantel-problem-statement-03.txt Dear all, We just submitted a new version (-03) of fantel problem statement draft to incorporate the comments received both on the list and offline. Thanks again for all the review, discussion and suggestions. The major changes in this version include: - A new coauthor joined: Reshad Rahman. - In the introduction section, some descriptions about the hardware capability in detecting network condition change at fine-grained time scales were added, which shows the gaps in fast network notifications. - The expected operating time range of fast network notifications was clarified. - The content in section 3 and section 4 was reorganized to improve readability and avoid duplication. - The descriptions about ECN mechanism were corrected. - Figure 1 was updated to better reflect the problem space in section 4.1. - Some explanation about the content of Table 2 was added. - Some description about multiple recipients of the same notification was added. - The security considerations section was enhanced. As always, further review and discussion are appreciated. One thing for open discussion is, whether we should keep using the term "FANTEL" which was introduced at the BoF, or change it to something like "FANN (FAst Network Notification)" to better reflect the scope of this work? Any feedback is welcome. The authors believe this version is in a good shape for the RTGWG to consider adoption or a consensus call. And we would like to see these problems being worked on in the IETF. Guidance from the AD and the RTG chairs are much appreciated. Best regards, Jie (on behalf of coauthors) -----Original Message----- From: [email protected] <[email protected]> Sent: Wednesday, January 7, 2026 4:19 PM To: Francois Clad (editor) <[email protected]>; Dongjie (Jimmy) <[email protected]>; Luis M. Contreras <[email protected]>; Mike McBride (editor) <[email protected]>; DURMUS Mehmet <[email protected]>; Francois Clad <[email protected]>; Hao Lu <[email protected]>; Jeffrey Zhang <[email protected]>; Dongjie (Jimmy) <[email protected]>; Luis Contreras <[email protected]>; Mehmet Durmus <[email protected]>; Mike McBride <[email protected]>; Ran Pang <[email protected]>; Reshad Rahman <[email protected]>; Rui Zhuang <[email protected]>; Xiaohu Xu <[email protected]>; Yadong Liu <[email protected]>; Yongqing Zhu <[email protected]>; Zhaohui Zhang <[email protected]> Subject: New Version Notification for draft-dong-fantel-problem-statement-03.txt A new version of Internet-Draft draft-dong-fantel-problem-statement-03.txt has been successfully submitted by Jie Dong (editor) and posted to the IETF repository. Name: draft-dong-fantel-problem-statement Revision: 03 Title: Fast Network Notifications Problem Statement Date: 2026-01-07 Group: Individual Submission Pages: 17 URL: https://www.ietf.org/archive/id/draft-dong-fantel-problem-statement-03.txt Status: https://datatracker.ietf.org/doc/draft-dong-fantel-problem-statement/ HTMLized: https://datatracker.ietf.org/doc/html/draft-dong-fantel-problem-statement Diff: https://author-tools.ietf.org/iddiff?url2=draft-dong-fantel-problem-statement-03 Abstract: Modern networks require adaptive traffic manipulation including Traffic Engineering (TE), load balancing, flow control, and protection, to support high-throughput, low-latency, and lossless applications such as Artificial Intelligence (AI) /Machine Learning (ML) training and real-time services. A good and timely understanding of network operational status, such as congestion and failures, can help to improve network utilization, enable the selection of paths with reduced latency, and enable faster response to critical events. This document describes the existing problems and why a new set of fast network notification solutions are needed. The IETF Secretariat _______________________________________________ rtgwg mailing list -- [email protected] To unsubscribe send an email to [email protected] _______________________________________________ rtgwg mailing list -- [email protected] To unsubscribe send an email to [email protected]
