ACTN Extensions for Inter-Operator Coordination
draft-miyatoch-teas-actn-inter-operator-extension-00
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Authors | Takuya Miyasaka , Yuji Tochio | ||
| Last updated | 2026-07-06 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-miyatoch-teas-actn-inter-operator-extension-00
TEAS Working Group T. Miyasaka
Internet-Draft KDDI
Intended status: Informational Y. Tochio
Expires: 7 January 2027 1Finity
6 July 2026
ACTN Extensions for Inter-Operator Coordination
draft-miyatoch-teas-actn-inter-operator-extension-00
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 7 January 2027 [Page 1]
Internet-Draft Inter-Operator ACTN July 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 7 January 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 . . . . . 5
4. Gap Analysis . . . . . . . . . . . . . . . . . . . . . . . . 6
4.1. Current ACTN and related IETF work . . . . . . . . . . . 6
4.2. What is missing . . . . . . . . . . . . . . . . . . . . . 8
5. Framework . . . . . . . . . . . . . . . . . . . . . . . . . . 9
5.1. Policy and information exchange between operators . . . . 10
6. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 11
6.1. Requirements on MDSC for inter-operator operation . . . . 11
6.2. Requirements for Interfaces . . . . . . . . . . . . . . . 12
6.2.1. Requirements for the MMI . . . . . . . . . . . . . . 12
6.2.2. Requirements for MPI interface between PNC and
MDSC . . . . . . . . . . . . . . . . . . . . . . . . 12
6.2.3. Requirements for MPI interface between CNC and
MDSC . . . . . . . . . . . . . . . . . . . . . . . . 12
7. Interface Protocols and YANG Data Models for the MPIs . . . . 12
Miyasaka & Tochio Expires 7 January 2027 [Page 2]
Internet-Draft Inter-Operator ACTN July 2026
8. Security Considerations . . . . . . . . . . . . . . . . . . . 12
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
10.1. Normative References . . . . . . . . . . . . . . . . . . 13
10.2. Informative References . . . . . . . . . . . . . . . . . 13
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 14
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15
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. This arrangement assumes
that all MDSCs belong to a single administrative domain, or that the
MDSC-H holds administrative authority over every MDSC-L, and in
either case the MDSCs are owned and operated by a single operator.
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. The current ACTN framework does
not address this case, because it assumes that the MDSC is owned and
operated by a single operator and coordinates multiple domains only
under that single authority. In a multi-operator setting each
operator owns and operates its own MDSC, but ACTN defines no
interface between the MDSCs of different operators. This gap is
analyzed in detail later in this document.
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
Miyasaka & Tochio Expires 7 January 2027 [Page 3]
Internet-Draft Inter-Operator ACTN July 2026
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.
MMI (MDSC-MDSC Interface): The symmetric peer interface between the
MDSCs of different operators, defined in this document.
Miyasaka & Tochio Expires 7 January 2027 [Page 4]
Internet-Draft Inter-Operator ACTN July 2026
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.
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
Miyasaka & Tochio Expires 7 January 2027 [Page 5]
Internet-Draft Inter-Operator ACTN July 2026
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. In both the flat and the hierarchical case, the whole
controller hierarchy belongs to a single operator, or to a single
entity that has authority over every MDSC.
Miyasaka & Tochio Expires 7 January 2027 [Page 6]
Internet-Draft Inter-Operator ACTN July 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; all of them assume the single-authority model described above.
* 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 7 January 2027 [Page 7]
Internet-Draft Inter-Operator ACTN July 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. What is missing
None of the work above defines coordination between the MDSCs of
different operators. The specific gaps are the following.
* No peer relationship between MDSCs. ACTN covers control within a
single operator, including coordination across multiple domains
and layers, 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.
* Hierarchical MDSC does not fill this gap. The MDSC-H and MDSC-L
model needs a root MDSC with authority over and full visibility
into the domains below it, which different operators do not grant
to each other.
* No confidentiality-preserving information exchange. Each operator
needs to limit and negotiate how much of its topology and
resources it reveals to a peer. [RFC8795] defines abstraction
levels such as black-box and white-box views, but not a way for
two operators to negotiate this between themselves.
* No coordinated provisioning or assurance across operators. There
is no defined way for different operators to commit their per-
domain segments together and roll back together on failure, nor to
monitor an end-to-end service and isolate faults across operator
boundaries.
* Service orchestration exists, but not at the TE-control layer.
Inter-operator service orchestration is already defined outside
the IETF, for example the MEF (now Mplify) LSO architecture
[MEF55.1], whose inter-provider reference points cover business
functions such as ordering and billing and operational functions
such as service assurance. These operate at the service and
business layer and rely on an underlying network control system
for the traffic engineering itself; the MEF intra-provider control
reference point corresponds to the ACTN MPI. They do not define
how the MDSCs of different operators coordinate to exchange
abstracted TE topology, to compute an end-to-end path
cooperatively, or to provision it across the operator boundary.
Miyasaka & Tochio Expires 7 January 2027 [Page 8]
Internet-Draft Inter-Operator ACTN July 2026
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 2.
+---------+ +---------+
| 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 2: ACTN architecture extended for inter-operator operation
Miyasaka & Tochio Expires 7 January 2027 [Page 9]
Internet-Draft Inter-Operator ACTN July 2026
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.
* Policy-governed disclosure. Each operator decides what topology
and resource information it exposes to the peer, subject to
negotiation between the two operators.
At a high level, peer MDSCs use the MMI for 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 the following sections.
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 agreement covers the level of topology
and resource abstraction each side discloses, the categories of
information shared, and how often it is updated. The MMI is more
than a per-service connection request: beyond requesting an end-to-
end connection, it also carries the exchange of abstracted topology
Miyasaka & Tochio Expires 7 January 2027 [Page 10]
Internet-Draft Inter-Operator ACTN July 2026
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.
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 an end-to-end path as above mentioned.
* 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.
Miyasaka & Tochio Expires 7 January 2027 [Page 11]
Internet-Draft Inter-Operator ACTN July 2026
* MDSC SHOULD address the network resource information and network
status information, e.g., performance monitoring and fault
notification, to other MDSCs. In addressing, the network
information SHOULD be abstracted and minimized enough to
provisioning and maintaining the end-to-end service path as
requested from CNC.
* MDSC SHOULD address the network resource information immediately
when it is changed and impacts on the management of end-to-end
service path.
* 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.
* ((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 MPI interface between PNC and MDSC
* to be added if needed.
6.2.3. Requirements for MPI interface between CNC and MDSC
* to be added if needed.
7. Interface Protocols and YANG Data Models for the MPIs
* to be considered...
8. Security Considerations
TODO Security
Miyasaka & Tochio Expires 7 January 2027 [Page 12]
Internet-Draft Inter-Operator ACTN July 2026
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,
<https://www.rfc-editor.org/rfc/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.
[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,
<https://www.rfc-editor.org/rfc/rfc8453>.
10.2. Informative References
[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-05, 18 April
2026, <https://datatracker.ietf.org/doc/html/draft-ietf-
ccamp-actn-optical-transport-mgmt-05>.
[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-18, 2 February 2026,
<https://datatracker.ietf.org/doc/html/draft-ietf-teas-
actn-pm-telemetry-autonomics-18>.
Miyasaka & Tochio Expires 7 January 2027 [Page 13]
Internet-Draft Inter-Operator ACTN July 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-19, 11 June 2026,
<https://datatracker.ietf.org/doc/html/draft-ietf-teas-
actn-poi-applicability-19>.
[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,
<https://datatracker.ietf.org/doc/html/draft-ietf-teas-
applicability-actn-slicing-10>.
[IGF-MD-FA]
IOWN Glogal Forum, "Functional Architecture for Multi-
domain IOWN Networking", March 2025, <https://iowngf.org/
wp-content/uploads/2025/03/IOWN-GF-RD-MD-Functional-
Architecture-1.0.pdf>.
[MEF55.1] MEF Forum, "Lifecycle Service Orchestration (LSO):
Reference Architecture and Framework", MEF 55.1, February
2021.
[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, <https://www.rfc-editor.org/rfc/rfc8454>.
[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,
<https://www.rfc-editor.org/rfc/rfc8795>.
[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,
<https://www.rfc-editor.org/rfc/rfc9731>.
Acknowledgments
TODO acknowledge.
Miyasaka & Tochio Expires 7 January 2027 [Page 14]
Internet-Draft Inter-Operator ACTN July 2026
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 7 January 2027 [Page 15]