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, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . 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, . [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, . 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]