Hi Zafar, Thanks for your support to this work. And please see replies to your comments inline:
From: Zafar Ali (zali) <[email protected]> Sent: Thursday, January 29, 2026 2:06 PM To: 'Yingzhen Qu' <[email protected]> Cc: [email protected]; [email protected]; [email protected]; [email protected]; Zafar Ali (zali) <[email protected]> Subject: Re: [fantel] Re: [rtgwg] Call for adoption: draft-dong-fantel-problem-statement-03 (Ends 2026-01-30) Dear chairs and the WG: I support the adoption of the draft. It is a good starting point. Here are some comments that IMO will help refine and focus the document: * The term "fast" is a bit problematic. This is because the draft lists a wide range of receivers for those notifications, from forwarding ASICs to controllers, but their real-time requirements differ by orders of magnitude. In other words, the draft needs some focus. Trying to build something too generic can result in an outcome that is not suitable for the main target use cases. E.g., a solution targeted for handling in the fast path (silicon) is different from one handled by control-plane protocols or controllers. [Jie] To my understanding this comment is not on the term, but more about the type of recipients listed in the draft. As discussed during IETF 124 meeting, the scope would be focusing on the problem of fast notification mechanism delivered in data plane, and its major purpose is for actions in data plane. While the information may also be used by recipients in different layers (consider the role of BFD in connectivity failure detection). We will clarify this in next revision. * The focus should be on the AI workflow, and hence it would be good to discuss which deployments we target (scale up, scale across, scale out). Is it possible to factor in specific topologies in certain domains, or should we generalize the solution to any topology? [Jie] As discussed at the Fantel BoF, the major use cases is for AI/ML services, and there are also use cases for other cloud based services. At current stage we want to generalize the problem and take the requirements in different scenarios/topologies into consideration. In the next step the difference in use cases and deployment topologies will be considered, and both the common characteristics and scenario-specific information could be specified in an information model, which would be used to guide the solution design for different use cases. We can add some clarification text about this in next revision. * A clarification is needed that notifications serve a different purpose than routing protocols or OAM mechanisms. [Jie] You are right the role of fast notification is different from that of routing protocol and OAM mechanisms. We will consider to clarify this in next revision. * Sec. 5.4 discusses "Actions to Fast Network Notifications". Providing some guidelines in this document may be fine, but the reaction to a notification should largely be out of scope of this work. [Jie] Fully agree, we will make it clearer that the action mechanisms to fast network notification are out of the scope. Best regards, Jie Thanks Regards ... Zafar -----Original Message----- From: Yingzhen Qu via Datatracker <[email protected]<mailto:[email protected]>> Sent: Thursday, January 15, 2026 2:12 PM To: [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]> Subject: [rtgwg] Call for adoption: draft-dong-fantel-problem-statement-03 (Ends 2026-01-30) [EXTERNAL EMAIL] This message starts a rtgwg WG Call for Adoption of: draft-dong-fantel-problem-statement-03 This Working Group Call for Adoption ends on 2026-01-30 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. Please reply to this message and indicate whether or not you support adoption of this Internet-Draft by the rtgwg WG. Comments to explain your preference are greatly appreciated. Please reply to all recipients of this message and include this message in your response. Authors, and WG participants in general, are reminded of the Intellectual Property Rights (IPR) disclosure obligations described in BCP 79 [2]. Appropriate IPR disclosures required for full conformance with the provisions of BCP 78 [1] and BCP 79 [2] must be filed, if you are aware of any. Sanctions available for application to violators of IETF IPR Policy can be found at [3]. Thank you. [1] https://datatracker.ietf.org/doc/bcp78/ [2] https://datatracker.ietf.org/doc/bcp79/ [3] https://datatracker.ietf.org/doc/rfc6701/ The IETF datatracker status page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-dong-fantel-problem-statement/ There is also an HTMLized version available at: https://datatracker.ietf.org/doc/html/draft-dong-fantel-problem-statement-03 A diff from the previous version is available at: https://author-tools.ietf.org/iddiff?url2=draft-dong-fantel-problem-statement-03 _______________________________________________ rtgwg mailing list -- [email protected]<mailto:[email protected]> To unsubscribe send an email to [email protected]<mailto:[email protected]> _______________________________________________ fantel mailing list -- [email protected]<mailto:[email protected]> To unsubscribe send an email to [email protected]<mailto:[email protected]>
_______________________________________________ rtgwg mailing list -- [email protected] To unsubscribe send an email to [email protected]
