Exactly. This draft does not assume instantaneous signaling or bypassing laws of physics. The intent is to describe a real operational gap between what the data plane can observe and what routing/te systems can consume today. And we aren't starting from scratch. There have already been solution discussions in rtgwg that explore faster or more targeted off-path dissemination of network notifications.
The problem statement appears sufficiently well defined (yes, I'm biased) and in scope for rtgwg. Draft adoption would allow the wg to refine the problem statement, align on requirements and determine which solution approaches are viable. mike -----Original Message----- From: Adrian Farrel <[email protected]> Sent: Sunday, January 18, 2026 5:37 AM To: '[email protected]' <[email protected]>; 'Dongjie' <[email protected]> Cc: [email protected]; [email protected] Subject: [fantel] Re: [rtgwg] Re: Re: Re: Call for adoption: draft-dong-fantel-problem-statement-03 (Ends 2026-01-30) I agree, John, we are not going to change the laws of physics. And we already have some on-path notification mechanisms (notably BFD) that do a pretty good job. What we lack is rapid (i.e., more rapid than IGP convergence) off-path updates about changes in network characteristics that can be used by nodes that operate on the (TE) link state database. So, the point is, I think, to try to understand the problem statement and the consequent requirements. Then we can try to work out whether solutions are possible. Cheers, Adrian -----Original Message----- From: [email protected] <[email protected]> Sent: 17 January 2026 20:52 To: Dongjie <[email protected]> Cc: [email protected]; [email protected] Subject: [rtgwg] Re: [fantel] Re: Re: Call for adoption: draft-dong-fantel-problem-statement-03 (Ends 2026-01-30) Jie, What bothers me about this approach is that it presumes that there is a magical delivery mechanism that this group will discover that delivers instantaneous messages. This is clearly absurd; we have what we have. John Sent from my iPhone > On Jan 17, 2026, at 3:12 AM, Dongjie (Jimmy) > <[email protected]> wrote: > Hi Joel, > > You're right that the focus of this document is on notification. The goal is > to minimize the delivery time of the notification, and to provide > fine-grained network condition information to enable prompt and precise > actions. These enhancements in notification could help to improve the > performance of the applications, including those that require very-low-loss > delivery. > > As for the applicable use cases, we believe fast network notification in > general can help in all these use cases. It is understood that the delivery > time and some specific processing can be different in some of these cases, > while it is expected that the design principle and basic mechanism for fast > notification could be shared. What we are doing at this stage is collecting > all the required characteristics and information for fast network > notifications, so as to show the general problem space. In the next step they > could be further classified into common information and characteristics and > scenario-specific information and characteristics using a detailed > information model, which would be used to guide the solution design. > > Best regards, > Jie > >> -----Original Message----- >> From: Joel Halpern <[email protected]> >> Sent: Saturday, January 17, 2026 1:23 AM >> To: Dongjie (Jimmy) <[email protected]>; Yingzhen Qu >> <[email protected]>; [email protected]; [email protected] >> Subject: Re: [fantel] Re: [rtgwg] Re: Call for adoption: >> draft-dong-fantel-problem-statement-03 (Ends 2026-01-30) >> >> If the focus is on notifications, and not on the responses to >> notifications, then issues such as very-low-loss delivery should be >> described as potential results, not as goals of the work. >> >> Separately, I think it is a mistake to conflate the intra-data >> center, one-hop-wan, and arbitrary communication path cases. The >> time and processing constraints for these cases are VERY different, >> and likely useful notification approaches are likely to be different >> (and some cases may not be amenable to significant improvement). As >> such, at the very least I would expect identification of problem >> spaces with different characteristics, and possibly explicit statements that >> they should be addressed with different techniques. >> >> Yours, >> >> Joel >> >>> On 1/15/2026 10:13 PM, Dongjie (Jimmy) wrote: >>> Hi Joel, >>> Many thanks to your review and clarification questions. Please see >>> replies >> inline: >>> -----Original Message----- >>> From: Joel Halpern <[email protected]> >>> Sent: Friday, January 16, 2026 5:09 AM >>> To: Yingzhen Qu <[email protected]>; [email protected]; >>> [email protected] >>> Subject: [rtgwg] Re: [fantel] Call for adoption: >> draft-dong-fantel-problem-statement-03 (Ends 2026-01-30) >>> I have several basic concerns with the draft. >>> 1) The draft starts by asserting that there is a need for lossless >>> traffic >> delivery. It is possible you actually mean lossless. In which case >> I consider the target impossible for any general use network. It is >> mor elikely you mean very low loss (e.g 1 in 10^6 packet loss over >> any 1 minute time period.) If so, you need to state that and not refer to >> "lossless". >>> [Jie] Thanks for pointing this out. "Lossless" used in the abstract >>> and the >> introduction section refers to the expectation of some applications >> to the network. This is similar to the target of Detnet on "zero >> congestion loss". For the network it is difficult to guarantee >> lossless in all scenarios and situations, what it network can do is >> to minimize packet loss and control the loss rate below certain level >> (as you suggested), so that it does not impact the performance of the >> applications. We can clarify this further in next revision, and consider to >> use other word to avoid confusion. >>> 2) Unless I missed it, other than in terms of examples the draft >>> does not >> seem to state whether it wants to solve an intra-data-center problem >> (a interesting, important, and solvable problem), one hop wide are >> anetwork ( aproblem where it may be possible to do something, >> depending upon the link delay, srbitrary but special constructed wide >> area interconnects (demonstrated to be addressable by throwing money >> at the problem), or arbitrary multi-use, multi-hop wide area >> networks. The demands and difficulties of these different cases are >> different. >>> [Jie] The network scenarios you listed above are considered as >>> potential use >> cases of the fast notification mechanism. I agree there are >> differences in these cases, while in general fast notification would >> help to enable prompt and precise action upon network condition >> changes. Thus it is not limited to any specific network scenario. >>> 3) There is also an assertion that "faster" responsiveness to issues >>> is >> needed. Without some quantification of what kind of speed is needed, I do >> not see how this claim can be evaluated, nor how solutions can be considered. >>> [Jie] Based on the discussion during the BoF and in RTGWG, in recent >> revisions some text was added to the introduction and section 3 to >> quantify the expected speed of fast notification (in the order of >> sub-milliseconds or milliseconds), and why it is considered faster than >> existing mechanisms. >>> Net: While I see a nice sketch of a topic for investigation, I do >>> not see >> enough clarity for adoption. >>> [Jie] Hope the above can answer your clarification questions. >>> [Jie] BTW, after the submission of the -03 version, we asked the WG >>> to give >> opinion on which term to use for this work. "Fantel" was previously >> used for the BoF and in several drafts following that, while >> according to the discussion and feedbacks, we would focus on the >> notification part and not limit the actions to TE and load balancing. >> Thus another term "FANN" was proposed for "FAst Network >> Notification". We'd appreciate your opinion on which term is better, or you >> are welcome to propose other terms. Thanks. >>> Bes regards, >>> Jie >>> Yours, >>> Joel >>> On 1/15/2026 2:12 PM, Yingzhen Qu via Datatracker wrote: >>>> 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://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fd >>>> atatracker.ietf.org%2Fdoc%2Fbcp78%2F&data=05%7C02%7Cmichael.mcbride >>>> %40futurewei.com%7C87cd1a3f1b784446fba108de5696a40c%7C0fee8ff2a3b24 >>>> 0189c753a1d5591fedc%7C1%7C0%7C639043402190832266%7CUnknown%7CTWFpbG >>>> Zsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsI >>>> kFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=OwzUOcJosDA7gClh >>>> ZDTlRUrUd%2B%2FR6j3G7cg4Dz50oPM%3D&reserved=0 >>>> [2] >>>> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fd >>>> atatracker.ietf.org%2Fdoc%2Fbcp79%2F&data=05%7C02%7Cmichael.mcbride >>>> %40futurewei.com%7C87cd1a3f1b784446fba108de5696a40c%7C0fee8ff2a3b24 >>>> 0189c753a1d5591fedc%7C1%7C0%7C639043402190858963%7CUnknown%7CTWFpbG >>>> Zsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsI >>>> kFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=d68HRABPMFw4waPM >>>> 0bZJJcGcEUoB0csUfipKvqLtFvY%3D&reserved=0 >>>> [3] >>>> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fd >>>> atatracker.ietf.org%2Fdoc%2Frfc6701%2F&data=05%7C02%7Cmichael.mcbri >>>> de%40futurewei.com%7C87cd1a3f1b784446fba108de5696a40c%7C0fee8ff2a3b >>>> 240189c753a1d5591fedc%7C1%7C0%7C639043402190874810%7CUnknown%7CTWFp >>>> bGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiI >>>> sIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=%2BZx1UiNV8Ssl >>>> PRqfYCj5k96icN4vnG6NKnpWe7nK2x0%3D&reserved=0 >>>> The IETF datatracker status page for this Internet-Draft is: >>>> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fd >>>> atatracker.ietf.org%2Fdoc%2Fdraft-dong-fantel-problem-statement%2F& >>>> data=05%7C02%7Cmichael.mcbride%40futurewei.com%7C87cd1a3f1b784446fb >>>> a108de5696a40c%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C6390434 >>>> 02190886807%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiI >>>> wLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7 >>>> C%7C%7C&sdata=x7KlwlcMGeTpKRZzkqw%2Bw%2B763TpuseaaivbZVtrAcCc%3D&re >>>> served=0 There is also an HTMLized version available at: >>>> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fd >>>> atatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-dong-fantel-problem-statem >>>> &data=05%7C02%7Cmichael.mcbride%40futurewei.com%7C87cd1a3f1b784446f >>>> ba108de5696a40c%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C639043 >>>> 402190899804%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOi >>>> IwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0% >>>> 7C%7C%7C&sdata=zMgbrrcDxGjkuxW1xP3q9L4qhTxFqI54rRF%2FnjUttII%3D&res >>>> erved=0 >>>> ent-03 >>>> A diff from the previous version is available at: >>>> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fa >>>> uthor-tools.ietf.org%2Fiddiff%3Furl2%3Ddraft-dong-fantel-problem-st >>>> &data=05%7C02%7Cmichael.mcbride%40futurewei.com%7C87cd1a3f1b784446f >>>> ba108de5696a40c%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C639043 >>>> 402190911535%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOi >>>> IwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0% >>>> 7C%7C%7C&sdata=cWr0kGxnMOqNDfFLbZ8sW4IOXlzkzBH5zWy8BRpTCYM%3D&reser >>>> ved=0 >>>> atement-03 >>>> _______________________________________________ >>>> fantel 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] _______________________________________________ >>> fantel 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] _______________________________________________ rtgwg mailing list -- [email protected] To unsubscribe send an email to [email protected] _______________________________________________ fantel 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]
