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

"Dongjie (Jimmy)" <jie.dong@huawei.com> Thu, 30 July 2026 15:37 UTC

Return-Path: <jie.dong@huawei.com>
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 1E8FE12120A71; Thu, 30 Jul 2026 08:37:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1785425848; bh=aqRePlKB32TRlxLlLG8Q6SHPPnkIVksfndayEPopD+8=; h=From:To:CC:Subject:Date:References:In-Reply-To; b=BBPTeJir4Fj+R7CX1F/3hs+w2lU0D/uwg9RvU3P5WclQTBT4ZLPYeVZ7pnvhSUHT0 LynbE4QK1ulcGhYjjf6gPKHyGnZwe9WIzfNsmjqy1TOw61R28u0TVhgiC77csOtSrR RSv6YRvQukYp3EZvZ0vJq/e5urUlA4f/IBqBz6XU=
X-Virus-Scanned: amavisd-new at ietf.org
X-Spam-Flag: NO
X-Spam-Score: -4.393
X-Spam-Level:
X-Spam-Status: No, score=-4.393 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_VALIDITY_CERTIFIED_BLOCKED=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no
Authentication-Results: mail2.ietf.org (amavisd-new); dkim=pass (1024-bit key) header.d=huawei.com
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 hrnKEkA3FGOk; Thu, 30 Jul 2026 08:37:27 -0700 (PDT)
Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-256)) (No client certificate requested) by mail2.ietf.org (Postfix) with ESMTPS id C8C9C12120A6A; Thu, 30 Jul 2026 08:37:26 -0700 (PDT)
dkim-signature: v=1; a=rsa-sha256; d=huawei.com; s=dkim; c=relaxed/relaxed; q=dns/txt; h=From; bh=aqRePlKB32TRlxLlLG8Q6SHPPnkIVksfndayEPopD+8=; b=haiUohfHCOOC2dNNnXtBU0NbUjFVGs4IAN/PhxyEIU5rYgRZm1Bp8q4z6huppRzTRMrv8ot9D CXNYFCqBItsoLZwdoG2cKJbzEvtsdyVuOrfc5u2I+z+WfBOA0KcVw+iJoezJkwPh0kl9Krv1cZq AYuxB1xDkhtG2cEqt6m+8T8=
Received: from mail.maildlp.com (unknown [172.18.224.83]) by frasgout.his.huawei.com (SkyGuard) with ESMTPS id 4h9tbW65fKzHnGjH; Thu, 30 Jul 2026 23:36:39 +0800 (CST)
Received: from kwepemh500011.china.huawei.com (unknown [7.202.181.142]) by mail.maildlp.com (Postfix) with ESMTPS id 11A574057A; Thu, 30 Jul 2026 23:37:22 +0800 (CST)
Received: from dggpemf500008.china.huawei.com (7.185.36.156) by kwepemh500011.china.huawei.com (7.202.181.142) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1544.11; Thu, 30 Jul 2026 23:37:20 +0800
Received: from kwepemf100006.china.huawei.com (7.202.181.220) by dggpemf500008.china.huawei.com (7.185.36.156) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1544.11; Thu, 30 Jul 2026 23:37:19 +0800
Received: from kwepemf100006.china.huawei.com ([7.202.181.220]) by kwepemf100006.china.huawei.com ([7.202.181.220]) with mapi id 15.02.1544.036; Thu, 30 Jul 2026 23:37:19 +0800
From: "Dongjie (Jimmy)" <jie.dong@huawei.com>
To: "xiao.min2@zte.com.cn" <xiao.min2@zte.com.cn>, "cjbc@it.uc3m.es" <cjbc@it.uc3m.es>
Thread-Topic: [Fann] Call for adoption: draft-dong-fann-problem-statement-00 (Ends 2026-08-18)
Thread-Index: AQHdHoj/kW8fr2RAxkCcxNBGCdewk7aE3laAgAFP2cA=
Date: Thu, 30 Jul 2026 15:37:19 +0000
Message-ID: <06ec71579f974826bc7b46766cff5894@huawei.com>
References: 178524015053.1230393.14124574133204422376@dt-datatracker-d4d6ff9d9-fsx7d <20260730110857741HVVCE_XihAXMT1eqzEPBy@zte.com.cn>
In-Reply-To: <20260730110857741HVVCE_XihAXMT1eqzEPBy@zte.com.cn>
Accept-Language: en-US, zh-CN
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.48.122.254]
Content-Type: multipart/alternative; boundary="_000_06ec71579f974826bc7b46766cff5894huaweicom_"
MIME-Version: 1.0
Message-ID-Hash: UK4ONA5DX26KXES5OUC4WVCARWS2OEJY
X-Message-ID-Hash: UK4ONA5DX26KXES5OUC4WVCARWS2OEJY
X-MailFrom: jie.dong@huawei.com
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: "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>
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/gBOdBO-edb0RMuvsRAAoi569T-Y>
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>

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<mailto:noreply@ietf.org>>
To: fann@ietf.org<mailto:fann@ietf.org> <fann@ietf.org<mailto:fann@ietf.org>>;fann-chairs@ietf.org <fann-chairs@ietf.org<mailto:fann-chairs@ietf.org>>;draft-dong-fann-problem-statement@ietf.org <draft-dong-fann-problem-statement@ietf.org<mailto: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<mailto:fann@ietf.org>
To unsubscribe send an email to fann-leave@ietf.org<mailto:fann-leave@ietf.org>