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

[Joel Halpern <[e-mail]>]

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] <[e-mail]>
> *Sent:* Thursday, July 30, 2026 11:09 AM
> *To:* [e-mail]
> *Cc:* [e-mail]; [e-mail]; 
> [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]>
>
> *To: *[e-mail] <[e-mail]>;[e-mail] 
> <[e-mail]>;[e-mail] 
> <[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/
> [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-fann-problem-statement/
>
> There is also an HTMLized version available at:
> https://datatracker.ietf.org/doc/html/draft-dong-fann-problem-statement-00
>
> _______________________________________________
> Fann mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>
>
> _______________________________________________
> Fann mailing list [e-mail]
> To unsubscribe send an email [e-mail]