Fast Network Notifications S. P. K. Pasalapudi Internet-Draft V. P. Beeram Intended status: Standards Track Hewlett Packard Enterprise Expires: 21 January 2027 20 July 2026 A YANG Data Model for Link Quality Telemetry in CLOS Data Center Fabrics draft-praveen-fann-lq-telemetry-info-00 Abstract This document defines a YANG data model for real-time link quality telemetry in multi-stage CLOS (leaf-spine) data center fabrics. The data model provides a vendor-agnostic representation of link congestion state, enabling next-next-hop (NNH) path quality visibility required for adaptive routing in AI/ML training networks. The link quality advertisement is modeled as a YANG data structure, making the model directly usable with any transport. The data model is deliberately decoupled from any transport. A lightweight UDP transport binding for disseminating the modeled data is specified in a companion document; additional transport bindings may be specified in future documents. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 21 January 2027. Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. Pasalapudi & Beeram Expires 21 January 2027 [Page 1] Internet-Draft LQ Telemetry Model July 2026 This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. The Congestion Visibility Gap . . . . . . . . . . . . . . 4 1.2. Design Principles . . . . . . . . . . . . . . . . . . . . 5 1.3. Document Structure . . . . . . . . . . . . . . . . . . . 5 1.4. Relationship to Other Work . . . . . . . . . . . . . . . 6 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 7 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 7 4. Architectural Overview . . . . . . . . . . . . . . . . . . . 8 4.1. Dual-Plane Architecture . . . . . . . . . . . . . . . . . 8 4.2. Node Roles . . . . . . . . . . . . . . . . . . . . . . . 9 4.3. Solicited vs. Unsolicited Operation . . . . . . . . . . . 9 5. YANG Data Model . . . . . . . . . . . . . . . . . . . . . . . 9 5.1. Model Overview . . . . . . . . . . . . . . . . . . . . . 10 5.2. Link Quality Score (LQS) Semantics . . . . . . . . . . . 11 5.3. Congestion Level (CL) Semantics . . . . . . . . . . . . . 12 5.4. Available Bandwidth . . . . . . . . . . . . . . . . . . . 13 5.5. Diagnostic Metrics . . . . . . . . . . . . . . . . . . . 13 5.6. YANG Module: ietf-lq-telemetry . . . . . . . . . . . . . 13 6. Receiver Processing . . . . . . . . . . . . . . . . . . . . . 29 6.1. Prerequisite: NNH Mapping . . . . . . . . . . . . . . . . 29 6.2. Path Quality Table . . . . . . . . . . . . . . . . . . . 29 6.3. Weighted ECMP Computation . . . . . . . . . . . . . . . . 30 6.4. Receiver Damping and Stability . . . . . . . . . . . . . 31 6.5. Heartbeat-Based Failure Detection . . . . . . . . . . . . 32 7. Transport Requirements . . . . . . . . . . . . . . . . . . . 32 7.1. Serialization . . . . . . . . . . . . . . . . . . . . . . 32 7.2. Periodic and Triggered Signaling . . . . . . . . . . . . 32 7.3. Link-Local Scoping . . . . . . . . . . . . . . . . . . . 33 8. Operation in 3-Stage CLOS . . . . . . . . . . . . . . . . . . 33 9. Operation in 5-Stage CLOS . . . . . . . . . . . . . . . . . . 33 10. Configuration Parameters . . . . . . . . . . . . . . . . . . 34 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35 11.1. IETF XML Registry . . . . . . . . . . . . . . . . . . . 35 11.2. YANG Module . . . . . . . . . . . . . . . . . . . . . . 35 12. Security Considerations . . . . . . . . . . . . . . . . . . . 35 12.1. Protocol Considerations . . . . . . . . . . . . . . . . 36 12.2. YANG Module Considerations . . . . . . . . . . . . . . . 36 Pasalapudi & Beeram Expires 21 January 2027 [Page 2] Internet-Draft LQ Telemetry Model July 2026 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 37 13.1. Normative References . . . . . . . . . . . . . . . . . . 37 13.2. Informative References . . . . . . . . . . . . . . . . . 39 Appendix A. Congestion Detection Pipeline . . . . . . . . . . . 41 A.1. Hardware Signals . . . . . . . . . . . . . . . . . . . . 42 A.2. Derived Metrics . . . . . . . . . . . . . . . . . . . . . 42 A.3. Asymmetric EWMA Smoothing . . . . . . . . . . . . . . . . 43 A.4. LQS Computation . . . . . . . . . . . . . . . . . . . . . 43 A.5. CL Mapping . . . . . . . . . . . . . . . . . . . . . . . 44 A.6. Hysteresis State Machine . . . . . . . . . . . . . . . . 44 Appendix B. Worked Example . . . . . . . . . . . . . . . . . . . 45 B.1. Steady State . . . . . . . . . . . . . . . . . . . . . . 45 B.2. Congestion (T=100ms) . . . . . . . . . . . . . . . . . . 45 B.3. Rerouting (T=104ms) . . . . . . . . . . . . . . . . . . . 45 B.4. Recovery (T=500ms) . . . . . . . . . . . . . . . . . . . 45 Appendix C. YANG Tree Diagram . . . . . . . . . . . . . . . . . 45 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 47 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 47 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 48 1. Introduction Modern data center networks employ multi-stage CLOS (leaf-spine) fabrics to provide high-bandwidth, equal-cost multi-path connectivity. AI and ML training workloads generate synchronous, bursty traffic patterns that create transient congestion lasting single-digit milliseconds. Effective adaptive routing requires real- time visibility into congestion on remote links -- the "next-next-hop visibility" problem -- but no vendor-neutral data model or standard transport exists for this information. Today, this gap is filled by proprietary mechanisms from major ASIC and switch vendors. Each uses a different wire format, a different metric set, and different semantics. An operator deploying switches from multiple vendors cannot obtain a unified view of fabric congestion, and management applications cannot consume link quality data without vendor-specific adapters. This document addresses the gap by defining a YANG data model (ietf- lq-telemetry) that specifies WHAT link quality information is exchanged, with vendor-agnostic semantics. The model has two parts: 1. The "lq-advertisement" YANG data structure [RFC8791], which is the transport-independent information model of a single link quality advertisement. This structure is the normative core of the document and is usable with any transport. Pasalapudi & Beeram Expires 21 January 2027 [Page 3] Internet-Draft LQ Telemetry Model July 2026 2. A configuration and operational state model for the nodes that generate and consume link quality advertisements. HOW the modeled data is carried on the wire is specified by transport binding documents. A lightweight UDP transport binding is defined in the companion document [I-D.praveen-fann-lq-telemetry-udp]. The UDP binding provides maximum forwarding-plane performance and ASIC offload in greenfield deployments. On forwarding engines capable of processing UDP payloads directly in the data plane, that binding achieves sub-100 microsecond notification latency, while retaining the routability, manageability, and payload richness of a UDP/IP transport. The data model and transport are deliberately decoupled. Additional transport bindings (e.g., gRPC/gNMI for controller-based architectures) MAY be specified in future documents without changing the data model. In this document, the lq-advertisement YANG structure serves as the concrete realization of the information model: it defines both the abstract semantics and the YANG encoding in a single artifact. When this document refers to the "information model," it means the abstract content and semantics of an LQ advertisement; when it refers to the "data model," it means the YANG module that realizes it. Because no separate abstract specification exists, the YANG module serves as both. 1.1. The Congestion Visibility Gap In a 3-stage CLOS fabric, a source leaf switch (L1) sending traffic to a remote destination leaf (L4) has multiple equal-cost paths through spine switches. Dynamic Load Balancing (DLB) monitors LOCAL uplink quality but cannot observe REMOTE link quality (spine-to-L4). If spine S2's link to L4 is severely congested while L1's link to S2 is healthy, L1 continues sending traffic to S2. S2 queues or drops it. The problem: * L1 has no visibility into S2-to-L4 link quality. * S2 has no standardized way to tell L1 about the congestion. * Even if S2 could signal, L1 has no standardized way to consume the data for forwarding decisions. The FANN problem statement [I-D.ietf-rtgwg-net-notif-ps] identifies remote congestion and failure notification as a critical requirement and calls for an information model for the data carried in such Pasalapudi & Beeram Expires 21 January 2027 [Page 4] Internet-Draft LQ Telemetry Model July 2026 notifications. The adaptive routing framework [I-D.cheng-rtgwg-adaptive-routing-framework] decomposes the solution into routing plane, forwarding plane, congestion detection, and remote congestion notification; this document and its companion [I-D.praveen-fann-lq-telemetry-udp] specify the last two, starting from the information model defined here. 1.2. Design Principles 1. *Data Model Is the Standard:* The YANG model is the normative interoperability point. Implementations are interoperable at the model level, which remains stable across future transport bindings. 2. *Transport Is Pluggable:* Transport bindings are specified in separate documents. The UDP binding is defined in [I-D.praveen-fann-lq-telemetry-udp]; additional bindings can be defined in future documents without changing the data model, enabling deployment-specific transport choices while preserving a single data model. 3. *Interoperability Fields Only on the Wire:* An advertisement carries the MINIMUM the receiver needs: a composite Link Quality Score (LQS, 0-255) and Congestion Level (CL, 0-7). HOW a sender computes these is implementation-defined, subject to the conformance requirements of Section 5.2 and Section 5.3. Diagnostic metrics are optional. 4. *ASIC Offload Without Mandatory Dependency:* The information model is designed so that a transport binding can serialize it for generation and consumption in the forwarding pipeline (see Section 7.1 and [I-D.praveen-fann-lq-telemetry-udp]), but no binding is required to mandate hardware processing. Implementations MAY process LQ advertisements on the line-card CPU or routing engine without affecting protocol semantics. 1.3. Document Structure The LQ Telemetry specification is split across two documents: This document: The data model: the YANG data structure defining the advertisement, the YANG configuration and operational state model, field semantics, receiver processing, requirements that any transport binding must satisfy, and operational guidance for 3-stage and 5-stage CLOS fabrics. This is transport-independent and constitutes the core normative contribution. [I-D.praveen-fann-lq-telemetry-udp]: The UDP transport binding: the Pasalapudi & Beeram Expires 21 January 2027 [Page 5] Internet-Draft LQ Telemetry Model July 2026 concrete wire format, addressing and scoping, and hardware- accelerated processing behavior. Additional transport bindings for the same data model may be specified in future documents. 1.4. Relationship to Other Work Among the IETF proposals on fast network notification for AI/ML and DC fabrics, now converging on the FANN Working Group, LQ Telemetry is distinguished by carrying graduated, quantitative link quality (a 256-level score and 8-level congestion level) rather than a binary up/down or single-event signal, and by making the transport- independent data model the normative interoperability point. The most directly relevant documents: FARE [I-D.xu-idr-fare]: BGP Path Bandwidth conveys static capacity (seconds timescale). LQ Telemetry conveys dynamic congestion (milliseconds timescale). They form a dual-plane architecture (Section 4.1). Fast Network Notifications Problem Statement [I-D.ietf-rtgwg-net-notif-ps]: Defines the problem space for fast network notification mechanisms and calls for an information model (Section 5.1) describing what notifications carry. LQ Telemetry's YANG model (Section 5) is a candidate information model for the congestion case, realized by the UDP binding [I-D.praveen-fann-lq-telemetry-udp]. FANN Framework [I-D.song-fann-framework]: Defines the reference architecture, functional roles, and delivery and scoping models that a fast network notification solution is expected to instantiate. In that taxonomy, a helper node acts as a notification originator and a load-balancer node as a consumer; the lq-advertisement structure is a realization of the framework's information model for the congestion case; and the link-local scoping requirement (Section 7.3) is a specific instance of the framework's notification-domain isolation. Lightspeed Notification Protocol (LSN) [I-D.camarillo-rtgwg-lsn]: A Pasalapudi & Beeram Expires 21 January 2027 [Page 6] Internet-Draft LQ Telemetry Model July 2026 hardware-accelerated, forwarding-plane signaling mechanism for sub-100 microsecond convergence that propagates link failures and congestion and provides an immediate hardware "veto" to prune congested or failed paths. LSN and LQ Telemetry occupy a very similar design point (forwarding-plane processing, hardware path pruning). LQ Telemetry is distinguished by its vendor-agnostic YANG information model, its graduated 256-level quality score (rather than a primarily failure/veto-oriented signal), and its decoupling of model from transport. Convergence or differentiation with LSN is expected to be a key discussion in FANN. BGP Next-Next-Hop Nodes [I-D.ietf-idr-next-next-hop-nodes]: An adopted IDR Working Group document advertising next-next-hop node information in BGP. This is the slow-plane counterpart to the NNH visibility problem (Section 1.1) that LQ Telemetry addresses dynamically: it establishes which NNH a path leads to, while LQ Telemetry supplies the fast-plane quality of the link to that NNH. It is one mechanism by which a receiver can obtain the NNH Mapping required by Section 6.1. Outside the IETF, the Ultra Ethernet Consortium [UEC] is standardizing Congestion Signaling (CSIG), an in-band, per-packet mechanism in which congestion state is updated hop-by-hop in the forwarding plane and reflected by the receiving NIC to the sender for rate control and path selection. CSIG informs end-host transport behavior on the timescale of a round trip; LQ Telemetry is out-of- band and switch-to-switch, giving the load-balancer switch the NNH visibility that sender-reflected in-band tags do not provide. The two are complementary and can coexist in the same fabric: in-band signaling steers end-host transport, while LQ Telemetry steers switch-level weighted ECMP. 2. 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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 3. Terminology CLOS Fabric: Multi-stage switching topology providing equal-cost paths between leaf switches via spine switches. Also known as leaf-spine fabric. Helper Node: Device that monitors egress link quality and generates Pasalapudi & Beeram Expires 21 January 2027 [Page 7] Internet-Draft LQ Telemetry Model July 2026 LQ advertisements. In a 3-stage CLOS, this is the spine switch. In a 5-stage CLOS, super-spines are helpers toward spines, and spines are helpers toward leaves. Load-Balancer Node: Device that consumes LQ data and adjusts forwarding weights. In a 3-stage CLOS, this is the leaf switch. In a 5-stage CLOS, spines are load-balancers from super-spines, and leaves are load-balancers from spines. Link Quality Score (LQS): 8-bit unsigned integer (0-255). Composite link quality metric. 0 = unusable, 255 = fully available. Computation is implementation-defined. Congestion Level (CL): 3-bit unsigned integer (0-7). Coarse severity classification. Next-Next-Hop (NNH): Node two forwarding hops away. In a CLOS fabric, the remote leaf reachable through a spine. NNH Mapping: The mapping from a destination prefix to the remote node (NNH) through which it is reachable, per next-hop. Required input to receiver processing; see Section 6.1. T_notify: Periodic advertisement interval. Default: 20 ms. Transport Binding: A specification mapping the lq-advertisement YANG data structure to a specific wire protocol. The UDP transport binding is defined in [I-D.praveen-fann-lq-telemetry-udp]. Node Identifier: 4-octet Router-ID used to identify a node in LQ advertisements, regardless of IPv4/IPv6 underlay. A Router-ID is a 4-octet identifier [RFC4271] that is only guaranteed unique within an Autonomous System [RFC6286]; for a globally unique identity it is qualified by an AS Number (see AS Qualifier). AS Qualifier: 4-octet AS Number [RFC6793] that, together with a Router-ID, forms a globally unique node identity [RFC6286]. The reserved value 0 [RFC7607] is a sentinel meaning "unqualified": the Router-ID alone identifies the node within the receiver's scope, as is sufficient in single-AS fabrics or fabrics with administratively unique Router-IDs. 4. Architectural Overview 4.1. Dual-Plane Architecture LQ Telemetry operates alongside BGP-based path signaling: Pasalapudi & Beeram Expires 21 January 2027 [Page 8] Internet-Draft LQ Telemetry Model July 2026 Slow Plane (BGP/FARE): Topology, ECMP structure, static capacity. Timescale: seconds. Determines WHICH paths exist and their maximum capacity. Fast Plane (LQ Telemetry): Dynamic congestion, available bandwidth, quality scores. Timescale: milliseconds (or microseconds on hardware-accelerated forwarding engines). Determines HOW MUCH of each path is currently usable. The load-balancer node (leaf) combines both: weight(path_i) = f(FARE_capacity(i), LQ_quality(i)) The fast plane data is defined by the YANG model in Section 5 and carried by whichever transport binding the deployment uses. A path is eligible for forwarding only if permitted by the slow plane (BGP route installed) AND confirmed healthy by the fast plane (LQS > 0). 4.2. Node Roles Helper-Only Mode: Monitors egress link quality. Generates LQ advertisements. Does NOT consume LQ from neighbors for its own forwarding. In a 3-stage CLOS: spine switches. Load-Balancer-Only Mode: Receives LQ advertisements. Builds path quality table. Computes weighted ECMP. Does NOT generate LQ advertisements. In a 3-stage CLOS: leaf switches. Dual Mode: Both helper and load-balancer simultaneously. In a 5-stage CLOS: spine switches (helper toward leaves, load-balancer toward super-spines). 4.3. Solicited vs. Unsolicited Operation The UDP transport binding [I-D.praveen-fann-lq-telemetry-udp] operates in unsolicited (push) mode: a helper node proactively advertises LQ data to neighbors at periodic intervals and upon significant changes. Solicited (pull) operation is not supported by the UDP binding; it is anticipated that future transport bindings (e.g., gRPC/gNMI) will provide solicited retrieval of the same YANG- modeled data. The "solicited" value of the signaling-mode leaf in the lq-advertisement structure is defined for use by such future bindings. 5. YANG Data Model Pasalapudi & Beeram Expires 21 January 2027 [Page 9] Internet-Draft LQ Telemetry Model July 2026 5.1. Model Overview The ietf-lq-telemetry YANG module defines the LQ Telemetry information in two parts: * The "lq-advertisement" structure, defined using YANG Data Structure Extensions [RFC8791], is the transport-independent information model of a single LQ advertisement. It is not part of any datastore. A transport binding document specifies how instances of this structure are serialized on the wire; the UDP binding is specified in [I-D.praveen-fann-lq-telemetry-udp]. * The "lq-telemetry" container holds node configuration and the operational state derived from generated and received advertisements, structured per the Network Management Datastore Architecture (NMDA) [RFC8342] with operational state marked "config false". The modeled link quality information is organized in three tiers: Tier 1 -- Core (Mandatory): LQS, CL, Available Bandwidth, Remote Node ID, Link ID, and the Remote AS Qualifier. These are the interoperability fields that MUST be present in every LQ advertisement. The (Remote AS, Remote Node ID, Link ID) tuple forms a composite key that uniquely identifies a per-destination, per-link quality entry, supporting parallel links, shared media, and point-to-point topologies. The Remote AS is 0 (unqualified) in single-AS fabrics; whether and how it appears on the wire is determined by the transport binding (in the UDP binding, it is carried only when the AS-Qualified (Q) flag is set). A receiver can make forwarding decisions using ONLY Tier 1 data. Tier 2 -- Metadata (Mandatory): Node Identifier, AS Qualifier, Sequence Number, Timestamp, and signaling mode, carried in the lq- advertisement-header grouping. Advertisement-level information for validation and freshness. Tier 3 -- Diagnostics (Optional): Queue depth, ECN marking rate, PFC pause fraction, link capacity, drop indicator. Useful for troubleshooting and analytics but NOT required for forwarding. Included only when explicitly enabled; their presence in an advertisement is indicated by the presence of the per-entry "diagnostics" container (transport bindings encode this presence as appropriate, e.g., the D flag of the UDP binding). Pasalapudi & Beeram Expires 21 January 2027 [Page 10] Internet-Draft LQ Telemetry Model July 2026 5.2. Link Quality Score (LQS) Semantics LQS is an 8-bit unsigned integer (0-255): +=========+===========================================+ | Range | Meaning | +=========+===========================================+ | 255 | Fully available, no congestion. | +---------+-------------------------------------------+ | 192-254 | Healthy, minor utilization. | +---------+-------------------------------------------+ | 128-191 | Moderately loaded, usable. | +---------+-------------------------------------------+ | 64-127 | Significantly congested, reduced quality. | +---------+-------------------------------------------+ | 1-63 | Severely congested, minimal capacity. | +---------+-------------------------------------------+ | 0 | Unusable (failed or fully congested). | +---------+-------------------------------------------+ Table 1 The computation of LQS from hardware signals is EXPLICITLY implementation-defined. Vendors MAY use different detection algorithms, counter sets, smoothing functions, and weighting schemes. The normative requirements are: * The value MUST conform to the semantic ranges above. * The mapping MUST be monotonic in each congestion indicator (utilization, queue depth, ECN marking rate, PFC pause fraction, and drop state): a worsening of any one indicator, with the others held constant, MUST produce an equal or lower LQS value. A RECOMMENDED detection pipeline is provided in Appendix A, which is a normative part of this specification. Implementations SHOULD follow the detection pipeline in Appendix A to ensure comparable LQS values across vendors within a fabric. Comparability caveat: The weighted ECMP computation (Section 6.3) compares LQS values received from different helper nodes against one another. Two implementations that each satisfy the conformance requirements above may nevertheless produce different LQS values for identical link conditions. All helper nodes whose advertisements are compared within a single ECMP group SHOULD therefore use the same LQS computation. Operators SHOULD NOT mix helper implementations with different LQS computations within one ECMP group unless the implementations have been verified to Pasalapudi & Beeram Expires 21 January 2027 [Page 11] Internet-Draft LQ Telemetry Model July 2026 produce comparable scores (e.g., both follow Appendix A with the RECOMMENDED parameter values); doing otherwise results in systematically skewed traffic distribution rather than a protocol failure. 5.3. Congestion Level (CL) Semantics CL is a 3-bit unsigned integer (0-7) providing coarse severity: +=======+==========+==============================================+ | Value | Name | Meaning | +=======+==========+==============================================+ | 0 | NONE | No congestion detected. | +-------+----------+----------------------------------------------+ | 1 | MINIMAL | Approaching capacity; no quality impact yet. | +-------+----------+----------------------------------------------+ | 2 | LOW | Buffering detected; negligible user impact. | +-------+----------+----------------------------------------------+ | 3 | MODERATE | Measurable quality reduction. | +-------+----------+----------------------------------------------+ | 4 | ELEVATED | Significant congestion; transport feedback | | | | (ECN/DCQCN) active. | +-------+----------+----------------------------------------------+ | 5 | HIGH | Heavy congestion; flow control (PFC) active. | +-------+----------+----------------------------------------------+ | 6 | SEVERE | Near-capacity; backpressure propagating. | +-------+----------+----------------------------------------------+ | 7 | CRITICAL | Data loss occurring or link unusable. | +-------+----------+----------------------------------------------+ Table 2 The mapping from hardware signals to CL levels is implementation- defined. The mapping MUST be monotonic in each congestion indicator in the sense of Section 5.2: a worsening of any one indicator, with the others held constant, MUST produce an equal or higher CL value. Implementations SHOULD follow the CL mapping in Appendix A.5 to ensure consistent severity classification across vendors within a fabric. The comparability caveat of Section 5.2 applies equally to CL. Pasalapudi & Beeram Expires 21 January 2027 [Page 12] Internet-Draft LQ Telemetry Model July 2026 5.4. Available Bandwidth Available bandwidth represents the estimated currently available bandwidth of the link in Gbps, accounting for utilization and any flow control impact. It is modeled as a decimal64 value with three fractional digits; a transport binding MAY serialize it as an IEEE 754 [IEEE754] single-precision value, with the rounding rules given in the "bandwidth-gbps" typedef of the YANG module. Aligns with [RFC7471] (OSPF-TE Metric Extensions), [RFC8571] (BGP-LS Performance Metrics), and FARE conventions. 5.5. Diagnostic Metrics The following metrics are OPTIONAL and included only when diagnostics are enabled: Link Capacity: Configured/negotiated link speed in Gbps. Static; changes only on speed renegotiation. Queue Depth: Uint8 (0-255). Normalized egress queue occupancy, where 0 is an empty buffer and 255 is a full buffer. ECN Marking Rate: Uint8 (0-31). ECN marking percentage in ~3.2% increments. PFC Pause Fraction: Uint8 (0-31). Fraction of time paused in ~3.2% increments. Meaningful only in PFC fabrics. Drop Indicator: Boolean. True if packet drops in current interval. These metrics are NOT interoperability fields. Receivers MUST NOT use them for forwarding decisions. They exist to support NMS visualization, controller analytics, and troubleshooting. 5.6. YANG Module: ietf-lq-telemetry The ietf-lq-telemetry module is written in YANG version 1.1 [RFC7950]. It imports common YANG data types [RFC9911] (the "dotted- quad", "date-and-time", and "milliseconds32" types from ietf-yang- types and the "as-number" type from ietf-inet-types) and the "structure" extension from ietf-yang-structure-ext [RFC8791]. Pasalapudi & Beeram Expires 21 January 2027 [Page 13] Internet-Draft LQ Telemetry Model July 2026 file "ietf-lq-telemetry@2026-07-07.yang" module ietf-lq-telemetry { yang-version 1.1; namespace "urn:ietf:params:xml:ns:yang:ietf-lq-telemetry"; prefix lqt; import ietf-yang-types { prefix yang; reference "RFC 9911: Common YANG Data Types"; } import ietf-inet-types { prefix inet; reference "RFC 9911: Common YANG Data Types"; } import ietf-yang-structure-ext { prefix sx; reference "RFC 8791: YANG Data Structure Extensions"; } organization "IETF FANN (Fast Network Notifications) Working Group"; contact "WG Web: WG List: Author: S. Praveen K. Pasalapudi Author: Vishnu Pavan Beeram "; description "This module defines the data model for link quality (LQ) telemetry in CLOS (leaf-spine) data center fabrics, together with the configuration and operational state of nodes that generate and consume LQ telemetry. The 'lq-advertisement' structure (RFC 8791) is the transport-independent information model of a single LQ advertisement. Transport binding documents specify how instances of this structure are serialized on the wire. The 'lq-telemetry' container holds node configuration and the operational state derived from generated and received advertisements. Pasalapudi & Beeram Expires 21 January 2027 [Page 14] Internet-Draft LQ Telemetry Model July 2026 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 (RFC 2119) (RFC 8174) when, and only when, they appear in all capitals, as shown here. Copyright (c) 2026 IETF Trust and the persons identified as authors of the code. All rights reserved. Redistribution and use in source and binary forms, with or without modification, is permitted pursuant to, and subject to the license terms contained in, the Revised BSD License set forth in Section 4.c of the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info). This version of this YANG module is part of RFC XXXX (https://www.rfc-editor.org/info/rfcXXXX); see the RFC itself for full legal notices."; revision 2026-07-07 { description "Initial revision. Models the LQ advertisement as an RFC 8791 structure, separate from device configuration and operational state, with node identity as an (AS Number, Router-ID) pair where the reserved value 0 (RFC 7607) means unqualified."; reference "RFC XXXX: A YANG Data Model for Link Quality Telemetry in CLOS Data Center Fabrics"; } /* * Features */ feature diagnostics { description "Support for optional Tier 3 diagnostic metrics. When not advertised, diagnostic data is neither generated in LQ advertisements nor retained in operational state."; } /* * Identities */ Pasalapudi & Beeram Expires 21 January 2027 [Page 15] Internet-Draft LQ Telemetry Model July 2026 identity lq-transport { description "Base identity for LQ transport bindings. Documents that specify a transport binding for the LQ Telemetry data model derive an identity from this base; such derived identities MAY be defined in the binding document's own YANG module."; } identity lq-transport-udp { base lq-transport; description "Lightweight UDP transport binding using a compact, fixed-offset binary encoding suitable for forwarding-plane (ASIC) generation and consumption. As a leaf value, denotes the binding's native UDP carriage; see 'lq-transport-udp-router-info' for the Router-Info carriage of the same payload."; reference "RFC YYYY: A UDP Transport Binding for Link Quality Telemetry in CLOS Data Center Fabrics"; } identity lq-transport-udp-router-info { base lq-transport-udp; description "Carriage of the UDP binding's LQ payload as a TLV within the Router-Info advertisement mechanism, gaining that mechanism's authentication and refresh-rate negotiation."; reference "RFC YYYY: A UDP Transport Binding for Link Quality Telemetry in CLOS Data Center Fabrics"; } /* * Type Definitions */ typedef link-quality-score { type uint8; description "Composite link quality score (LQS) in the range 0-255, where 0 means unusable (failed or fully congested) and 255 means fully available. The computation of the score from hardware signals is implementation-defined but MUST be monotonic in each congestion indicator: worsening conditions MUST produce equal or lower Pasalapudi & Beeram Expires 21 January 2027 [Page 16] Internet-Draft LQ Telemetry Model July 2026 values."; } typedef congestion-level { type uint8 { range "0..7"; } description "Coarse congestion severity (CL) in the range 0-7, where 0 means no congestion and 7 means critical (data loss occurring or link unusable). The mapping from hardware signals is implementation-defined but MUST be monotonic: worsening conditions MUST produce equal or higher values."; } typedef bandwidth-gbps { type decimal64 { fraction-digits 3; } units "Gbps"; description "Bandwidth in gigabits per second. A transport binding MAY serialize values of this type as an IEEE 754 binary32 value per RFC 7471 and RFC 8571 conventions; in that case, values are rounded to the nearest representable binary32 value on encoding, and the decoded value is rounded to three fractional digits."; } typedef node-identifier { type yang:dotted-quad; description "4-octet Router-ID (RFC 4271, RFC 6286) identifying a node, used regardless of IPv4/IPv6 underlay. A Router-ID is only guaranteed unique within an Autonomous System (RFC 6286); for a globally unique node identity, it is qualified by an AS Number (see 'as-qualifier')."; } typedef as-qualifier { type inet:as-number; description "AS Number qualifying a node's Router-ID. Together with a Router-ID, it forms a globally unique node identity, since a Router-ID is only unique within an AS (RFC 6286). Pasalapudi & Beeram Expires 21 January 2027 [Page 17] Internet-Draft LQ Telemetry Model July 2026 The reserved value 0 (RFC 7607) is a sentinel meaning 'unqualified': the Router-ID alone identifies the node within the receiver's scope. This is the expected value in single-AS fabrics and in fabrics that administratively guarantee fabric-wide unique Router-IDs. When a transport binding omits AS Numbers from the wire (e.g., when the UDP binding's AS-Qualified (Q) flag is clear), the receiver populates leaves of this type with 0. As a key component, a leaf of this type is always present in the datastore, keeping lookup keys (and any hardware path quality table) a fixed width."; } /* * Groupings - Reusable Building Blocks */ grouping lq-entry-key { description "Composite key identifying a per-destination, per-link quality entry: (remote-as, remote-node-id, link-id). Supports parallel links, shared media, and point-to-point topologies."; leaf remote-as { type as-qualifier; description "AS Number qualifying 'remote-node-id'. 0 (RFC 7607) when unqualified."; } leaf remote-node-id { type node-identifier; description "Router-ID of the far-end neighbor on the reported link. In a CLOS fabric, this identifies the remote leaf reachable through the advertising spine. Qualified by 'remote-as' for a globally unique identity (RFC 6286)."; } leaf link-id { type uint32; description "Local interface identifier on the advertising node. Together with (remote-as, remote-node-id), it forms a composite key that uniquely identifies a (destination, link) pair. Pasalapudi & Beeram Expires 21 January 2027 [Page 18] Internet-Draft LQ Telemetry Model July 2026 This field supports three topology cases: 1. Single link to a single remote node: link-id SHOULD be set to the ifIndex of the link. 2. Parallel links to the same remote node: each link produces a separate entry with the same remote-node-id but distinct link-id values (one per physical link or LAG member). 3. Multiple remote nodes reachable via the same link (shared medium or multi-access segment): each destination produces a separate entry with the same link-id but distinct remote-node-id values. The helper MAY report different LQS values per destination on the same link if per-destination quality differs. When the advertising node treats parallel links as a LAG and advertises aggregate quality, this field SHOULD be set to the ifIndex of the LAG bundle interface."; } } grouping lq-entry-data { description "Core per-link quality data (Tier 1). The MINIMUM data a receiver needs for forwarding decisions."; leaf available-bandwidth { type bandwidth-gbps; mandatory true; description "Estimated currently available bandwidth (Gbps). Accounts for utilization and flow control."; } leaf lqs { type link-quality-score; mandatory true; description "Composite quality score. Implementation-defined computation; standardized semantic ranges."; } leaf cl { type congestion-level; mandatory true; description "Congestion severity. Implementation-defined Pasalapudi & Beeram Expires 21 January 2027 [Page 19] Internet-Draft LQ Telemetry Model July 2026 mapping; standardized semantic levels."; } } grouping lq-diagnostics { description "Optional per-link diagnostics (Tier 3), for analytics, troubleshooting, and visualization. NOT for forwarding decisions."; leaf link-capacity { type bandwidth-gbps; description "Configured/negotiated link speed (Gbps)."; } leaf queue-depth { type uint8; description "Normalized egress queue occupancy in the range 0-255, where 0 means an empty buffer and 255 means a full buffer."; } leaf ecn-marking-rate { type uint8 { range "0..31"; } description "ECN marking rate in ~3.2% steps. 0 = none, 31 = 100%."; } leaf pfc-pause-fraction { type uint8 { range "0..31"; } description "PFC pause time fraction in ~3.2% steps. Meaningful only when the advertising node reports a PFC-enabled fabric ('pfc-fabric' is true)."; } leaf drops-active { type boolean; default "false"; description "True if packet drops were detected in the current interval."; } } grouping lq-advertisement-header { Pasalapudi & Beeram Expires 21 January 2027 [Page 20] Internet-Draft LQ Telemetry Model July 2026 description "Advertisement-level metadata (Tier 2), present in every LQ advertisement regardless of transport."; leaf node-id { type node-identifier; mandatory true; description "Router-ID of the sending node."; } leaf node-as { type as-qualifier; default "0"; description "AS Number qualifying the sending node's Router-ID. 0 (unqualified) unless the node is configured for AS-qualified operation."; } leaf sequence-number { type uint16; mandatory true; description "Monotonically increasing per sending node, wrapping from 65535 to 0. Used for loss, reordering, and replay detection. Receivers MUST compare sequence numbers using serial number arithmetic (RFC 1982) with SERIAL_BITS = 16."; reference "RFC 1982: Serial Number Arithmetic"; } leaf timestamp-ms { type yang:milliseconds32; description "Milliseconds since the sending node booted, modulo 2^32 (the value wraps approximately every 49.7 days). Meaningful only relative to other advertisements from the same sender; not comparable across nodes."; } leaf pfc-fabric { type boolean; default "false"; description "True if the sender operates in a PFC-enabled (lossless) fabric. When false, PFC-related diagnostic fields are not meaningful."; } leaf signaling-mode { type enumeration { enum periodic { Pasalapudi & Beeram Expires 21 January 2027 [Page 21] Internet-Draft LQ Telemetry Model July 2026 description "Scheduled heartbeat advertisement."; } enum triggered { description "Change-detected advertisement."; } enum solicited { description "Response to an explicit query. Not used by the UDP transport binding, which operates only in unsolicited mode; defined for future transport bindings that support solicited retrieval."; } } description "How this advertisement was generated."; } } /* * LQ Advertisement Information Model (RFC 8791 Structure) * * This structure is the transport-independent definition * of an LQ advertisement. It is not part of any datastore; * transport binding documents specify its serialization. */ sx:structure lq-advertisement { description "A single LQ advertisement as generated by a helper node and consumed by a load-balancer node."; uses lq-advertisement-header; list link-quality { key "remote-as remote-node-id link-id"; description "Per-egress-link quality entries carried in this advertisement."; uses lq-entry-key; uses lq-entry-data; container diagnostics { if-feature "diagnostics"; presence "Tier 3 diagnostic metrics are included for this entry."; description "Optional diagnostic metrics. The presence of this container indicates that diagnostics were included Pasalapudi & Beeram Expires 21 January 2027 [Page 22] Internet-Draft LQ Telemetry Model July 2026 in the advertisement."; uses lq-diagnostics; } } } /* * Configuration and Operational State */ container lq-telemetry { description "Configuration and operational state for link quality telemetry."; leaf enabled { type boolean; default "false"; description "Enable LQ telemetry on this node."; } leaf role { type enumeration { enum helper { description "Generate LQ advertisements. Spine in a 3-stage CLOS."; } enum load-balancer { description "Consume LQ data. Leaf in a 3-stage CLOS."; } enum dual { description "Both roles. Spine in a 5-stage CLOS."; } } description "Node role in the LQ telemetry system."; } leaf-list active-transports { type identityref { base lq-transport; } description "Transport bindings enabled on this node. Multiple bindings may be active simultaneously."; } leaf as-qualified { Pasalapudi & Beeram Expires 21 January 2027 [Page 23] Internet-Draft LQ Telemetry Model July 2026 type boolean; default "false"; description "When true, this node operates in AS-qualified mode and includes AS Numbers (the sender AS in the advertisement header and a remote AS per entry) in its advertisements. Enable in multi-AS fabrics where Router-IDs are not unique fabric-wide (RFC 6286). When false, advertisements carry Router-IDs only and AS qualifiers are treated as 0 (unqualified). This value MUST be configured consistently on all nodes of a fabric."; } leaf local-as { type inet:as-number; description "This node's BGP Autonomous System Number, used to populate the sender AS qualifier when 'as-qualified' is true. If absent, the node uses its BGP local AS."; } leaf pfc-fabric { type boolean; default "false"; description "True if this node operates in a PFC-enabled (lossless) fabric. Advertised in the 'pfc-fabric' leaf of generated advertisements."; } leaf notify-interval-ms { type uint16 { range "10..100"; } units "milliseconds"; default "20"; description "Periodic advertisement interval (T_notify). All helper nodes in a fabric MUST use the same value."; } leaf change-threshold { type uint8 { range "10..50"; } default "25"; description "LQS delta relative to the last advertised value that triggers an immediate advertisement. All helper nodes in a fabric MUST use the same value."; } Pasalapudi & Beeram Expires 21 January 2027 [Page 24] Internet-Draft LQ Telemetry Model July 2026 leaf miss-count { type uint8 { range "2..10"; } default "3"; description "Consecutive missed heartbeats before declaring neighbor failure."; } leaf diagnostics-enabled { if-feature "diagnostics"; type boolean; default "false"; description "Include Tier 3 diagnostic metrics in generated advertisements."; } container local { config false; description "Operational state of LQ data generated by this node (helper role)."; leaf last-sequence-number { type uint16; description "Sequence number of the most recently transmitted advertisement."; } list link-quality { key "remote-as remote-node-id link-id"; description "Per-egress-link quality as most recently computed and advertised by this node."; uses lq-entry-key; uses lq-entry-data; container diagnostics { if-feature "diagnostics"; presence "Diagnostics are being generated for this entry."; description "Optional diagnostic metrics."; uses lq-diagnostics; } } } container neighbors { config false; description Pasalapudi & Beeram Expires 21 January 2027 [Page 25] Internet-Draft LQ Telemetry Model July 2026 "Operational state of LQ data received from neighbor nodes (load-balancer role)."; list neighbor { key "node-as node-id"; description "Per-neighbor received state."; leaf node-as { type as-qualifier; description "AS Number qualifying the neighbor's Router-ID. 0 (RFC 7607) when unqualified."; } leaf node-id { type node-identifier; description "Neighbor's Router-ID."; } leaf last-seen { type yang:date-and-time; description "Time at which the last LQ advertisement was received from this neighbor."; } leaf last-sequence { type uint16; description "Sequence number of the last accepted advertisement, compared using serial number arithmetic (RFC 1982)."; } leaf transport { type identityref { base lq-transport; } description "Transport binding over which LQ advertisements are received from this neighbor."; } leaf state { type enumeration { enum active { description "Receiving LQ advertisements normally."; } enum stale { description "No advertisement received for more than T_notify but less than Pasalapudi & Beeram Expires 21 January 2027 [Page 26] Internet-Draft LQ Telemetry Model July 2026 miss-count * T_notify."; } enum failed { description "No advertisement received for more than miss-count * T_notify. All paths through this neighbor are set to quality zero."; } } description "Neighbor health state."; } list link-quality { key "remote-as remote-node-id link-id"; description "Per-link quality most recently received from this neighbor."; uses lq-entry-key; uses lq-entry-data; container diagnostics { if-feature "diagnostics"; presence "Diagnostics were received for this entry."; description "Diagnostic data, if received."; uses lq-diagnostics; } } } } } /* * Notifications */ notification lq-threshold-crossed { description "Generated when a link's congestion level (CL) changes. This notification can be consumed by management systems subscribing to YANG notifications via any compatible transport."; leaf node-id { type node-identifier; mandatory true; description "Node reporting the change."; } Pasalapudi & Beeram Expires 21 January 2027 [Page 27] Internet-Draft LQ Telemetry Model July 2026 leaf node-as { type as-qualifier; default "0"; description "AS Number qualifying the reporting node's Router-ID. 0 when unqualified."; } leaf remote-as { type as-qualifier; default "0"; description "AS Number qualifying 'remote-node-id'. 0 when unqualified."; } leaf remote-node-id { type node-identifier; mandatory true; description "Affected link's far end."; } leaf link-id { type uint32; mandatory true; description "Local interface identifier on the reporting node. Identifies the specific link to the remote node."; } leaf old-cl { type congestion-level; mandatory true; description "Previous congestion level."; } leaf new-cl { type congestion-level; mandatory true; description "New congestion level."; } leaf lqs { type link-quality-score; description "Current LQS value."; } } } Pasalapudi & Beeram Expires 21 January 2027 [Page 28] Internet-Draft LQ Telemetry Model July 2026 6. Receiver Processing This section defines how a load-balancer node (leaf) processes received LQ data, independent of which transport delivered it. 6.1. Prerequisite: NNH Mapping Receiver processing requires, as an input, the NNH Mapping: for each destination prefix D and each candidate next-hop (spine) S, the identity of the remote node R (the NNH) through which D is reachable via S. This mapping associates the (remote-as, remote-node-id) key of received LQ entries with the destinations the receiver forwards to. How the NNH Mapping is obtained is outside the scope of this document. It MAY be learned dynamically, for example via BGP next- next-hop node advertisement [I-D.ietf-idr-next-next-hop-nodes], or provisioned by a fabric controller or static configuration. A receiver that lacks an NNH Mapping for a destination MUST fall back to local-only quality (DLB) for that destination; received LQ entries for unknown remote nodes are retained in the path quality table but do not influence forwarding until a mapping exists. 6.2. Path Quality Table The leaf maintains a table indexed by (spine_as, spine_node_id, remote_leaf_as, remote_leaf_id, link_id). The AS components are the sender (node-as) and remote (remote-as) AS Qualifiers, and are 0 when the advertisement is not AS-qualified. Including the AS components in the index keeps the key width fixed, and disambiguates nodes whose Router-IDs are reused across Autonomous Systems [RFC6286]: For each LQ entry from spine S (= spine_as:spine_node_id) targeting remote leaf R (= remote_leaf_as:remote_leaf_id) on link L: remote_lqs(S, R, L) = lqs remote_avail(S, R, L) = available-bandwidth remote_cl(S, R, L) = cl link_id(S, R, L) = link-id last_seen(S) = current_time last_seq(S) = sequence-number When multiple parallel links exist between a spine and a remote leaf, each link appears as a separate entry in the table. The link-id field distinguishes them. Pasalapudi & Beeram Expires 21 January 2027 [Page 29] Internet-Draft LQ Telemetry Model July 2026 When multiple remote nodes are reachable via the same link (shared medium or multi-access segment), each (remote-as, remote-node-id, link-id) tuple appears as a separate entry. In this case, the physical link congestion (queue depth, utilization) may be the same across destinations, but the helper MAY report different LQS values per destination if per-destination quality differs (e.g., due to per- destination queuing or scheduling). The composite key (remote-as, remote-node-id, link-id) thus covers all topology cases: one-to-one, parallel links to the same remote, shared links to multiple remotes, and remotes in different Autonomous Systems that happen to share a Router-ID. 6.3. Weighted ECMP Computation For destination prefix D reachable via remote leaf R (per the NNH Mapping, Section 6.1): When a single link exists per (spine, remote-leaf) pair: path_quality(S) = min(local_quality(S), remote_lqs(S, R, L)) where local_quality(S) is the quality of the leaf's uplink to spine S from the local DLB mechanism. target_weight(S) = path_quality(S) / sum(path_quality(j)) for all j When multiple parallel links exist between spine S and remote leaf R, the receiver MAY compute per-link path quality: path_quality(S, L) = min(local_quality(S), remote_lqs(S, R, L)) and distribute traffic across individual links proportionally, or MAY aggregate parallel link qualities (e.g., use the minimum or weighted average across links) to produce a single weight per spine. When multiple remote nodes share the same link from spine S, the receiver observes distinct LQS values for each destination on that link. The receiver SHOULD use the per-destination LQS for weight computation, as congestion toward one remote node on a shared link does not necessarily affect paths to other remote nodes on the same link. LQS = 0: target weight = 0 unless all paths are 0 (fallback to equal). Pasalapudi & Beeram Expires 21 January 2027 [Page 30] Internet-Draft LQ Telemetry Model July 2026 The target weights computed above are applied subject to the damping rules of Section 6.4. 6.4. Receiver Damping and Stability Adaptive traffic steering driven by fast congestion feedback is a closed control loop and is susceptible to oscillation: when a triggered advertisement reports congestion on one path, all load- balancer nodes that receive it shift traffic away from that path near-simultaneously, which can congest the remaining paths, trigger further advertisements, and cause traffic to slosh back -- a synchronized herd effect. Sender-side smoothing and hysteresis (Appendix A) dampen the quality signal itself; this section specifies complementary receiver-side damping of the response to that signal. A receiver MUST NOT apply target weights (Section 6.3) more often than once per T_reweight per destination, where T_reweight is RECOMMENDED to be equal to T_notify (default 20 ms). Exception: a transition of any path_quality to or from 0 (path failure or recovery) SHOULD be applied immediately, since pruning a dead path cannot cause oscillation. A receiver SHOULD apply weight changes gradually rather than stepping directly to the target: weight_new(S) = weight_old(S) + g * (target_weight(S) - weight_old(S)) where g is the damping gain, RECOMMENDED 0.5, with permitted values in the range 0.25 to 1.0 (g = 1.0 disables damping). Lower values of g trade responsiveness for stability. After applying damping, weights are renormalized to sum to 1. To desynchronize periodic advertisements from different helper nodes, a helper SHOULD jitter each periodic transmission uniformly in the interval [0.9 * T_notify, 1.1 * T_notify]; see Section 7.2. The mechanisms in this section bound the worst-case reaction of the fabric to a single congestion event to a small number of damped reweighting steps rather than an immediate full shift, at the cost of reaching the target distribution over approximately ceil(log(epsilon) / log(1 - g)) reweighting intervals (for g < 1), where epsilon is the acceptable residual expressed as a fraction of the initial weight shift. With the RECOMMENDED g = 0.5 and T_reweight = 20 ms, the residual falls below 10% of the initial weight shift within 4 reweighting intervals, i.e., in approximately 80 ms, while remaining stable under synchronized feedback. Pasalapudi & Beeram Expires 21 January 2027 [Page 31] Internet-Draft LQ Telemetry Model July 2026 6.5. Heartbeat-Based Failure Detection If no LQ message from spine S for miss_count * T_notify: set remote_lqs(S, R, L) = 0 and remote_cl(S, R, L) = 7 for all R and L. With the default parameters (miss_count = 3, T_notify = 20 ms), this provides sub-100 ms failure detection (60 ms nominal; 66 ms with worst-case transmission jitter of 1.1 * T_notify) independent of BFD [RFC5880], using the same data stream as congestion signaling. Detection time scales as miss_count * T_notify for other settings. 7. Transport Requirements This section states requirements that a transport binding for this data model MUST satisfy. The UDP transport binding defined in [I-D.praveen-fann-lq-telemetry-udp] satisfies these requirements; future transport bindings for the same data model SHOULD satisfy them. 7.1. Serialization A transport binding MUST specify how instances of the lq- advertisement structure map to octets on the wire, covering every Tier 1 and Tier 2 node and, if the binding supports diagnostics, every Tier 3 node. A binding MUST preserve the value spaces and semantics defined by the YANG model; where a binding uses a wire type with a different value space (e.g., IEEE 754 [IEEE754] binary32 for available bandwidth), the binding MUST specify the conversion and rounding rules. Bindings intended for forwarding-plane processing SHOULD use a compact binary encoding with fixed-position fields so the payload is parseable by an ASIC without variable-length or TLV walking. (As a non-normative example, the UDP binding encodes LQS as 1 octet, CL as 3 bits, and available bandwidth as a 4-octet IEEE 754 value.) 7.2. Periodic and Triggered Signaling A transport binding MUST support: * Periodic: every T_notify (default 20 ms). To desynchronize helper nodes, each periodic transmission SHOULD be jittered uniformly within [0.9 * T_notify, 1.1 * T_notify] (Section 6.4). * Triggered: within one sampling interval when |LQS_new - LQS_last_sent| > CHANGE_THRESHOLD or CL changes. Upon triggered send, periodic timer resets. Pasalapudi & Beeram Expires 21 January 2027 [Page 32] Internet-Draft LQ Telemetry Model July 2026 A binding is not required to provide reliable delivery: the periodic advertisement acts as the repair mechanism for lost triggered advertisements, bounding the staleness of receiver state to approximately one T_notify interval per loss. 7.3. Link-Local Scoping Unsolicited advertisements MUST be confined to one hop. The UDP binding achieves this with TTL/Hop Limit = 255 and GTSM-style [RFC5082] validation on receipt, as specified in [I-D.praveen-fann-lq-telemetry-udp]. 8. Operation in 3-Stage CLOS 4 leaves (L1-L4), 4 spines (S1-S4), all 400G. Each spine runs as helper, generating LQ advertisements via the configured transport binding (e.g., the UDP binding [I-D.praveen-fann-lq-telemetry-udp]). Each leaf runs as load- balancer, receiving and processing LQ data. Steady state: ~equal ECMP weights. Congestion on S2-to-L4: S2 sends triggered LQ, LQS=72. L1 recomputes: S2 weight drops from 25% toward a 9.2% target over the damped reweighting steps of Section 6.4. Recovery: slow decay, hold-down, return to equal weights. Full numerical walkthrough in Appendix B. 9. Operation in 5-Stage CLOS In a 5-stage CLOS, pods of leaves and spines are interconnected by a super-spine tier. Node roles are: super-spines run in helper mode (advertising toward spines), spines run in dual mode (load-balancer for advertisements received from super-spines, helper toward leaves), and leaves run in load-balancer mode. This document specifies stage-by-stage operation: * The LQS and CL that a helper advertises for a link MUST reflect the quality of that local egress link only, at every tier. A dual-mode spine advertising the quality of its spine-to-leaf links to source leaves does not incorporate the quality of its super- spine-facing uplinks into those advertisements. * Congestion above a given tier is mitigated at that tier: a dual- mode spine uses the LQ advertisements it receives from super- spines, together with its own uplink DLB, to steer its upward traffic among super-spines, exactly as a leaf does among spines. Pasalapudi & Beeram Expires 21 January 2027 [Page 33] Internet-Draft LQ Telemetry Model July 2026 Each stage of the fabric therefore runs an independent instance of the receiver processing defined in this document, and congestion at any tier is first addressed by the load-balancer immediately below it. * A source leaf consequently has direct visibility one and two hops up (its own uplinks via DLB, and its spines' next links via LQ advertisements) and relies on the intermediate tiers' own adaptive steering for congestion deeper in the fabric. The stage-by-stage model preserves the per-link semantics of LQS and CL (Section 5.2, Section 5.3) and requires no aggregation logic. An OPTIONAL "effective quality" mode -- in which a dual-mode node folds the quality of its best upstream path into the values it advertises downstream, giving source leaves indirect visibility beyond two hops -- is deliberately NOT specified in this document. Defining it requires an aggregation function with cross-tier monotonicity and loop-freedom properties, and a means of distinguishing local from aggregated quality in diagnostics; it is left for a future document. Implementations MUST NOT advertise aggregated upstream quality in the LQS and CL fields defined by this document. 10. Configuration Parameters +==================+=========+=============+===============+ | Parameter | Default | Range | Scope | +==================+=========+=============+===============+ | T_notify | 20 ms | 10-100 ms | Wire protocol | +------------------+---------+-------------+---------------+ | CHANGE_THRESHOLD | 25 | 10-50 | Wire protocol | +------------------+---------+-------------+---------------+ | miss_count | 3 | 2-10 | Receiver | +------------------+---------+-------------+---------------+ | T_reweight | 20 ms | >= T_notify | Receiver | +------------------+---------+-------------+---------------+ | g (damping gain) | 0.5 | 0.25-1.0 | Receiver | +------------------+---------+-------------+---------------+ Table 3 Detection pipeline parameters (T_sample, alpha_rise, alpha_fall, T_hold_down, weighting coefficients) are specified in Appendix A with RECOMMENDED values. Implementations SHOULD follow the RECOMMENDED values to ensure comparable LQS computation across vendors. All spines in a fabric MUST use the same T_notify and CHANGE_THRESHOLD, and MUST use the same setting of AS-qualified operation (the "as-qualified" leaf). Pasalapudi & Beeram Expires 21 January 2027 [Page 34] Internet-Draft LQ Telemetry Model July 2026 11. IANA Considerations 11.1. IETF XML Registry IANA is requested to register the following URI in the "ns" subregistry within the "IETF XML Registry" [RFC3688]: URI: urn:ietf:params:xml:ns:yang:ietf-lq-telemetry Registrant Contact: The IESG. XML: N/A; the requested URI is an XML namespace. 11.2. YANG Module IANA is requested to register the following YANG module in the "YANG Module Names" registry [RFC6020]: +===========+===============================================+ | Field | Value | +===========+===============================================+ | Name | ietf-lq-telemetry | +-----------+-----------------------------------------------+ | Namespace | urn:ietf:params:xml:ns:yang:ietf-lq-telemetry | +-----------+-----------------------------------------------+ | Prefix | lqt | +-----------+-----------------------------------------------+ | Reference | RFC XXXX | +-----------+-----------------------------------------------+ Table 4 [RFC Editor: please replace RFC XXXX with the RFC number assigned to this document and remove this note.] Transport-specific code points (multicast group addresses and the UDP port) are registered by the UDP transport binding document [I-D.praveen-fann-lq-telemetry-udp]. 12. Security Considerations Pasalapudi & Beeram Expires 21 January 2027 [Page 35] Internet-Draft LQ Telemetry Model July 2026 12.1. Protocol Considerations LQ Telemetry advertisements influence forwarding decisions at receiving nodes. A malicious or malfunctioning sender could cause traffic mis-steering by advertising falsified quality data. The link-local scoping requirements (Section 7.3) using TTL/Hop Limit = 255 with GTSM [RFC5082] validation limit the attack surface to directly connected neighbors. In deployments spanning administrative boundaries, authentication of LQ messages SHOULD be applied; IPsec or a comparable integrity mechanism SHOULD be used by any transport binding in untrusted environments. Wire-level considerations specific to the UDP binding are described in [I-D.praveen-fann-lq-telemetry-udp]. Receivers MUST validate sequence numbers to detect replay, comparing them using serial number arithmetic [RFC1982] with SERIAL_BITS = 16, and MUST enforce the heartbeat-based failure detection described in Section 6.5 to prevent stale data from influencing forwarding. A forged AS Qualifier (node-as or remote-as) could cause a receiver to key a quality entry under the wrong node identity, either masking a real condition or creating a spurious entry. This is a sub-case of the falsified-data threat above and is bounded by the same link-local scoping and authentication measures; it adds no new trust boundary, since the AS Qualifier fields are covered by whatever integrity mechanism protects the rest of the advertisement. Receivers SHOULD treat an AS Qualifier whose value is not consistent with the local fabric's AS plan as an error and discard the record. 12.2. YANG Module Considerations This section is modeled after the template described in Section 3.7.1 of [RFC9907]. The "ietf-lq-telemetry" YANG module defines a data model that is designed to be accessed via YANG-based management protocols, such as NETCONF [RFC6241] and RESTCONF [RFC8040]. These protocols have to use a secure transport layer (e.g., SSH [RFC4252], TLS [RFC8446], and QUIC [RFC9000]) and have to use mutual authentication. The Network Configuration Access Control Model (NACM) [RFC8341] provides the means to restrict access for particular NETCONF or RESTCONF users to a preconfigured subset of all available NETCONF or RESTCONF protocol operations and content. There are a number of data nodes defined in this YANG module that are writable/creatable/deletable (i.e., "config true", which is the default). All writable data nodes are likely to be considered Pasalapudi & Beeram Expires 21 January 2027 [Page 36] Internet-Draft LQ Telemetry Model July 2026 sensitive or vulnerable in some network environments. Write operations (e.g., edit-config) and delete operations to these data nodes without proper protection or authentication can have a negative effect on network operations. These are the subtrees and data nodes and their sensitivity/vulnerability: /lq-telemetry/enabled and /lq-telemetry/role: Disabling telemetry or changing a node's role removes congestion visibility from load- balancer nodes, degrading adaptive routing to static ECMP and potentially masking congestion or failure conditions. /lq-telemetry/notify-interval-ms, /lq-telemetry/change-threshold, and /lq-telemetry/miss-count: Manipulating timers and thresholds can delay congestion signaling, cause spurious neighbor-failure declarations (miss-count too low), or suppress failure detection (miss-count too high), directly mis-steering traffic. /lq-telemetry/as-qualified and /lq-telemetry/local-as: Inconsistent configuration across a fabric causes receivers to ignore or mis- key advertisements, which the heartbeat mechanism then interprets as neighbor failure. Some of the readable data nodes in this YANG module may be considered sensitive or vulnerable in some network environments. It is thus important to control read access (e.g., via get, get-config, or notification) to these data nodes. These are the subtrees and data nodes and their sensitivity/vulnerability: /lq-telemetry/local and /lq-telemetry/neighbors: These subtrees expose the real-time congestion state and topology (Router-IDs, AS Numbers, link identifiers) of the fabric. An attacker with read access can infer traffic patterns and identify the most effective links to target with a congestion-based denial-of-service attack. This module does not define any RPC operations. The "lq-threshold- crossed" notification exposes the same information as the readable subtrees above and is subject to the same access control considerations. 13. References 13.1. Normative References [IEEE754] Institute of Electrical and Electronics Engineers, "IEEE Standard for Floating-Point Arithmetic", IEEE 754-2019, 2019. Pasalapudi & Beeram Expires 21 January 2027 [Page 37] Internet-Draft LQ Telemetry Model July 2026 [RFC1982] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982, DOI 10.17487/RFC1982, August 1996, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, DOI 10.17487/RFC3688, January 2004, . [RFC4252] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) Authentication Protocol", RFC 4252, DOI 10.17487/RFC4252, January 2006, . [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, DOI 10.17487/RFC4271, January 2006, . [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)", RFC 6020, DOI 10.17487/RFC6020, October 2010, . [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., and A. Bierman, Ed., "Network Configuration Protocol (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, . [RFC6286] Chen, E. and J. Yuan, "Autonomous-System-Wide Unique BGP Identifier for BGP-4", RFC 6286, DOI 10.17487/RFC6286, June 2011, . [RFC6793] Vohra, Q. and E. Chen, "BGP Support for Four-Octet Autonomous System (AS) Number Space", RFC 6793, DOI 10.17487/RFC6793, December 2012, . [RFC7607] Kumari, W., Bush, R., Schiller, H., and K. Patel, "Codification of AS 0 Processing", RFC 7607, DOI 10.17487/RFC7607, August 2015, . Pasalapudi & Beeram Expires 21 January 2027 [Page 38] Internet-Draft LQ Telemetry Model July 2026 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", RFC 7950, DOI 10.17487/RFC7950, August 2016, . [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration Access Control Model", STD 91, RFC 8341, DOI 10.17487/RFC8341, March 2018, . [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, . [RFC8791] Bierman, A., Björklund, M., and K. Watsen, "YANG Data Structure Extensions", RFC 8791, DOI 10.17487/RFC8791, June 2020, . [RFC9000] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based Multiplexed and Secure Transport", RFC 9000, DOI 10.17487/RFC9000, May 2021, . [RFC9911] Schönwälder, J., Ed., "Common YANG Data Types", RFC 9911, DOI 10.17487/RFC9911, December 2025, . 13.2. Informative References [I-D.camarillo-rtgwg-lsn] Camarillo, P., Filsfils, C., Chachmon, N., Iny, O., Su, Y., and R. Jiang, "Lightspeed Notification Protocol", Work in Progress, Internet-Draft, draft-camarillo-rtgwg-lsn-00, 2 March 2026, . Pasalapudi & Beeram Expires 21 January 2027 [Page 39] Internet-Draft LQ Telemetry Model July 2026 [I-D.cheng-rtgwg-adaptive-routing-framework] Cheng, W., Lin, C., Wang, K., Ye, J., Zhuang, R., and P. Huo, "Adaptive Routing Framework", Work in Progress, Internet-Draft, draft-cheng-rtgwg-adaptive-routing- framework-05, 7 April 2026, . [I-D.ietf-idr-next-next-hop-nodes] Wang, K., Haas, J., Lin, C., and J. Tantsura, "BGP Next- next Hop Nodes", Work in Progress, Internet-Draft, draft- ietf-idr-next-next-hop-nodes-01, 26 May 2026, . [I-D.ietf-rtgwg-net-notif-ps] Dong, J., McBride, M., Clad, F., Zhang, Z. J., Zhu, Y., Xu, X., Zhuang, R., Pang, R., Lu, H., Liu, Y., Contreras, L. M., Mehmet, D., and R. Rahman, "Fast Network Notifications Problem Statement", Work in Progress, Internet-Draft, draft-ietf-rtgwg-net-notif-ps-02, 7 May 2026, . [I-D.praveen-fann-lq-telemetry-udp] Pasalapudi, S. P. K. and V. P. Beeram, "A UDP Transport Binding for Link Quality Telemetry in CLOS Data Center Fabrics", Work in Progress, Internet-Draft, draft-praveen- fann-lq-telemetry-udp-00, July 2026, . [I-D.song-fann-framework] Song, H., Dong, J., Cheng, W., Zhu, Y., Pang, R., Contreras, L. M., and L. Guo, "A Framework for Fast Network Notifications", Work in Progress, Internet-Draft, draft-song-fann-framework-01, 6 July 2026, . [I-D.xu-idr-fare] Xu, X., Hegde, S., Patel, K., He, Z., Wang, J., Huang, H., Zhang, Q., Wu, H., Liu, Y., Xia, Y., Wang, P., Tiezheng, and R. Glebov, "Fully Adaptive Routing Ethernet using BGP", Work in Progress, Internet-Draft, draft-xu-idr-fare- 06, 19 July 2026, . Pasalapudi & Beeram Expires 21 January 2027 [Page 40] Internet-Draft LQ Telemetry Model July 2026 [RFC5082] Gill, V., Heasley, J., Meyer, D., Savola, P., Ed., and C. Pignataro, "The Generalized TTL Security Mechanism (GTSM)", RFC 5082, DOI 10.17487/RFC5082, October 2007, . [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010, . [RFC7471] Giacalone, S., Ward, D., Drake, J., Atlas, A., and S. Previdi, "OSPF Traffic Engineering (TE) Metric Extensions", RFC 7471, DOI 10.17487/RFC7471, March 2015, . [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, . [RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., and R. Wilton, "Network Management Datastore Architecture (NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018, . [RFC8571] Ginsberg, L., Ed., Previdi, S., Wu, Q., Tantsura, J., and C. Filsfils, "BGP - Link State (BGP-LS) Advertisement of IGP Traffic Engineering Performance Metric Extensions", RFC 8571, DOI 10.17487/RFC8571, March 2019, . [RFC9907] Bierman, A., Boucadair, M., Ed., and Q. Wu, "Guidelines for Authors and Reviewers of Documents Containing YANG Data Models", BCP 216, RFC 9907, DOI 10.17487/RFC9907, March 2026, . [UEC] Ultra Ethernet Consortium, "Ultra Ethernet Specification v1.0", June 2025, . Appendix A. Congestion Detection Pipeline This appendix is a normative part of this specification, stated at SHOULD/RECOMMENDED strength: it describes the RECOMMENDED approach to computing LQS and CL, while the MUST-level conformance floor remains the semantic-range and per-indicator monotonicity requirements of Section 5.2 and Section 5.3. Implementations SHOULD follow this pipeline to ensure comparable LQS and CL values across different vendor implementations within a fabric (see the comparability caveat in Section 5.2). Implementations that deviate from this pipeline MUST still produce LQS and CL values that conform to the requirements Pasalapudi & Beeram Expires 21 January 2027 [Page 41] Internet-Draft LQ Telemetry Model July 2026 of Section 5.2 and Section 5.3. A.1. Hardware Signals Commonly available on modern DC ASICs: * Egress queue depth (cells/octets) * TX byte counter * ECN-marked packet counter * ECN-eligible packet counter * PFC PAUSE frame RX/TX counters (and, where available, a pause- duration register) * Packet drop counter T_sample SHOULD be 2 ms. Implementations MAY use values in the range 1-5 ms. Values below 1 ms may introduce excessive noise; values above 5 ms reduce responsiveness to transient congestion events common in AI/ML workloads. A.2. Derived Metrics Metrics are computed per egress link once per T_sample from deltas of free-running hardware counters. In the definitions below, tx_delta is in octets, T_sample is in seconds, link_speed is the nominal link rate in bits per second, and U, E, F, and D are dimensionless values in the range [0, 1]. * Utilization (U): min(1.0, tx_delta * 8 / (T_sample * link_speed)) * ECN Rate (E): ecn_marked_delta / ecn_eligible_delta; defined as 0 when ecn_eligible_delta is 0 * PFC Pause Fraction (F): min(1.0, pause_duration / T_sample), where pause_duration is the time the egress link was paused during the interval, taken from a hardware pause-duration register where available or otherwise derived from the PFC PAUSE frames received on the egress port by summing their pause quanta (one quantum is the time to transmit 512 bits at the current link speed) * Normalized Queue Depth (D): queue_depth / max_buffer * Drop Indicator (X): 1 if the drop counter advanced during the interval, else 0 Pasalapudi & Beeram Expires 21 January 2027 [Page 42] Internet-Draft LQ Telemetry Model July 2026 A.3. Asymmetric EWMA Smoothing For each metric M: if M_raw > M_smooth: alpha = alpha_rise (RECOMMENDED: 0.5) else: alpha = alpha_fall (RECOMMENDED: 0.1) M_smooth = alpha * M_raw + (1 - alpha) * M_smooth_prev M_smooth is initialized to the first raw sample observed after monitoring of a link begins (equivalently, alpha = 1 for the first sample). The asymmetric EWMA SHOULD use the RECOMMENDED alpha values. alpha_rise = 0.5 enables congestion detection in approximately 4 ms (2 sampling intervals). alpha_fall = 0.1 enables congestion clearing reflection in approximately 50 ms, preventing oscillation during recovery. Implementations MAY adjust alpha values within the following ranges: * alpha_rise: 0.3 to 0.8 (higher = faster congestion detection, more noise sensitivity) * alpha_fall: 0.05 to 0.2 (lower = slower recovery reflection, more stability) A.4. LQS Computation raw = (1.0 - U_smooth) - (D_smooth)^2 - (E_smooth * 0.5) - (F_smooth)^2 * 2.0 if X: raw = raw * 0.1 LQS = floor(clamp(raw, 0.0, 1.0) * 255) Implementations SHOULD use this formula or an equivalent that produces monotonically decreasing LQS as any individual congestion indicator worsens, with the following properties: * Utilization has linear impact (1:1 with available capacity). * Queue depth has quadratic impact (increasing urgency as buffers fill). Pasalapudi & Beeram Expires 21 January 2027 [Page 43] Internet-Draft LQ Telemetry Model July 2026 * ECN marking has moderate linear impact (weighted at 0.5). * PFC pause has strong quadratic impact (weighted at 2.0, reflecting the severity of flow control backpressure). * Active drops immediately suppress LQS to near-zero (multiplication by 0.1, bounding LQS at 25 while drops persist). The response of this formula is deliberately steep: sustained utilization above roughly 90%, or a near-full buffer, drives LQS into the lowest semantic bands even before drops occur, reflecting the rapid onset and high cost of congestion in synchronized AI/ML collective traffic. The middle semantic bands of Section 5.2 consequently correspond to moderate smoothed metric values (see the worked example in Appendix B). A.5. CL Mapping Implementations SHOULD use the following mapping from smoothed metrics to CL values. The mapping is evaluated top-to-bottom; the first matching condition determines the CL. 7 (CRITICAL): X == 1 (drops active) 6 (SEVERE): F_smooth > 0.50 (heavy PFC) 5 (HIGH): F_smooth > 0.10 (PFC active) 4 (ELEVATED): E_smooth > 0.50 (heavy ECN) 3 (MODERATE): E_smooth > 0.10 (ECN active) 2 (LOW): D_smooth > 0.50 (queue building) 1 (MINIMAL): U_smooth > 0.80 (high utilization) 0 (NONE): all clear The thresholds above are RECOMMENDED. Implementations MAY adjust thresholds to match their specific hardware characteristics and deployment requirements, provided the monotonicity requirement is maintained (higher CL values always indicate worse conditions than lower CL values). A.6. Hysteresis State Machine Four states: HEALTHY, DEGRADED, CONGESTED, CRITICAL. Upward transitions (toward CRITICAL): immediate upon condition being met. Downward transitions (toward HEALTHY): require sustained improvement for T_hold_down (RECOMMENDED: 100 ms) before transitioning. Pasalapudi & Beeram Expires 21 January 2027 [Page 44] Internet-Draft LQ Telemetry Model July 2026 Implementations SHOULD implement this hysteresis to prevent rapid oscillation between states. T_hold_down SHOULD be in the range 50-200 ms. Appendix B. Worked Example Topology: 4 leaves (L1-L4), 4 spines (S1-S4), 400G links. B.1. Steady State S1 advertises (any binding): LQS = 235-240 for all links. L1 computes ~25% weight per spine for destination L4. B.2. Congestion (T=100ms) S2-to-L4 experiences sustained congestion. After asymmetric EWMA smoothing (Appendix A), the metrics are U_smooth = 0.55, D_smooth = 0.30, E_smooth = 0.15 (no PFC, no drops). Pipeline: raw = (1 - 0.55) - 0.30^2 - 0.15 * 0.5 = 0.285; LQS = floor(0.285 * 255) = 72. CL = 3 (E_smooth > 0.10 and <= 0.50). The delta from the last advertised LQS (~237) far exceeds CHANGE_THRESHOLD (25), so a triggered advertisement is sent. B.3. Rerouting (T=104ms) Assuming path_quality (the min of local DLB quality and remote LQS) is 237 for S1, S3, and S4 and 72 for S2, L1's target weights are S1 = S3 = S4 = 30.27% and S2 = 9.20%. With the RECOMMENDED damping gain g = 0.5 and T_reweight = 20 ms (Section 6.4), S2's applied weight moves from 25% to 17.1% at T=104ms and then, over successive reweighting steps, to 13.2%, 11.2%, and 10.2% at T=164ms, at which point the residual (1.0 point) is 6.25% of the initial 15.8-point shift -- within the 10%-of-initial-shift convergence bound of Section 6.4. The applied weight reaches 9.7% by T=184ms. B.4. Recovery (T=500ms) Slow EWMA decay + hold-down. S2 LQS returns to 228. L1 returns to equal weights over damped reweighting steps. Appendix C. YANG Tree Diagram The following tree diagram [RFC8340] shows the structure of the ietf- lq-telemetry YANG module, including the lq-advertisement structure [RFC8791]. The diagram was produced with "pyang -f tree --tree- print-structures". Pasalapudi & Beeram Expires 21 January 2027 [Page 45] Internet-Draft LQ Telemetry Model July 2026 module: ietf-lq-telemetry +--rw lq-telemetry +--rw enabled? boolean +--rw role? enumeration +--rw active-transports* identityref +--rw as-qualified? boolean +--rw local-as? inet:as-number +--rw pfc-fabric? boolean +--rw notify-interval-ms? uint16 +--rw change-threshold? uint8 +--rw miss-count? uint8 +--rw diagnostics-enabled? boolean {diagnostics}? +--ro local | +--ro last-sequence-number? uint16 | +--ro link-quality* [remote-as remote-node-id link-id] | +--ro remote-as as-qualifier | +--ro remote-node-id node-identifier | +--ro link-id uint32 | +--ro available-bandwidth bandwidth-gbps | +--ro lqs link-quality-score | +--ro cl congestion-level | +--ro diagnostics! {diagnostics}? | +--ro link-capacity? bandwidth-gbps | +--ro queue-depth? uint8 | +--ro ecn-marking-rate? uint8 | +--ro pfc-pause-fraction? uint8 | +--ro drops-active? boolean +--ro neighbors +--ro neighbor* [node-as node-id] +--ro node-as as-qualifier +--ro node-id node-identifier +--ro last-seen? yang:date-and-time +--ro last-sequence? uint16 +--ro transport? identityref +--ro state? enumeration +--ro link-quality* [remote-as remote-node-id link-id] +--ro remote-as as-qualifier +--ro remote-node-id node-identifier +--ro link-id uint32 +--ro available-bandwidth bandwidth-gbps +--ro lqs link-quality-score +--ro cl congestion-level +--ro diagnostics! {diagnostics}? +--ro link-capacity? bandwidth-gbps +--ro queue-depth? uint8 +--ro ecn-marking-rate? uint8 +--ro pfc-pause-fraction? uint8 +--ro drops-active? boolean Pasalapudi & Beeram Expires 21 January 2027 [Page 46] Internet-Draft LQ Telemetry Model July 2026 notifications: +---n lq-threshold-crossed +--ro node-id node-identifier +--ro node-as? as-qualifier +--ro remote-as? as-qualifier +--ro remote-node-id node-identifier +--ro link-id uint32 +--ro old-cl congestion-level +--ro new-cl congestion-level +--ro lqs? link-quality-score structure lq-advertisement: +-- node-id node-identifier +-- node-as? as-qualifier +-- sequence-number uint16 +-- timestamp-ms? yang:milliseconds32 +-- pfc-fabric? boolean +-- signaling-mode? enumeration +-- link-quality* [remote-as remote-node-id link-id] +-- remote-as as-qualifier +-- remote-node-id node-identifier +-- link-id uint32 +-- available-bandwidth bandwidth-gbps +-- lqs link-quality-score +-- cl congestion-level +-- diagnostics! {diagnostics}? +-- link-capacity? bandwidth-gbps +-- queue-depth? uint8 +-- ecn-marking-rate? uint8 +-- pfc-pause-fraction? uint8 +-- drops-active? boolean Acknowledgments The authors thank the IETF RTGWG and FANN communities for discussion of the adaptive routing problem space that motivated this work. Contributors Kaliraj Vairavakkalai Hewlett Packard Enterprise Email: kaliraj.vairavakkalai@hpe.com Swamy SRK Hewlett Packard Enterprise Email: swamy.sadashivaiah-renu-kananda@hpe.com Pasalapudi & Beeram Expires 21 January 2027 [Page 47] Internet-Draft LQ Telemetry Model July 2026 Authors' Addresses S. Praveen K. Pasalapudi Hewlett Packard Enterprise Email: praveenp@hpe.com Vishnu Pavan Beeram Hewlett Packard Enterprise Email: vishnu-pavan-kumar.beeram@hpe.com Pasalapudi & Beeram Expires 21 January 2027 [Page 48]