Fast Network Notifications
charter-ietf-fann-01

[Ballot comment]

It was pointed out to me that I missed the text at the end of the overview, which states, ".. and develop a comprehensive solution."

With this in mind, I have changed my position from "Block" to "No Objection". I would like to also provide a suggestion for rewording the last sentence.

OLD
The Fast Network Notification (FANN) Working Group is chartered to investigate this problem space for the need 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 and to develop a comprehensive solution.

NEW
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.

Here are some nits for your consideration.

OLD: especially in high-scale and high-bandwidth
NEW: especially in large-scale, high-bandwidth

OLD: at microseconds to sub-millisecond timescales
NEW: in microseconds to sub-millisecond timescales

OLD: via local techniques like adaptive load balancing, fast-reroute, and other mechanisms.
NEW: via local techniques like adaptive load balancing and fast-reroute.

OLD: timely and efficient manner resulting in diverted traffic flows
NEW: timely and efficient manner, resulting in diverted traffic flows

OLD:  nodes that are one or more hops away which are then able to apply techniques
NEW:  nodes that are one or more hops away, which are then able to apply techniques

OLD: how network notifications are generated, and consumed, including integration
NEW: how network notifications are generated and consumed, including integration

OLD: the RTGWG
NEW: RTGWG

[Ballot block]
This is a small point but I believe it is important and easy to address.

The last sentence in the overview reads as follows:

"The Fast Network Notification (FANN) Working Group is chartered to investigate this problem space for the need 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 and to develop a comprehensive solution."

As I understand it, and based on the rest of the charter and the deliverables, FANN is chartered to not only investigate the need but also define solutions. Currently, the overview leads me to believe otherwise.

[Ballot comment]
These are all nits for your consideration.

OLD: especially in high-scale and high-bandwidth
NEW: especially in large-scale, high-bandwidth

OLD: at microseconds to sub-millisecond timescales
NEW: in microseconds to sub-millisecond timescales

OLD: via local techniques like adaptive load balancing, fast-reroute, and other mechanisms.
NEW: via local techniques like adaptive load balancing and fast-reroute.

OLD: timely and efficient manner resulting in diverted traffic flows
NEW: timely and efficient manner, resulting in diverted traffic flows

OLD:  nodes that are one or more hops away which are then able to apply techniques
NEW:  nodes that are one or more hops away, which are then able to apply techniques

OLD: how network notifications are generated, and consumed, including integration
NEW: how network notifications are generated and consumed, including integration

OLD: the RTGWG
NEW: RTGWG

[Ballot comment]
Removing the BLOCK to help move the charter discussion for External Review.

The change in the charter text puts the management plane notification out of scope for the primary objective. In my mind, it was clear that the management plane was not the primary objective. But thanks for making it clear in the charter.

The clarification I was looking for in the charter had to do with the secondary objective, which talks about supporting consumption by the management system. For that piece of work, can we clarify that the solution would look at existing definitions of management notification in other WGs?

"IETF.", paragraph 16
> 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
>
> Jul 2028 - Submit Specifications Document(s) for Network Notifications to IESG for
>            publication

Can we make the last milestone date as Dec 2028

[Ballot comment]
I believe this charter is ready for external review. It is well written and it describes a well-scoped area of work that has an understandable relationship to other WGs without much ambiguity.

One note: it opens with an emphasis on AI/ML use cases by giving this as the only example, which is misleading. I recommend either (1) adding other examples of use cases where existing data center networking performance is insufficient or (2) simply not list examples given the alternative to this charter's claim can be rejected ("data center networking performance is a solved problem"). AI/ML is not unique among use cases requiring the best of networking.

[Ballot block]
Paragraph 1
> The Fast Network Notification (FANN) Working Group is chartered to investigate
> this problem space for the need to convey locally detected adverse conditions
> (and their recovery) to remote nodes that can then act on them for enabling
> efficient and responsive traffic flow handling and to develop a comprehensive
> solution.

RFC 8641 (YANG Push) defines on-change subscriptions that deliver notifications
when YANG datastore state changes. Link failures, signal degradation, and
congestion state changes — the exact events FANN targets — are representable
as YANG datastore state changes. NMOP is actively working on operational aspects
of YANG Push. The NETCONF WG has published draft-ietf-netconf-distributed-notif,
which extends YANG Push to allow metrics to be published directly from line cards
to target receivers (bypassing the route processor for the data path). A reader
will reasonably ask: why not use YANG Push on-change, possibly with distributed-notif
extensions, instead of chartering a new WG to build something new?

I know the answer, but it would help for the charter to be upfront about why that
solution may not work for FANN. Mainly, they are:

1. YANG Push delivers notifications to management systems and telemetry collectors —
external subscribers that register with a device. FANN's primary consumer is the
forwarding plane of adjacent network nodes, which must react at forwarding speeds.
A forwarding ASIC cannot establish YANG Push subscriptions or deserialize
YANG-encoded notifications at line rate.

2. YANG Push reports changes in the YANG datastore, which is updated by management-plane software.
FANN requires generation in the forwarding plane — ideally directly from ASIC/NPU hardware —
without traversing the management stack. Even draft-ietf-netconf-distributed-notif,
which allows line cards to publish directly, still assumes management-plane stacks on
those line cards and external IP-routable addresses for line card interfaces.
It does not provide hardware-native event generation.

Having said that, the charter's secondary objective — allowing FANN notifications to be
consumed by management systems — is precisely where YANG Push could serve as a bridge.
A FANN-capable device could translate forwarding-plane notifications into YANG Push
on-change events for management consumption. The charter should acknowledge this
relationship: FANN is not a replacement for YANG Push but fills the forwarding-plane
tier that YANG Push cannot reach. This framing also clarifies why NMOP collaboration
is listed — NMOP's work defines the management-plane layer that FANN notifications
may feed into.

Recommended charter text addition: A sentence or two in the Overview or Scope section
noting that existing management-plane notification mechanisms
(including YANG Push on-change) are insufficient for the forwarding-plane timescale
requirements would eliminate this line of questioning. Without it, the absence of
any reference to YANG Push reads as an oversight rather than a deliberate design
decision.

[Ballot comment]
"IETF.", paragraph 8
> - 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).

"Informational" in the IETF context means an Informational RFC — a published document.
"Not intended for publication" means a WG-internal document that never becomes an
RFC. These are mutually exclusive designations, and the charter cannot have both.

"IETF.", paragraph 16
> 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
>
> Jul 2028 - Submit Specifications Document(s) for Network Notifications to IESG for
>            publication

The charter requires "at least two interoperable implementations that utilize
hardware-based forwarding" before seeking PS publication. Hardware ASIC or NPU
implementations of new network protocols realistically take 18–24+ months from
stable specification. This means the Jul 2028 milestone from the time it is
adopted (Jun 2027, a 13 month window) is likely unachievable on the stated timeline.

[Ballot comment]

I agree with Eric V re: is it necessary to have 'including AI/ML training/inference and cloud services'?  I think it is fine without that phrase.

[Ballot comment]
Thanks for the work done on this charter (and for being specific about the intended publication status). Some comments though:

Unsure whether ` including AI/ML training/inference and cloud services` helps in a charter.

I find the sentence `...is chartered to investigate this problem space...` conflicting with the text later about `the WG will work on the development`.

Why not a "must" in `These mechanisms may include discovery and registration procedures ` ?

[Ballot comment]
Hi all,

Thank you for the effort put into the charter.

# Overall

The problem space is an interesting one. Although, it is not clear if the solution has to be at the routing level (at the first place), a network management (including INT/in-situ), a new application shim for advertisement of relevant events, or a combination therefore, I’m supportive of this work. Such matters can be the outcome of the exploration proposed here.

The charter includes provisions for ops/deployment work item. That work can be the place to assess links and interference when similar efforts are also enabled at Layer 2 or Layer 4. I’m not suggesting to make any change to the charter to cover inter-layer dependency although I think that ignoring them may lead to biased results.

# Responsiveness: application-specific

CURRENT:
Many network applications, including AI/ML training/inference and cloud services, require high bandwidth, low loss, low delay, and low jitter networks that can rapidly adapt to link faults,  degradation, congestion, and other such adverse conditions to maintain service continuity and experience.
..
The WG will initially focus on notifications for link failures, signal degradation, and port output queue congestion, while ensuring extensibility for additional conditions in the future.

There is a dependency between the FANN component (whatsoever that means) and expectations of applications making use of a network. However, the technical work is scoped vs. specific events not traffic performance characteristics bounds that that can be provided. These bounds are application-specific.

Should the work be scoped so that FANN outcome can be customized per application need? Or the expectation is that it is a generic component that is tweaked independent of applications running on a network?

# Some minor comments

## Configuration is a management function

OLD: YANG models for configuration and management of the solution

NEW: YANG models for the management of the solution

## signal degradation

Not sure which signal are we referring to here.

Cheers,
Med