A Framework for Fast Network Notifications

Introduction Modern high-performance networks, in particular data center (DC) and data center interconnect (DCI) fabrics serving AI/ML and cloud workloads, demand rapid adaptation to changing network conditions. A single fiber link failure, signal degradation, or transient congestion event can stall a distributed training job, waste compute and energy, and degrade service experience . Contemporary forwarding hardware can detect link failures, signal degradation reported as link errors, queue buildup, microbursts, and output-queue congestion at microsecond to sub-millisecond timescales. However, the time required to disseminate this information to the remote nodes that can act on it typically far exceeds the detection time. This gap between detection and reaction is the central problem that fast network notifications address. The Fast Network Notifications Problem Statement documents the need for a fast notification mechanism and the limitations of existing approaches. The companion requirements and gap analysis documents elaborate the requirements and the deficiencies of current technologies. Built on these documents, this document defines a framework to describe the overall architecture, the functional roles, the information carried, how notifications are delivered and scoped, and how the mechanism integrates with existing protocols and technologies across layers. This informational document does not define a wire protocol, encoding, or YANG model. Those are expected to be specified in separate protocol and management documents that build on this framework.

Scope This framework applies to limited-domain networks under a single administrative control, consistent with the deployment assumptions of the FANN charter. It prioritizes the requirements of DC and DCI networks where rapid responsiveness is critical, while remaining applicable to other deployments such as wide-area backbone networks. The framework initially targets notifications for link failures, signal degradation reported as link errors, and port queue congestion, while remaining extensible to additional conditions in the future. The specific actions a recipient takes in response to a notification (for example fast reroute, adaptive load balancing, or rate adjustment) are out of scope of this framework; they are the responsibility of the consuming subsystem and the protocols that realize those actions. In this document, "fast" does not denote a single rigid numerical threshold. It characterizes a class of mechanisms designed to minimize notification delivery time so that the latency is on the order of microseconds to milliseconds, depending on the operational objective and the diameter of the notification domain, and is substantially shorter than the Round-Trip Time (RTT) of the affected traffic. This framework is solution-agnostic. It defines the functional roles, information model, and delivery and scoping models that a fast network notification solution is expected to instantiate, but it does not specify, mandate, or endorse any particular protocol, encoding, or solution document. It is intentionally general so that a range of realization approaches can conform to it, potentially in combination, without conflicting with one another or with this framework. Consistent with the FANN charter, fast generation and consumption in the forwarding plane (ideally in hardware) is the primary design point and the means of meeting the latency targets described above; consumption by the control plane or management plane is a secondary objective, permitted only where it preserves routing stability and does not compromise forwarding-plane responsiveness. Specific solutions are developed in separate documents; such documents are expected to map their behavior onto the roles and models defined here, and any capability they require that is not yet covered is expected to be accommodated as an extension of this framework rather than a departure from it.

Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

Terminology This document uses the following terms.

Fast Network Notification (FANN):: An event-driven message that conveys a locally detected adverse network condition, or the recovery from such a condition, to one or more remote nodes within a defined notification domain, with the objective of low-latency delivery suitable for action in the forwarding plane.
Notification Originator:: A functional role that detects an adverse condition (or its recovery) and generates a fast network notification. Also referred to as the originating or reporting node.
Notification Consumer:: A functional role that receives a fast network notification and may take action based on it. Also referred to as the recipient node.
Notification Relay:: A functional role that forwards or redistributes a notification toward additional consumers, optionally applying filtering, damping, or aggregation. A node may be both a relay and a consumer.
Notification Domain:: A bounded region of the network, under a single administrative control, within which fast network notifications are generated, distributed, and consumed, and outside of which they are not propagated without explicit policy.
Notification Controller:: An optional control-plane or management-plane entity that assists with discovery, registration, subscription, policy, and global optimization. It is not required to be on the fast notification delivery path.
Event:: A change in network condition detected by a node, such as a link failure, signal degradation, or output-queue congestion, including the recovery from a previously reported condition.

The terms BFD , ECN , FRR , and IOAM are used as defined in their respective references.

Fast Network Notification Framework This chapter defines the core of the framework: its design principles, the deployment scenarios it serves, the functional reference architecture, the information carried in notifications, and the models for delivering, scoping, discovering, and controlling them.

Design Principles and Goals The framework is guided by the following principles, derived from the problem statement and requirements .

Event-driven, not periodic:: Notifications are generated in response to detected events. This distinguishes fast network notifications from preconfigured periodic mechanisms such as BFD , which detect rather than disseminate.
Forwarding-plane optimized:: The primary design point is fast generation and consumption in the forwarding plane, ideally in hardware, to meet responsiveness targets. Consumption by the control plane and management plane is a secondary objective and MUST NOT compromise routing stability.
Lightweight and bounded:: Notification messages are compact and the system is designed to bound the load it places on the network, especially during the very events it reports. The notification system MUST NOT exacerbate a failure or congestion event.
Action-agnostic:: A notification message conveys information; it does not mandate a specific reaction. A notification MAY explicitly indicate a recommended action, or the action MAY be determined implicitly by the consumer from the information carried.
Extensible:: The information model and event taxonomy are extensible to additional conditions, metrics, and scopes without redefining the architecture. Extensibility is equally a principle for the protocol design: the notification message encoding SHOULD allow new information elements, event types, and optional fields to be added in a forward-compatible way, such that a receiver MUST skip or ignore any element it does not understand rather than discarding the notification. This lets the set of carried information evolve over time without breaking the interoperability with existing implementations or requiring a new protocol version.
Complementary:: Fast network notifications complement, and do not replace, existing OAM, control-plane, and telemetry mechanisms. They bridge the time gap between event onset and slower control-plane or telemetry-driven responses.
Scoped and isolated:: Notifications are confined to a notification domain. Domain identification and isolation are first-class concerns.
Decoupled from routing convergence:: Fast-changing network state SHOULD be conveyed by mechanisms that are separate from the routing protocol database and their own flooding and best-path computation, so that high-frequency or transient events do not introduce churn, instability, or excessive recomputation in the routing control plane. This separation lets notifications be generated and refreshed at a fast pace independently of routing convergence, while any consumption by routing remains a secondary objective bounded by the routing-stability constraint above.

Deployment Scenarios Fast network notifications apply across a range of network scenarios, but the time budget, processing constraints, and the mechanisms that are practical differ substantially between them. This framework does not assume one-size-fits-all: the scenarios below have materially different characteristics, and a given deployment is expected to select the delivery mode, scope, and realization mechanism appropriate to its scenario rather than apply a single mechanism everywhere.

Intra-data-center fabric:: Within a single DC fabric (for example a Clos topology), originators and consumers are typically a small number of hops apart, propagation delay is very low, and forwarding hardware can both detect and consume notifications. This scenario has the tightest time budget (sub-millisecond) and is the most amenable to forwarding-plane, in-band, or scoped-flooding delivery with action such as adaptive load balancing or local repair. The dominant challenge is volume and rate of change at scale rather than propagation distance.
Single-hop DCI / point-to-point WAN:: Between two sites or routers connected by one (logical) hop, the recipient set is small and often known in advance, favoring unicast or a directed notification to the upstream or ingress node. The time budget is dominated by the link propagation delay, which is fixed; the design goal is to add minimal processing delay on top of it so the notification still beats the affected traffic's E2E reaction loop.
Multi-hop managed DCI interconnect:: Data centers may also be interconnected across multiple IP hops by a managed network, for example for AI collaborative computing and other DCI services. Unlike arbitrary WAN paths, this case is typically highly engineered: traffic follows deterministic, traffic-engineered (TE) paths, and network slicing can be used to isolate tenants. Because the path and the relevant upstream or ingress nodes are known in advance, notifications can be delivered either unicast or hop-by-hop along the path and scoped per slice or per tenant, and the resulting action can be applied at tenant or path granularity rather than only per physical link or node.
Multi-hop / arbitrary WAN paths:: When notifications must reach nodes several hops away or across a wider domain, propagation delay, the number of potential recipients, and the risk of notification storms all grow. Time budgets are typically milliseconds rather than sub-millisecond, and subscription, relaying with filtering/aggregation, and bounded scoping become essential. Some timeliness targets achievable intra-DC may simply not be feasible here; the framework expects such cases to use more conservative techniques, and the feasibility of meeting a specific target is itself scenario-dependent.

The functional roles (), information model (), and delivery modes () defined in this document are common across scenarios, but their realization and the achievable latency are not. Where a requirement (for example a sub-millisecond target) is stated, it SHOULD be understood as scoped to the scenario in which it is feasible.

Reference Architecture

Functional Roles The framework defines four functional roles. A single physical or virtual network element MAY implement more than one role.

Notification Originator:: Detects an event using local detection mechanisms (for example link fault detection, error counters, queue occupancy thresholds, or BFD as a detection input) and generates a notification. The originator determines, by policy or signaling, the set of consumers and the delivery mode, and applies origination-side controls such as damping and rate limiting.
Notification Relay:: Receives a notification and forwards it toward additional consumers. A relay MAY filter, aggregate, deduplicate, or damp notifications. Relays enable hop-by-hop and scoped-flooding delivery and allow load to be bounded inside the domain.
Notification Consumer:: Receives a notification and may act on it in the data plane (for example rate adjusting, ECMP rebalancing, flow steering, traffic pause, etc.), and/or pass the information to the control plane or management plane. A consumer MAY also be a relay.
Notification Controller:: An optional entity that supports discovery, registration, subscription, and policy distribution, and that may consume notifications for global traffic-engineering or load-balancing optimization. The controller is not required to be on the fast delivery path and SHOULD NOT be a single point of failure for forwarding-plane reactions.

Notification Lifecycle A fast network notification proceeds through the following stages.

Detection. A node observes an event at the forwarding plane using a local detection mechanism. Detection mechanisms are out of scope of this framework, but their output is the trigger for notification generation.
Generation. The originator constructs a notification populated from the information model (), subject to origination policy, damping, and rate limiting.
Delivery. The notification is delivered to the intended consumers using one of the delivery modes (), possibly via one or more relays.
Consumption. A consumer parses the notification and decides whether and how to act, based on the information carried and on any local state it holds.
Action. The consumer performs an action (out of scope of this framework) and may relay the notification further.
Recovery and withdrawal. When the condition clears, the originator may generate a recovery notification so consumers can revert or update their state. Recovery notifications are subject to damping so that flapping conditions do not generate excessive traffic.

Detection Assumptions and Constraints The mechanisms by which a node detects an event are out of scope of this framework, but the framework assumes their existence and depends on their characteristics. Two assumptions are important. First, the E2E responsiveness of a fast notification system is bounded by detection time as well as delivery time: a notification cannot be faster than the moment the originating node becomes aware of the condition. Detection latency, accuracy, and false-positive behavior therefore directly shape what the notification system can achieve, and an event that is detected slowly or unreliably limits the value of fast delivery. Second, detection itself has a cost that interacts with scaling. For example, achieving fast liveness detection by running BFD at very short transmit intervals consumes forwarding and control resources and does not by itself notify any node beyond the BFD endpoints. Driving detection intervals down to obtain faster notification can impose significant load, and this trade-off between detection speed and detection cost SHOULD be considered together with the notification load discussed in . Where hardware can detect a condition directly (for example loss of signal, FEC errors, or queue-occupancy thresholds), it is generally preferable to detection mechanisms that rely on periodic message exchange such as BFD. The relevant distinction is between hardware-based and protocol-session-based detection in terms of speed and overhead, rather than between polling and non-polling as such: a hardware mechanism may itself poll internally, but its detection speed and per-event cost are typically far lower than those of a protocol session driven to an aggressive interval.

Information Model A fast network notification carries one or more information elements. For a given scenario some elements are mandatory and others optional; the framework does not require all elements in every notification. The detailed encoding is left to protocol specifications. The information elements are:

Event Type:: The class of event, for example failure, signal degradation, congestion, or performance degradation, and whether the notification reports onset or recovery. The event taxonomy is extensible.
Location of Event:: An identifier of where the event occurred, for example a link, node, interface, or queue identifier. Location identifiers SHOULD be interpretable by consumers within the notification domain.
Fine-grained Network Status:: Quantifiable metrics such as link utilization, available bandwidth, link capacity, queue length, level of congestion, link or node delay, jitter, and packet loss. Conveying such quantitative metrics, rather than a binary up/down indication, enables graduated and proportional responses such as weighted load-sharing adjustments.
Path Identification:: Identification of the path affected by the event, allowing consumers to scope their reaction to specific paths.
Flow/Service Identification:: Identification of an affected flow (for example a 5-tuple) or service, allowing differentiated, per-flow or per-service responses.
Timing and Validity:: Optional event timestamp and a validity or hold time after which the reported condition should be considered stale absent refresh or recovery.
Action Hint:: An optional explicit indication of a recommended action. When absent, the consumer determines the action implicitly from the other elements.
Origin and Sequence:: Originator identity, which may be represented by the source IP address of the notification, and an optional sequence or epoch indicator. The sequence or epoch supports ordering, deduplication, and loop detection at relays and consumers; it is RECOMMENDED where notifications may be relayed, flooded, or reordered, and MAY be omitted in simple cases such as single-hop unicast delivery where such protection is unnecessary.

A consistent information model across implementations is necessary for interoperability; defining the normative model and encodings is a task for the protocol specification.

Delivery and Scoping

Delivery Modes Depending on the position and number of consumers, the framework supports the following delivery modes. A scenario MAY use more than one.

Unicast:: Direct delivery to a single consumer. Suitable when the originator knows the specific node that must react (for example a designated ingress or upstream node).
Multicast / Point-to-Multipoint:: Delivery to a selected group of consumers, for example along a service or forwarding path. Suitable when a defined set of nodes must react together.
Hop-by-hop:: Delivery along a series of nodes on a specified path, with each node acting as a relay and possibly a consumer. Suitable for propagating awareness upstream along an affected path.
Scoped Flooding:: Dissemination to all nodes within a bounded region of the domain. Suitable for critical events with many interested consumers, with special attention to control overhead and duplicate suppression.

Transport Considerations Delivery MAY reuse existing messaging and transport mechanisms or a new lightweight mechanism MAY be defined where existing ones cannot meet the latency or forwarding-plane processing targets. Regardless of the underlying transport, the delivery mechanism is responsible for timely delivery to the intended consumers and for bounding the load it introduces. Because notifications are most valuable precisely when the network is under stress, the transport MUST support prioritization so that notifications are not delayed or dropped behind the very congestion they report. A notification that is queued behind the congested traffic loses most of its value. Prioritization can be realized using existing forwarding-plane mechanisms, including:

DiffServ marking, for example a dedicated DSCP code point mapped to a high-priority or low-latency per-hop behavior (for example Expedited Forwarding ) along the notification path, so that classification and queuing of notifications can be done in hardware at every hop;
a strict-priority or low-latency queue, or a dedicated control-class queue, separated from user-data queues so notifications bypass congested data queues;
at Layer 2, priority marking such as IEEE 802.1p / PCP where the delivery path traverses bridged segments.

The chosen marking and per-hop behavior MUST be consistent across the notification domain so that priority is honored E2E within the domain. Operators MUST be able to configure the marking, and the markings used for notifications SHOULD be reserved so that ordinary traffic cannot claim the same priority and so that notification traffic itself cannot be abused to obtain preferential treatment (). Because notifications occupy a high-priority class, their volume MUST be bounded by the rate limiting, damping, and filtering of to avoid starving other control traffic. Reliability requirements vary by scenario: some events warrant best-effort, low-latency delivery, while others (for example recovery state) may warrant acknowledgement or periodic refresh.

Notification Domain and Isolation Fast network notifications are confined to a notification domain. The framework requires mechanisms to:

identify a notification domain and its membership;
ensure notifications are not propagated outside the domain without explicit policy;
prevent notifications from one domain being injected into or trusted by another.

Domain scoping bounds the blast radius of both legitimate notification storms and malicious injection, and it aligns the trust boundary with the single administrative control assumed by the charter.

Discovery, Registration, and Subscription To deliver notifications only to interested and authorized consumers, the framework supports the following procedures. A deployment MAY use configuration, dynamic signaling, or a combination.

Discovery:: Originators and consumers determine the existence, identity, and capabilities (event types, encodings, delivery modes) of relevant peers and relays within the domain.
Registration:: A node registers as a potential originator or consumer within the domain, establishing the trust and addressing state needed for delivery.
Subscription:: A consumer expresses interest in specific event types, locations, paths, flows, or metric thresholds. A subscription-based approach ensures each consumer receives only relevant information, reducing unnecessary overhead. Subscriptions MAY be brokered by a controller or established directly between nodes.

These procedures MAY be realized by reusing existing protocols where appropriate, or by new mechanisms defined in the protocol specification work.

Loop Prevention, Filtering, and Damping Because relays may forward notifications and consumers may relay further, the solution MUST provide for:

Loop prevention:: Use of origin identity, sequence/epoch indicators, scope limits (for example a hop or region bound), and duplicate suppression so that a notification does not circulate indefinitely.
Filtering and aggregation:: Relays MAY filter notifications that are not relevant to downstream consumers and MAY aggregate multiple related events to reduce volume.
Damping:: The solution MUST define where responsibility lies for handling rapidly changing conditions, such as a flapping link. Damping MAY be applied at the originator, at a transit relay, or required to reach the consumer; the chosen location and its controls MUST be specified explicitly. A common policy is to report a degradation immediately but to delay reporting the corresponding recovery for a configurable interval to confirm stability.

Realization and Operational Considerations This chapter describes how the framework relates to existing technologies, the candidate mechanisms that could realize it, the applications it enables, and the scaling and operational considerations that apply when deploying it. It is informational and does not mandate any particular realization.

Integration with Existing Technologies A central goal of the framework is integration with existing mechanisms across layers, as required by the charter. Fast network notifications are complementary to these mechanisms.

Layer 2:: Link-layer fault and error detection (for example physical-layer alarms, FEC error counters, and interface error statistics) are detection inputs to the originator. Layer 2 protection may act as a consumer's response.
Layer 3 / Routing:: Fast network notifications complement IGP/BGP-based dissemination and FRR . Whereas a Point of Local Repair acts on a local topology view and may cause congestion on a backup path, a notification can give upstream nodes a wider view before they react. Consumption by routing protocols is a secondary objective and MUST preserve routing stability; notifications MUST NOT be allowed to induce control-plane churn or instability. Topology and inventory models such as may provide context for interpreting location and path identifiers.
Layer 4 / Transport:: ECN signals congestion to the transport sender only coarsely and over a full RTT. Fast network notifications can deliver richer congestion information to network nodes far sooner, but they then act inside the network while end-to-end transport congestion control (TCP, QUIC, or RDMA/RoCE) acts at the endpoints, so the two loops run concurrently on the same traffic. A solution MUST ensure its actions remain a net-positive complement to transport: it SHOULD preserve per-flow ordering and avoid abrupt RTT or capacity changes where feasible, and SHOULD NOT suppress or rewrite end-to-end congestion signals such as ECN marks. Where the interaction cannot be shown to be benign, a conservative reaction is preferred; detailed coordination between network-side and transport-side reactions is for further study with the relevant transport working groups.
Detection and OAM:: BFD provides fast bidirectional fault detection between endpoints but does not notify other nodes; it can serve as a detection input to the originator. Obtaining faster detection by shortening BFD transmit intervals increases resource consumption, as discussed in . IOAM , the Alternate-Marking (AM) , and IPFIX provide detailed data-plane measurements but are not designed for lightweight, rapid alerts to specific nodes for immediate action. Performance metrics may be defined consistently with . Fast network notifications fill this gap and feed, rather than replace, telemetry pipelines.

The interaction with each technology, including any required protocol extensions, is expected to be developed in the relevant IETF working groups.

Candidate Realization Approaches This section surveys, non-normatively, classes of mechanism that could realize fast network notifications. It does not endorse a specific approach; the choice depends on the deployment scenario (), and a solution MAY combine more than one.

Advertisement of link/path status to neighbors, decoupled from the IGP:: A node advertises the up/down status and quality of its links or paths to neighboring nodes, separately from the IGP and its link-state database, so that fast or frequent updates do not perturb routing convergence (see the decoupling principle in ). illustrates this approach; note that what is advertised is link/path reachability (up/down) and quality, which is distinct from the node and link state that an IGP floods. It suits cases where the consumers are routing or forwarding elements that benefit from a wider view without incurring IGP churn.
IGP/BGP protocol extensions:: Existing control-plane protocols could be extended to carry notification information. This reuses deployed machinery but must be weighed carefully against the routing-stability and overhead concerns in , and is generally better suited to slower-changing or control-plane-consumed information than to the fastest forwarding-plane reactions.
In-band / data-plane signaling:: Notifications are carried in the forwarding plane, for example in packet headers or lightweight dedicated packets, so that detection, delivery, and consumption can occur in hardware. This offers the lowest latency and best matches the intra-DC scenario, at the cost of requiring forwarding-hardware support and careful scoping. The need for such forwarding-plane notification in AI data center fabrics is motivated by , which analyzes the limitations of existing IP-FRR in these fabrics and the requirements for its enhancement. As examples of the notification mechanisms, defines a fast notification protocol that operates above the Ethernet layer, and proposed fast-notification-based IP-FRR optimization over a decade ago, with the companion defining a data-plane transport and message container for the notifications themselves.
Tunnel- or overlay-based delivery in the WAN:: For multi-site or WAN deployments, notifications may be delivered over established tunnels or overlays toward ingress or upstream nodes; work such as explores fast notification in this context for tunnel-based transport.
Telemetry-assisted collection toward the traffic source:: Rather than pushing an alert outward from the detecting node, path latency and congestion state are accumulated in-band along the path and returned to the traffic source, so that the source obtains fresh path state and can steer traffic or adjust its congestion response. FALCON realizes this by combining in-network telemetry with source routing and collecting the data on the reverse path toward the source, reducing the feedback lag to less than half the baseline RTT; it applies to both DCN and WAN and reuses existing IETF mechanisms.
Path- and slice-scoped flow control and backpressure:: Congestion or available-bandwidth information is notified to upstream nodes along the forwarding path and acted upon as flow control, scoped per path segment or per slice so that control applies at tenant or task granularity. uses SRv6 segments and slicing to throttle specific flows for lossless transmission, and extends Layer 2 PFC into the WAN with hop-by-hop backpressure messages and slice-based isolation. This approach suits the managed multi-hop DCI scenario of .

Each approach trades off latency, hardware dependence, protocol reuse, and impact on routing stability differently, and fits some scenarios in better than others. Coordination when multiple recipients act on the same notification is out of scope and for further study.

Illustrative Applications This section sketches, non-normatively, applications that fast network notifications enable. The actions themselves are out of scope (); they illustrate what the information in makes possible.

Upstream (remote) protection:: On a link or node failure notification, a node several hops upstream activates a pre-computed backup path instead of relying only on local repair, avoiding the hairpinning that purely local alternates (LFA or TI-LFA) can introduce. Efficient Remote Protection describes such a mechanism and applies both to failures and to degradations such as reduced capacity or congestion.
Fast protection in AI/ML fabrics:: AI/ML fabrics need convergence within tens of microseconds, requiring notification and reaction within the forwarding plane without CPU intervention. analyzes the limitations of existing IP-FRR in such fabrics and the requirements for fast, forwarding-plane protection.
Graduated load-sharing and flow control:: When a notification carries fine-grained status (utilization, available bandwidth, or capacity degradation) rather than a binary up/down, an upstream node can rebalance load-sharing weights in proportion to the reported severity, or apply per-flow, per-tenant, or per-slice flow control and backpressure toward the congestion point instead of the coarse, port-level pausing of link-layer PFC. Both responses are graduated and capacity-aware, shifting or throttling traffic gradually rather than all at once; the realizing mechanisms are surveyed in .

Scaling Considerations The solution must remain effective as the network grows. Scaling pressure arises from network size (the number of nodes and links that may report events), the volume and rate of change of reported information, and the number of consumers. The design assumption is that if anything can go wrong it will, so the system must cope with a high proportion of nodes and links reporting simultaneously. The framework addresses scale through subscription (delivering only relevant information), scoping and domain isolation (bounding propagation), relay-based filtering and aggregation, damping of rapidly changing conditions, and transport prioritization and rate limiting. Protocol specifications SHOULD quantify the load their mechanisms place on the forwarding and control planes under worst-case event conditions.

Operational Considerations Fast network notifications introduce additional traffic. During the failures and congestion events they report, the notification system MUST NOT exacerbate the situation and SHOULD actively assist in mitigating it. Operators SHOULD be able to configure which event types trigger notifications, the delivery modes and scopes used, damping and rate-limiting parameters, and prioritization, so that notification behavior aligns with network operation policies. Management and configuration of the solution are expected to be supported by YANG modules, to be defined as a separate deliverable consistent with the charter. Manageability includes observability of the notification system itself (counts, drops, damping events) so operators can verify it is helping rather than harming.

Security Considerations If not properly authenticated and rate-limited, fast network notifications could be a denial-of-service vector: an attacker that injects or floods spurious notifications could trigger unnecessary re-convergence, path changes, or repeated state updates, and could induce state flapping to keep an originator busy. Notifications may also reveal sensitive operational information, whether by inspection or by an adversary registering as a consumer. Accordingly, solutions built on this framework MUST provide integrity protection and origin authentication of notifications, MUST apply rate controls on both sending and receiving, and MUST address trust boundaries around domains and subscriptions, authorization of notification sources, and protection of sensitive operational data. Because stronger security can add latency, the trade-off between notification latency and security strength is considered per scenario. Domain identification and isolation () are central to confining notifications to the trusted administrative boundary. The charter's restriction to a single administrative control reduces, but does not eliminate, the threat surface. Because the operator controls every originator, relay, and consumer and the trust boundary coincides with the notification domain (), the boundary can drop notifications arriving from outside it (constraining external injection and spoofing), exposure of operational data to third parties is bounded, and trust for discovery, registration, and subscription can reuse existing intra-domain infrastructure. This lets the design favor lightweight, low-latency mechanisms internally while concentrating stronger enforcement at the domain boundary. This assumption does not remove the need for in-domain protection: insider threats, compromised or malfunctioning nodes, and the self-inflicted denial of service of a flapping link all originate inside the boundary. The requirements above therefore still apply within the domain, and the single-administrative-control premise should be treated as defense in depth rather than a substitute for them.

IANA Considerations This document requires no IANA actions.