Per-Entry Soft-State Refresh Horizon and Paced Fragmentation Scheduling for Fast Network Notification (FANN) Telemetry
draft-li-fann-soft-state-refresh-yang-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 | Zhiqiang Li , Zongpeng Du , Junjie Wang , Wei Cheng , Ying Zhao , Chunhao Zhao , Xun Sun | ||
| Last updated | 2026-11-02 | ||
| 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-li-fann-soft-state-refresh-yang-00
Fast Network Notifications Z. Li
Internet-Draft Z. Du
Intended status: Standards Track China Mobile
Expires: 3 May 2027 J. Wang
W. Cheng
Y. Zhao
Centec
C. Zhao
SAIA
X. Sun
Inesa
30 October 2026
Per-Entry Soft-State Refresh Horizon and Paced Fragmentation Scheduling
for Fast Network Notification (FANN) Telemetry
draft-li-fann-soft-state-refresh-yang-00
Abstract
This document specifies a Standards Track per-entry soft-state
refresh horizon profile, a bounded multi-packet fragmentation
scheduling invariant, and a YANG 1.1 data model (ietf-fann-soft-
state-refresh) for Fast Network Notification (FANN) link-quality
telemetry. To prevent unrefreshed link entries from persisting
indefinitely when partial event-triggered updates share a transport
channel with periodic full sweeps, each receiver maintains an
independent monotonic receipt horizon per six-tuple link-record key.
Furthermore, when a full periodic sweep spans F fragmented datagrams
paced at inter-packet interval T_spacing, the refresh period
T_refresh and expiration horizon T_expire satisfy T_refresh <=
T_expire - M - (F - 1) * T_spacing.MUST NOT reset the full-sweep
periodic timer for omitted records. The refresh bound explicitly
accounts for multi-packet fragmentation emission duration (T_refresh
<= T_expire - M - (F - 1) * T_spacing).
Discussion and Scope
This is an individual Standards Track proposal prepared for review.
It has not been adopted by a working group, and no independent
implementation or interoperability result is claimed. The proposed
scope and sponsoring venue require community discussion.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Li, et al. Expires 3 May 2027 [Page 1]
Internet-Draft FANN Soft-State Refresh Horizon October 2026
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 3 May 2027.
Copyright Notice
Copyright (c) 2026 IETF Trust and the persons identified as the
document authors. All rights reserved.
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. Requirements Language . . . . . . . . . . . . . . . . . . 3
1.2. Scope of the Guarantee . . . . . . . . . . . . . . . . . 3
2. Record Identity and Local State . . . . . . . . . . . . . . . 4
3. Configuration and Deployment Agreement . . . . . . . . . . . 4
4. Sender Procedure . . . . . . . . . . . . . . . . . . . . . . 5
5. Receiver Procedure . . . . . . . . . . . . . . . . . . . . . 6
6. Router-Info Carriage . . . . . . . . . . . . . . . . . . . . 8
7. Worked Trace and Interoperability Cases . . . . . . . . . . . 8
8. YANG Data Model Augmentation for FANN Per-Record Aging . . . 9
9. Security and Operational Considerations . . . . . . . . . . . 11
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
11. Implementation Status and Integration Plan . . . . . . . . . 12
12. Normative References . . . . . . . . . . . . . . . . . . . . 13
13. Informative References . . . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14
Li, et al. Expires 3 May 2027 [Page 2]
Internet-Draft FANN Soft-State Refresh Horizon October 2026
1. Introduction
Link-quality advertisements can contain several records and can be
split across packets. A receiver that refreshes every record when
any packet from a helper arrives can retain an omitted record
indefinitely. This document specifies a per-record receipt-aging
profile for the Link Quality Telemetry model [LQ-INFO] and its UDP
binding [LQ-UDP]. It also specifies that partial triggered
advertisements must not postpone the sender's periodic coverage of
other records.
The profile is a focused proposed amendment to those individual
drafts. It does not define a new notification packet, metric,
transport, congestion-control algorithm, or forwarding policy.
[ROUTER-INFO] already discusses per-neighbor and per-link refresh and
aging. The contribution here is to make the aging unit, sender
scheduling, and composition with nested LQ records explicit. The
preferred progression is joint integration into the base documents,
not parallel standardization of the same mechanism.
The failure scenario follows from partial refresh and loss semantics;
it is not presented as a measured production incident. The FANN
problem statement [FANN-PROBLEM] establishes the wider notification
problem, but does not constitute working-group adoption of this
particular profile. The current framework [FANN-FRAMEWORK] remains
work in progress.
1.1. 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.
1.2. Scope of the Guarantee
The normative bound is the maximum local time for which a record can
influence a consumer without another accepted update explicitly
carrying that record. It is a bound on receipt recency. It is not a
bound on the age of the underlying physical measurement, on network
delivery delay, or on successful recovery after loss. UDP can lose
an unbounded number of successive advertisements.
Li, et al. Expires 3 May 2027 [Page 3]
Internet-Draft FANN Soft-State Refresh Horizon October 2026
No timestamp synchronization or sender boot epoch is added to the
wire format. Deployments requiring a bound on measurement age or
cryptographic freshness need additional mechanisms in the underlying
binding. A delayed but accepted packet can renew receipt recency
while containing an old observation; this profile MUST NOT be
advertised as preventing that case.
2. Record Identity and Local State
For the native LQ model the receiver keys a record by the tuple
(administrative receive scope, sender AS qualifier, sender node ID,
remote AS qualifier, remote node ID, link ID). Zero AS qualifiers
retain the unqualified semantics of [LQ-INFO]; the administrative
receive scope MUST keep otherwise ambiguous identifiers separate.
Interface indices or node IDs from unrelated scopes MUST NOT alias
the same state entry.
Each admitted record stores its value, monotonic accepted-receipt
time, expiry deadline, and validity state. Validity is absent,
fresh, or stale. Stale means that this profile no longer permits use
of the retained quality observation. It does not by itself mean that
the physical link is down, healthy, or has zero capacity.
Sender heartbeat state and per-record validity are separate. An
accepted packet for record B can establish that the sender is
responsive while record A expires. A heartbeat failure can
invalidate all records from that sender according to the base
mechanism, but heartbeat success MUST NOT refresh an omitted record.
Topology validity remains an independent condition.
3. Configuration and Deployment Agreement
The operator configures an upper bound R on the interval between
completed emissions that explicitly refresh each advertised record.
R is expressed in integer milliseconds and MUST be positive. The
receiver uses a positive integer miss multiplier M and computes L = M
* R using checked arithmetic. L is the local receipt lifetime. An
implementation MUST reject a configuration whose product is not
representable in its timer system or whose scheduling precision
cannot enforce it.
R is a per-record coverage budget, not necessarily the nominal packet
timer. If the periodic scheduler has a maximum gap of ceil(1.1 * T)
and a full emission cycle takes at most E milliseconds, a
conservative choice is R = ceil(1.1 * T) + E. E includes
serialization, batching, and scheduler delays for the entire
advertised record set. An implementation MUST NOT set E to zero
merely because each individual packet is small.
Li, et al. Expires 3 May 2027 [Page 4]
Internet-Draft FANN Soft-State Refresh Horizon October 2026
The sender and receiver MUST be provisioned consistently for this
profile. There is no in-band negotiation in this version. Enabling
only the receiver provides conservative expiry but does not ensure
that the sender refreshes records frequently enough; enabling only
the sender does not correct receiver aging. A mixed deployment
requires explicit operational compatibility assessment. The packet
format is unchanged, but the profile intentionally changes behavior
relative to the timer-reset rule in [LQ-INFO] and [LQ-UDP].
When L is reduced, existing deadlines MUST be shortened to no later
than accepted-receipt-time + new-L. Increasing L MUST NOT extend an
existing record's deadline; the longer value applies after a new
accepted explicit update. Changes of administrative scope, sender
identity mapping, or topology mapping MUST invalidate affected
entries until valid updates are admitted under the new mapping.
4. Sender Procedure
While a record is advertised as current, the sender MUST schedule
explicit refreshes so that the interval between completed emissions
for that record does not exceed R under the declared operating
envelope. Periodic coverage includes unchanged records. Triggered
advertisements can contain a subset, but MUST NOT reset or postpone
the periodic coverage deadlines of omitted records.
Splitting a full refresh across packets does not make the packet
group atomic. The sender follows the base binding's sequence-number
rules and advances the packet sequence as required. Every packet
contains self-contained records. The sender MUST budget for the
entire group when claiming R and MUST account for the maximum record
count and link serialization rate.
The sender MUST NOT present a stale local measurement as newly
sampled merely by periodically transmitting it. Existing
measurement-validity procedures remain applicable. This profile does
not add an observation-age field, so a receiver cannot derive such
age solely from successful refreshes. If local sampling is
unavailable, the sender MUST stop refreshing the affected
observation, or use an unavailable indication only if the selected
base binding explicitly defines one. It MUST NOT manufacture a
healthy score. Stopping refresh permits the receiver's deadline to
expire; it does not signal an immediate physical link failure.
Li, et al. Expires 3 May 2027 [Page 5]
Internet-Draft FANN Soft-State Refresh Horizon October 2026
If overload prevents compliance with R, the sender SHOULD expose a
local alarm and reduce the advertised set or renegotiate
configuration through management. It MUST NOT silently advertise
that the guarantee still holds. The receiver still expires entries
according to L; thus overload can reduce usable telemetry without
extending stale use.
When a link-quality record first becomes eligible for periodic
advertisement, its first completed explicit emission MUST occur no
later than R after that eligibility event under the declared
operating envelope. Initial coverage and subsequent periodic sweeps
share the same per-record refresh bound. An event-triggered emission
satisfies the refreshed record's own deadline but MUST NOT postpone
the emission deadline of any omitted link record.
5. Receiver Procedure
The receiver MUST validate packet framing, source and scope checks,
configured security protections, and the base sequence rule before
any timer renewal. A rejected, duplicate, or stale packet renews
neither a record timer nor a sender heartbeat in this profile.
Serial comparisons use the bit width and procedures of the base
binding and [RFC1982]; the exactly-half-range case is not a newer
value.
This profile retains the base per-sender packet ordering. For
example, if packet 102 containing B arrives before packet 101
containing A, the base rule can reject packet 101. The receiver MUST
NOT treat receipt of B as recovery of A. A subsequently accepted
explicit refresh can restore A. This profile does not change to per-
record serial numbers or claim to repair all reordering losses.
For an otherwise admissible packet, the receiver validates every
record and rejects the packet if it contains duplicate composite keys
or structurally invalid records. No timer is partially updated
before this validation completes. Optional fields continue to follow
the base binding's rules. An unsupported record type MUST NOT be
interpreted as a refresh of a previously known type.
For every valid, admitted record K explicitly present, the receiver
applies the following operation. The time is the local monotonic
time at successful admission, not an untrusted sender timestamp.
Li, et al. Expires 3 May 2027 [Page 6]
Internet-Draft FANN Soft-State Refresh Horizon October 2026
on_admit(K, value, now):
state[K].value = value
state[K].last = now
state[K].deadline = checked_add(now, L)
state[K].validity = fresh
usable(K, now):
return (state[K].validity == fresh
and now < state[K].deadline
and topology_allows(K)
and parent_carriage_allows(K))
At now equal to the deadline, the record is not usable. Periodic
cleanup may run later, but the forwarding consumer MUST test the
deadline or an equivalent hardware validity mechanism before using
the observation. A timer implementation with bounded error must
conservatively account for that error; delayed housekeeping MUST NOT
create extra usable lifetime.
Entries absent from the packet are unchanged. Their deadlines MUST
NOT be extended. Expiry marks an entry stale and prevents its
quality value from affecting forwarding. The consumer then uses its
configured base-protocol fallback, such as topology-only forwarding,
withdrawing the affected optimization, or another independently
validated source. This document does not mandate a new fallback that
contradicts the base protocol's eligibility rule.
Receiver restart or loss of validity state makes all affected
observations unusable until renewed. Reset of a sender's sequence
state follows the base binding's recovery rule and its security
limitations. A heartbeat timeout is not proof of a fresh
authenticated incarnation. Deployments that cannot exclude delayed
or replayed traffic across that reset MUST NOT claim measurement
freshness from this profile. Adding a boot epoch would require a
separate wire-format agreement.
Any installed path weight or derived forwarding state that depends on
a link-quality record MUST NOT remain eligible for traffic steering
beyond the earliest applicable input record expiry, topology
invalidation, or enclosing node-record expiry. An implementation
MUST either propagate that conservative expiration timestamp into the
derived forwarding table entry or atomically invalidate the derived
entry at the exact expiry boundary, even if background telemetry
table garbage collection has not yet executed.
Li, et al. Expires 3 May 2027 [Page 7]
Internet-Draft FANN Soft-State Refresh Horizon October 2026
6. Router-Info Carriage
When LQ records are carried inside Router-Info, the validity checks
compose. A record is usable only while its own LQ deadline, the
applicable enclosing Router-Info record lifetime, and topology
conditions all permit it. Expiry of the enclosing information
invalidates its dependent observations. Receipt of an unrelated
Router-Info TLV, a different neighbor, or another nested link record
MUST NOT extend an LQ record's lifetime.
The base Router-Info refresh-rate rules remain applicable to their
own record types, including the treatment of one-time notifications.
This profile MUST NOT create an indefinite lifetime for periodic LQ
records by selecting a zero refresh value. A deployment with no
finite agreed LQ coverage bound cannot enable this profile for those
records.
Because [ROUTER-INFO] already has per-record aging, the normative
work needed there may be only a clarification of composition with the
nested LQ TLV. A new parallel timer or packet type is not required
when existing implementation state can express the same deadlines.
7. Worked Trace and Interoperability Cases
Assume T = 20 ms, maximum jittered gap 22 ms, E = 1 ms, R = 23 ms,
and M = 3. Then L = 69 ms. At t = 0, A and B are admitted. Updates
containing only B are admitted at t = 20 and t = 40. At t = 69, A is
unusable even though the sender heartbeat remains healthy. B's
deadline is t = 109. A is usable again only after an explicit
accepted update, for example at t = 75, establishing a new deadline
at t = 144.
This trace is an arithmetic example, not a measured hardware result.
Loss of every packet carrying A can keep A stale indefinitely. A
full sender refresh schedule creates transmission opportunities; it
cannot promise successful delivery in R milliseconds.
An interoperability suite MUST cover omitted records, duplicate
packets, duplicate keys, packet reordering, exact deadline
boundaries, sequence wrap and half-range ambiguity, sender restart,
changed scope, reduced and increased lifetime configuration, nested
outer expiry, receiver resource exhaustion, and sustained loss.
Expected outcomes should be compared at the usability interface, not
only by inspecting whether entries remain allocated.
Li, et al. Expires 3 May 2027 [Page 8]
Internet-Draft FANN Soft-State Refresh Horizon October 2026
Interoperability verification MUST additionally test the initial-
emission deadline bound R and verify that derived forwarding weights
cease influencing packet selection at the exact nanosecond a
constituent link record expires, prior to asynchronous background
record purge.
8. YANG Data Model Augmentation for FANN Per-Record Aging
To ensure interoperable configuration and operational monitoring of
the per-record receipt-aging profile across Fast Network Notification
(FANN) senders and receivers, this section defines the YANG 1.1
[RFC7950] module ietf-fann-soft-state-refresh, which augments the
Link Quality Telemetry model [LQ-INFO], uses the common data types of
[RFC9911], and conforms to NMDA [RFC8342] and the YANG module
guidance in [RFC9907].
<CODE BEGINS> file "ietf-fann-soft-state-refresh@2026-10-30.yang"
module ietf-fann-soft-state-refresh {
yang-version 1.1;
namespace
"urn:ietf:params:xml:ns:yang:ietf-fann-soft-state-refresh";
prefix fann-ssr;
import ietf-yang-types {
prefix yang;
reference
"RFC 9911: Common YANG Data Types";
}
organization
"IETF Fast Network Notifications (FANN) Working Group";
contact
"WG Web: <https://datatracker.ietf.org/wg/fann/>
WG List: <mailto:fann@ietf.org>
Author: Zhiqiang Li
<mailto:lizhiqiangyjy@chinamobile.com>";
description
"This module defines configuration and operational state
parameters for per-record receipt aging and bounded refresh
scheduling in Fast Network Notification (FANN) Link-Quality
Telemetry.
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
Li, et al. Expires 3 May 2027 [Page 9]
Internet-Draft FANN Soft-State Refresh Horizon October 2026
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; see the
RFC itself for full legal notices.";
revision 2026-10-30 {
description
"Initial version specifying per-record receipt aging
parameters including multi-packet fragmentation emission
margin (E).";
reference
"RFC XXXX: Per-Record Receipt Aging and Bounded Refresh
Scheduling for Fast Network Notification (FANN)
Link-Quality Telemetry";
}
container fann-soft-state-refresh {
description
"Per-record receipt aging configuration and operational
telemetry.";
leaf record-expire-ms {
type uint32 {
range "1..3600000";
}
units "milliseconds";
default "1000";
description
"Receiver per-record expiration interval (T_expire).";
}
leaf safety-margin-ms {
type uint32;
units "milliseconds";
default "200";
description
"Configured transit, jitter, and loss safety margin (M).";
}
leaf fragment-spacing-ms {
type uint32;
units "milliseconds";
default "10";
description
"Maximum inter-fragment emission spacing (T_spacing).";
}
leaf max-fragments-per-sweep {
type uint16 {
range "1..1024";
Li, et al. Expires 3 May 2027 [Page 10]
Internet-Draft FANN Soft-State Refresh Horizon October 2026
}
default "1";
description
"Maximum fragments (F) required to emit a full link-record
sweep.";
}
leaf refresh-interval-ms {
type uint32 {
range "1..3600000";
}
units "milliseconds";
must ". + ../safety-margin-ms + "
+ "((../max-fragments-per-sweep - 1) * "
+ "../fragment-spacing-ms) <= ../record-expire-ms" {
error-message
"T_refresh + M + (F - 1) * T_spacing MUST NOT exceed "
+ "T_expire.";
}
default "500";
description
"Bounded full-sweep refresh interval (T_refresh).";
}
leaf expired-record-purges {
type yang:counter64;
config false;
description
"Total number of link-quality records transitioned to
Expired because T_now - T_rx_last >= T_expire.";
}
}
}
<CODE ENDS>
9. Security and Operational Considerations
Per-record deadlines prevent unrelated accepted traffic from
extending a record's local receipt lifetime. They do not
authenticate telemetry. Source-address checks and a hop-limit check
restrict scope but are not cryptographic authentication. The
deployment MUST apply the base binding's security requirements and
assess whether its link protection and operational trust suffice for
the proposed use.
Li, et al. Expires 3 May 2027 [Page 11]
Internet-Draft FANN Soft-State Refresh Horizon October 2026
An on-link attacker able to inject accepted packets can create
misleading records or advance serial state. Per-record aging does
not solve that attack. Integrity protection, authorization of sender
identities and scope, and protection against replay are required
where that threat is in scope. This document adds no authentication
field and MUST NOT claim to provide such protection by itself.
Receivers MUST bound admitted senders and records. A record that
cannot be stored MUST NOT be represented as fresh. Resource eviction
invalidates the affected observation; it MUST NOT transfer its
deadline to another key. Operators SHOULD monitor per-record expiry,
heartbeat failure, sequence rejection, capacity rejection, and
coverage-budget violations separately.
Frequent expiry can cause forwarding changes, so implementations need
a stable fallback and appropriate policy damping. Any adaptation
must respect the data transport's ordering assumptions; this profile
does not authorize arbitrary packet spraying for RoCE traffic.
Hardware timer capacity and update rate must be measured under the
maximum advertised record set.
10. IANA Considerations
This document requests no IANA allocation. It changes no codepoint,
YANG namespace, packet header, or registry. Its intended progression
is integration of the specified behavior into the relevant base
documents, subject to their editors and the FANN working group. It
does not claim to update an existing RFC.
11. Implementation Status and Integration Plan
No conforming hardware implementation or independent interoperability
result is claimed. The FANN charter [FANN-CHARTER] includes
hardware-forwarding and interoperability requirements before protocol
publication. Model-level trace checks cannot satisfy those
requirements.
The proposed integration points are the per-entry last-seen and
heartbeat procedures in Sections 6.2 and 6.5 of [LQ-INFO], its
transmission procedure in Section 7.2, and the triggered/periodic
interaction in Section 4.5 of [LQ-UDP]. Router-Info composition
should be reviewed with its per-neighbor/link aging text and the LQ
carriage rules. The exact section numbers are tied to the cited -00
revisions.
Before adoption, the base editors should confirm whether current
senders can omit unchanged records, whether complete periodic
coverage is already intended, how reset and replay are handled, and
Li, et al. Expires 3 May 2027 [Page 12]
Internet-Draft FANN Soft-State Refresh Horizon October 2026
whether the receiver's existing per-entry timestamp is already used
for expiry. If an updated base draft specifies equivalent behavior,
this proposal should be merged or retired instead of remaining a
duplicate document.
12. Normative References
[RFC1982] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982,
DOI 10.17487/RFC1982, August 1996,
<https://www.rfc-editor.org/info/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/info/rfc2119>.
[RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language",
RFC 7950, DOI 10.17487/RFC7950, August 2016,
<https://www.rfc-editor.org/info/rfc7950>.
[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/info/rfc8174>.
[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/info/rfc8342>.
[RFC9911] Schönwälder, J., Ed., "Common YANG Data Types", RFC 9911,
DOI 10.17487/RFC9911, December 2025,
<https://www.rfc-editor.org/info/rfc9911>.
13. Informative References
[FANN-CHARTER]
IETF, "Fast Network Notifications Working Group Charter",
Snapshot accessed 28 October 2026; not an implementation
of this proposal, October 2026,
<https://datatracker.ietf.org/wg/fann/about/>.
[FANN-FRAMEWORK]
Song, H., Dong, J., Ali, Z., 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-03, 26 October 2026,
<https://datatracker.ietf.org/doc/html/draft-song-fann-
framework-03>.
Li, et al. Expires 3 May 2027 [Page 13]
Internet-Draft FANN Soft-State Refresh Horizon October 2026
[FANN-PROBLEM]
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-fann-problem-statement-01, 26
October 2026, <https://datatracker.ietf.org/doc/html/
draft-ietf-fann-problem-statement-01>.
[LQ-INFO] Pasalapudi, S. P. K. and V. P. Beeram, "A YANG Data Model
for Link Quality Telemetry in CLOS Data Center Fabrics",
Work in Progress, Internet-Draft, draft-praveen-fann-lq-
telemetry-info-00, 21 July 2026,
<https://datatracker.ietf.org/doc/html/draft-praveen-fann-
lq-telemetry-info-00>.
[LQ-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, 21 July 2026,
<https://datatracker.ietf.org/doc/html/draft-praveen-fann-
lq-telemetry-udp-00>.
[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/info/rfc9907>.
[ROUTER-INFO]
Zhang, Z. J., Wang, K., Lin, C., Vaidya, N., Tantsura, J.,
and Y. Liu, "Advertising Router Information", Work in
Progress, Internet-Draft, draft-zzhang-fann-router-info-
00, 6 July 2026, <https://datatracker.ietf.org/doc/html/
draft-zzhang-fann-router-info-00>.
Authors' Addresses
Zhiqiang Li
China Mobile
Beijing
China
Email: lizhiqiangyjy@chinamobile.com
Zongpeng Du
China Mobile
Beijing
China
Li, et al. Expires 3 May 2027 [Page 14]
Internet-Draft FANN Soft-State Refresh Horizon October 2026
Email: duzongpeng@chinamobile.com
Junjie Wang
Centec
Shanghai
China
Email: wangjj@centec.com
Wei Cheng
Centec
Shanghai
China
Email: chengw@centec.com
Ying Zhao
Centec
Shanghai
China
Email: zhaoying@centec.com
Chunhao Zhao
SAIA
Shanghai
China
Email: chunhao.zhao@sh-aia.com
Xun Sun
Inesa
Shanghai
China
Email: sunxun@inesa.com
Li, et al. Expires 3 May 2027 [Page 15]