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

xiao.min2@zte.com.cn Fri, 31 July 2026 06:10 UTC

Return-Path: <xiao.min2@zte.com.cn>
X-Original-To: fann@mail2.ietf.org
Delivered-To: fann@mail2.ietf.org
Received: from localhost (localhost [127.0.0.1]) by mail2.ietf.org (Postfix) with ESMTP id 9F0191216C59B for <fann@mail2.ietf.org>; Thu, 30 Jul 2026 23:10:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1785478203; bh=kd4UhlHFu0YPwKAQCAAxwjKjMaVW1ux3y9HfgT5Bxr4=; h=In-Reply-To:References:Date:From:To:Cc:Subject; b=L33X4R/QkpKOQsWZ3K0wTLvvQDmSUlcOJt6mrSFtDk+QTK72kYTyaLti6yE97+EHk 9tSHx5BmWxROwNdCTGdySJ87yV/28zh19vjRumAxTDbZRERAAdTG/f2sRDqG7NHtHs 4s3/XjEbkM1fkcki0fVhfhg3HlP2MaYtrKtSGIco=
X-Virus-Scanned: amavisd-new at ietf.org
X-Spam-Flag: NO
X-Spam-Score: -4.196
X-Spam-Level:
X-Spam-Status: No, score=-4.196 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_VALIDITY_CERTIFIED_BLOCKED=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=unavailable autolearn_force=no
Received: from mail2.ietf.org ([166.84.6.31]) by localhost (mail2.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id di1mjP7kcfQm for <fann@mail2.ietf.org>; Thu, 30 Jul 2026 23:10:01 -0700 (PDT)
Received: from mxct.zte.com.cn (mxct.zte.com.cn [183.62.165.209]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by mail2.ietf.org (Postfix) with ESMTPS id 5FF8A1216C584 for <fann@ietf.org>; Thu, 30 Jul 2026 23:10:00 -0700 (PDT)
Received: from mse-fl1.zte.com.cn (unknown [10.5.228.132]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange x25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mxct.zte.com.cn (FangMail) with ESMTPS id 4hBFz03f1nz55RJ4; Fri, 31 Jul 2026 14:09:48 +0800 (CST)
Received: from njb2app07.zte.com.cn ([10.55.22.95]) by mse-fl1.zte.com.cn with SMTP id 66V69dfs026998; Fri, 31 Jul 2026 14:09:39 +0800 (+08) (envelope-from xiao.min2@zte.com.cn)
Received: from mapi (njy2app03[null]) by mapi (Zmail) with MAPI id mid201; Fri, 31 Jul 2026 14:09:41 +0800 (CST)
X-Zmail-TransId: 2afb6a6c3c25118-8696b
X-Mailer: Zmail v1.0
Message-ID: <202607311409410804oBtl9bpXMetHjoUFoohJ@zte.com.cn>
In-Reply-To: <24af1577-2f5f-4056-b568-200c402956fc@joelhalpern.com>
References: 20260730110857741HVVCE_XihAXMT1eqzEPBy@zte.com.cn,06ec71579f974826bc7b46766cff5894@huawei.com,24af1577-2f5f-4056-b568-200c402956fc@joelhalpern.com
Date: Fri, 31 Jul 2026 14:09:41 +0800
Mime-Version: 1.0
From: xiao.min2@zte.com.cn
To: jmh@joelhalpern.com
Content-Type: multipart/mixed; boundary="=====_001_next====="
X-MAIL: mse-fl1.zte.com.cn 66V69dfs026998
X-TLS: YES
X-ENVELOPE-SENDER: xiao.min2@zte.com.cn
X-SOURCE-IP: 10.5.228.132 unknown Fri, 31 Jul 2026 14:09:48 +0800
X-CLEAN: YES
X-Fangmail-Anti-Spam-Filtered: true
X-Fangmail-MID-QID: 6A6C3C2C.001/4hBFz03f1nz55RJ4
Message-ID-Hash: HYXRY4JK6ZRW6E7Y3RM7L2XLGKNT5DQL
X-Message-ID-Hash: HYXRY4JK6ZRW6E7Y3RM7L2XLGKNT5DQL
X-MailFrom: xiao.min2@zte.com.cn
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: jie.dong=40huawei.com@dmarc.ietf.org, fann@ietf.org
X-Mailman-Version: 3.3.9rc6
Precedence: list
Subject: [Fann] Re: Call for adoption: draft-dong-fann-problem-statement-00 (Ends 2026-08-18)
List-Id: "Fast Network Notifications (fann) Working Group" <fann.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/fann/rFGAUFGSe3q2ETqjbRdzA38uzzs>
List-Archive: <https://mailarchive.ietf.org/arch/browse/fann>
List-Help: <mailto:fann-request@ietf.org?subject=help>
List-Owner: <mailto:fann-owner@ietf.org>
List-Post: <mailto:fann@ietf.org>
List-Subscribe: <mailto:fann-join@ietf.org>
List-Unsubscribe: <mailto:fann-leave@ietf.org>

I reread the FANN WG charter and fully agree with Joel.
Cheers,
Xiao Min


Original


From: JoelHalpern <jmh@joelhalpern.com>
  
To: Dongjie (Jimmy) <jie.dong=40huawei.com@dmarc.ietf.org>;肖敏10093570;
  
Cc: fann@ietf.org <fann@ietf.org>;
Date: 2026年07月30日 23:50
  
Subject: Re: [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:               xiao.min2@zte.com.cn <xiao.min2@zte.com.cn>               
               Sent: Thursday, July 30, 2026 11:09 AM
               To: cjbc@it.uc3m.es
               Cc: fann@ietf.org; fann-chairs@ietf.org;               draft-dong-fann-problem-statement@ietf.org
               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                 <noreply@ietf.org>  
To: fann@ietf.org                 <fann@ietf.org>;fann-chairs@ietf.org                 <fann-chairs@ietf.org>;draft-dong-fann-problem-statement@ietf.org                 <draft-dong-fann-problem-statement@ietf.org>;  
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 -- fann@ietf.org
               To unsubscribe send an email to fann-leave@ietf.org
 




       _______________________________________________
Fann mailing list -- fann@ietf.org
To unsubscribe send an email to fann-leave@ietf.org