DISA SD-WAN Interoperability Requirements Comprehensive.xlsx

SDN Requirements

1. Each controller publishes and consumes the agreed topology elements, including nodes, links, reachability, identifiers, and administrative attributes.

2. Each controller can retrieve and interpret the same topology dataset from the other vendor domain.

3. Topology changes are synchronized within the agreed test interval and are reflected in both domains.

Required evidence: exported topology dataset, synchronization timestamp, and cross-vendor interpretation results.

Failure: missing topology elements, incompatible identifiers, stale topology, or manual reconciliation required to complete exchange. 1. Align TLV/attribute sets and identifier conventions across controllers.

2. Configure the selected topology exchange protocol and schema.

3. Validate topology model compatibility before production federation. Normative references:

1. BGP-LS (RFC 9552)

- Sections 3, 4, 5, 5.1, 5.2, 5.2.1, 5.2.2, 5.2.3, 5.3, 5.3.2, 5.5, 5.6, 5.9, 6, 8, 8.2.3, 8.2.5, 8.2.6, and 10.

2. BGP-EVPN (RFC 7432)

- Sections 4, 5, 6, 7, 7.1 through 7.4, 7.7 through 7.10, 8, 9, 9.2.1, 9.2.2, 10, 11, 12, 14, 15, 16, 17, and 19.

3. Network topology YANG models including RFC 8345

- Sections 4.1, 4.2, 4.3, 4.4.2, 4.4.3, 4.4.6, 4.4.9, 4.4.10, 4.4.11, 6.1, and 6.2.

Informative references:

1. BGP SD-WAN overlay usage draft

2. ALTO (RFC 7285) map/network cost concepts

- Sections 3.1, 4.1, 5, 5.1, 5.2, 6, 6.1 through 6.4, 7, 8.3, 9, 11.2 through 11.5, 15, and 16

20 1b. Controller-to-Controller Policy Synchronization High Unknown SD-WAN controllers MUST synchronize inter-domain policy objects, policy intent, policy bindings, and policy state required for consistent cross-vendor enforcement using standards-based YANG data models. The solution MUST align inter-domain workflow coordination with MEF 55.1 Lifecycle Service Orchestration (LSO) reference architecture, using applicable LSO interface roles such as Interlude, Sonata, Legato, or Presto based on the provider/domain relationship. Where OpenDaylight or ONOS federation plugins are used, they MUST be treated as implementation mechanisms and MUST expose documented, interoperable YANG-based, NETCONF/RESTCONF, or MEF LSO-aligned interfaces rather than proprietary-only Failure to address this requirement can cause policy drift, inconsistent segmentation, traffic exposure, and manual policy reconciliation across vendor domains. Acceptance criteria:

1. Controllers exchange the agreed policy object types, including policy identifiers, scope, enforcement point, priority, and version.

2. A policy update in one domain is visible to the peer controller and preserves policy intent.

3. Conflicting or unsupported policy attributes are explicitly rejected or flagged for remediation.

Required evidence: policy export, synchronized policy state, version history, and conflict/failure logs.

Failure: silent policy loss, inconsistent priority/order, or unsupported attributes accepted without warning. 1. Align the shared policy model and versioning rules.

2. Configure inter-controller policy synchronization APIs.

3. Define conflict handling and unsupported-attribute behavior before interoperability testing. Normative references:

1. YANG model validation for topology and policy

- RFC 7950 Sections 4.2.2, 4.2.3, 5.6, 5.6.2, 5.6.3, 7.5.3, 7.8.2, 7.8.3, 7.21.5, 8, and 9.9.

- RFC 8342 Sections 5.1- 5.3.

- RFC 8525 Sections 2-4.

- RFC 8345 Sections 4.1- 4.3, and 4.4.10.

- RFC 9067 Sections 3-7.

-RFC 8519 Sections 3-4.

- RFC 6241 Sections 8.3-8.5, and 8.6.

- RFC 8040 Sections 3.4, 4 and 7.

2. MEF LSO workflow interfaces where selected

- Sections 8.2.3, 8.7, 8.8, 8.9, 8.11, 9.1, 9.2, 10.2, and 10.3, and MEF 95 Sections 7, 8, and 9.2.

Informative references:

1. NETCONF, RESTCONF where applicable

2. OpenDaylight or ONOS federation plugins 30 1c. Controller Federation Path and Service Lifecycle Coordination High Unknown SD-WAN controllers MUST coordinate cross-domain path computation, path state synchronization, and path update requests using PCEP as defined in RFC 5440 and Stateful PCE extensions as defined in RFC 8231. Where abstract topology, network maps, or path-cost information is exchanged for policy-based path selection, controllers MUST support ALTO as defined in RFC 7285. Service lifecycle actions, including service feasibility, activation, modification, suspension, restoration, testing, assurance, and termination, MUST use standards-based or fully documented federation workflows aligned with MEF LSO workflow interfaces, such as Interlude, Sonata, Legato, or Presto, as applicable to the provider/domain relationship. Failure to address this requirement can prevent automated inter-domain service instantiation, path delegation, and lifecycle state alignment. Acceptance criteria:

1. Controllers compute, delegate, and synchronize cross-domain path intent using the agreed workflow.

2. Service lifecycle states are consistently represented across domains.

3. Service creation, modification, and deletion complete without manual re-entry of peer-domain data.

Required evidence: workflow transaction log, lifecycle state record, and cross-domain path computation result.

Failure: state mismatch, manual peer-domain rework, or path delegation that cannot be audited. 1. Configure PCEP, MEF LSO, or selected federation workflow interfaces.

2. Align lifecycle state names and identifiers across domains.

3. Validate service creation, update, and teardown workflows end to end. Normative references:

1. PCEP (RFC 5440/8231)

- Sections 4.1, 4.2, 4.2.1, 6.2, 4.2.2, 6.3, 4.2.3, 6.4, 4.2.4, 6.5, 7.5, 7.6, 7.7.8, 7.9, 7.10, 7.13, 4.2.5, and 4.2.6.

- RFC 8231 Sections 3.12, 3.13, 3.2, 4, 5.4, 5.6, 5.7, 5.8.3, 6.1, 6.2, 7.2, 7.3, 7.3.3, and 5.10.

2. MEF 55.1 LSO workflow interfaces where selected

- Sections 6.1, 6.2, 7.1, 7.2, 7.4, 7.5, 8.2.1, 8.2.2, 8.2.3, 8.2.4, 8.3, 8.4, 9.2, 10.3, and Appendix A Table 4.

Informative references:

1. ALTO map/network cost query

2. Standardized controller federation API profiles 3.PCE-initiated extensions such as RFC 8281 where applicable 40 1d. Orchestrator-to-Edge Configuration Interoperability High Unknown All SD-WAN controllers, orchestrators, and edge devices MUST support standards-based configuration and provisioning interfaces using NETCONF as defined in RFC 6241 and/or RESTCONF as defined in RFC 8040. These interfaces MUST use YANG-modeled configuration and operational data, including model discovery through YANG Library RFC 8525, to support interoperable service, topology, tunnel, segmentation, routing, telemetry, and policy provisioning. Where service-orchestration workflows are required, the solution MUST align with applicable MEF LSO API and MEF LSO reference-interface roles for service ordering, activation, modification, assurance, and lifecycle management. Failure to address this requirement can lead to configuration drift, vendor lock-in, integration overhead, manual lifecycle management, and inconsistent service activation. Acceptance criteria:

1. The controller/orchestrator establishes a standards-based management session with each vendor edge.

2. Capability and schema discovery identify supported datastores, modules, revisions, and augmentations.

3. Create, read, update, delete, commit, rollback, and candidate datastore behavior complete as specified.

4. The resulting operational state matches the requested configuration.

Required evidence: session log, schema/capability response, configuration transaction log, rollback result, and operational state verification.

Failure: unsupported CRUD operation, unannounced schema difference, failed rollback, or operational state mismatch. 1. Enable NETCONF/RESTCONF and required YANG libraries.

2. Align common service and policy models across controllers and edges.

3. Configure mediation only where needed to normalize vendor-specific deviations.

4. Re-test CRUD, commit, rollback, and state verification workflows. Normative references:

1. NETCONF (RFC 6241)

- Sections 1.2, 1.3, 1.4, 2, 2.1, 2.2, 2.3, 4, 4.3, 4.5, 5.1, 5.2, 6, 7.1, 7.2, 7.3, 7.5, 7.6, 7.7, 8.1, 8.2, 8.3, 8.4, 8.5, 8.6, 8.7, 9, and Appendix A & E.

2. RESTCONF (RFC 8040)

- Sections 1.2, 1.3, 1.4, 2, 2.1, 2.5, 3.1, 3.2, 3.3, 3.3.1, 3.3.2, 3.3.3, 3.4, 3.4.1, 3.5, 3.5.1, 3.5.2, 3.6, 3.7, 3.9, 4, 4.3, 4.7, 4.8, 5, 6, 7, 9, 10, and 12.

3. YANG library (RFC 8525) and selected IETF SD-WAN/service models

- Sections 1.1, 2, 3, 4, 6, and Appendix A.

Informative references:

1. OpenConfig YANG where selected by the interoperability profile

- Not a single RFC, it is family of vendor-neutral YANG models.

2. MEF LSO API alignment for resource provisioning, topology, and service orchestration 50 1e. Zero-Touch Provisioning (ZTP) and Device Onboarding High Unknown All SD-WAN edge devices MUST support secure, vendor-neutral onboarding using Secure Zero Touch Provisioning (SZTP) as defined in RFC 8572 for bootstrapping, onboarding, and redirection to the authorized SD-WAN orchestrator or controller. Where manufacturer-installed device identity and voucher-based trust establishment are required, edge devices MUST support Bootstrapping Remote Secure Key Infrastructure (BRSKI) as defined in RFC 8995 to authenticate the device, validate ownership, and establish trust with the authorized domain. Failure to address this requirement can lead to onboarding failures, admission of unvalidated devices, manual provisioning delays, and inconsistent service activation. Acceptance criteria:

1. A device authenticates and completes onboarding using the approved identity and voucher process.

2. The device receives and validates its LDevID before joining the service domain.

3. The device discovers and connects to the authorized bootstrapping/registrar service without manual intervention.

4. An invalid voucher, untrusted identity, wrong registrar, or tampered bootstrap response is rejected and logged.

Required evidence: successful onboarding log, LDevID issuance record, discovery trace, and negative test logs.

Failure: unauthorized device admission, missing rejection evidence, or manual steps required for the approved workflow. 1. Update device firmware and registrar software for full ZTP workflow support.

2. Configure discovery paths and registrar trust anchors consistently.

3. Add negative tests for invalid identity, voucher, registrar, and bootstrap response cases. Normative references:

1. SZTP (RFC 8572)

- Sections 1.1, 1.2, 2.1, 2.2, 3, 3.2, 3.3, 3.4, 4, 4.2, 4.3, 4.4, 5.1, 5.2, 5.3, 5.4, 5.5, 5.6, 6, 7, 7.1, 7.3, 8.1, 8.2, 8.3, and 9.

2. BRSKI (RFC 8995)

- Sections 1.2, 1.3, 1.3.3, 1.4, 2, 2.1, 2.2, 2.3, 2.4, 2.5.1, 2.5.5, 2.6, 2.7, 3, 3.4, 4, 5, 5.1, 5.2, 5.3, 5.5, 5.6, 5.6.1, 5.7, 5.8, 5.9, 7, 10, and 11.

3. IEEE Std 802.1AR IDevID

- Sections DevID capability, Initial Device Identifier, or IDevID, Protection of the IDevID, and Cryptographic binding of LDevID to device / IDevID.

4. Automated discovery mechanisms selected by the profile Informative references:

1. BRSKI-AE/ANI

2. TPM 2.0

3. MEF LSO ZTP

60 1f. Segmentation Interoperability High Unknown All SD-WAN controllers and edge devices MUST support standardized representation and exchange of segmentation constructs using YANG topology and service models, including segment identifiers, service identifiers, tenant or VPN membership, endpoint membership, policy associations, and inter-domain boundary behavior. Segmentation constructs MUST align with MEF SD-WAN service attribute models, including Zones, SWVCs, SWVC End Points, Virtual Topologies, Application Flows, Policy Maps, and Allowed Destination Zones, where MEF SD-WAN semantics are used. Failure to address this requirement can cause segment identity drift, policy leakage, or inconsistent isolation across vendors. Acceptance criteria:

1. Equivalent segments are created in multiple vendor domains using the agreed model.

2. Segment identity, membership, and policy association are preserved across the inter-domain boundary.

3. Traffic assigned to one segment cannot leak into another segment.

Required evidence: segment definition export, membership/state records, policy association records, and isolation test results.

Failure: mismatched segment identity, missing policy association, or cross-segment leakage. 1. Define common segment identifiers and boundary behavior.

2. Configure segment/policy mapping in each controller.

3. Validate isolation and membership preservation across domains. Normative references:

1. YANG topology/service models where selected

- RFC 8345 Sections 1, 4.1, 4.2, 4.4.2, 4.4.9, 4.4.10, and Appendix A.4.

- RFC 8346 Sections 1, 4, 5, 6, and 7.

- RFC 8529 Sections 3.1, 3.2, 3.3, 3.4, and 6.

- RFC 8530 Sections 1, 2, 3, and 3.1.

- RFC 9181 Sections 3, and 4.

- RFC 8299 Sections 4, 5, 6.2.1, 6.2.4, 6.5, 6.5.2, 6.6.7, and 6.9.

- RFC 9182 Sections 4, 5, 7.2, 7.3, 7.5, and 7.6.

- RFC 8466 Sections 3, 4, 5.2.2, 5.2.2.1, and 5.5.

- RFC 9291 Sections 4, 5, 7.3, 7.5, 7.6, and 8.4.

- RFC 9408 Sections 1, 3, 5, and 6.

- RFC 9067 Sections 1, 3, 4, 5, 6, and 7.

-RFC 8519 Sections 1, 2, 3, 4.1, and 4.2.

Informative references:

1. MEF SD-WAN service attribute models 70 1g. Application-Aware Steering / Path-Quality Signaling High Unknown All SD-WAN controllers MUST support standardized exchange of path-quality telemetry using OpenConfig YANG models and gNMI telemetry interfaces, including latency, packet loss, packet delay variation/jitter, availability, and path state where supported. Controllers MUST also exchange application intent and path-selection constraints sufficient for interoperable steering across vendor domains, and MUST support ALTO network and cost-map concepts to represent abstract path cost, preference, and policy information without exposing full internal topology. Failure to address this requirement can lead to inconsistent application steering decisions and SLA behavior between vendor domains. Acceptance criteria:

1. Controllers exchange the agreed path-quality metrics and application intent attributes.

2. Multi-vendor controllers make consistent steering decisions for the same policy and path state.

3. Injected impairment causes the expected steering change within the agreed interval.

Required evidence: exchanged metric set, policy/intent record, impairment test, and steering decision log.

Failure: incompatible metric names/units, inconsistent decision outcome, or no steering change after threshold breach. 1. Define metric names, units, thresholds, and update intervals.

2. Configure shared application intent/policy attributes.

3. Test impairment scenarios across all vendor pairs. Normative references:

1. Selected telemetry and policy models in the interoperability profile (OpenConfig/gNMI telemetry profiles)

- Sections 2.1, 2.2.1, 2.2.2, 2.4, 2.5, 2.6, 2.7, 3.1, 3.2, 3.3, 3.4, 3.5, and 3.5.2.

Informative references:

1. ALTO path cost concepts

2. OpenConfig/gNMI telemetry profiles where selected

1. The orchestrator produces required artifacts for each lifecycle phase: service order, intent, design, resource assignment, activation record, policy binding, assurance state, modification record, and termination record.

2. Lifecycle states are explicit and auditable, including ordered, designed, activated, assured, modified, suspended if applicable, and terminated.

3. Intent-driven policy is translated and enforced in each participating domain.

4. Assurance telemetry confirms the service state and SLA outcome.

Required evidence: lifecycle state history, service artifacts, policy deployment logs, and assurance records.

Failure: missing lifecycle artifact, undocumented state transition, or subjective compliance determination without evidence. 1. Align service lifecycle artifacts and state names to the selected MEF/IETF profile.

2. Update YANG/OpenAPI models and orchestration workflows.

3. Re-validate lifecycle transitions and evidence collection. Normative references:

1. MEF LSO Legato (MEF 55.1)

- Sections 2, 3, 6.2, 7.2, 7.4, 7.5, 8.1, 8.2, 8.2.2, 8.2.3, 8.2.4, 8.5, 8.7, 8.9, 9.1, 10.2, 10.3, 10.5, and Appendix A Table 4.

2. MEF LSO Presto (MEF 55.1)

- Sections 7.4, 7.5, 8.2.2, 8.2.3, 8.2.4, 8.3, 8.4, 8.5, 8.7, 8.9, 9.2, 10.2, 10.3, 10.4, 10.6, and Appendix A Table 4.

3. MEF 70.1

- Sections 6.1, 6.2, 7.1, 7.2, 7.3, 7.4, 7.6, 7.7, 7.8, 7.9, 7.10, 7.11, 7.12, 7.13, 7.14, 9, 9.6, 9.7, 9.8, 9.9, 9.10, 9.12, 10, 10.4, 11, 11.6, 12, 15, and Appendix A & B.

4. MEF 82

- Sections 2, 3, 4, 5, 6, 7, 7.1, 7.2, 7.3, 8, 8.1 - 8.4, 8.5 - 8.8, 9, 9.1, 9.2 - 9.8, 9.12, 10.1 - 10.4, and 10.5 - 10.8.

Informative references:

1. IETF service models selected by the interoperability profile 90 2b. API Mediation Layer High Unknown The SD-WAN solution MUST provide native standards-based APIs where available, including applicable MEF LSO APIs for service lifecycle workflows and OpenAPI specifications for documented HTTP-based API contracts. Where a participating vendor does not provide a required native standards-based API, the solution MUST provide an API mediation layer as a compensating control to normalize vendor-specific APIs into the required standards-aligned interface, data model, workflow, error-handling, and security behavior. Failure to define the mediation role can lead to inconsistent architecture, one-off vendor integrations, policy mismatch, translation errors, and unclear compliance expectations. Acceptance criteria:

1. The solution inventory identifies which required APIs are native and which rely on mediation.

2. The mediation layer maps payloads to the selected standard models without losing mandatory fields.

3. Translation, normalization, protocol bridging, schema mapping, and security enforcement are validated with representative configuration and telemetry payloads.

4. Mediation failures are logged and do not silently apply incomplete changes.

Required evidence: API inventory, mapping specification, schema validation results, and failure logs.

Failure: undocumented mediation dependency, missing mandatory field, silent translation loss, or incompatible security enforcement. 1. Publish the native API versus mediation inventory.

2. Update mapping logic and mediation engine configuration.

3. Retest representative configuration, telemetry, and failure cases. Normative references:

1. Selected MEF LSO APIs (MEF 55.1)

- Sections 6.2, 7.1, 7.2, 7.4, 7.5, 7.6, 7.7, 8.7, 8.9, 9.1, 9.2, 10, and 11.

2. Slected MEF LSO (MEF 128)

- Sections 6.1 - 6.5, 7.1, 7.4, and 8.

3. Selected IETF/YANG models

- RFC 8309 Sections 3, 4, 6.1-6.4, and 7.1 - 7.4.

- RFC 7950 Sections 4.1, 4.2.2, 4.2.3, 4.2.8-4.2.10, 5.6, 5.6.2, 5.6.3, 7.5-7.8, 7.14-7.16, 7.20, and 8.

- RFC 8342 Sections 5.1-5.3, 5.3.4.

- RFC 8525 Sections 1, 2, 3, 4, 6.

- RFC 6241 Sections 1.3, 5.1, 7.1 - 7.7, 8.3 - 8.6, 9.

- RFC 8040 Sections 1.3, 2, 3.1 - 3.7, 4.3-4.7, 7, 9, 10, 12.

- RFC 8527 Sections 2, 3.1, 3.2.2.

- RFC 8639 Sections 2-3

- RFC 8641 Sections 3.1-3.11.

- RFC 8345 Sections 4.1, 4.2, 4.4.2, 4.4.10

- RFC 8346 Sections 4-7.

- RFC 9408 Sections 1, 3, 4, 5, 6.

- RFC 8529 1-3, 6.

- RFC 8530 Sections 1-3.

- RFC 8299 Sections 4-6, 8-9

- RFC 9182 Sections 4, 5, 7.2-7.6.

- RFC 8466 3-5; RFC 9291 Sections 4, 5, 7.3, 7.5, 7.6, 8.

- RFC 8519 Sections 3, 4.1

- RFC 9061 Sections 3, 3.1, 3.2, 4.1-4.4, 5.1-5.3.

4. Selected OpenAPI specifications

- Section 3, 4.1, 4.2, 4.5, 4.7, 4.8, 4.8.2, 4.9, 4.10, 4.12, 4.13, 4.14, 4.17, 4.18, 4.20, 4.23, 4.24, 4.25, 4.27, 4.30. 5, and 6.

Informative references:

5. Vendor-specific API adapters 100 2c. Interoperability Profile / Conformance Profile High Unknown The SD-WAN solution MUST publish, maintain, and implement a documented interoperability profile that identifies the mandatory protocols, YANG models, API specifications, API versions, telemetry objects, security mechanisms, supported feature sets, optional capabilities, and vendor extensions required for multi-vendor SD-WAN operation. The profile MUST define conformance requirements, version compatibility rules, supported model revisions, feature/deviation reporting, testable behaviors, and pass/fail criteria for all participating controllers, orchestrators, edge devices, gateways, and API mediation components. Failure to define a shared profile can make compliance subjective and allow products to claim interoperability while supporting different protocol versions or object sets. Acceptance criteria:

1. The profile lists mandatory and optional protocols, model revisions, API versions, telemetry objects, security profiles, and feature options.

2. Each vendor/controller advertises support for the same mandatory profile.

3. A common conformance test set is executed against each implementation.

Required evidence: published profile, vendor conformance declarations, and test results.

Failure: missing mandatory object/version, unsupported profile item, or vendor-specific exception not documented in the profile. 1. Create the interoperability profile and version it.

2. Require vendors to declare conformance to mandatory items.

3. Maintain a conformance test set aligned to the profile. Normative references:

1. Mandatory protocols and models selected by the profile Informative references:

1. Conformance test documentation

2. Vendor capability declarations 110 2d. Closed-Loop Assurance Integration High Unknown The SD-WAN orchestrator MUST support closed-loop assurance using standardized telemetry and MEF LSO assurance-aligned APIs to validate service intent, monitor service health, detect performance or policy deviations, and trigger corrective workflows across vendor and provider domains. Assurance inputs MUST be correlated to service, topology, policy, SLA/SLS, inventory, fault, and performance objects so that remediation actions can be executed consistently across multi-vendor SD-WAN components. Failure to address this requirement can leave service assurance reactive, manual, and inconsistent across multi-vendor deployments. Acceptance criteria:

1. The orchestrator ingests standardized telemetry inputs defined by the interoperability profile.

2. Service intent is compared against observed state and SLA metrics.

3. A simulated SLA breach triggers a documented corrective workflow, remediation recommendation, or policy update.

4. Remediation outcome is recorded and correlated to the original deviation.

Required evidence: telemetry input sample, deviation detection record, workflow trigger log, and remediation outcome.

Failure: SLA breach not detected, no workflow trigger, or no auditable correlation between event and action. 1. Map assurance telemetry to service intent and SLA classes.

2. Configure corrective workflows and approval gates.

3. Test breach detection, workflow trigger, and remediation closure. Normative references:

1. Selected MEF LSO assurance APIs where applicable

- MEF 55.1 Sections 8.2.3, 8.3, 8.4, 8.8, 8.9, 9.1, 9.2, 10.4, 10.5, 10.6

2. Mplify LSO operational APIs Informative references:

1. Closed-loop assurance workflow patterns

1. The API inventory identifies each endpoint as controller east-west, orchestrator northbound, service ordering, topology, policy, assurance, or gateway/NNI.

2. Each endpoint supports the selected authentication and authorization mechanism.

3. Service, topology, policy, and assurance payloads validate against the selected schema/model.

4. Cross-domain workflow tests use the declared API layer without manual out-of-band steps.

Required evidence: API inventory, endpoint test results, authentication/authorization logs, and schema validation output.

Failure: undefined API layer, schema mismatch, missing authorization evidence, or manual integration outside the declared API scope. 1. Publish the API layer inventory and endpoint ownership.

2. Align OpenAPI/YANG schemas with the interoperability profile.

3. Configure authentication, authorization, and mediation where needed. Normative references:

1. RESTCONF (RFC 8040)

- Sections 1.3, 1.4, 1.5, 2, 2.1 - 2.5, 3.1, 3.3, 3.3.1, 3.3.2, 3.4, 3.4.1, 3.7, 3.8, 4, 4.3 - 4.7, 4.8, 6, 7, 9, 10. and 12.

2. NETCONF (RFC 6241) where selected

- Sections 1.2, 1.3, 1.4, 2, 2.1, 2.2, 2.3, 4, 4.3, 4.5, 5.1, 5.2, 6, 7.1, 7.2, 7.5, 7.7, 8.1, 8.3, 8.4, 8.5, 8.6, 9, and Appendix A amd E.

3. OpenAPI endpoints for services, routes, topology, and gateway NNI where selected Sections 2, 2.1, 4.1, 4.5, 4.6, 4.8, 4.8.2, 4.9, 4.10, 4.12, 4.13, 4.14, 4.16, 4.17, 4.18, 4.20, 4.21, 4.22, 4.23, 4.24, 4.25, 4.27, 4.30, 5, and 6.

4. YANG model alignment

- RFC 7950 Sections 4.1, 4.2.1-4.2.3, 5.1.1, 5.3, 5.6, 5.6.2, 5.6.3, 7.17, 7.18, 7.20, and 8, 9.1.

- RFC 8407 Sections 3.4, 3.10, 4.1- 4.6.

- RFC 8199 Sections 2.1, 2.2, 3.1- 3.3.

- RFC Sections 3, 4, 6.1-6.4, 7.1 - 7.4.

- RFC 8342 Sections 5.1-5.3, 5.3.4, Appendix A.

- RFC 8525 Sections 1, 2, 3, 4, 6.

- RFC 7951 Sections 3, 4, 5, 6, 7.

- RFC 8819 Sections 1.1, 2, 3, 4, 6.

- RFC 9196 Sections 1, 2, 3, 4, 5.

- RFC 8528 Sections 3, 3.1-3.4, 6, 7, and Appendix A.

- RFC 8345 Sections 4.1, 4.2, 4.4.2, 4.4.10, 5.

5. MEF LSO APIs where selected (MEF 55.1)

- Sections 7.4, 7.5, 8.7, 8.9, 8.11, 9.2, 10.2, 10.3, 10.4, 10.5, 10.6, and 10.7.

6. MEF 128

- Sections 5, 6, 6, 6.1 - 6.5, 7 and 8.

Informative references:

1. ONUG API concepts 130 3b. Route Exchange Protocol High Unknown The SD-WAN solution MUST support a mandatory baseline inter-domain route exchange profile using standards-based BGP mechanisms, including BGP-4 for route exchange and MP-BGP where multiple address families or VPN/overlay reachability are required. Optional advanced capabilities, including topology/path information exchange using BGP-LS, tunnel attribute advertisement, and route-origin validation using RPKI architecture RFC 6480 and resource certificates RFC 6487, MUST be identified separately in the interoperability profile with supported address families, attributes, validation behavior, and policy constraints Failure to distinguish baseline and advanced route exchange can cause fragmented overlays, routing loops, outages, limited scalability, and inconsistent claims of interoperability. Acceptance criteria:

1. The baseline profile exchanges required reachability and route segmentation information between domains.

2. Secure route-exchange sessions establish successfully and recover after failure.

3. Optional advanced attributes, including tunnel parameters or application-aware path metrics, are negotiated and tested only when declared supported.

4. Route-origin validation is performed according to the selected RPKI policy.

Required evidence: baseline route table, secure session logs, failover/recovery results, optional attribute negotiation results, and RPKI validation result.

Failure: baseline route exchange fails, optional attributes are treated as mandatory without declaration, or invalid route-origin information is accepted contrary to policy. 1. Define baseline versus optional route-exchange capabilities in the interoperability profile.

2. Correct attribute mapping and re-establish secure sessions.

3. Configure route-origin validation and redundancy behavior.

4. Deploy protocol adapters only for declared normalization gaps. Normative references:

1. BGP and selected BGP extensions

- RFC 4271 Sections 1.1, 3, 3.1, 4.2, 4.3, 4.4, 4.5, 5, 5.1, 6, 9. 9.1, and 9.2.

- RFC 4760 Sections 3, 5, 6, and 8.

- RFC 4364 Sections 3, 3.1 - 3.3, 4, 4.1, 4.3, 4.3.1, 4.3.2, 4.3.5.

- RFC 7432 Section 4, 7, 7.1 - 7.4, 7.9, 7.10, 9, 11, 13 - 17.

- RFC 9012 Sections 3.1, 3.2, 3.4, 7, 8, 9, 13.

- RFC 4456 Sections 4 - 8.

- RFC 4684 Sections 3.1, 4, 5, 6.

- RFC 7911 Sections Section 2 - 5.

- RFC 8212 Section 3

- RFC 9234 Section 3.1, 4, 4.1, 4.2, 5.

2. BGP-LS (RFC 9552)

- Sections 2, 2.1, 2.2, 3, 4, 5, 5.2, 5.2.1, 5.3, 5.3.2, 5.6, 6, 8.1.6, 8.2,5, and 10.

3. RPKI route-origin validation

- RFC 6480 Sections 2, 2.1, 2.3, 2.4, 3, 3.1, 3.2, 4, 4.3, 5, 5.1, 6, 7.3.

- RFC 6487 Sections 2, 3, 4, 4.8.6, 4.8.10, 4.8.11, 5, 7, 7.1, 7.2, 9, 10.

Informative references:

1. SD-WAN hybrid tunnel TLV concepts

2. ALTO (RFC 7285/9275) application-aware path metrics

3. PCE/PCEP and SR-PCE for centralized inter-domain path computation

4. OMP route redistribution controls for multi-vendor environments 140 3c. YANG Data Model High Unknown The SD-WAN solution MUST support the mandatory YANG modules, revisions, features, deviations, and datastore mappings defined by the SD-WAN interoperability profile for service, topology, policy, configuration, telemetry, and operational state. The solution MUST document all YANG augmentations, vendor extensions, supported revisions, version-compatibility rules, and migration behavior to ensure consistent multi-vendor interpretation and validation of SD-WAN service and policy data. Failure to define mandatory models, allowed augmentations, and version handling can cause policy translation errors, model drift, and integration overhead. Acceptance criteria:

1. Each controller/device advertises the required YANG modules and revisions through schema discovery.

2. Vendor augmentations are documented and do not change mandatory model semantics.

3. Compatibility/version handling is tested for the current and supported prior profile versions.

4. Identical service and policy intent can be deployed across domains using the mandatory model set.

Required evidence: YANG library output, module/revision list, augmentation register, version compatibility matrix, and policy deployment result.

Failure: missing mandatory module, incompatible revision, undocumented augmentation affecting required behavior, or deployment that only works with proprietary model fields. 1. Validate required YANG modules and revisions.

2. Publish allowed vendor augmentations and compatibility rules.

3. Test schema discovery and profile-version compatibility.

4. Push/pull configurations and verify operational state. Normative references:

1. ietf-sdwan-svc where selected Sections 1, 1.2, 2, 3, 4, 4.1, 4.1.1, 4.1.2, 4.2, 5, 6, 7, 8, Appendix 1 & 2.

2. RFC 8345 network topology model Sections 4, 4.1, 4.2, 4.3, 4.4.2, 4.4.3, 4.4.5, 4.4.6, 4.4.7, 4.4.8, 4.4.9, 4.4.10, 4.4.11, 5, 6.1, 6.2, 8, Appendix A.1 & A.4.

3. ietf-l3vpn-svc and ietf-l2vpn-svc where selected

- RFC 8299 Sections 4, 5, 6, 6.1, 6.2, 6.2.2, 6.5, 6.11, 6.11.7, 6.14, 6.15, 8, 9, 10, 11.

- RFC 8644 Sections 3, 3.1, 4, 5, 5.1, 5.2.1, 5.2.2, 5.2.2.1, 5.3, 5.6, 5.7, 5.10, 5.13, 5.15, 5.16, 5.17, 6, 8, 9, 10.

4. YANG library (RFC 8525)

- Sections 1.1, 2, 3, 4, 5, 6, Appendix B & C.

Informative references:

1. draft-ietf-opsawg-sdwan-uml-reqs

2. MEF 3.0 SD-WAN service attributes

3. OpenConfig YANG

4. ietf-ose-gateway-svc and ietf-ose-path-svc drafts 150 3d. Policy Translation Mechanism High Unknown The SD-WAN solution MUST provide policy translation gateways or orchestrator functions capable of mapping QoS, SLA, routing, segmentation, and security policies between vendor or provider domains using standards-based YANG policy models, routing policy models, ACL/security policy models, and Event-Condition-Action policy constructs where selected. The solution MUST maintain documented translation matrices that define source-to-target policy mappings, semantic equivalence, loss of fidelity, default handling, conflict resolution, and explicitly unsupported policy behavior. Failure to address this requirement can lead to policy drift, silent policy loss, manual translation, and compliance risk. Acceptance criteria:

1. QoS, SLA, and security policies are translated using the approved model and translation matrix.

2. Exact mappings preserve policy intent and enforcement priority.

3. Partial or unsupported mappings are rejected, flagged for approval, or handled according to a documented degradation rule.

4. No policy is silently downgraded or applied with missing mandatory attributes.

Required evidence: translation matrix, policy deployment result, unsupported-policy test, and audit log.

Failure: silent fallback, unlogged partial mapping, inconsistent enforcement, or policy drift after update. 1. Refine policy abstraction and translation logic.

2. Update mapping tables for DSCP, SLA, and security policy classes.

3. Add explicit unsupported-policy behavior and approval workflow.

4. Automate drift detection and policy reconciliation across domains. Normative references:

1. Selected YANG-based policy and ECA models

- RFC 8328 Sections 1, 3.1, 3.2, 3.3, 3.4.

- RFC 9067 Sections 3, 4, 5, 6, 7.

- RFC 8519 Sections 3,4, 5.

- RFC 7950 4.2.2, 4.2.3, 7.5.3, 7.21.5, 7.12, 7.13, 7.17, 7.18, 7.19.

- RFC 8342 Sections 5.1, 5.3.

- RFC 8525 Sections 2, 3, 4.

2. Selected DSCP/SLA mapping metrics

- RFC 2474 Section 3, 4.1, 4.2.2, 5.

- RFC 2475 Sections 2.1, 2.2, 2.4, 2.5.

- RFC 4594 Sections 1.3, 1.4, 2.1, 2.3, 3, 4, 5.3.

- RFC 5127 Sections 4.1, 5.

- RFC 2597 Sections 2, 3, 4, 6.

- RFC 3246 Sections 2.1, 2.7.

- RFC 2983 Sections 2, 3, 4, 4.1, 4.2.

- RFC 7679 Sections 3, 4, 5.

- RFC 7680 Section 2.6, 2.8.1.

- RFC 3393 Sections 2, 3, 4.

3. RESTCONF/NETCONF where selected

- RFC 6241 Sections 1.3, 1.4, 2.2, 4.3, 5.1, 5.2, 7.1, 7.2, 7.5, 7.6, 7.7, 8.18.3, Appendix E.

- RFC 8040 Sections 1.3, 1.4, 2, 3.1, 3.4, 3.4.1, 4.3, 4.7, 4.8, 6, 7, 9, 10, 12.

Informative references:

1. IETF SUPA GPIM/EPRIM concepts

2. MEF SD-WAN SLA classes

3. draft-ietf-supa-generic-policy-data-model-04 160 3e. Service Function Chaining / Service Insertion Interoperability High Unknown The SD-WAN solution MUST support interoperable service function chaining or service insertion across vendor domains using standardized service-chain constructs, APIs, and metadata where selected by the interoperability profile. Where SFC is selected, the solution MUST align with the Service Function Chaining architecture in RFC 7665 and, where packet-level SFC encapsulation is required, MUST support Network Service Header (NSH) as defined in RFC 8300 for service path identification, service index, and metadata carriage Failure to address this requirement can lead to static service chains, inconsistent service insertion, metadata loss, and vendor lock-in. Acceptance criteria:

1. A service chain or service insertion policy is created through the selected standard API/model.

2. Dynamic insertion, removal, and reordering complete across vendor domains.

3. NSH, SRv6, or selected metadata is preserved end to end where selected.

4. Service path integrity is verified after path or policy change.

Required evidence: service chain definition, insertion/removal transaction logs, metadata validation, and path integrity test.

Failure: manual chain updates, metadata loss, unsupported dynamic insertion/removal, or path integrity failure. 1. Configure the selected service chaining model and API.

2. Mandate SFC/NSH/SRv6 support only where required by the profile.

3. Test dynamic insertion, removal, metadata propagation, and path integrity. Normative references:

1. Service Function Chaining architecture (RFC 7665)

- Sections 1.1, 1.2, 1.4, 2, 2., 2.2, 2.3, 2.3.1, 3, 4, 4.1, 4.2, 4.3, 4.3.1, 4.4, 4.5, 4.6, 4.7, 4.8, 4.9, 5.1, 5.2, 5.3, 5.4, 5.5, 5.6, 5.7, 5.8, 6.

2. Network Service Header (RFC 8300)

- Sections 1.1, 1.3, 1.5, 2, 2.1, 2.2, 2.3, 2.4, 2.5, 2.5.1, 3, 4, 5, 6.1, 6.2, 6.3, 6.4, 7.1, 7.2, 7.3, 8.1, 8.2.1, 9.1.

3. SRv6-based service chaining where selected

- RFC 8402 Sections 1, 2, 5, 8.2.

- RFC 8754 Sections 2, 2.1, 3.1, 3.3, 4.1, 4.3, 5, 5.1, 5.3, 5.5, 6.3.2, 6.3.3, 7.

- RFC 8986 Sections 2. 3.1, 3.3, 4, 4.1, 4.2, 4.3, 4.4, 4.12, 4.13, 4.14, 5, 8.1, 8.4.

- RF 9256 Sections 2.1, 2.2, 2.8, 2.11.6, 8, 8.6, 8.7, 9, 10, 11.

Informative references:

1. Service insertion orchestration patterns

2. draft-ietf-spring-sr-service-programming-12 170 3f. Inter-Domain Segmentation Federation High Unknown The SD-WAN solution MUST support federation of segmentation constructs across provider and vendor domains using standardized APIs and models aligned with MEF SD-WAN service attributes. The solution MUST preserve segmentation intent across boundaries, including zones, segments, virtual topologies, service endpoints, membership, permitted destination zones, policy bindings, and boundary enforcement behavior. Failure to address this requirement can cause segment identity mismatch, broken policy inheritance, or isolation failure between providers and vendors. Acceptance criteria:

1. Segment/service definitions are exchanged across domains using the selected API/model.

2. Segment identity, membership, and isolation are preserved end to end.

3. Boundary behavior is documented and tested for allowed and denied flows.

Required evidence: exchanged segment definition, membership records, boundary policy test, and isolation test.

Failure: segment identity mismatch, membership loss, or isolation breach. 1. Define segmentation federation fields and boundary rules.

2. Configure cross-domain segment exchange.

3. Validate identity, membership, and isolation end to end. Normative references:

1. MEF SD-WAN service attributes

- MEF 70.2 Sections 7.11, 7.1.12, 7.13, 8, 9.5, 9.6, 9.6.1, 9.6.2, 9.10, 9.12, 9.12.2.6, 10.4.

- MEF 82 Sections 4, 5, 7.2, 7.3, 8.1 - 8.8, 10.3, 10.4, 10.8.

- NEF 55.1 Sections 8.7, 8.9, 9.2, Appendix A Table 4.

Informative references:

1. Selected segmentation/service model

2. Selected inter-domain API model

180 3g. End-to-End SLA Semantics Normalization High Unknown The SD-WAN solution MUST normalize SLA classes, path-quality thresholds, performance objectives, and assurance semantics across vendor and provider domains using standardized models aligned with MEF SD-WAN service and performance attributes. The solution MUST provide translation logic that maps vendor-specific SLA classes and path-quality policies to common MEF-aligned semantics, including latency, jitter or delay variation, packet loss, availability, bandwidth, reporting intervals, threshold behavior, and remediation triggers. Failure to address this requirement can cause vendors to enforce different meanings for the same SLA intent, leading to inconsistent assurance and remediation. Acceptance criteria:

1. SLA classes, thresholds, units, measurement windows, and remediation semantics are defined in the interoperability profile.

2. Identical SLA intent is applied across domains and maps to equivalent enforcement behavior.

3. Measurement results are comparable across vendors for the same path or service.

Required evidence: SLA mapping table, applied policy records, measurement comparison, and remediation decision log.

Failure: unit/threshold mismatch, non-equivalent enforcement, or incomparable measurements. 1. Normalize SLA class names, units, thresholds, and measurement windows.

2. Configure translation logic for vendor-specific SLA classes.

3. Test enforcement and measurement equivalence across domains. Normative references:

1. Selected MEF SD-WAN SLA class definitions where applicable

- MEF 70.2 Sections 9.7, 9.8, 9.9, 9.12, 9.12.2.9, 9.12.2.10, 11.7, 11.8, 12, 13.1, 13.2, 13.3, 13.4, 13.5, Appendix C

- MEF 82 Sections 8, 9.1, 9.12

- MEF 55.1 Sections 8.5, 8.11 Informative references:

1. Closed-loop assurance profile

2. Selected SLA and telemetry models 190 3h. Baseline Interoperability Requirement High Unknown The SD-WAN solution MUST support a documented baseline inter-domain interoperability mode that uses standards-based routing exchange and secure tunnel connectivity when advanced SD-WAN federation features are unavailable or unsupported between domains. This baseline mode MUST provide interoperable reachability, segmentation, tunnel security, policy enforcement, telemetry visibility, and failure handling using open standards and documented configuration profiles. Failure to define a baseline mode can leave multi-vendor edges unable to pass protected traffic when advanced federation features are not supported. Acceptance criteria:

1. Baseline mode is documented with mandatory routing, secure tunnel, segmentation, and operational constraints.

2. Inter-domain connectivity, route exchange, secure traffic forwarding, and failure recovery are verified.

3. Advanced federation features can be unavailable without breaking the documented baseline mode.

Required evidence: baseline mode profile, route table, secure tunnel state, protected traffic test, and failover/recovery result.

Failure: routing works but secure traffic forwarding fails, traffic passes without required protection, or baseline behavior depends on undocumented vendor features. 1. Define baseline mode in the interoperability profile.

2. Configure standard route exchange and secure tunnel connectivity.

3. Validate protected forwarding and failure recovery with advanced features disabled. Normative references:

1. Baseline route exchange profile

2. Selected secure tunnel profile

3. Selected operational state/telemetry profile Informative references:

1. Degraded/basic interoperability runbook

1. A documented vendor-neutral cloud gateway capability model exists and identifies the mandatory baseline objects and attributes for cloud gateway interoperability.

2. The model includes cloud-facing mappings for supported cloud provider constructs, including region, VPC/VNet, subnet, attachment, cloud interface, route table, security policy, and provider API objects.

3. The model includes SD-WAN-facing mappings for gateway, edge, interface, tunnel, route, policy, security, telemetry, and management/API capabilities.

4. Cloud-provider-specific and SD-WAN-vendor-specific fields are separated from the mandatory baseline and placed in documented optional extensions or namespaces.

5. MEF 70.x/70.2 terminology is used only as a provider-facing service-attribute crosswalk for applicable service-level SD-WAN attributes exposed through northbound or service-ordering interfaces.

6. The model represents topology relationships consistent with RFC 8345, including cloud gateways, SD-WAN edges, sites, links, tunnels, and termination points.

7. The model represents Layer 3 routing relationships consistent with RFC 8346, including routed links, prefixes, next hops, route tables, and gateway routing capabilities.

8. The model represents interface attributes consistent with RFC 8343, including physical/logical interfaces, tunnel interfaces, admin state, operational state, addresses, counters, and parent/child relationships.

9. Where the model is YANG-modeled, the YANG modules compile and validate under YANG 1.1 as defined in RFC 7950.

10. Supported YANG modules, revisions, features, and deviations are discoverable through YANG Library as defined in RFC 8525.

11. Where BGP tunnel signaling is used, the model exposes applicable tunnel encapsulation attributes consistent with RFC 9012. If BGP tunnel signaling is not used, the requirement is marked not applicable with rationale.

12. Where ECMP is supported, the model documents ECMP path count, hashing behavior, load-sharing constraints, failover behavior, and cloud-provider limitations.

13. The same model can be used to compare equivalent gateway capabilities across supported cloud providers and SD-WAN vendors.

14. Validation demonstrates that automation can discover, compare, and consume the normalized cloud gateway capability model without relying on vendor-native or cloud-native-only fields for baseline interoperability. 1. Vendor must publish or update the canonical cloud gateway capability model before production onboarding.

2. Vendor must add missing cloud-provider object mappings and document any provider-specific limitations or extensions.

3. Vendor must add missing SD-WAN-facing mappings for controller, edge, gateway, tunnel, route, policy, security, telemetry, or API functions.

4. Vendor must separate mandatory baseline fields from optional provider/vendor extensions and document extension behavior.

5. Vendor must revise MEF mappings so MEF terms are not treated as native controller, edge, gateway, cloud-gateway, or device API compliance requirements.

6. Vendor must correct topology mappings so nodes, links, tunnels, and termination points are represented consistently.

7. Vendor must correct Layer 3 topology mappings for routes, prefixes, next hops, routing domains, and gateway routing behavior.

8. Vendor must expose missing interface state, addressing, counters, hierarchy, or tunnel-interface attributes.

9. Vendor must correct YANG syntax, module structure, data types, augments, revisions, features, deviations, or validation errors.

10. Vendor must expose accurate YANG Library information for supported modules, revisions, features, deviations, and unsupported fields.

11. Vendor must add RFC 9012 tunnel-encapsulation mappings and tests, or document why BGP tunnel signaling is not applicable.

12. Vendor must document ECMP behavior and correct missing path-count, hashing, load-sharing, failover, or cloud-provider limitation details.

13. Vendor must normalize capability names, semantics, units, states, and supported/unsupported indicators across cloud and SD-WAN implementations.

14. Vendor must update APIs, adapters, schemas, or mediation logic so baseline automation works across supported vendors and cloud providers. Normative references:

1. MEF 70.x SD-WAN services:

- Clause Clauses 6.1, 6.2, 7.1, 7.6, 7.7, 7.8, 7.10, 7.13, 7.14, 11, 11.6, and 12

2. RFC 9012 (BGP Tunnel Encapsulation):

- Sections 2, 3.1, 3.2, 3.3, 3.4, 6, 7.1, 9, 11, and 13.

3. RFC 8345:

- Sections 4.1, 4.2, 4.3, 4.4.2, 4.4.3, 4.4.6, 4.4.9, 4.4.10, 4.4.11, 6.1, and 6.2

4. RFC 8346:

- Sections 4, 5, 6, and 7

5. RFC 8343:

- Sections 1, 2, 3, 3.1, 3.2, 3.3, 4, 5, and 7

6. RFC 7950:

- Sections 4.2.2, 4.2.3, 4.2.8, 5.6, 5.6.2, 5.6.3, 7.1, 7.5 through 7.8, 7.12, 7.13, 7.17, 7.20, 7.21.1, 8, and 9.1

7. RFC 8525:

- Sections 1, 2, 3, 4, and 6 240 4b. Policy Enforcement High Unknown All SD-WAN solutions MUST support standardized,…