CATS R. Pang, Ed.
Internet-Draft M. Han, Ed.
Intended status: Standards Track China Unicom
Expires: 7 January 2027 T. Huang, Ed.
CNIC CAS
N. Zhang, Ed.
China Unicom
6 July 2026
CATS Fallback Decision Framework
draft-pang-cats-fallback-decision-framework-00
Abstract
This document describes the framework and considerations for fallback
decision-making in Computing-Aware Traffic Steering (CATS). While
existing OAM frameworks provide multi-dimensional telemetry
collection capabilities, how the CATS Path Selector (C-PS) should
react to partial or transient failures remains an open issue. This
document highlights the problems of misjudgment due to correlated
failures, steering flapping, and non-deterministic fallback
behaviors. It outlines the high-level considerations for logical
decoupling of status dimensions and stable state transition
mechanisms to ensure carrier-grade reliability. Specific protocol
extensions and algorithm implementations will be explored in future
revisions based on working group discussions.
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 7 January 2027.
Pang, et al. Expires 7 January 2027 [Page 1]
Internet-Draft CATS Fallback Decision Framework July 2026
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 . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Conventions and Definitions . . . . . . . . . . . . . . . . . 3
3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 3
4. High-Level Considerations for the Framework . . . . . . . . . 3
4.1. Logical Decoupling of Dimensions . . . . . . . . . . . . 4
4.2. Graceful Degradation . . . . . . . . . . . . . . . . . . 4
4.3. State Stability Mechanisms . . . . . . . . . . . . . . . 4
4.4. Deterministic Fallback Behavior . . . . . . . . . . . . . 4
5. CATS Fallback Decision Framework . . . . . . . . . . . . . . 4
6. Next Steps . . . . . . . . . . . . . . . . . . . . . . . . . 5
7. Security Considerations . . . . . . . . . . . . . . . . . . . 5
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 5
9.1. Normative References . . . . . . . . . . . . . . . . . . 5
9.2. Informative References . . . . . . . . . . . . . . . . . 6
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6
1. Introduction
As described in [I-D.ietf-cats-framework], Computing-Aware Traffic
Steering (CATS) optimizes service instance selection by incorporating
dynamic states of computing and network resources. Existing OAM
frameworks, such as [I-D.fu-cats-oam-fw], define mechanisms to
collect these multi-dimensional metrics.
However, when the C-PS receives telemetry indicating a failure (e.g.,
metric timeout or path unreachable), the decision logic governing how
to fallback is not defined. Simply removing the instance or
immediately switching to an alternative often leads to service
disruption, especially in edge computing scenarios where stateful
sessions are common.
Pang, et al. Expires 7 January 2027 [Page 2]
Internet-Draft CATS Fallback Decision Framework July 2026
This document initiates the discussion on the CATS Fallback Decision
Framework. It identifies key challenges in existing approaches and
proposes high-level considerations for improving the robustness of
the C-PS. The specific protocol extensions and detailed state
machine algorithms are outside the scope of this initial version and
will be addressed in subsequent revisions.
2. Conventions and Definitions
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. Abbreviations and definitions used in this
document:
3. Problem Statement
In the absence of a well-defined fallback decision framework, several
critical issues persist in CATS deployments:
* Correlated Failure Misjudgment: When the telemetry reporting
channel (e.g., for computing metrics) experiences a transient
network flap, the C-PS may incorrectly mark a reachable service
instance as unavailable. This conflation of channel failure and
instance failure causes unnecessary traffic black-holing.
* Steering Flapping: High-frequency volatility of computing metrics
or intermittent network issues can cause the C-PS to oscillate
between normal and fallback states. This instability breaks
stateful sessions (e.g., online gaming, video conferencing) and
degrades user experience.
* Non-deterministic Fallback: In multi-device or Anycast
deployments, if fallback algorithms are not consistent across
nodes, the same client request may be steered to different
instances during a failure, breaking session consistency.
* Binary State Limitation: Existing models often use a binary (up/
down) status. When a partial failure occurs (some metrics are
stale but the instance is reachable), the C-PS abruptly abandons
policy steering, failing to utilize the remaining valid resources.
4. High-Level Considerations for the Framework
To address the problems described in Section 2, the CATS Fallback
Decision Framework SHOULD consider the following principles in its
future definition:
Pang, et al. Expires 7 January 2027 [Page 3]
Internet-Draft CATS Fallback Decision Framework July 2026
4.1. Logical Decoupling of Dimensions
The framework SHOULD allow the C-PS to logically decouple the
evaluation of metric availability (from Instance OAM) and network
reachability (from Path/Link OAM). A failure in one dimension SHOULD
NOT automatically result in the immediate withdrawal of an instance
if other dimensions indicate normal operation. This helps mitigate
misjudgments caused by isolated channel failures.
4.2. Graceful Degradation
Instead of a binary up/down model, the framework MAY support a multi-
level state approach. When partial failures occur, the C-PS SHOULD
attempt to maintain policy steering within a valid candidate subset
rather than immediately falling back to default routing. This
graceful degradation maximizes resource utilization.
4.3. State Stability Mechanisms
To prevent steering flapping, the framework SHOULD define mechanisms
to absorb transient state fluctuations. State transitions,
particularly recovery transitions, SHOULD be stabilized to ensure
that intermittent metric refreshes do not cause rapid oscillation of
traffic.
4.4. Deterministic Fallback Behavior
When a complete fallback is unavoidable, the selection mechanism
SHOULD be deterministic. This means that given the same network
state and client context, different C-PS nodes SHOULD select the same
target instance to maintain session consistency. The prioritization
of deterministic fallback methods SHOULD be consistent across the
network to maintain session continuity.
Pang, et al. Expires 7 January 2027 [Page 4]
Internet-Draft CATS Fallback Decision Framework July 2026
5. CATS Fallback Decision Framework
Figure 1 shows the framework diagram of CATS fallback decision.
+----------------------+
| Policy Engine |
+----------+-----------+
|
| Policy decision / metadata feedback
v
+--------------------+ +--------+-------------------------------+
| Service Metric | | Network Edge Device |
| Collection Agent |---->| |
+--------------------+ | +-------------------+ |
Metric channel | | Path Selection | |
(logically independent) | | Module | |
| +---------+---------+ |
+--------------------+ | | |
| Reachability |---->| | Decision result |
| Detection Mechanism| | v |
+--------------------+ | +-------------------+ |
Reachability channel | | Data-plane | |
(logically independent) | | Forwarding Unit | |
| +---------+---------+ |
+------------|---------------------------+
|
| User traffic steering
v
+--------------+--------------+
| Compute Service Instance |
+-----------------------------+
* The service metric collection agent reports service metrics to the
path selection module through a logically independent metric
channel.
* The reachability detection mechanism provides network-layer
reachability status to the path selection module through a
logically independent reachability channel.
* The path selection module makes path decisions and sends the
decision result to the data-plane forwarding unit.
* The policy engine is deployed externally or as a sidecar. It
provides policy decisions to the path selection module, and
receives decision metadata feedback from the path selection
module.
* The data-plane forwarding unit steers user traffic to the selected
compute service instance.
6. Next Steps
This document initiates the discussion on CATS fallback decision
mechanisms. Based on working group feedback, future revisions of
this draft will define specific requirements, state machine models,
and YANG data models to support the framework.
7. Security Considerations
The fallback decision mechanism relies on the integrity of OAM data.
If an attacker injects fake stale metrics, it could trigger
unnecessary fallbacks. Implementations MUST ensure that OAM feeds
used for decision-making are authenticated and integrity-protected.
8. IANA Considerations
TBD
9. References
9.1. Normative References
Pang, et al. Expires 7 January 2027 [Page 5]
Internet-Draft CATS Fallback Decision Framework July 2026
[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>.
[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>.
9.2. Informative References
[I-D.ietf-cats-framework]
Li, C., Du, Z., Boucadair, M., Contreras, L. M., and J.
Drake, "A Framework for Computing-Aware Traffic Steering
(CATS)", Work in Progress, Internet-Draft, draft-ietf-
cats-framework-24, 2 April 2026,
<https://datatracker.ietf.org/doc/html/draft-ietf-cats-
framework-24>.
[I-D.fu-cats-oam-fw]
Huakai.Fu, Xiong, Q., Du, Z., Liu, B., and Z. Li,
"Computing-Aware Traffic Steering (CATS) Operations,
Administration, and Maintenance (OAM) Framework", Work in
Progress, Internet-Draft, draft-fu-cats-oam-fw-07, 18 June
2026, <https://datatracker.ietf.org/doc/html/draft-fu-
cats-oam-fw-07>.
Authors' Addresses
Ran Pang (editor)
China Unicom
Beijing
China
Email: pangran@chinaunicom.cn
Mengyao Han (editor)
China Unicom
Beijing
China
Email: hanmy12@chinaunicom.cn
Tianyi Huang (editor)
CNIC CAS
Beijing
China
Email: tyhuang@cnic.cn
Pang, et al. Expires 7 January 2027 [Page 6]
Internet-Draft CATS Fallback Decision Framework July 2026
Naihan Zhang (editor)
China Unicom
Beijing
China
Email: zhangnh12@chinaunicom.cn
Pang, et al. Expires 7 January 2027 [Page 7]