Network Working Group S. Dikshit Internet-Draft Aruba Networks, HPE Intended status: Informational 31 July 2026 Expires: 1 February 2027 Use Cases and Requirements for Computing-Aware Traffic Steering (CATS) Operations, Administration, and Maintenance (OAM) draft-dikshit-cats-oam-usecases-00 Abstract [I-D.ietf-cats-oam-fw] defines a framework for Operations, Administration, and Maintenance (OAM) in Computing-Aware Traffic Steering (CATS) networks, introducing Instance OAM and Service OAM as new components alongside traditional Link and Path OAM, and specifying high-level requirements (O-REQ, A-REQ, M-REQ) for each. As with the base CATS work, where [I-D.ietf-cats-usecases-requirements] separately catalogued problem statement, use cases, and requirements alongside [I-D.ietf-cats-framework], the OAM framework similarly benefits from a companion document grounding its requirements in concrete operator scenarios. This document fills that gap. It presents five use cases for CATS OAM -- multi-domain compute-node failure detection, SLA verification that closes the loop with metric-driven traffic- steering decisions, demarcation of network-path faults from compute-instance faults, OAM-triggered fallback steering, and multi-vendor Compute-Service Metric Agent (C-SMA) interoperability verification -- and maps each to the Link/Path/Instance/Service OAM layering and O-REQ/A-REQ/M-REQ requirement categories defined in [I-D.ietf-cats-oam-fw]. 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 1 February 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. Dikshit Expires 1 February 2027 [Page 1] Internet-Draft CATS OAM Use Cases July 2026 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3.1. Multi-Domain Compute-Node Failure Detection . . . . . . 3 3.2. SLA Verification Closing the Loop with Metric-Driven Steering . . . . . . . . . . . . . . . . . . . . . . . . 4 3.3. Network-vs-Compute Fault Demarcation . . . . . . . . . . 5 3.4. OAM-Triggered Fallback Steering . . . . . . . . . . . . . 5 3.5. Multi-Vendor C-SMA Interoperability Verification . . . . 6 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 6 5. Relationship to Existing Work . . . . . . . . . . . . . . . . 7 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 9.1. Normative References . . . . . . . . . . . . . . . . . . 8 9.2. Informative References . . . . . . . . . . . . . . . . . 9 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9 1. Introduction [I-D.ietf-cats-framework] and [I-D.ietf-cats-usecases-requirements] established a pattern for CATS base documents: a framework document defines the architecture, and a companion problem-statement/use- cases/requirements document grounds it in concrete operator scenarios and derives testable requirements. Both are now in the RFC Editor queue. [I-D.ietf-cats-oam-fw] extends the CATS architecture with Operations, Administration, and Maintenance (OAM) capability, introducing Instance OAM (monitoring the health and load of individual compute service instances) and Service OAM (end-to-end service-level verification), in addition to the Link OAM and Path OAM already used in the network underlay/overlay. It defines high-level Operation (O-REQ), Administration (A-REQ), and Maintenance (M-REQ) requirements for these components, but -- as of its -01 revision, published 2026-07-21 -- has no companion use-cases document, unlike the base framework/use-cases pair it otherwise mirrors in structure. [I-D.ietf-cats-oam-fw] Section 4 states a motivation and problem statement, but does so in terms of the properties of CATS itself rather than in terms of operator scenarios, and does not trace individual requirements back to the situations that motivate them. This document provides that companion. It does not modify or compete with [I-D.ietf-cats-oam-fw]'s requirements; it grounds them in concrete scenarios and, where a scenario surfaces a requirement not already covered, proposes additions for WG consideration. 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. 2. Terminology This document uses "Client", "Network Element (NE)", "CATS Forwarder (C-FW)", "CATS Metric Agent (C-MA)", "Compute Service Metric Agent (C-SMA)", and "Compute Service Instance (CSI)" as defined in [I-D.ietf-cats-framework]. It uses "Link OAM", "Path OAM", "Instance OAM", and "Service OAM" as defined in [I-D.ietf-cats-oam-fw]. 3. Use Cases 3.1. Multi-Domain Compute-Node Failure Detection A CATS domain steers traffic across several CSIs, each hosted on compute nodes that may fail, be drained for maintenance, or become unreachable independently of any network-layer fault. Today, a C-FW learns about instance health only through the metric feed from C-MA/C-SMA, which is typically periodic and may lag an actual failure by one or more reporting intervals. Instance OAM, per [I-D.ietf-cats-oam-fw] Section 5.2.1, is intended to provide faster, more direct observability of instance health. This use case asks for Instance OAM to support: (a) an active liveness check the C-FW (or a delegated Instance OAM function) can run independently of the metric-collection cadence, and (b) a passive fast-fail signal (e.g., an explicit "instance withdrawing" notification) analogous to a routing protocol's graceful/ungraceful shutdown distinction, so the CATS control plane can distinguish a clean drain from an unexpected failure and react with different urgency. Relevant OAM layer: Instance OAM. Relevant requirements: O-REQ-1 (threshold-triggered reporting) and A-REQ-2 (differentiated monitoring intensity) already admit (a); item (b), an explicit withdrawal signal distinguishing a clean drain from an unexpected failure, is not covered by any current requirement. 3.2. SLA Verification Closing the Loop with Metric-Driven Steering CATS steers traffic based on advertised compute and network metrics ([I-D.ietf-cats-metric-definition]), but advertised metrics are inherently a prediction of expected service quality, not a guarantee. Operators need a way to verify, after the fact, that traffic steered toward a given CSI based on its advertised metrics actually received the expected service level (latency, throughput, completion time). This use case asks Service OAM to support periodic or on-demand end-to-end measurement runs correlated against the metric values that were in effect at steering-decision time, so that persistent mismatches between advertised and observed service quality can be detected and fed back (out of band) to metric-source calibration. [I-D.ietf-cats-oam-fw] M-REQ-2 already requires the OAM system to record historical snapshots of network paths and computing status, and O-REQ-4 already requires computing metrics to carry collection timestamps. Together these supply the raw material for the correlation described above. What neither requirement states is that the recorded history should be compared against the observed end-to-end service level and the residual fed back to calibrate the metric sources. M-REQ-2 motivates history for post-mortem analysis of steering oscillation; this use case asks for the same history to be used as a closed-loop calibration input against [I-D.ietf-cats-metric-definition]. Relevant OAM layer: Service OAM. Relevant requirements: extends M-REQ-2 (historical traceability) and O-REQ-4 (metric timestamps) toward closed-loop calibration. 3.3. Network-vs-Compute Fault Demarcation [I-D.ietf-cats-oam-fw] M-REQ-1 already requires the system to distinguish whether a service failure is caused by a network-layer issue or by computing resource exhaustion at the Service Instance, and states that this requires correlation of Link, Path, Instance, and Service OAM data. This use case does not propose a new capability; it grounds M-REQ-1 in an operator scenario and identifies what the requirement leaves open. Because a CATS steering decision blends network path metrics and compute instance metrics, a degraded end-user experience can be caused by network path congestion, compute instance overload, or both simultaneously. The simultaneous case is the difficult one: M-REQ-1 is phrased as an either/or determination ("whether a service failure is caused by a network-layer issue ... or computing resource exhaustion"), but concurrent degradation on both sides is common in practice and is precisely when manual correlation across separately operated monitoring systems fails. This use case therefore asks that the demarcation capability required by M-REQ-1 be able to attribute a given steering decision's observed outcome to network path, compute instance, or both, rather than selecting a single fault domain. It also asks that the attribution be expressed per steering decision, so that an automated fault-management system consuming both Path OAM and Instance OAM results can determine whether the network path to the selected CSI met its expected characteristics independently of whether the CSI itself was healthy -- an OAM-level equivalent of the underlay/ overlay separation already present in the CATS data-plane architecture. Relevant OAM layers: Path OAM and Instance OAM jointly. Relevant requirement: M-REQ-1 (joint fault demarcation), for which this use case supplies operator motivation and proposes extension to the concurrent-fault case. 3.4. OAM-Triggered Fallback Steering [I-D.pang-cats-fallback-decision-framework] defines a framework for falling back to default/legacy traffic steering when CATS metric feeds are stale, missing, or otherwise untrustworthy. Today, staleness detection in that framework is implicitly tied to the metric-distribution protocol's own liveness (e.g., a BGP session or IGP extension going down); it does not describe how Link, Path, or Instance OAM results might independently trigger the same fallback behavior -- for example, when the metric feed is nominally live but an OAM check reveals the path or instance it describes is not actually reachable. This use case asks the OAM framework to define how its O-REQ/A-REQ signals can serve as an additional, OAM-native trigger for fallback decisions, complementing (not replacing) the metric-freshness triggers already described in [I-D.pang-cats-fallback-decision-framework] and the staleness threshold already required by [I-D.ietf-cats-oam-fw] O-REQ-4. The distinction matters because O-REQ-4 detects a metric that is known to be old, whereas this use case addresses a metric that is fresh and therefore passes the O-REQ-4 threshold, but is contradicted by an OAM observation. Relevant OAM layers: Link, Path, and Instance OAM. Relevant requirements: complements O-REQ-4 (metric freshness handling) and consumes M-REQ-1 output as a fallback trigger. 3.5. Multi-Vendor C-SMA Interoperability Verification A CATS domain may include C-SMA implementations from multiple vendors, each computing and advertising compute metrics using its own internal instrumentation. Operators need a way to verify that different C-SMA implementations, when measuring the same underlying compute resource, produce comparable OAM-observable results -- otherwise CATS steering decisions across a multi-vendor domain risk being skewed by measurement inconsistency rather than genuine differences in service quality. This use case asks for an OAM verification procedure (e.g., a reference workload or synthetic probe whose expected Instance OAM result is known in advance) that operators can run against each C-SMA implementation in a domain to validate measurement consistency before relying on cross-vendor metric comparison for steering decisions. Relevant OAM layer: Instance OAM. Relevant requirements: O-REQ-3 (telemetry integration with C-SMA) presumes C-SMA-reported metrics are comparable across implementations; no current requirement states how that comparability is to be verified. 4. Requirements Restating and extending [I-D.ietf-cats-oam-fw]'s O-REQ/A-REQ/M-REQ categories in light of Section 3: UC-REQ-1: Instance OAM SHOULD support both an active liveness check independent of C-MA/C-SMA metric-reporting cadence and a passive graceful-withdrawal notification (Section 3.1). UC-REQ-2: Service OAM SHOULD support correlating an end-to-end measurement result against the specific metric values that were in effect at the time of the corresponding steering decision (Section 3.2). UC-REQ-3: The fault-demarcation capability required by M-REQ-1 SHOULD be able to attribute a degraded steering outcome to Path OAM findings, Instance OAM findings, or both concurrently, rather than selecting a single fault domain (Section 3.3). UC-REQ-4: The OAM framework SHOULD document how Operation and Administration signals can serve as an additional trigger input to fallback-decision logic such as [I-D.pang-cats-fallback-decision-framework], alongside the metric-staleness threshold already required by O-REQ-4 (Section 3.4). UC-REQ-5: Instance OAM SHOULD support a reference/synthetic verification procedure usable to validate measurement consistency across multiple C-SMA implementations in the same administrative domain (Section 3.5). None of UC-REQ-1 through UC-REQ-5 are believed to conflict with the O-REQ/A-REQ/M-REQ requirements already stated in [I-D.ietf-cats-oam-fw]; they are refinements/extensions offered for WG consideration. 5. Relationship to Existing Work * [I-D.ietf-cats-oam-fw] defines the OAM framework this document supplies use cases and requirements for. * [I-D.ietf-cats-framework] and [I-D.ietf-cats-usecases-requirements] establish the base CATS architecture and the framework/use-cases document-pairing pattern this document follows. * [I-D.ietf-cats-metric-definition] defines the metrics whose advertised-versus-observed consistency Section 3.2 addresses. * [I-D.pang-cats-fallback-decision-framework] defines the fallback decision logic Section 3.4 proposes an additional OAM-native trigger for. * [I-D.zhu-cats-metric-semantics] discusses operational semantics for metric consumption; a future revision of this document may draw on it further when detailing UC-REQ-2. 6. Security Considerations This document introduces no new protocol mechanisms, only use cases and requirements. It inherits the security considerations of [I-D.ietf-cats-oam-fw] and [I-D.wang-cats-security-considerations]. Active liveness checks proposed in UC-REQ-1 and the synthetic verification procedure in UC-REQ-5 both introduce additional probe traffic into a CATS domain; implementations SHOULD rate-limit and authenticate such probes to avoid their use as a reflection or amplification vector, consistent with general OAM probing guidance. 7. IANA Considerations This document has no IANA actions. 8. Acknowledgements Thanks to the authors of [I-D.ietf-cats-oam-fw] and [I-D.ietf-cats-usecases-requirements] for the frameworks this document builds on. 9. References 9.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, May 2017. [I-D.ietf-cats-oam-fw] Fu, H., Xiong, Q., Du, Z., Liu, B., and Z. Li, "Computing-Aware Traffic Steering (CATS) Operations, Administration, and Maintenance (OAM) Framework", Work in Progress, draft-ietf-cats-oam-fw-01, 21 July 2026. [I-D.ietf-cats-framework] Li, C., Ed., Du, Z., Boucadair, M., Ed., Contreras, L. M., and J. Drake, "A Framework for Computing-Aware Traffic Steering (CATS)", Work in Progress, draft-ietf-cats-framework-24, 2 April 2026. [I-D.ietf-cats-usecases-requirements] Yao, K., Contreras, L. M., Shi, H., Zhang, S., and Q. An, "Computing-Aware Traffic Steering (CATS) Problem Statement, Use Cases, and Requirements", Work in Progress, draft-ietf-cats-usecases-requirements-14, 3 February 2026. 9.2. Informative References [I-D.ietf-cats-metric-definition] Yao, K., Li, C., Contreras, L. M., Ros-Giralt, J., and G. Zeng, "CATS Metrics Definition", Work in Progress, draft-ietf-cats-metric-definition-10, 22 June 2026. [I-D.pang-cats-fallback-decision-framework] Pang, R., Ed., Han, M., Ed., Huang, T., Ed., and N. Zhang, Ed., "CATS Fallback Decision Framework", Work in Progress, draft-pang-cats-fallback-decision- framework-00, 6 July 2026. [I-D.zhu-cats-metric-semantics] Zhu, M., "Operational Semantics for CATS Metric Consumption", Work in Progress, draft-zhu-cats-metric- semantics-00, 24 April 2026. [I-D.wang-cats-security-considerations] Shi, J., Wang, C., and Y. Fu, "Security Considerations for Computing-Aware Traffic Steering", Work in Progress, draft-wang-cats-security-considerations-04, 2 March 2026. Author's Address Saumya Dikshit Aruba Networks, Hewlett Packard Enterprise Email: saumya.dikshit@hpe.com