Cross-Domain OAM Problem Statement and Requirements:Across Trust Boundaries

Introduction The deployment models of modern network services are undergoing profound changes. Service paths are no longer confined within the core network of a single operator; instead, they are widely distributed across Multi-access Edge Computing (MEC) nodes, public cloud environments, and tenant-owned datacenters. In such cross-domain deployments, service chains (e.g., SFC), tunnels, or security paths frequently need to traverse distinct trust boundaries. Existing IETF OAM standards, such as SFC OAM defined in , are primarily designed for single administrative domains, assuming that the entity initiating the probe and the probed network elements operate under unified management. When an OAM probe must cross administrative domains, existing mechanisms fail to provide secure, privacy-preserving fault localization because: * The target domain distrusts external probe packets. * The target domain is reluctant to expose its internal topology. Consequently, operators currently resort to ad-hoc methods (e.g., manual Pings across VPNs, proprietary orchestrator APIs), which are non-interoperable and break OAM semantics. This document uses cross-domain Service Function Chaining (SFC) as a primary use case, while also covering MEC offloading, multi-cloud interconnection, and managed security services, to describe the generic problem space of OAM across trust boundaries. It analyzes the gaps in current OAM standards and specifies requirements for a Cross-Domain OAM Proxy (CD-OAM Proxy). The scope of this document is strictly limited to problem statements, use cases, gap analysis, and requirements for cross-domain OAM. The following items are explicitly out of scope: * Cross-domain service orchestration (assumed to be handled by existing orchestrators). * Automated discovery of cross-domain service capabilities. * Billing or SLA enforcement mechanisms. * Modifications to existing data plane forwarding behaviors (such as NSH, VXLAN-GPE, or SFF forwarding logic).

Terminology 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 when, and only when, they appear in all capitals, as shown here.

Administrative Domain: A network region governed by a single administrative entity, operating under independent security and management policies.
CD-OAM (Cross-Domain OAM): OAM operations that span two or more administrative domains.
CD-OAM Proxy: An entity deployed at the boundary of an administrative domain, consisting of data-plane relay components and control-plane policy management components.
Cross-Domain SFC: A service chain where its SFFs and one or more SFs reside in different administrative domains.

Use Cases

MEC Offloading and Managed Security Services An operator deploys service forwarding capabilities at an MEC site close to the user. Traffic must traverse a firewall and Deep Packet Inspection (DPI) functions. The firewall resides in the operator's core cloud, whereas the DPI is hosted in the tenant's private datacenter. The operator needs to verify that the cross-domain link to the tenant SFF is healthy and that the tenant SFF is reachable, without requiring the tenant to expose its internal SF topology or modify its service function implementations. In a variant of managed security services, a third-party security provider does not accept OAM probes directly entering its internal network and provides no guarantee that its SFs support specific technologies (e.g., NSH OAM).

Multi-Cloud Interconnection An enterprise workload is distributed across two public clouds. A service path in Cloud A steers egress traffic through a security gateway hosted by Cloud B. Cloud A and Cloud B represent different administrative domains with no shared management plane. Cloud A requires a standardized mechanism to probe the reachability of Cloud B's boundary node without establishing a full management-plane trust relationship.

Enterprise VPN and Segmented Security Services A large enterprise connects hundreds of branches via an operator VPN. The operator provides a shared security service chain (Firewall, IDS, DLP) hosted across multiple vendor clouds. When application performance degrades, the enterprise IT team needs to know which segment of the service chain is at fault. These vendors will not expose internal SF health to either the enterprise or the operator, and multi-tenancy constraints restrict what information can be exposed to an individual tenant.

Problem Statement

Trust Boundary Traversing Existing single-domain OAM mechanisms assume that the network element initiating a probe can send probe packets directly to all downstream elements. In cross-domain scenarios: 1. The source domain lacks the security credentials to inject packets into the target domain. 2. The target domain does not trust unauthenticated external probes. Feedback from operators indicates that cross-domain fault resolution times are typically orders of magnitude longer than intra-domain resolution, largely due to the need for manual escalation of trouble tickets between domains.

OAM-Unaware Service Nodes Within a single domain, an operator can uniformly configure all nodes. However, in cross-domain scenarios, the source domain has no visibility into the capabilities of the target domain's nodes. Nodes in the target domain may be legacy devices, third-party virtualized functions, or cloud-native services that do not support specific OAM extensions (such as the NSH O-bit). Standard OAM probes entering the target domain are silently dropped, leading to false-positive fault detections. Existing standards provide no mechanism for a target domain to signal "boundary reachable only, do not probe deeper", nor do they allow the source domain to gracefully degrade to boundary-only probing based on target domain capabilities.

Fault Localization vs. Privacy When a cross-domain OAM probe fails, source domain operators cannot determine whether the fault lies within the source domain, on the inter-domain link, or within the target domain. Standard IP Ping or BFD can verify Layer 3 reachability but cannot interpret upper-layer (e.g., SFC/NSH) semantics. Target domains are reluctant to expose internal topologies due to security and commercial reasons. Any cross-domain OAM mechanism MUST support privacy-preserving fault localization, revealing only the minimum necessary information.

Gap Analysis

Limitations of Single-Domain OAM Standards Taking SFC OAM as an example, it explicitly states that proxy functions are out of scope. The resulting gap is that no IETF standard defines a CD-OAM proxy operating at administrative domain boundaries. The absence of such a proxy means there is no standardized source-domain authentication, authorization for service path probing, or relaying of OAM forwarding context across boundaries.

Semantic Disconnect in Generic L3 OAM Tools Standard IP Ping or Bidirectional Forwarding Detection (BFD) can verify Layer 3 reachability, but in complex cross-domain service chaining scenarios, they are unaware of service function states and cannot locate which specific service node segment or security policy caused the failure. Application-layer monitoring is too coarse and introduces significant latency.

Mismatch between Security Protocols and OAM Real-Time Needs IPsec and TLS could theoretically protect cross-domain OAM traffic. However:

IPsec tunnel establishment imposes heavy overhead, making it unsuitable for frequent, short-lived OAM probes.
TCP-based TLS introduces head-of-line blocking and connection setup latency, conflicting with real-time OAM constraints.

Neither efficiently carries the forwarding context (such as NSH SPI, SI, or other metadata) required to reconstruct OAM replies.

Requirements

Functional Requirements

REQ-1: The mechanism MUST operate without requiring any modifications to the data plane forwarding behavior of existing network elements (such as SFFs or SFs).
REQ-2: The mechanism SHOULD maintain backward compatibility with existing single-domain OAM standards (such as RFC 9516).
REQ-3: To prevent spurious probe timeouts, the data plane components of boundary proxies SHOULD process and relay packets in a low-latency, stateless manner.
REQ-4: The mechanism MUST support both IPv4 and IPv6 transport.
REQ-5: The mechanism MUST provide a "boundary-reachability-only" mode to gracefully degrade when downstream nodes or SFs lack OAM capabilities.

Security and Privacy Requirements

REQ-6: The proxy MUST authenticate the source administrative domain and perform path-level authorization before processing any cross-domain probe.
REQ-7: Cross-boundary OAM traffic MUST be protected by integrity, confidentiality, and anti-replay mechanisms, and SHOULD support confidentiality protection where policy demands.
REQ-8: By default, the information exposed externally MUST be restricted to the binary path status and end-to-end delay.
REQ-9: The mechanism MUST NOT disclose internal topology details (such as node types, hop counts, or internal IP addresses) unless explicitly authorized by the target domain's policy.
REQ-10: The mechanism MUST support rate limiting to mitigate DoS vectors and SHOULD provide the capability to coarsen or fuzz latency measurements against timing side-channel analysis.

Operations, Management, and Extensibility Requirements

REQ-11: The mechanism MUST provide a standardized fault localization model that unambiguously differentiates between faults in the source domain, the inter-domain link, and the internal target domain.
REQ-12: To minimize operational coupling, the mechanism SHOULD NOT require real-time control plane interactions between domains and MUST support asymmetric or offline policy configuration exchanges.
REQ-13: The mechanism SHOULD provide a YANG data model for policy configuration, and this model SHOULD align with generic OAM management models (such as RFC 8531).
REQ-14: The framework MUST be extensible to support future network data plane technologies (such as SRv6-based service chaining or SAV rule-related information announcement scenarios) without modifying its core control logic.

Security Considerations

Topology Reconnaissance Mitigation: Solutions SHOULD prevent the abuse of cross-domain probes for scanning internal domain nodes.
Denial of Service (DoS): Rate limiting and strict control plane filtering mechanisms MUST be applied at the CD-OAM proxy boundary to avoid message amplification vulnerabilities.

Acknowledgements TBD.

IANA Considerations TBD.