[Fann] 回复：Re: 回复：Re: Call for adoption: draft-dong-fann-problem-statement-00 (Ends 2026-08-18)

[Eddie Ruan <[e-mail]>]

Hi, Jie
Sounds good to me. 
By the way, I just hosted a SONiC forum in Beijing on August 8th. the full event recap could be found at https://sonicfoundation.dev/sonic-china-forum-2026-from-scale-up-standard-to-the-open-source-networking-landscape/ <https://sonicfoundation.dev/sonic-china-forum-2026-from-scale-up-standard-to-the-open-source-networking-landscape/ >
Two of the sessions discussed 'scale across' networking, but proposed different technical approaches: one suggested utilizing switch chips, while the other suggested for routing chips. Despite these different methods, I agree with them that scale-across is fundamentally distinct from traditional DCI use cases.
I plan to lead SONiC routing WG to discuss scale across needed feature set in Sep and eventually come up SONiC Scale across reference architecture. Notifications would be a critical piece in this discussion. Maybe two WG could partner and leverage each other’s progress in the future.
Thanks
Eddie
------------------------------------------------------------------
发件人：Dongjie (Jimmy) <jie.dong=[e-mail]>
发送时间：2026年8月10日(周一) 00:58
收件人："Ruan, Yixing"<[e-mail]>; Joel Halpern<[e-mail]>; "[e-mail]"<[e-mail]>
抄　送："[e-mail]"<[e-mail]>
主　题：[Fann] Re: 回复：Re: Call for adoption: draft-dong-fann-problem-statement-00 (Ends 2026-08-18)
Hi Eddie, 
Thanks for your reply to this point, and the view on different implementations of the end hosts/NICs/DPUs.
I agree that in IETF the generation and delivery of fast network notifications can be decoupled from the actions taken on them, and the scope of “network node” in the charter cover both the transit network nodes and the ingress network node, which may take different actions in difference use cases. 
Section 4.2 of the problem statement draft gives further classification of the recipients to identify their roles and possible actions. It shows that fast network notifications may be sent to and consumed by different types of nodes. 
As for the inconsistent terminology in the charter and the problem statement draft, as the charter uses “nodes”/“network nodes”, to align with the charter and take your input into consideration, the problem statement draft could replace “end hosts” with “sending nodes”. We will make this change if there is no objection to it. 
Best regards,
Jie
From: Eddie Ruan <eddie.ruan=[e-mail]> 
Sent: Wednesday, August 5, 2026 11:30 PM
To: Dongjie (Jimmy) <[e-mail]>; Joel Halpern <[e-mail]>; [e-mail]
Cc: [e-mail]
Subject: 回复：[Fann] Re: Call for adoption: draft-dong-fann-problem-statement-00 (Ends 2026-08-18)
Hi，
Thanks for raising this. The confusion is real, and as chairs we think it comes from the charter and the draft using different vocabulary rather than from an actual disagreement about scope. 
The short version of where we see the line: FANN defines what notifications a fabric generates and how they are delivered; it does not define how a transport reacts to them. An end host can therefore legitimately receive a FANN notification without transport-layer congestion control becoming FANN work. That is the distinction the IETF 126 comment was drawing, and we should have stated it more clearly at the time. 
On "node": the charter consistently says "nodes" / "network nodes", while §4.2 of the draft under adoption lists End Hosts as a recipient. Those two are only inconsistent if "network node" is read as "router/switch". We do not read it that way. It is really depending on the use cases. For AI cluster, we have seen two different approaches. Cloud providers tends to include end hosts into AI fabric consideration, such as Microsoft / Open AI’s MRC, Alibaba’s HPN., while some enterprise customers may still want to keep AI fabric for traditional network devices. 
Smart NICs/DPUs started their journey before the AI wave and remain costly. So outside bare-metal use cases, the adoption has been limited. In large AI clusters we more often see "super NICs" than DPUs getting deployed. But either way the NIC increasingly performs fabric functions: e.g. MRC-style designs rely on the NIC to impose SRv6 encapsulation and steer flows onto selected paths. The charter's choice of "nodes" correctly captures this blurring host/network boundary instead of freezing a legacy network devices only. 
On the broader framing, we would like to propose that FANN focus explicitly on AI infrastructure across scale-up, scale-out, and scale-across (DCI). Even within those three the boundary differs. For scale-out, cloud providers generally treat the end host as part of the AI fabric solution, while some enterprise deployments prefer VOQ-style in-network approaches with no host involvement. 
FANN Charter has already accommodated the blurring host/network boundary. Instead we would ask the authors to align §4.2 with the charter's vocabulary: "nodes, including host-resident fabric elements" rather than "End Hosts”. 
From there, let us describe the problems and develop solutions against specific use cases. 
Thanks
Carlos & Eddie
------------------------------------------------------------------
发件人：Dongjie (Jimmy) <jie.dong=[e-mail] <mailto:jie.dong=[e-mail] >>
发送时间：2026年8月3日(周一) 03:15
收件人：Joel Halpern<[e-mail] <mailto:[e-mail] >>; "[e-mail] <mailto:[e-mail] >"<[e-mail] <mailto:[e-mail] >>
抄　送："[e-mail] <mailto:[e-mail] >"<[e-mail] <mailto:[e-mail] >>
主　题：[Fann] Re: Call for adoption: draft-dong-fann-problem-statement-00 (Ends 2026-08-18)
Hi Joel,
Thanks for your reply and the interpretation of the charter scope. Yes there is no qualification of the “remote nodes” in the charter text, from this point I agree that notifications to hosts seem to be in the charter, and it is also mentioned in the current problem statement draft. 
In my reply to Min’s question (which was sent to this adoption call thread), I just provided my personal understanding to the concerns raised about “notifications to the host” during the IETF FANN session. For further discussion on this point , a separate thread may be more appropriate. 
Best regards,
Jie
From: Joel Halpern <[e-mail] <mailto:[e-mail] >> 
Sent: Thursday, July 30, 2026 11:51 PM
To: Dongjie (Jimmy) <jie.dong=[e-mail] <mailto:jie.dong=[e-mail] >>; [e-mail] <mailto:[e-mail] >
Cc: [e-mail] <mailto:[e-mail] >
Subject: [Fann] Re: Call for adoption: draft-dong-fann-problem-statement-00 (Ends 2026-08-18)
Jie,
 It is unclear whether your emails intends to claim that the scoping of the WG is up to the WG. The question of whether to treat all parts of the scope as one, or as I and others would prefer to be more explicit about various segments of the scope and their differences, is indeed up to the WG. However, the overall scoping is not. Unless we choose to update the charter and get IESG approval of such an update, the charter is clear that notifications are to "remote nodes" without any qualification as to "network nodes", "host nodes", "control nodes", etc. As such, notifications to hosts would seem to be as much in charter as notifications to any of the other kinds of nodes that are discussed. Whether we choose adopt any problem descriptions, requirements, or later solutions, for any given subset is up to the working group. But the scope of the WG is defined by the charter.
Yours,
Joel
On 7/30/2026 11:37 AM, Dongjie (Jimmy) wrote:
Hi Min, 
Thanks for raising the question about the scope of the WG. This is a topic for WG discussion, and further discussion on the WG scope could happen on a separate thread. 
I can just share some personal view. As specified in section 4.2 of this draft, the fast network notifications can be sent to different types of recipients, which include adjacent network nodes, network nodes which are multiple hops away, the ingress network nodes, and the end hosts. While the type of recipients is not explicitly mentioned in the WG charter text. IMO the comment during IETF 126 meeting was mainly about the possible overlap/interaction with the work in the transport area, which was also raised in the TSV review of this draft. Another point is whether FANN will define a unified notification mechanism which applies to both the network nodes, and the hosts/edge nodes, or separate notification mechanisms need to be defined for network nodes and the hosts respectively. And if separate notifications are needed, which one should be prioritized in the WG? Currently I have no answer to these questions, the problem statement draft can be updated to reflect the WG’s decision.
Best regards,
Jie
From:[e-mail] <mailto:[e-mail] ><[e-mail]> <mailto:[e-mail] >
Sent: Thursday, July 30, 2026 11:09 AM
To: [e-mail] <mailto:[e-mail] >
Cc: [e-mail] <mailto:[e-mail] >; [e-mail] <mailto:[e-mail] >; [e-mail] <mailto:[e-mail] >
Subject: Re: [Fann] Call for adoption: draft-dong-fann-problem-statement-00 (Ends 2026-08-18)
Hi all,
In Section 4.2 of this draft in adoption poll, it describes *End Hosts* as a type of recipient of fast network notification, however when I presented problems and gap analysis for DCI congestion notification at IETF 126, I heard a statement that said if the end host is a consumer of congestion notification then the congestion notification is outside the scope of the FANN WG, so what on earth is it within or outside the scope of this new working group?
 Cheers,
Xiao Min
Original
From: CarlosJesúsBernardosviaDatatracker <[e-mail] <mailto:[e-mail] >> 
To: [e-mail] <mailto:[e-mail] > <[e-mail] <mailto:[e-mail] >>;[e-mail] <[e-mail] <mailto:[e-mail] >>;[e-mail] <[e-mail] <mailto:[e-mail] >>; 
Date: 2026年07月28日 20:02 
Subject: [Fann] Call for adoption: draft-dong-fann-problem-statement-00 (Ends 2026-08-18) 
This message starts a fann WG Call for Adoption of:
 draft-dong-fann-problem-statement-00
 This Working Group Call for Adoption ends on 2026-08-18
 Abstract:
 Many network applications, ranging from Artificial Intelligence (AI)
 /Machine Learning (ML) training/inference to cloud services, require
 networks with various combination of high bandwidth, low delay and
 low jitter and minimal packet loss in data transfer. This requires
 that the networks must rapidly adapt to the presence of faults,
 degradation and congestion. However, existing routing and traffic
 management mechanisms often face limitations in responsiveness,
 coverage, and operational complexity, particularly in large-scale and
 high-bandwidth network environments (e.g. data center (DC) and data
 center interconnect (DCI)). A good and timely understanding of
 network conditions can help to enable faster response to critical
 events, so as to enable the selection of paths with reduced latency
 and improve network utilization. This document describes the gap
 analysis and the need for fast network notification, and identifies
 the set of problems which a fast network notification solution needs
 to address.
 Please reply to this message and indicate whether or not you support adoption
 of this Internet-Draft by the fann 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/ <https://datatracker.ietf.org/doc/bcp78/ >
 [2] https://datatracker.ietf.org/doc/bcp79/ <https://datatracker.ietf.org/doc/bcp79/ >
 [3] https://datatracker.ietf.org/doc/rfc6701/ <https://datatracker.ietf.org/doc/rfc6701/ >
 The IETF datatracker status page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-dong-fann-problem-statement/ <https://datatracker.ietf.org/doc/draft-dong-fann-problem-statement/ >
 There is also an HTMLized version available at:
https://datatracker.ietf.org/doc/html/draft-dong-fann-problem-statement-00 <https://datatracker.ietf.org/doc/html/draft-dong-fann-problem-statement-00 >
 _______________________________________________
 Fann mailing list -- [e-mail] <mailto:[e-mail] >
 To unsubscribe send an email to [e-mail] <mailto:[e-mail] >
_______________________________________________Fann mailing list -- [e-mail] <mailto:[e-mail] >To unsubscribe send an email to [e-mail] <mailto:[e-mail] >