A YANG Data Model for Link Quality Telemetry in CLOS Data Center Fabrics
draft-praveen-fann-lq-telemetry-info-00
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Authors | S. Praveen K. Pasalapudi , Vishnu Pavan Beeram | ||
| Last updated | 2026-07-21 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Yang Validation | 0 errors, 0 warnings | ||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-praveen-fann-lq-telemetry-info-00
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
<CODE BEGINS> 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: <https://datatracker.ietf.org/wg/fann/>
WG List: <mailto:fann@ietf.org>
Author: S. Praveen K. Pasalapudi
<mailto:praveenp@hpe.com>
Author: Vishnu Pavan Beeram
<mailto:vishnu-pavan-kumar.beeram@hpe.com>";
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.";
}
}
}
<CODE ENDS>
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,
<https://www.rfc-editor.org/rfc/rfc1982>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/rfc/rfc2119>.
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
DOI 10.17487/RFC3688, January 2004,
<https://www.rfc-editor.org/rfc/rfc3688>.
[RFC4252] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH)
Authentication Protocol", RFC 4252, DOI 10.17487/RFC4252,
January 2006, <https://www.rfc-editor.org/rfc/rfc4252>.
[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,
<https://www.rfc-editor.org/rfc/rfc4271>.
[RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for
the Network Configuration Protocol (NETCONF)", RFC 6020,
DOI 10.17487/RFC6020, October 2010,
<https://www.rfc-editor.org/rfc/rfc6020>.
[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,
<https://www.rfc-editor.org/rfc/rfc6241>.
[RFC6286] Chen, E. and J. Yuan, "Autonomous-System-Wide Unique BGP
Identifier for BGP-4", RFC 6286, DOI 10.17487/RFC6286,
June 2011, <https://www.rfc-editor.org/rfc/rfc6286>.
[RFC6793] Vohra, Q. and E. Chen, "BGP Support for Four-Octet
Autonomous System (AS) Number Space", RFC 6793,
DOI 10.17487/RFC6793, December 2012,
<https://www.rfc-editor.org/rfc/rfc6793>.
[RFC7607] Kumari, W., Bush, R., Schiller, H., and K. Patel,
"Codification of AS 0 Processing", RFC 7607,
DOI 10.17487/RFC7607, August 2015,
<https://www.rfc-editor.org/rfc/rfc7607>.
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,
<https://www.rfc-editor.org/rfc/rfc7950>.
[RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017,
<https://www.rfc-editor.org/rfc/rfc8040>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.
[RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration
Access Control Model", STD 91, RFC 8341,
DOI 10.17487/RFC8341, March 2018,
<https://www.rfc-editor.org/rfc/rfc8341>.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/rfc/rfc8446>.
[RFC8791] Bierman, A., Björklund, M., and K. Watsen, "YANG Data
Structure Extensions", RFC 8791, DOI 10.17487/RFC8791,
June 2020, <https://www.rfc-editor.org/rfc/rfc8791>.
[RFC9000] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based
Multiplexed and Secure Transport", RFC 9000,
DOI 10.17487/RFC9000, May 2021,
<https://www.rfc-editor.org/rfc/rfc9000>.
[RFC9911] Schönwälder, J., Ed., "Common YANG Data Types", RFC 9911,
DOI 10.17487/RFC9911, December 2025,
<https://www.rfc-editor.org/rfc/rfc9911>.
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, <https://datatracker.ietf.org/doc/html/
draft-camarillo-rtgwg-lsn-00>.
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,
<https://datatracker.ietf.org/doc/html/draft-cheng-rtgwg-
adaptive-routing-framework-05>.
[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,
<https://datatracker.ietf.org/doc/html/draft-ietf-idr-
next-next-hop-nodes-01>.
[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, <https://datatracker.ietf.org/doc/html/draft-ietf-
rtgwg-net-notif-ps-02>.
[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,
<https://datatracker.ietf.org/doc/html/draft-praveen-fann-
lq-telemetry-udp-00>.
[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,
<https://datatracker.ietf.org/doc/html/draft-song-fann-
framework-01>.
[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, <https://datatracker.ietf.org/doc/html/
draft-xu-idr-fare-06>.
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,
<https://www.rfc-editor.org/rfc/rfc5082>.
[RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection
(BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010,
<https://www.rfc-editor.org/rfc/rfc5880>.
[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,
<https://www.rfc-editor.org/rfc/rfc7471>.
[RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams",
BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018,
<https://www.rfc-editor.org/rfc/rfc8340>.
[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,
<https://www.rfc-editor.org/rfc/rfc8342>.
[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,
<https://www.rfc-editor.org/rfc/rfc8571>.
[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, <https://www.rfc-editor.org/rfc/rfc9907>.
[UEC] Ultra Ethernet Consortium, "Ultra Ethernet Specification
v1.0", June 2025, <https://ultraethernet.org/>.
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]