Use Cases and Requirements for Computing-Aware Traffic Steering (CATS) Operations, Administration, and Maintenance (OAM)
draft-dikshit-cats-oam-usecases-00

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