TEAS Working Group T. Miyasaka Internet-Draft KDDI Intended status: Informational Y. Tochio Expires: 6 May 2027 1Finity 2 November 2026 ACTN Extensions for Inter-Operator Coordination draft-miyatoch-teas-actn-inter-operator-extension-01 Abstract This document specifies an extension to the ACTN framework (RFC 8453) that enables coordination between the MDSCs of different operators, so that they can establish and operate end-to-end TE services cooperatively while each operator keeps full control of its own network and keeps its internal details private. As its concrete realization within ACTN, the extension defines the MDSC-MDSC Interface (MMI), a symmetric peer interface between the MDSCs of different operators, in which neither MDSC has authority over the other, and which complements rather than modifies the CMI and the MPI. The extension is independent of the underlying switching technology and applies to packet, optical, and multi-layer TE networks. About This Document This note is to be removed before publishing as an RFC. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-miyatoch-teas-actn-inter- operator-extension/. Discussion of this document takes place on the TEAS Working Group mailing list (mailto:teas@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/teas/. Subscribe at https://www.ietf.org/mailman/listinfo/teas/. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Miyasaka & Tochio Expires 6 May 2027 [Page 1] Internet-Draft Inter-Operator ACTN November 2026 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 6 May 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. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Conventions and Definitions . . . . . . . . . . . . . . . . . 4 3. Usecase . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.1. Inter-operator optical connectivity . . . . . . . . . . . 5 3.2. Inter-operator IP traffic engineering . . . . . . . . . . 5 3.3. Multi-layer interconnection for AI data centers . . . . . 6 4. Gap Analysis . . . . . . . . . . . . . . . . . . . . . . . . 6 4.1. Current ACTN and related IETF work . . . . . . . . . . . 6 4.2. Resources shared at the inter-operator boundary . . . . . 8 4.2.1. Boundary links . . . . . . . . . . . . . . . . . . . 9 4.2.2. End-to-end TE path . . . . . . . . . . . . . . . . . 9 4.3. What is missing . . . . . . . . . . . . . . . . . . . . . 10 5. Framework . . . . . . . . . . . . . . . . . . . . . . . . . . 11 5.1. Policy and information exchange between operators . . . . 13 6. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 14 6.1. Requirements on MDSC for inter-operator operation . . . . 14 6.2. Requirements for Interfaces . . . . . . . . . . . . . . . 15 6.2.1. Requirements for the MMI . . . . . . . . . . . . . . 15 6.2.2. Requirements for the MPI between PNC and MDSC . . . . 15 6.2.3. Requirements for the CMI between CNC and MDSC . . . . 15 Miyasaka & Tochio Expires 6 May 2027 [Page 2] Internet-Draft Inter-Operator ACTN November 2026 7. Interface Protocols and YANG Data Models for the MPIs . . . . 16 8. Security Considerations . . . . . . . . . . . . . . . . . . . 16 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 10.1. Normative References . . . . . . . . . . . . . . . . . . 16 10.2. Informative References . . . . . . . . . . . . . . . . . 16 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 19 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 19 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 1. Introduction The Abstraction and Control of TE Networks (ACTN) framework [RFC8453] defines a three-tier hierarchy of controllers, the Customer Network Controller (CNC), the Multi-Domain Service Coordinator (MDSC), and the Provisioning Network Controllers (PNCs), connected by the CNC- MDSC Interface (CMI) and the MDSC-PNC Interface (MPI). ACTN also addresses multi-domain networks through a hierarchical arrangement in which a higher-level MDSC (MDSC-H) coordinates lower-level MDSCs (MDSC-L) by applying the MPI recursively. [RFC8453] also describes how a VN can be built from resources operated by different operators, with one operator acting as a customer of another through the CMI. A growing driver of network operation across different operators is the rapid growth of AI workloads and the data center interconnection (DCI) traffic they generate. Distributed training and inference for large-scale AI models demand high-bandwidth, low-latency, and highly reliable connectivity between data centers, which are frequently owned by data center or cloud operators that are distinct from the network operators owning the wide-area transport infrastructure between them. Satisfying this demand requires high-quality traffic- engineered paths, and increasingly end-to-end optical paths, that are established cooperatively across the data center operator's network and the networks of one or more other operators [IGF-MD-FA]. In these deployments the networks are operated by different operators, so no operator controls another and no single entity can see or manage all of the networks. Each operator owns and operates its own MDSC, and the existing ACTN mechanisms already support connectivity between their networks. What they do not specify is how independently controlled MDSCs coordinate their resource allocation decisions (e.g., the wavelength assigned to a WSON LSP, or the MPLS label or Segment Routing SID used across the inter-operator link) and keep the TE resources (see Section 2) and constraints of the end-to- end path consistent across their networks. Miyasaka & Tochio Expires 6 May 2027 [Page 3] Internet-Draft Inter-Operator ACTN November 2026 This document specifies an extension to the ACTN framework that enables coordination between the MDSCs of different operators, so that they can establish and operate end-to-end TE services cooperatively while each operator keeps full control of its own network and keeps its internal details private. As its concrete realization within ACTN, the extension defines the MDSC-MDSC Interface (MMI), a symmetric peer interface between the MDSCs of different operators. Unlike the hierarchical use of the MPI between an MDSC-H and an MDSC-L, the MMI assumes no subordination, and neither MDSC has authority over the other. The MMI complements, and does not modify, the CMI and the MPI. The extension is independent of the underlying switching technology and applies to packet, optical, and multi-layer TE networks. While the primary scenario is coordination between different operators, the same mechanism also applies within a single operator to networks that have independent control planes, for example where organizational, technological, or historical reasons prevent a single MDSC from having authority over all of them. It relates to and where possible reuses existing IETF work, including the ACTN VN model [RFC9731], the TE topology model [RFC8795], and the applicability of ACTN to packet-optical integration [I-D.ietf-teas-actn-poi-applicability] and to network slicing [I-D.ietf-teas-applicability-actn-slicing]. 2. Conventions and Definitions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. The terms CNC, MDSC, PNC, CMI, and MPI are used as defined in [RFC8453]. This document additionally uses the following terms. Operator: An independent administrative entity that owns and operates its own ACTN stack, comprising a CNC, an MDSC, and one or more PNCs. Domain: A network controlled by a single PNC, as in [RFC8453]. A domain belongs to one operator. Multi-domain: Involving multiple domains within a single operator, as in [RFC8453]. Multi-operator: Involving multiple independent operators. Inter-operator: Between independent operators. This document defines inter-operator coordination between MDSCs. Miyasaka & Tochio Expires 6 May 2027 [Page 4] Internet-Draft Inter-Operator ACTN November 2026 MMI (MDSC-MDSC Interface): The symmetric peer interface between the MDSCs of different operators, defined in this document. TE resource: A resource of a TE network that is allocated to an LSP, such as bandwidth on a TE link, a wavelength, a timeslot, or a label. The term follows the usage of [RFC7926], and the TE topology model [RFC8795] represents such resources. 3. Usecase This section presents representative cases that motivate coordination between the MDSCs of different operators. In each case the participating networks belong to different operators, and an end-to- end service has to be built across them without any operator revealing its internal network. 3.1. Inter-operator optical connectivity A customer such as an enterprise, a broadcaster, or a research network needs a high-capacity, deterministic optical circuit between two sites that are reached through different operators' optical networks. Each operator operates its own optical transport network based on WDM and OTN, and the circuit has to cross more than one of them. Where the operators' networks support it, the circuit can be realized as an end-to-end all-optical path across their optical networks, avoiding optical-electrical-optical conversion at the boundaries [IGF-MD-FA]. The operators' MDSCs coordinate to assign wavelength or spectrum at the border between their networks, to validate optical feasibility across the boundary, and to agree on the end-to-end optical budget such as OSNR and latency, while each operator exposes only its border capabilities and an abstracted view of its reachability. 3.2. Inter-operator IP traffic engineering A service such as low-latency financial connectivity, real-time media transport, or an enterprise VPN needs a traffic-engineered path that spans more than one operator's IP/MPLS network. Each operator operates its own IP/MPLS network, and inter-operator connectivity today relies on static peering with little dynamic TE coordination. The operators' MDSCs coordinate to reserve bandwidth at the inter- operator links and to compute a TE path that meets the end-to-end objective, while each operator keeps control of how the path is realized inside its own network. Miyasaka & Tochio Expires 6 May 2027 [Page 5] Internet-Draft Inter-Operator ACTN November 2026 3.3. Multi-layer interconnection for AI data centers Large-scale AI workloads, together with the power and siting constraints of large data centers, are driving operators to distribute data centers across multiple sites, which increases the traffic between them. These data centers are run by a data center or cloud operator, while the wide-area connectivity between the sites is provided by one or more network operators. The data center operator runs an IP or packet-optical network at each site, and the network operators provide the transport between the sites over OTN and optical (WDM) infrastructure, so the end-to-end service is both multi-layer and multi-operator. The data center operator's MDSC and the network operators' MDSCs coordinate to build a packet or IP connection that is carried over OTN or optical paths across those operators, agreeing on the interconnection points, the end-to-end latency and bandwidth, and the management of the shared resources, while each operator keeps its internal topology private. 4. Gap Analysis 4.1. Current ACTN and related IETF work [RFC8453] defines the ACTN reference architecture shown in Figure 1. A single MDSC sits between the customer, reached through the CMI, and one or more PNCs, reached through the MPI, and it abstracts and coordinates the domains below it. For larger networks, ACTN allows the MDSC to be arranged hierarchically, with a higher-level MDSC (MDSC-H) coordinating lower-level MDSCs (MDSC-L) over a recursive MPI. Miyasaka & Tochio Expires 6 May 2027 [Page 6] Internet-Draft Inter-Operator ACTN November 2026 +---------+ +---------+ +---------+ | CNC | | CNC | | CNC | +---------+ +---------+ +---------+ \ | / \ | / Boundary ========\==================|=====================/======= between \ | / Customer & ----------- | CMI -------------- Network Operator \ | / +---------------+ | MDSC | +---------------+ / | \ ------------ | MPI ------------- / | \ +-------+ +-------+ +-------+ | PNC | | PNC | | PNC | +-------+ +-------+ +-------+ | SBI / | / \ | / | SBI SBI / \ --------- ----- | / \ ( ) ( ) | / \ - Control - ( Phys. ) | / ----- ( Plane ) ( Net ) | / ( ) ( Physical ) ----- | / ( Phys. ) ( Network ) ----- ----- ( Net ) - - ( ) ( ) ----- ( ) ( Phys. ) ( Phys. ) --------- ( Net ) ( Net ) ----- ----- Figure 1: ACTN Base Architecture Figure 1 shows that multiple PNCs, each controlling one domain, are coordinated by a single MDSC. ACTN is defined together with, and complemented by, a number of other IETF specifications, summarized below. * Base framework and models: the ACTN framework [RFC8453] and the ACTN information model [RFC8454]. * Virtual network operations: the VN operations model [RFC9731]. * Packet-optical and optical transport: the applicability of ACTN to packet-optical integration [I-D.ietf-teas-actn-poi-applicability] and the optical transport network management model [I-D.ietf-ccamp-actn-optical-transport-mgmt]. Miyasaka & Tochio Expires 6 May 2027 [Page 7] Internet-Draft Inter-Operator ACTN November 2026 * Slicing and performance: the applicability of ACTN to network slicing [I-D.ietf-teas-applicability-actn-slicing] and ACTN PM telemetry and autonomics [I-D.ietf-teas-actn-pm-telemetry-autonomics]. 4.2. Resources shared at the inter-operator boundary Section 5.5 of [RFC8453] describes how a VN can be built from resources operated by different operators: in its Figure 10, Operator 1 obtains connectivity from Operator 2 as a customer, through a CNC that communicates with Operator 2's MDSC over the CMI, and that connectivity appears as a virtual link in Operator 1's network. This VN recursion is a valid way of connecting the networks of different operators, and this document does not replace it. It is coordination through a customer-provider relationship, and it leaves to the provider everything inside its network; it does not define how the two MDSCs agree on the resources they share at their boundary, or how they validate a path that runs through both networks. Figure 2 shows such a customer-provider relationship, in which the segment of Operator B lies in the middle of the path of Operator A. Operator A (customer role) Operator B (provider role) +-------------+ | MDSC A | | +-----+ | | | CNC |----|------ CMI ------+ | +-----+ | | +-----+-------+ v | MPI +-----+-----+ +-----+-----+ | MDSC B | | PNC A | +-----+-----+ +-----+-----+ | MPI | +-----+-----+ | | PNC B | | +-----+-----+ | | a1 ---- a2 ---- a3 =[AP]= b1 ---- b2 ---- b3 =[AP]= a4 ---- a5 ^ ^ | | +------------+------------+ | boundary links: TE resource agreed by A and B <--------------------------------------------------------> end-to-end path: resource continuity and constraints hold end-to-end Figure 2: Inter-operator connectivity through the CMI Miyasaka & Tochio Expires 6 May 2027 [Page 8] Internet-Draft Inter-Operator ACTN November 2026 The two networks are connected by two boundary links, between a3 and b1 and between b3 and a4; Operator A controls one end of each (a3 and a4) and Operator B the other (b1 and b3). Coordination between the operators is needed at two levels: at these boundary links, and along the end-to-end path from a1 to a5. 4.2.1. Boundary links On each boundary link, the two ends have to agree on the TE resource used for the LSP, such as the wavelength of a WSON LSP or the MPLS label or SR SID of a packet LSP. Existing mechanisms cover part of this. The TE topology model [RFC8795] represents the boundary links and, in its Section 4.3, correlates the links of topologies supplied by independent providers. Inter-domain MPLS and GMPLS signaling [RFC5151] agrees on the label between the two ends of a boundary link, where a control plane runs across it. On the other hand, this document considers deployments in which no signaling protocol (e.g., RSVP-TE) runs across the boundary links between operators. This is a deployment assumption, not a restriction of ACTN, which allows a control plane inside each domain. In such a deployment, the agreement has to be carried over an interface between the two operators, and the CMI is the only ACTN interface that crosses the boundary. However, the models currently defined for the CMI do not specify it: the AP only identifies the access link, and the VN model [RFC9731] has no attribute for the label or the wavelength used on it. What is missing, therefore, is a procedure by which the two MDSCs agree on the TE resource of each boundary link and configure the two ends consistently, for example how the label that b1 assigns for the LSP is communicated to the operator of a3 and applied there. This is coordination at the level of resources, beyond identifying the access link in a service request. 4.2.2. End-to-end TE path Along the end-to-end path from a1 to a5, some TE resources have to be the same on every link, such as the frequency slot [RFC7698] of an optical path without wavelength conversion, and constraints have to be checked over all the links, such as the end-to-end latency and the optical signal quality. Neither can be settled from one segment alone: a slot chosen on a1 to a3 has to be free on b1 to b3 and on a4 to a5 as well. Miyasaka & Tochio Expires 6 May 2027 [Page 9] Internet-Draft Inter-Operator ACTN November 2026 Here too, existing mechanisms cover part of this. BRPC [RFC5441] computes a path across several domains without disclosing their internal topology, and the PCEP extensions for WSON [RFC8780] compute the wavelength assignment, including wavelength continuity, within one PCE, leaving optical impairments outside its scope. This document does not replace these mechanisms. However, they do not specify what happens after the path has been computed, when Operator A and Operator B each allocate the resources of their own segments without a common MDSC above them: * how the two MDSCs check that the resources chosen for their segments are continuous where the technology requires it (e.g., the same frequency slot on every segment) and that the constraints of the end-to-end path are met (e.g., the end-to-end latency and the signal quality), once both have chosen the resources of their own segments; * how a later change on one side (e.g., a reroute) is reported to the other side and re-checked. Alternatively, Operator A could request a particular frequency slot from Operator B as part of the service request. Unless the service request also lets the two operators exchange candidate slots and re- validate the path, A would choose the slot without knowing which slots are free on b1 to b3 or how much signal degradation that segment adds, and a slot that B cannot provide, or a later change on either side, would start the request over. Closing these gaps requires coordination at the level of resources between the MDSCs that control the segments of the path, both when the resources are first allocated and when a change on one side affects the end-to-end path. Such coordination complements the service request and the path computation, and leaves each MDSC in control of its own resources. The MMI introduced in the following sections is the interface for it; this document does not assert that the same functions could not be added to the CMI. In summary, neither [RFC8453] nor the mechanisms above specifies these procedures for the deployments considered here; they are the subject of this document. 4.3. What is missing None of the work above defines coordination between the MDSCs of different operators as peers, in particular for the TE resources at the boundary links and for the resources and constraints of the end- to-end path. The specific gaps are the following. Miyasaka & Tochio Expires 6 May 2027 [Page 10] Internet-Draft Inter-Operator ACTN November 2026 * No peer relationship between MDSCs. ACTN covers coordination across multiple domains and layers under one MDSC, and connectivity between operators through the customer-provider relationship of Section 5.5 of [RFC8453], but it does not define how the MDSCs of different operators coordinate as peers, where neither has authority over the other. This is the core gap, and the points below are consequences of it. * Information disclosure between peers. Existing TE abstraction and information exchange mechanisms, including the abstraction levels of [RFC8795], support policy-controlled disclosure. Their application to the coordination of shared TE services between peer MDSCs, that is, what each operator discloses to the other (e.g., only the free frequency slots on its boundary links, or its whole abstract topology), requires further analysis; it is a choice separate from how much the two operators coordinate. * No coordinated provisioning or assurance across operators. Existing mechanisms support path computation, provisioning, and monitoring within and across domains. What remains unspecified is the coordination between independently controlled MDSCs of the resource allocation (Section 4.2), of service changes, of the handling of a failure in one segment, and of the isolation of an end-to-end fault across the operator boundary. * Service orchestration has a different scope. Inter-operator service orchestration is already defined outside the IETF, for example the MEF (now Mplify) LSO architecture [MEF55.1], which provides inter-provider service orchestration and operational interactions, including ordering, service changes, and assurance. This document focuses on the coordination of TE constraints and resource decisions between ACTN MDSCs. The relationship between the two requires further analysis. The first gap, the missing peer interface between MDSCs, is the foundation for the others, and it is the focus of the extension defined in this document. The control-layer coordination defined here is complementary to service-layer orchestration such as MEF LSO, which can build on top of it. 5. Framework This document extends the ACTN architecture so that the MDSCs of different operators can coordinate directly as peers. Each operator keeps its own ACTN stack, namely a CNC, an MDSC, and one or more PNCs, unchanged. The extension adds the MMI between the MDSCs of different operators, as shown in Figure 3. Miyasaka & Tochio Expires 6 May 2027 [Page 11] Internet-Draft Inter-Operator ACTN November 2026 +---------+ +---------+ | CNC | | CNC | +---------+ +---------+ | | | | Boundary =====|==================|=============== between | | Customer & | CMI | Network | | Operator | | +------------+ MMI +------------+ | MDSC |-------| MDSC | +------------+ +------------+ | | | | MPI | MPI | | | | +-------+ +-------+ +-------+ | PNC | | PNC | | PNC | +-------+ +-------+ +-------+ | SBI / | | | / | SBI | --------- ----- | ----- ( ) ( ) | ( ) - Control - ( Phys. ) | ( Phys. ) ( Plane ) ( Net ) | ( Net ) ( Physical ) ----- | ----- ( Network ) ----- - - ( ) ( ) ( Phys. ) --------- ( Net ) ----- Figure 3: ACTN architecture extended for inter-operator operation In the figure, each operator runs its own MDSC over its own PNCs and serves its own customers through the CMI, exactly as in [RFC8453]. The new element is the MMI between the two MDSCs, which connects the operators as peers rather than placing one above the other. The MMI differs from the hierarchical use of the MPI between an MDSC-H and an MDSC-L in the following ways. * Symmetry. Both MDSCs have the same role, and either one can initiate a request, so there is no parent and no child. * No authority across the boundary. Neither MDSC can provision, change, or release resources in the other operator's network, and every action across the boundary follows from mutual agreement. Miyasaka & Tochio Expires 6 May 2027 [Page 12] Internet-Draft Inter-Operator ACTN November 2026 * Policy-governed disclosure. Each operator decides what topology and resource information it exposes to the peer, subject to negotiation between the two operators. Depending on the deployment and on the mechanisms reused (e.g., BRPC for path computation), the MMI may support some or all of the following interactions [IGF-MD-FA]: * Exchange of abstracted topology and resource information, at a level of detail each operator agrees to disclose. * Cooperative establishment of end-to-end services, including agreement on the interconnection points and on the per-domain segments. * Coordinated provisioning of the per-domain segments that make up an end-to-end service. * Exchange of performance-monitoring information for the shared services, supporting end-to-end assurance. Within each operator, the CMI and the MPI between the MDSC and its PNCs continue to work as defined in [RFC8453], and the extension does not change them. The functions carried over the MMI, and the information it exchanges, are described in Section 6. 5.1. Policy and information exchange between operators Because the MMI operates across administrative boundaries, the two operators first agree, bilaterally, on what information they exchange and under which policy. This document considers the bilateral case; how information is propagated or aggregated across three or more operators is left for a future revision. This agreement covers the level of topology and resource abstraction each side discloses, the categories of information shared, the meaning of that information (e.g., whether a resource reported as available is unused, allocatable, or validated as usable), and how often it is updated. Depending on the deployment, the MMI may support interactions beyond per-service connection requests, including the exchange of abstracted topology and resource information, cooperative path computation, coordinated provisioning, and end-to-end assurance. This document describes these interactions at a high level; the detailed agreement mechanism and the MDSC-to-MDSC workflow are left for a future revision. Miyasaka & Tochio Expires 6 May 2027 [Page 13] Internet-Draft Inter-Operator ACTN November 2026 6. Requirements 6.1. Requirements on MDSC for inter-operator operation in section 3.2 of [RFC8453], multi-domain coordination and virtualization/abstraction are defined as the functions in MDSC. The Multi-domain means the domains that MDSC operates via PNCs and the coordination means that among MDSC and PNCs. Multi-domain operation is supported with the coordination and virtualization/ abstraction. In inter-operator operation, each operator is responsible for providing an end-to-end service in coordination with other operators. Each operator is not required to expose the detail of internal topology, network resources and network elements to other operators, but is required to address the minimum information to provide an end- to-end path. So MDSC SHOULD have capability for creating and address the network information minimum enough to communicate with other MDSC(s) . Therefore, the requirements on MDSC for inter-operator operation are as below. * MDSC SHOULD request to other MDSCs to create an end-to-end path per request from CNC connected to the MDSC. * MDSC SHOULD have the capability of path calculation, path provisioning, and path management (e.g., fault management, performance management) in the domain MDSC controls and manages. The attributes of the path SHOULD be advertised to other MDSC(s) to create the end-to-end path. * MDSC SHOULD have the capability of managing the network resource information addressed from other domains to create the path in the domain, with coordination of the request of an end-to-end path. * MDSC SHOULD address the network resource information and network status information, e.g., performance monitoring and fault notification, to other MDSCs. * The network information addressed to other MDSCs SHOULD be abstracted and minimized to what is needed for provisioning and maintaining the end-to-end service path as requested from CNC. Miyasaka & Tochio Expires 6 May 2027 [Page 14] Internet-Draft Inter-Operator ACTN November 2026 * The status information SHOULD be associated with the TE resource it refers to (e.g., the signal quality measured on a wavelength, or a fault on a link), so that the other MDSC can tell whether an advertised resource is usable for the end-to-end path. * MDSC SHOULD address the network resource information immediately when it is changed and impacts on the management of end-to-end service path. The information SHOULD carry an indication of its validity (e.g., the time of the last update), so that the other MDSC can tell whether the information it holds is still current. * MDSC MAY request other MDSCs for their network status information regarding the end-to-end service path. For the request, MDSC SHOULD reply in the scope of agreement between them. * MDSC SHOULD NOT directly manage PNCs that belong to another operator; those PNCs are managed by that operator's own MDSC. A PNC SHOULD be managed by an MDSC of the same operator and SHOULD NOT be managed by an MDSC of another operator. * Before allocating resources for a shared end-to-end path, MDSC SHOULD confirm with the other MDSC that the TE resources at the two ends of the inter-operator link match (e.g., the same wavelength, or the agreed label). * MDSC SHOULD provide the other MDSC with the information needed to validate the resources and constraints of the end-to-end path (e.g., whether a frequency slot is free on its segment, the latency of its segment, or the signal quality of its segment), without disclosing its internal topology. * ((Requirements on the relationship between MDSC and CNC will be added)) 6.2. Requirements for Interfaces 6.2.1. Requirements for the MMI * to be added if needed. 6.2.2. Requirements for the MPI between PNC and MDSC * to be added if needed. 6.2.3. Requirements for the CMI between CNC and MDSC * to be added if needed. Miyasaka & Tochio Expires 6 May 2027 [Page 15] Internet-Draft Inter-Operator ACTN November 2026 7. Interface Protocols and YANG Data Models for the MPIs * to be considered... 8. Security Considerations The MMI crosses the boundary between two administrative entities, and every interaction over it is subject to the trust relationship between the two operators. The security considerations of [RFC8453] apply. In addition, the MDSCs have to authenticate each other and authorize each other's requests according to the agreement between the operators; the information disclosed over the MMI is limited by that agreement; and an MDSC has to protect itself against requests from a misbehaving or compromised peer that would exhaust its resources, for example by reserving wavelengths or bandwidth that are never used. A more detailed treatment is left for a future revision. 9. IANA Considerations This document has no IANA actions. 10. References 10.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8453] Ceccarelli, D., Ed. and Y. Lee, Ed., "Framework for Abstraction and Control of TE Networks (ACTN)", RFC 8453, DOI 10.17487/RFC8453, August 2018, . 10.2. Informative References Miyasaka & Tochio Expires 6 May 2027 [Page 16] Internet-Draft Inter-Operator ACTN November 2026 [I-D.ietf-ccamp-actn-optical-transport-mgmt] Tan, XingZhao, Yu, C., King, D., and A. Farrel, "Integrating YANG Configuration and Management into an Abstraction and Control of TE Networks (ACTN) System for Optical Networks", Work in Progress, Internet-Draft, draft-ietf-ccamp-actn-optical-transport-mgmt-06, 22 October 2026, . [I-D.ietf-teas-actn-pm-telemetry-autonomics] Dhody, D., King, D., Vilalta, R., Busi, I., and D. Ceccarelli, "YANG models for Virtual Network (VN)/TE Performance Monitoring Telemetry and Scaling Intent Autonomics", Work in Progress, Internet-Draft, draft-ietf- teas-actn-pm-telemetry-autonomics-19, 8 October 2026, . [I-D.ietf-teas-actn-poi-applicability] Peruzzini, F., Bouquier, J., Busi, I., King, D., and D. Ceccarelli, "Applicability of Abstraction and Control of Traffic Engineered Networks (ACTN) to Packet Optical Integration (POI)", Work in Progress, Internet-Draft, draft-ietf-teas-actn-poi-applicability-21, 30 October 2026, . [I-D.ietf-teas-applicability-actn-slicing] King, D., Drake, J., Zheng, H., and A. Farrel, "Applicability of Abstraction and Control of Traffic Engineered Networks (ACTN) to IETF Network Slicing", Work in Progress, Internet-Draft, draft-ietf-teas- applicability-actn-slicing-10, 28 August 2024, . [IGF-MD-FA] IOWN Global Forum, "Functional Architecture for Multi- domain IOWN Networking", March 2025, . [MEF55.1] MEF Forum, "Lifecycle Service Orchestration (LSO): Reference Architecture and Framework", MEF 55.1, February 2021. Miyasaka & Tochio Expires 6 May 2027 [Page 17] Internet-Draft Inter-Operator ACTN November 2026 [RFC5151] Farrel, A., Ed., Ayyangar, A., and JP. Vasseur, "Inter- Domain MPLS and GMPLS Traffic Engineering -- Resource Reservation Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC 5151, DOI 10.17487/RFC5151, February 2008, . [RFC5441] Vasseur, JP., Ed., Zhang, R., Bitar, N., and JL. Le Roux, "A Backward-Recursive PCE-Based Computation (BRPC) Procedure to Compute Shortest Constrained Inter-Domain Traffic Engineering Label Switched Paths", RFC 5441, DOI 10.17487/RFC5441, April 2009, . [RFC7698] Gonzalez de Dios, O., Ed., Casellas, R., Ed., Zhang, F., Fu, X., Ceccarelli, D., and I. Hussain, "Framework and Requirements for GMPLS-Based Control of Flexi-Grid Dense Wavelength Division Multiplexing (DWDM) Networks", RFC 7698, DOI 10.17487/RFC7698, November 2015, . [RFC7926] Farrel, A., Ed., Drake, J., Bitar, N., Swallow, G., Ceccarelli, D., and X. Zhang, "Problem Statement and Architecture for Information Exchange between Interconnected Traffic-Engineered Networks", BCP 206, RFC 7926, DOI 10.17487/RFC7926, July 2016, . [RFC8454] Lee, Y., Belotti, S., Dhody, D., Ceccarelli, D., and B. Yoon, "Information Model for Abstraction and Control of TE Networks (ACTN)", RFC 8454, DOI 10.17487/RFC8454, September 2018, . [RFC8780] Lee, Y., Ed. and R. Casellas, Ed., "The Path Computation Element Communication Protocol (PCEP) Extension for Wavelength Switched Optical Network (WSON) Routing and Wavelength Assignment (RWA)", RFC 8780, DOI 10.17487/RFC8780, July 2020, . [RFC8795] Liu, X., Bryskin, I., Beeram, V., Saad, T., Shah, H., and O. Gonzalez de Dios, "YANG Data Model for Traffic Engineering (TE) Topologies", RFC 8795, DOI 10.17487/RFC8795, August 2020, . Miyasaka & Tochio Expires 6 May 2027 [Page 18] Internet-Draft Inter-Operator ACTN November 2026 [RFC9731] Lee, Y., Ed., Dhody, D., Ed., Ceccarelli, D., Bryskin, I., and B. Yoon, "A YANG Data Model for Virtual Network (VN) Operations", RFC 9731, DOI 10.17487/RFC9731, March 2025, . Acknowledgments The authors would like to thank Deborah Brungard, Italo Busi, Daniele Ceccarelli, Dhruv Dhody, Shunsuke Homma, Daniel King, and Roberto Manzotti for their reviews and comments on this document. Contributors Reiko Kuroiwa 1Finity Japan Email: kuroiwa.reiko@fujitsu.com Authors' Addresses Takuya Miyasaka KDDI Japan Email: ta-miyasaka@kddi.com Yuji Tochio 1Finity Japan Email: tochio@fujitsu.com Miyasaka & Tochio Expires 6 May 2027 [Page 19]