Fwd: [rtgwg] WG Action: Formed Fast Network Notifications (fann)

[Rahman <[e-mail]>]

FYI 

Sent from my iPhone

Begin forwarded message:

> From: The IESG <[e-mail]>
> Date: June 22, 2026 at 6:32:58 PM EDT
> To: IETF-Announce <[e-mail]>
> Cc: The IESG <[e-mail]>, [e-mail], [e-mail], [e-mail], [e-mail]
> Subject: [rtgwg] WG Action: Formed Fast Network Notifications (fann)
> 
> A new IETF WG has been formed in the Routing Area. For additional
> information, please contact the Area Directors or the WG Chairs.
> 
> Fast Network Notifications (fann)
> -----------------------------------------------------------------------
> Current status: Proposed WG
> 
> Chairs:
>  Carlos Jesús Bernardos <[e-mail]>
>  Eddie Ruan <[e-mail]>
> 
> Assigned Area Director:
>  Ketan Talaulikar <[e-mail]>
> 
> Routing Area Directors:
>  Jim Guichard <[e-mail]>
>  Gunter Van de Velde <[e-mail]>
>  Ketan Talaulikar <[e-mail]>
> 
> Mailing list:
>  Address: [e-mail]
>  To subscribe: https://mailman3.ietf.org/mailman3/lists/fann.ietf.org/
>  Archive: https://mailarchive.ietf.org/arch/browse/fann
> 
> Group page: https://datatracker.ietf.org/group/fann/
> 
> Charter: https://datatracker.ietf.org/doc/charter-ietf-fann/
> 
> ## Overview
> A group of modern network applications, including AI/ML training/inference
> and cloud services, require networks with various combinations of high
> bandwidth, low loss, low delay, and low jitter. To maintain service
> continuity and experience, these networks must rapidly adapt to adverse
> conditions like link faults, degradation, and congestion. However, existing
> routing technologies often face limitations in reacting in a timely manner to
> such network conditions, especially in large-scale, high-bandwidth data
> center (DC) and data center interconnect (DCI) networks.
> 
> Network nodes can detect link failures, signal degradation, errors,
> congestion on output queues, microbursts, and other such adverse local
> conditions in microseconds to sub-millisecond timescales. These nodes are
> then able to adjust, when feasible, the traffic flows via local mechanisms
> like adaptive load balancing and fast-reroute. However, in many DC and DCI
> network designs, these local techniques are unable to mitigate such events in
> a timely and efficient manner, resulting in diverted traffic flows that
> introduce latency variations, create congestion in other parts of the
> network, and affect other traffic flows. This brings about the requirement
> for a fast notification mechanism whereby a node can signal such locally
> detected network conditions to other (remote) nodes that are one or more hops
> away, which are then able to apply techniques such as adaptive load balancing
> or fast-reroute in an efficient and timely manner.
> 
> The Fast Network Notification (FANN) Working Group is chartered to
> investigate the need and develop a comprehensive solution to convey locally
> detected adverse conditions (and their recovery) to remote nodes that can
> then react to them for enabling efficient and timely handling of traffic
> flows.
> 
> ## Scope and Work Plan
> The WG will begin by documenting the problem space, requirements, and gaps in
> existing mechanisms, including technologies defined both within and outside
> the IETF. The WG will then define a framework describing how network
> notifications are generated and consumed, including integration with existing
> technologies (including Layer 2 and Layer 4 techniques and inter-layer
> dependency with routing at Layer 3). The analysis will include the
> similarities and differences among the various deployment scenarios that the
> WG will be considering.
> 
> After the WG has completed their work (i.e., after WGLC) on requirements and
> this framework, the WG will work on the development of a solution to signal
> adverse network conditions (and their recovery) to remote nodes. These
> mechanisms may include discovery and registration procedures to identify
> interested remote nodes. The WG will reuse existing protocols where
> appropriate and define new protocols or mechanisms when necessary.
> 
> The notifications are expected to be event-driven and primarily optimized for
> fast generation and consumption in the forwarding plane (ideally in hardware)
> to meet the reaction time requirements. As a secondary objective, the
> solution may also support consumption by management systems and routing
> protocols, provided routing stability is preserved. The solution should look
> at the use of existing management plane techniques for this secondary
> objective.
> 
> The WG will initially focus on notifications for link failures, signal
> degradation reported as link errors, and port output queue congestion, while
> ensuring extensibility for additional conditions in the future.
> 
> Although the solution is intended to be generally applicable, the WG will
> prioritize the requirements of data center (DC) and data center interconnect
> (DCI) networks, where rapid reaction time is critical. The WG will balance
> these specific deployment requirements and general applicability of network
> notifications in its design of the solution.
> 
> The WG will seek publication of protocol specifications (i.e., Proposed
> Standards documents) only after demonstrating at least two interoperable
> implementations that utilize hardware-based forwarding, preferably across
> different network processor implementations.
> 
> The WG will also deliver an applicability statement document that provides
> operational guidance for deployment of the solution in the target deployments
> and YANG models for management of the solution.
> 
> The solution is intended for deployment within networks under single
> administrative control. The WG will define mechanisms to identify
> notification domains and to ensure isolation of notifications within those
> domains. Appropriate security mechanisms and considerations will be
> documented as part of the WG deliverables.
> 
> ## Work Items
> The WG is expected to produce the following deliverables:
> - A problem statement, requirements, and gap analysis document (using
> [draft-ietf-rtgwg-net-notif-ps] as a base) to guide the WG work and related
> deliverables (Informational, not intended for publication). - A framework
> document describing the overall architecture and integration with existing
> protocols and technologies (Informational). - One or more protocol
> specifications defining the fast network notification mechanisms, including
> associated discovery and registration procedures as needed (Proposed
> Standard). - An applicability and operational guidance document describing
> deployment considerations and usage models (Informational). - YANG modules
> for configuration and management of the solution (Proposed Standard).
> 
> ## Collaborations
> The WG will coordinate with other relevant IETF working groups for
> technologies and protocols within their respective areas of responsibility.
> This includes, but is not limited to, RTGWG, TEAS, IDR, LSR, SPRING, BFD,
> IPPM, TSVWG, CCWG, SRV6OPS and NMOP. Any required extensions to existing
> protocols or technologies will be developed in the appropriate working groups.
> 
> Milestones:
> 
>  Aug 2026 - Adopt Problem Statement, Requirements, and Gap Analysis
> 
>  Nov 2026 - Adopt Framework Document
> 
>  Jun 2027 - Submit Framework Document to IESG for publication
> 
>  Jun 2027 - Adopt Specifications Document(s) for Network Notifications
> 
>  Dec 2027 - Adopt Applicability Document
> 
>  Dec 2027 - Adopt YANG Modules Document
> 
>  Dec 2028 - Submit Specifications Document(s) for Network Notifications to
>  IESG for publication
> 
>  Dec 2028 - Submit Applicability Document to IESG for publication
> 
>  Dec 2028 - Submit YANG Module Document to IESG for publication
> 
> 
> 
> _______________________________________________
> rtgwg mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]