Applicability of Abstraction and Control of Traffic Engineered Networks (ACTN) to Packet Optical Integration (POI)

Applicability of Abstraction and Control of Traffic Engineered Networks (ACTN) to Packet Optical Integration (POI) FiberCop

fabio.peruzzini@fibercop.com

Vodafone

jeff.bouquier@vodafone.com

Huawei

italo.busi@huawei.com

Old Dog Consulting

daniel@olddog.co.uk

Cisco

daniele.ietf@gmail.com

Routing TEAS Working Group ACTN POI packet optical integration YANG DWDM This document explores the applicability of the Abstraction and Control of TE Networks (ACTN) architecture to Packet Optical Integration (POI) within the context of IP/MPLS and optical internetworking. It examines the YANG data models defined by the IETF that enable an ACTN-based deployment architecture and highlights specific scenarios pertinent to Service Providers. Existing IETF protocols and data models are identified for each multi-technology scenario (packet over optical), particularly emphasising the Multi-Domain Service Coordinator to Provisioning Network Controller Interface (MPI) within the ACTN architecture. About This Document The latest revision of this draft can be found at . Status information for this document may be found at . Discussion of this document takes place on the Traffic Engineering Architecture and Signaling Working Group mailing list (), which is archived at . Subscribe at . Source for this draft and an issue tracker can be found at .

Introduction The full automation of management and control for Service Providers' transport networks, spanning IP/MPLS, optical, and microwave technologies, is crucial to addressing customer demands for high-bandwidth applications. The Abstraction and Control of TE Networks (ACTN) architecture and interfaces enable the automation and efficient operation of complex optical and IP/MPLS networks using standardized interfaces and data models. This approach supports a broad spectrum of network services that can be requested by upper-layer applications, meeting diverse service-level requirements from a network perspective, such as physical diversity, latency, bandwidth, and topology. Packet Optical Integration (POI) represents an advanced application of traffic engineering. In wide-area networks, packet networks based on the Internet Protocol (IP), often augmented with Multiprotocol Label Switching (MPLS) or Segment Routing (SR), are typically implemented over an optical transport network utilizing Dense Wavelength Division Multiplexing (DWDM), occasionally with an optional Optical Transport Network (OTN) layer. There are significant technical differences between the packet and optical technologies (e.g., routers versus optical switches) and their associated network engineering and planning approaches (e.g., inter-domain peering optimization in IP networks versus managing physical impairments in DWDM systems or operating on vastly different time scales). Additionally, customer requirements often differ between packet and optical networks, and it is common for Service Providers to use different vendors for each domain. As a result, the operation of these complex packet and optical networks is often siloed, as each technology domain requires specialized skill sets. As a consequence, in many existing network deployments, packet and optical networks are engineered and operated independently. This separation is inefficient for several reasons. Firstly, integrating packet and optical networks can significantly reduce capital expenditures (CAPEX) and operational expenditures (OPEX). Secondly, multi-technology topology insights can optimize troubleshooting (e.g., alarm correlation) and enhance network operation (e.g., coordination of maintenance events). Additionally, detailed inventory and planning information can also improve service assurance quality, such as detecting constraint violations or lack of resource diversity. Thirdly, multi-technology traffic engineering enables more efficient use of available network capacity (e.g., coordination of restoration). Furthermore, provisioning workflows can be simplified or automated across layers, facilitating capabilities such as bandwidth-on-demand and streamlined maintenance activities. The ACTN framework facilitates seamless integration of packet and optical networks across multiple technologies and vendors. This is achieved through separated Provisioning Network Controllers (PNCs) for both packet and optical domains, which hide the complexities of the technical differences between the packet and optical technologies while providing sufficient abstract information that allows the Multi-Domain Service Coordinator (MDSC) to provide multi-layer coordination between packet and optical networks. This document uses packet-based Traffic Engineered (TE) service examples. These are described as "TE-path" in this document. Unless otherwise stated, these TE services may be instantiated using Resource Reservation Protocol (RSVP) Traffic Engineering (TE)-based or Segment Routing Traffic Engineering (SR-TE)-based, forwarding plane mechanisms. This document assumes familiarity with the ACTN architecture defined in , the TE topology model defined in , and the basic operation of IP/MPLS and optical transport networks. This document outlines key scenarios for Packet Optical Integration (POI) from the perspective of the packet service layer and highlights the necessary coordination between packet and optical layers to enhance POI deployment and operation. These scenarios emphasize multi-domain packet networks functioning as clients of optical networks. This document analyzes the scenario in which packet networks support multi-domain TE paths. The optical networks may consist of a DWDM network, an OTN network (without a DWDM layer), or a multi-layer OTN/DWDM network. Additionally, DWDM networks can be either fixed-grid or flexible-grid. Multi-technology and multi-domain scenarios, based on the reference network described in and very relevant for Service Providers, are described in and . For each scenario, existing IETF protocols and data models, identified in and , are analyzed with a particular focus on the MPI in the ACTN architecture. For each multi-technology scenario, the document analyzes how to use the interfaces and data models of the ACTN architecture. A summary of the gaps identified in this analysis is provided in . Understanding the degree of standardization and identifying potential gaps are crucial for evaluating the feasibility of integrating packet and optical DWDM domains (with an optional OTN layer) from an end-to-end, multi-vendor service provisioning perspective.

Terminology This document uses the ACTN terminology defined in . In addition, this document uses the following terminology.

Customer service:: The end-to-end service from Customer Edge (CE) to CE.
Network service:: Per , a network service provides Connectivity between customer sites and the Internet or between customer sites across the operator's network and across the Internet. In the context of this document, a network service is enabled by Provider Edge (PE) to PE configuration, including both the network service layer (VRFs, RT import/export policies configuration) and the network transport layer (e.g., RSVP-TE Label Switched Paths (LSPs)). This includes the configuration (on the PE side) of the interface towards the CE (e.g., VLAN, IP address, routing protocol, etc.).
Technology domain:: Short for "switching technology domain", defined as "region" in , where the term "region" is applied to (GMPLS) control domains.
PNC Domain:: A portion of the network controlled by one PNC instance, where capabilities are defined by the technologies supported by both the PNC instance and its managed Network Elements (NEs).
Optical PNC (O-PNC):: A PNC controlling an optical network domain.
Packet PNC (P-PNC):: A PNC controlling a packet network domain.
Muxponder:: An optical device that aggregates multiple lower-rate client signals into a single higher-speed optical signal, combining multiplexing and transponder functionalities to maximize network efficiency.
Port:: The physical entity that transmits and receives physical signals.
Interface:: A bidirectional link interface, as defined in .
Link:: A bidirectional data link, as defined in .
Intra-domain link:: A link between two adjacent nodes that belong to the same PNC domain.
Inter-domain link:: A link between two adjacent nodes that belong to different PNC domains.
Ethernet link:: A link between two Ethernet interfaces.
Single-technology Ethernet link:: An Ethernet link between two Ethernet interfaces on physically adjacent IP routers.
Multi-technology Ethernet link:: An Ethernet link between two Ethernet interfaces on logically adjacent IP routers, supported by two cross-technology Ethernet links interconnected through an optical tunnel.
Cross-technology Ethernet link:: An Ethernet link connecting an Ethernet interface on an IP router to an Ethernet interface on a physically adjacent optical node.
Inter-domain Ethernet link:: An Ethernet link between two Ethernet interfaces on physically adjacent IP routers that belong to different P-PNC domains.
Single-technology intra-domain Ethernet link:: An Ethernet link between two Ethernet interfaces on physically adjacent IP routers that belong to the same P-PNC domain.
Multi-technology intra-domain Ethernet link:: An Ethernet link between two Ethernet interfaces on logically adjacent IP routers within the same P-PNC domain, supported by two cross-technology Ethernet links interconnected through an optical tunnel.
IP link:: A link between two IP interfaces.
Inter-domain IP link:: An IP link supported by an inter-domain Ethernet link.
Single-technology intra-domain IP link:: An IP link supported by a single-technology intra-domain Ethernet link.
Multi-technology intra-domain IP link:: An IP link supported by a multi-technology intra-domain Ethernet link.

Reference Network Architecture This document examines various deployment scenarios for Packet and Optical Integration (POI), where the ACTN hierarchy is implemented to manage a multi-technology, multi-domain network comprising two optical domains and two packet domains, as illustrated in :

Reference Network The ACTN architecture, as defined in , is utilized to manage this multi-technology, multi-domain network. In this topology, each Packet PNC (P-PNC) is responsible for controlling its respective packet domain, while each Optical PNC (O-PNC) is tasked with managing its optical domain. The packet domains controlled by the P-PNCs can represent Autonomous Systems (ASes), as defined in , or Interior Gateway Protocol (IGP) areas within the same operator network. The IP routers between the packet domains can be either AS Boundary Routers (ASBR) or Area Border Router (ABR): in this document, the generic term Border Router (BR) is used to represent either an ASBR or an ABR. The Multi-Domain Service Coordinator (MDSC) is responsible for orchestrating the entire multi-domain, multi-technology network, encompassing both packet and optical domains. A standardized interface, the Multi-Domain Service Coordinator to Provisioning Network Controller Interface (MPI), enables the MDSC to interact with various Provisioning Network Controllers (O-PNCs and P-PNCs). The MPI interface provides the MDSC with an abstracted topology, concealing technology-specific details of the network and selectively hiding topology information based on the chosen abstraction policy. The level of abstraction is determined by the configuration parameters of the P-PNC and O-PNC, such as offering potential connectivity information between any Provider Edge (PE) and Border Router (BR) within a packet network. In the reference network of , it is assumed that:

The domain boundaries of the packet and optical domains are congruent. In other words, each optical domain exclusively supports connectivity between IP routers within a single packet domain.
There are no physical links directly connecting optical domains. Inter-domain physical links exist only under the following conditions:
- between packet domains (i.e., between BRs belonging to different packet domains): these links are called inter-domain Ethernet or IP links within this document;
- between packet and optical domains (i.e., between routers and optical nodes): these links are called cross-technology Ethernet links within this document;
- between customer sites and the packet network (i.e., between CE devices and PE routers): these links are called access links within this document.
All the physical interfaces at inter-domain links are Ethernet physical interfaces.

Scenarios using coherent pluggable optical interfaces on the IP routers (e.g., 400ZR or OpenZR+) are outside the scope of this document. This exclusion is deliberate: with coherent pluggables, the IP router itself becomes a DWDM endpoint, which changes the boundary between the packet and optical domains assumed in this document (there is no cross-technology Ethernet link), and the options for controlling the pluggables (from the O-PNC or from the P-PNC) are still evolving. These scenarios are addressed by separate work in the CCAMP Working Group (see and ). This document analyzes scenarios in which all multi-technology IP links supported by the optical network are intra-domain (intra-AS/intra-area), such as PE-BR, PE-P, BR-P, and P-P IP links. Consequently, inter-domain IP links are always single-technology connections, supported by single-technology Ethernet links between physically adjacent IP routers. Therefore, if inter-domain links between optical domains exist, they would be utilized to support multi-domain optical services, which fall outside the scope of this document. As described in , in order to increase the bandwidth between two adjacent routers, multiple Ethernet links can be setup between adjacent routers using either Link Aggregation Groups (LAGs) or Equal Cost Multi-Path (ECMP) . The optical nodes within the optical domains can be either:

Wavelength Division Multiplexing (WDM) nodes, as defined in , with an integrated Reconfigurable Optical Add-Drop Multiplexer (ROADM) function with or without integrated optical transponders;
OTN nodes, with an integrated OTN cross-connect function and with or without integrated ROADM functions or optical transponders.

Multi-domain Service Coordinator (MDSC) functions The MDSC in is responsible for coordinating multiple packet and optical domains in a multi-domain, multi-technology environment. It facilitates multi-layer and multi-domain L2/L3 VPN network services as requested by the Operational Support System/Orchestration layer. From an implementation perspective, the functions associated with MDSC described in may be grouped differently.

The service-related and network-related functions are combined into a single, monolithic implementation. This implementation manages end-customer service requests received through the Customer MDSC Interface (CMI) and adapts the corresponding network models. An example of this architecture is illustrated in Figure 2 of .
An implementation may opt to separate the service-related and network-related functions into distinct functional entities, as outlined in and Section 4.2 of . In this approach, the MDSC is decomposed into a top-level Service Orchestrator, which interfaces with the customer through the Customer MDSC Interface (CMI), and a Network Orchestrator, which interfaces southbound with the PNCs. The interface between the Service Orchestrator and the Network Orchestrator is not specified in .
Another implementation may choose to split the MDSC functions into a "higher-level MDSC" (MDSC-H) and "lower-level MDSCs" (MDSC-Ls). The MDSC-H is responsible for multi-technology coordination across packet and optical domains, while the MDSC-Ls handle domain-specific coordination. Specifically, an Optical MDSC-L manages multi-domain coordination between the O-PNCs, and a Packet MDSC-L manages multi-domain coordination between the P-PNCs. This approach is illustrated, for example, in Figure 9 of .
An alternative implementation may choose to integrate the MDSC and P-PNC functions in a single entity.

In current service provider network deployments, the MDSC's Northbound Interface (NBI) typically connects to an OSS/Orchestration layer rather than a Customer Network Controller (CNC). In this scenario, the MDSC is limited to performing Network Orchestration functions, as described in (point 2 above). Consequently, the MDSC handles network service requests received from the OSS and/or Orchestration. The functionality of the OSS and/or Orchestration layer, as well as its interface with the MDSC, is typically operator-specific and falls outside the scope of this draft. Therefore, this document assumes that the OSS and/or Orchestration layer requests the MDSC to provision L2/L3 VPN network services through mechanisms not covered in this document. There are two prominent workflow cases when the MDSC multi-technology coordination is initiated:

Initiated by request from the OSS and/or Orchestration layer to setup L2/L3 VPN network services that require multi-layer/multi-domain coordination;
The MDSC initiates these workflows to perform multi-layer and multi-domain optimizations and/or maintenance activities (e.g., rerouting LSPs and their associated services when a resource, such as a fiber, is placed in maintenance mode during a maintenance window). Unlike service fulfilment, these workflows are not triggered by a network service provisioning request from the OSS or Orchestration layer.

The latter workflow cases are outside the scope of this document. This document examines use cases in which multi-layer coordination is initiated by a network service request from the OSS and/or Orchestration layer.

Multi-domain L2/L3 VPN Network Services and provide an example of a hub & spoke multi-domain L2/L3 VPN with three PEs where the hub PE (PE13) and one spoke PE (PE14) are within the same packet domain, and the other spoke PE (PE23) is within a different packet domain.

Multi-domain VPN topology example

Multi-domain VPN TE paths example There are many options to implement multi-domain L2/L3 VPNs, including:

BGP-Labeled Unicast (BGP-LU) ()
Inter-domain RSVP-TE
Inter-domain SR-TE

This document explores inter-domain TE options where the TE tunnel model, as defined in , applies at the MPI for both intra-domain and inter-domain TE configurations. The assessment of alternative options is beyond the scope of this draft. It is also assumed that:

the bandwidth of each intra-domain TE path is managed by its respective P-PNC;
technology-specific mechanisms are employed for inter-domain TE path stitching. In the case of inter-domain SR-TE, a Segment Identifier (SID) is used in Segment Routing (SR) to define a segment (a portion of the path) within a network. A binding SID, a special type of SID, acts as a reference to a precomputed SR policy or path.
each packet domain in employs technology-specific local protection mechanisms, such as Fast Reroute (FRR) for MPLS-TE or Topology Independent Loop-Free Alternate (TI-LFA) for SR-TE. These mechanisms operate with an awareness of the multi-technology TE path properties, such as the Shared Risk Link Group (SRLG) path properties defined in .

For inter-domain TE paths, it is assumed that each packet domain in and employs the same TE technology. The stitching between two domains is achieved using inter-domain TE mechanisms. In this scenario, a key function of the MDSC is to identify the multi-domain and multi-layer TE paths for carrying L2/L3 VPN traffic between PEs in different packet domains. The MDSC then relays this information to the P-PNCs to ensure that the forwarding tables of the PEs (e.g., VRF) are correctly configured, allowing the L2/L3 VPN traffic to be routed over the designated multi-domain and multi-layer TE paths. The selection of the TE path should consider both the TE requirements and the binding requirements of the L2/L3 VPN network service. In general, the binding requirements for a network service (e.g., L2/L3 VPN) depend on the service isolation requirements (e.g., as discussed in ) and can be categorized into three main cases:

The L2/L3 VPN is bound to a set of dedicated TE tunnels, which neither share resources with other services, nor compete for bandwidth with other tunnels, ensuring deterministic or predictable latency performance.
The L2/L3 VPN is bound to a set of dedicated TE tunnels, which can compete for bandwidth with other tunnels.
The L2/L3 VPN is bound to a set of TE tunnels which can be shared with other services.

For each TE path required to support the L2/L3 VPN network service, it is possible that:

A TE path that meets the TE and binding requirements already exists in the network.
An existing TE path could be modified (e.g., through bandwidth increase) to meet the TE and binding requirements:
1. The TE path characteristics can be modified only in the packet layer.
2. One or more new underlay optical tunnels need to be setup to support the requested changes of the overlay TE paths (multi-layer coordination is required).
A new TE path needs to be setup to meet the TE and binding requirements:
1. The new TE path reuses existing underlay optical tunnels;
2. One or more new underlay optical tunnels need to be setup to support the setup of the new TE path (multi-layer coordination is required).

This document examines scenarios in which a single TE path is used to carry VPN traffic between PEs. Scenarios involving multiple parallel TE paths for load-balancing VPN traffic between PEs are possible but are beyond the scope of this document.

Multi-domain and Multi-layer Path Computation When establishing a new TE path, the MDSC is responsible for coordinating the path computation across multiple layers and domains. Based on the MDSC's knowledge of the underlying network topology and configuration, there are three possible approaches for multi-layer and multi-domain path computation:

Full Summarization: In this approach, the MDSC maintains an abstracted TE topology view of all its packet and optical underlying domains. In this case, the MDSC lacks sufficient TE topology information to perform multi-layer/multi-domain path computation. It delegates the P-PNCs and O-PNCs to compute local paths within their respective domains, then uses the returned information to compute the optimal multi-domain/multi-layer path. This approach presents an issue for the P-PNC, as it lacks the ability to perform single-domain/multi-layer path computation. It cannot retrieve topology information from the O-PNCs or delegate optical path computation to the O-PNCs. A possible solution is to include a CNC function within the P-PNC to request the MDSC for multi-domain optical path computation, as shown in Figure 10 of . Another solution could involve relying on the MDSC recursive hierarchy, as defined in Section 4.1 of , where each IP and optical domain pair has a "lower-level MDSC" (MDSC-L) for multi-layer correlation, and a "higher-level MDSC" (MDSC-H) for multi-domain coordination. In this case, the MDSC-H obtains an abstract view of the underlying multi-layer domain topologies from its MDSC-L. Each MDSC-L gets the full IP domain topology from the P-PNC and an abstracted view of the optical domain topology from its O-PNC. Topology abstraction occurs at the MPIs between MDSC-L and O-PNC, as well as between MDSC-L and MDSC-H.
Partial summarization: In this approach, the MDSC has complete visibility of the TE topology of the packet network domains and an abstracted view of the TE topology of the optical network domains. The MDSC can then only perform multi-domain/single-layer path computation for the packet layer, where the path can be computed optimally for the two packet domains. The MDSC still needs to delegate the O-PNCs to perform local path computation within their domains. It uses the information from the O-PNCs and its TE topology view of the multi-domain packet layer to perform multi-layer/multi-domain path computation.
Full knowledge: In this approach, the MDSC has a complete and enough detailed view of the TE topology of all the network domains (both optical and packet). In such a case, the MDSC has all the information needed to perform multi-domain/multi-layer path computation without relying on PNCs. This approach, however, may present scalability issues. As discussed in Section 2.2 of , performing path computation for optical networks in the MDSC is particularly challenging, as optimal paths also depend on vendor-specific optical attributes, which may vary across domains if provided by different vendors.

This document examines scenarios where the MDSC adopts the partial summarization approach to enable multi-domain and multi-layer path computation. Typically, O-PNCs are responsible for optical path computation within their respective domains. When setting up a network service, they must consider connection requirements such as bandwidth, amplification, wavelength continuity, and non-linear impairments that may impact the network service path. The methods and types of path requirements and impairments, such as those detailed in , used by the O-PNC for optical path computation, are not exposed at the MPI and therefore are out of scope for this document.

IP/MPLS Domain Controller and IP router Functions Each packet domain in , corresponding to either an IGP area or an Autonomous System (AS) within the same operator network, is controlled by a packet domain controller (P-PNC). P-PNCs are responsible for establishing TE paths between any two PEs or BRs within their controlled domains, as requested by the MDSC. They also provide topology information to the MDSC to enable efficient network coordination. For example, in inter-domain SR-TE, setting up a bidirectional SR-TE path from PE13 in Domain 1 to PE23 in Domain 2, as shown in , requires the MDSC to coordinate the following actions:

P-PNC1: Push a SID list to PE13, including the Binding SID associated with the SR-TE path in Domain 2, with PE23 as the target destination (forward direction).
P-PNC2: Push a SID list to PE23, including the Binding SID associated with the SR-TE path in Domain 1, with PE13 as the target destination (reverse direction).

With reference to , P-PNCs are responsible for the following:

To expose to MDSC their respective detailed TE topology
To perform single-layer, single-domain local TE path computation, when requested by the MDSC, between two PEs (for single-domain end-to-end TE path) or between PEs and BRs (for an intra-domain TE path segment, as selected by the MDSC).
To configure the routers in their respective domain to setup a TE path;
To configure the VRF and PE-CE interfaces (Service access points) for the intra-domain and inter-domain network services requested by the MDSC.

Domain Controller & node Functions ]]> When requesting a new TE path setup, the MDSC provides the P-PNCs with the explicit path to be created or modified. In other words, the MDSC communicates the complete list of nodes involved in the path (strict mode). The P-PNC is then responsible for setting up the explicit TE path. For example:

with SR-TE, the P-PNC pushes to headend PE or BR the list of SIDs to create the explicit SR-TE path, provided by the MDSC;
with RSVP-TE, the P-PNC requests the headend PE or BR to start signaling the explicit RSVP-TE path, provided by the MDSC.

To scale in large SR-TE packet domains, the MDSC can provide the P-PNC with a loose path and per-domain TE constraints. The P-PNC can then select the complete path within its domain. In this case, the P-PNC must signal back to the MDSC which path it has chosen, allowing the MDSC to track relevant resource utilization. From the example, the TE path requested by the MDSC touches PE13 - P16 - BR12 - BR21 - PE23. P-PNC2 is aware of two paths with the same topology metric, e.g., BR21 - P24 - PE23 and BR21 - BR22 - PE23, but with different loads. It may prefer to steer traffic on the latter as it is less loaded. For the purposes of this document, it is assumed that the MDSC always provides the explicit list of all hops to the P-PNCs to set up or modify the TE path.

Optical Domain Controller and NE Functions The optical network provides underlay connectivity services to IP/MPLS networks. The packet and optical multi-layer coordination is handled by the MDSC, as shown in . The O-PNC is responsible to:

Provide the MDSC with an abstract TE topology view of its underlying optical network resources;
perform single-domain local path computation when requested by the MDSC;
Perform optical tunnel set up when requested by the MDSC.

The mechanisms used by the O-PNC to perform intra-domain topology discovery and path setup are typically vendor-specific and outside the scope of this document. Depending on the optical network type, TE topology abstraction, path computation, and path setup can be single-layer (either OTN or DWDM) or multi-layer OTN/DWDM. In the latter case, multi-layer coordination between the OTN and DWDM layers is handled by the O-PNC.

Interface Protocols and YANG Data Models for the MPIs This section describes general assumptions applicable to all MPI interfaces between each PNC (Optical or Packet) and the MDSC, to support the scenarios discussed in this document.

RESTCONF Protocol at the MPIs The RESTCONF protocol, as defined in , using the JSON representation from , is assumed to be used at these interfaces. Additionally, extensions to RESTCONF, as defined in , to comply with the Network Management Datastore Architecture (NMDA) from , are assumed to be used at these MPI and MDSC NBI interfaces.

YANG Data Models at the MPIs The data models used on these interfaces are assumed to use the YANG 1.1 Data Modeling Language, as defined in . This section describes the YANG data models applicable to the Packet and Optical MPIs. Some of these YANG data models may be optional, depending on the specific network configuration detailed in and .

Common YANG Data Models at the MPIs As required in , the "ietf-yang-library" YANG module defined in is used to allow the MDSC to discover the set of YANG modules supported by each PNC at its MPI. Both Optical and Packet PNCs can use the following common topology YANG data models at the MPI:

The Base Network Model, defined in the "ietf-network" YANG module of ;
The Base Network Topology Model, defined in the "ietf-network-topology" YANG module of , which augments the Base Network Model;
The TE Topology Model, defined in the "ietf-te-topology" YANG module of , which augments the Base Network Topology Model.

Optical and Packet PNCs can use the common TE Tunnel Model, defined in the "ietf-te" YANG module of , at the MPI. All common YANG data models are generic and augmented by technology-specific YANG modules, as described in the following sections. Both Optical and Packet PNCs can also use the Ethernet Topology Model, defined in the "ietf-eth-te-topology" YANG module of , which augments the TE Topology Model with Ethernet technology-specific information. Both Optical and Packet PNCs can use the following common notifications YANG data models at the MPI:

Dynamic Subscription to YANG Events and Datastores over RESTCONF as defined in ;
Subscription to YANG Notifications for Datastores updates as defined in .

PNCs and MDSCs comply with subscription requirements as stated in .

YANG models at the Optical MPIs The Optical PNC can use the following technology-specific topology YANG data models, which augment the generic TE Topology Model:

The Wavelength Switched Optical Network (WSON) Topology Model, defined in the "ietf-wson-topology" YANG module of ;
the Flexi-grid Topology Model, defined in the "ietf-flexi-grid-topology" YANG module of ;
the OTN Topology Model, as defined in the "ietf-otn-topology" YANG module of .

The optical PNC can use the following technology-specific tunnel YANG data models, which augments the generic TE Tunnel Model:

The WDM Tunnel Model, defined in the "ietf-wdm-tunnel" YANG module of ;
the OTN Tunnel Model, defined in the "ietf-otn-tunnel" YANG module of .

The optical PNC can use the generic Path Computation YANG RPC, defined in the "ietf-te-path-computation" YANG module of . Note that technology-specific augmentations of the generic path computation RPC for WSON, Flexi-grid, and OTN path computation RPCs have been identified as a gap. The optical PNC can use the following client signal YANG data models:

the Constant Bit Rate (CBR) Client Signal Model, defined in the "ietf-trans-client-service" YANG module of ;
the Ethernet Client Signal Model, defined in the "ietf-eth-tran-service" YANG module of .

YANG data models at the Packet MPIs The Packet PNC can use the following technology-specific topology YANG data models:

The L3 Topology Model, defined in the "ietf-l3-unicast-topology" YANG module of , which augments the Base Network Topology Model;
the Packet TE Topology Mode, defined in the "ietf-te-topology-packet" YANG module of , which augments the generic TE Topology Model;
The MPLS-TE Topology Model, defined in the "ietf-te-mpls-topology" YANG module of , which augments the TE Packet Topology Model with or without the L3 TE Topology Model, defined in "ietf-l3-te-topology" YANG module of ;
the SR Topology Model, defined in the "ietf-sr-mpls-topology" YANG module of .

The Packet PNC can use the following technology-specific tunnel YANG data models, which augments the generic TE Tunnel Model:

The MPLS-TE Tunnel Model, defined in the "ietf-te-mpls" YANG modules of ;
the SR-TE Tunnel Model which is to be defined as described in .

The packet PNC can use the following network service YANG data models:

L3VPN Network Model (L3NM), defined in the "ietf-l3vpn-ntw" YANG module of ;
L3NM TE Service Mapping, defined in the "ietf-l3nm-te-service-mapping" YANG module of ;
L2VPN Network Model (L2NM), defined in the "ietf-l2vpn-ntw" YANG module of ;
L2NM TE Service Mapping, defined in the "ietf-l2nm-te-service-mapping" YANG module of .

Path Computation Element Protocol (PCEP) examines the applicability of a Path Computation Element (PCE) and PCE Communication Protocol (PCEP) to the ACTN framework. It further describes how the PCE architecture applies to ACTN and lists the PCEP extensions needed to use PCEP as an ACTN interface. The stateful PCE , PCE-Initiation , stateful Hierarchical PCE (H-PCE) , and PCE as a central controller (PCECC) are key extensions enabling the use of PCE/PCEP for ACTN. Since PCEP supports path computation in both packet and optical networks, it is well-suited for inter-layer path computation. describes a framework for applying the PCE-based architecture to interlayer (G)MPLS traffic engineering. Furthermore, section 6.1 of outlines H-PCE applicability for inter-layer or POI. lists various PCEP extensions that apply to ACTN. It also lists the PCEP extension for the optical network and POI. Note that PCEP can be used in conjunction with the YANG data models described in the rest of this document. Depending on whether ACTN is deployed in a greenfield or brownfield, two options are possible:

The MDSC uses a single RESTCONF/YANG interface to each PNC to discover all TE information and request TE tunnels. It may perform full multi-layer path computation or delegate path computation to the underlying PNCs. This approach is desirable for operators from a multi-vendor integration perspective as it is simple. Only one type of interface (RESTCONF) is needed, using the relevant YANG data models depending on the operator use case considered. The benefits of having only one protocol for the MPI between MDSC and PNC have already been highlighted in .
The MDSC uses the RESTCONF/YANG interface towards each PNC to discover all the TE information and requests the creation of TE tunnels. However, it uses PCEP for hierarchical path computation. As opposed to Option 1, from an operator perspective, this option can add integration complexity to have two protocols instead of one unless the RESTCONF/YANG interface is added to an existing PCEP deployment (brownfield scenario).

and of this draft analyze the case where a single RESTCONF/YANG interface is deployed at the MPI (i.e., option 1 above).

Inventory, Service and Network Topology Discovery In this scenario, the MDSC needs to discover the underlying PNCs:

the network topology, at both optical and IP layers, in terms of nodes and links, including the access links, inter-domain IP links as well as cross-technology Ethernet links;
the optical tunnels supporting multi-technology intra-domain IP links;
both intra-domain and inter-domain L2/L3 VPN network services deployed within the network;
the TE paths supporting those L2/L3 VPN network services;
the hardware inventory information of IP and optical equipment.

The O-PNC and P-PNC could discover and report the hardware network inventory information of the equipment used by the different management layers. In the context of POI, the inventory information of IP and optical equipment can complement the topology views and facilitate the packet/optical multi-layer view, e.g., by providing a mapping between the lowest-level link termination points (LTPs) in the topology view and corresponding ports in the network inventory view. The MDSC could also discover the entire network inventory information of both IP and optical equipment and correlate this information with the links reported in the network topology. Reporting the entire inventory and detailed topology information of packet and optical networks to the MDSC may present scalability issues as a potential drawback, in particular for large optical networks (see also ). This document does not analyze the scalability of this approach. The characterization of the scalability constraints (e.g., the network sizes at which they arise) and the mechanisms to address them (e.g., topology abstraction, as described in , or filtering of the notification subscriptions) are identified as a gap requiring further work (see ). The scale supported by a given MDSC or PNC implementation is implementation-specific. Each PNC provides the MDSC the topology view of the domain it controls, as described in and . The MDSC uses this information to discover the complete topology view of the multi-layer multi-domain networks it controls. The MDSC should also maintain up-to-date inventory, service, and network topology databases of IP and optical layers through notifications over the MPIs from the PNCs when any network inventory, topology, or service change occurs. It should also be possible to correlate information from IP and optical layers (e.g., which port, lambda/Optical Tributary Signal (OTSi), and direction are used by a specific IP service on the WDM node). In particular, for the cross-technology Ethernet links, it is key for MDSC to automatically correlate the information from the PNC network databases about the physical ports from the routers (single link or bundle links for LAG) to client ports in the ROADM. The analysis of multi-layer fault management is outside the scope of this document. However, the discovered information should be sufficient for the MDSC to correlate optical and IP layer alarms to speed-up troubleshooting easily. Alarms and event notifications are required between MDSC and PNCs so that any network changes are reported almost in real-time to the MDSC (e.g., node or link failure). As specified in , MDSC must subscribe to specific objects from PNC YANG datastores for notifications.

Optical Topology Discovery The WSON Topology Model and the Flexi-grid Topology model can be used to report the DWDM network topology (e.g., WDM nodes and OMS links), depending on whether the DWDM optical network is based on fixed-grid or flexible-grid or a mix of fixed-grid and flexible-grid. It is worth noting that, as described in Appendix I of , a fixed-grid can also be described as a flexible grid with constraints: for example, a 50GHz fixed-grid can be described as a flexible-grid which supports only m=4 and values of n which are only multiplier of 8. As a consequence:

A flexible-grid DWDM network topology can only be reported using the Flexi-grid Topology model;
A fixed-grid DWDM network topology, can be reported using either the WSON Topology model or the Flexi-grid Topology model;
A mixed fixed and flexible grid DWDM network topology can be reported using either the Flexi-grid Topology model or both WSON and Flexi-grid topology models.

Clarifying how both WSON and Flexi-grid topology models could be used together (e.g., through multi-inheritance as described in ) has been identified as a gap. The OTN Topology Model is used to report the OTN network topology (e.g., OTN switching nodes and links), when the OTN switching layer is deployed within the optical domain. To allow the MDSC to discover the complete multi-layer and multi-domain network topology and to correlate it with the hardware inventory information, the O-PNCs report an abstract optical network topology where:

one TE node is reported for each optical node deployed within the optical network domain; and
one TE link is reported for each OMS link and, optionally, for each OTN link.

Since the MDSC delegates optical path computation to its underlay O-PNCs, the following information can be abstracted and not reported at the MPI:

the optical parameters required for optical path computation, such as those detailed in ;
the underlay Optical Transmission Section (OTS) links and In-Line Amplifiers (ILAs) of Optical Multiplex Section (OMS) links;
the physical connectivity between the optical transponders and the ROADMs.

The OTN Topology Model also reports the CBR client LTPs that terminate the cross-technology Ethernet links: one CBR client LTP is reported for each CBR or multi-function client interface on the optical nodes (see sections 4.4 and 5.1 of for the description of multi-function client interfaces). The Ethernet Topology Model reports the Ethernet client LTPs that terminate the cross-technology Ethernet links: one Ethernet client LTP is reported for each Ethernet or multi-function client interface on the optical nodes. The optical transponders and, optionally, the OTN access cards, are abstracted at MPI by the O-PNC as Trail Termination Points (TTPs), defined in , within the optical network topology. This abstraction is valid independently of the fact that optical transponders are physically integrated within the same WDM node or are physically located on a device external to the WDM node since it both cases the optical transponders and the WDM node are under the control of the same O-PNC and abstracted as a single WDM TE Node at the O-MPI. The association between the Ethernet or CBR client LTPs terminating the Ethernet cross-technology Ethernet links and the optical TTPs is reported using the Inter Layer Lock-id (ILL) identifiers, defined in . For example, with a reference to , the ILL values X and Y are used to associate the client LTPs (7-0) in NE11 and (8-0) in NE12 with the corresponding optical TTPs (7) in NE11 and (8) in NE12, respectively.

Multi-layer optical topology discovery / / +------O------+ +------O------+ / / | (7-0) | | (8-0) | / / | | | | / / | NE11 | | NE12 | / / +-------------+ +-------------+ / / Ethernet or OTN Topology (O-PNC 1) / +-----------------------------------------------------------+ +----------------------------------------------------------+ / (7) (8) / / --- --- / / +-----\ /-----+ +-----\ /-----+ / / | V | | V | / / | | | | / / | NE11 | | NE12 | / / +-------------+ +-------------+ / / Optical Topology (O-PNC 1) / +----------------------------------------------------------+ Legend: ======= O LTP --- \ / TTP V < > Inter-Layer Lock-id reported by the PNC ]]> The intra-domain optical links are discovered by O-PNCs, using mechanisms which are outside the scope of this document, and reported at the MPIs within the optical network topology. In the case of a multi-layer DWDM/OTN network domain, multi-layer intra-domain OTN links are supported by underlay WDM tunnels: this relationship is reported by the mechanisms described in .

Optical Path Discovery The WDM Tunnel Model is used to report all the WDM tunnels established within the optical network. When the OTN switching layer is deployed within the optical domain, the OTN Tunnel Model is used to report all the OTN tunnels established within the optical network. The Ethernet client signal model and the Transparent CBR client signal model are used to report all the connectivity services provided by the underlay optical tunnels between Ethernet or CBR client LTPs, depending on whether the connectivity service is frame-based or transparent. The underlay optical tunnels can be either WDM tunnels or, when the optional OTN switching layer is deployed, OTN tunnels. The WDM tunnels can be used to support either Ethernet or CBR client signals or multi-layer intra-domain OTN links. In the latter case, the hierarchical-link container, defined in , associates the underlay WDM tunnel with the supported multi-layer intra-domain OTN link, and it allows discovery of the multi-layer path supporting all the connectivity services provided by the optical network. The O-PNCs report in their operational datastores all the Ethernet and CBR client connectivities and all the optical tunnels deployed within their optical domain regardless of the mechanisms being used to set them up, such as the mechanisms described in , as well as other mechanism (e.g., static configuration), which are outside the scope of this document.

Packet Topology Discovery The L3 Topology Model is used to report the IP network topology. The L3 Topology Model, SR Topology Model, TE Topology Model and the TE Packet Topology Model are used together to report the SR-TE network topology, as described in Figure 2 of . The TE Topology Model, TE Packet Topology Model and MPLS-TE Topology Model are used together to report the MPLS-TE network topology, as described in . As described in , the relationship between the IP network topology and the MPLS-TE network topology depend on whether the two network topologies are congruent or not: in the latter case, the L3 TE Topology Model is used, together with the L3 Topology Model to provide the association between the two network topologies. To allow the MDSC to discover the complete multi-layer and multi-domain network topology and to correlate it with the hardware inventory information as well as to perform multi-domain TE path computation, the P-PNCs report the full packet network, including all the information that the MDSC requires to perform TE path computation. In particular, one TE node is reported for each IP router and one TE link is reported for each intra-domain IP link. The packet topology also reports the IP LTPs terminating the inter-domain IP links. The Ethernet Topology Model is used to report the intra-domain Ethernet links supporting the intra-domain IP links as well as the Ethernet LTPs that might terminate cross-technology Ethernet links, inter-domain Ethernet links or access links, as described in detail in and in . All the intra-domain Ethernet and IP links are discovered by the P-PNCs, using mechanisms, such as Link Layer Discovery Protocol (LLDP) , which are outside the scope of this document, and reported at the MPIs within the Ethernet or the packet network topology.

TE Path Discovery This document assumes that the discovery of existing TE paths, including their bandwidth, at the MPI is done using the generic TE tunnel YANG data model, defined in , with packet technology-specific (e.g., MPLS-TE or SR-TE) augmentations. Note that technology-specific augmentations of the generic path TE tunnel model for SR-TE path setup and discovery is outlined in section 1 of but are currently identified as a gap in . To enable MDSC to discover the full end-to-end TE path configuration, the technology-specific augmentation of the should allow the P-PNC to report the TE path within its domain (e.g., the SID list assigned to an SR-TE path). For example, considering the L3VPN in , the TE path 1 in one direction (PE13-P16-PE14) and the TE path in the reverse direction (between PE14 and PE13) should be reported by the P-PNC1 to the MDSC as TE primary and primary-reverse paths of the same TE tunnel instance. The bandwidth of these TE paths represents the bandwidth allocated by P-PNC1 to the two TE paths, which can be symmetric or asymmetric in the two directions. The P-PNCs use the TE tunnel model to report, at the MPI, all the TE paths established within their packet domain regardless of the mechanism being used to set them up; i.e., independently on whether the mechanisms described in or other means, such as static configuration, which are outside the scope of this document, are used.

Inter-domain Link Discovery In the reference network of , there are three types of inter-domain links:

Inter-domain Ethernet links supporting inter-domain IP links between two adjacent IP domains;
Cross-technology Ethernet links between an IP domain and an adjacent optical domain;
Access links between a CE device and a PE router.

All the three types of links are Ethernet links. It is worth noting that the P-PNC may not be aware whether an Ethernet interface terminates a cross-technology Ethernet link, an inter-domain Ethernet link or an access link. The TE Topology Model supports the discovery for all these types of links with no need for the P-PNC to know the type of inter-domain link. There are two possible models to report the access links between CEs and PEs: the TE Topology Model, defined in , or the Service Attachment Points (SAP) Model, defined in . Although the discovery of access links is outside the scope of this document, clarifying the relationship between these two models has been identified as a gap. The inter-domain Ethernet links and cross-technology Ethernet links are discovered by the MDSC using the plug-id attribute, as described in section 4.3 of . A more detailed description of how the plug-id can be used to discover inter-domain links is also provided in section 5.1.4 of . The plug-id attribute can also be used to discover the access-links, but the analysis of the access-link discovery is outside the scope of this document. This document considers the following two options for discovering inter-domain links:

Static configuration
LLDP automatic discovery

Other link discovery options are possible but not described in this document. As outlined in , the encoding of the plug-id namespace and the specific LLDP information reported within the plug-id value, such as the Chassis ID and Port ID mandatory TLVs, is implementation-specific and needs to be consistent across all PNCs within the network. The static configuration requires an administrative burden to configure network-wide unique identifiers, making it more viable for inter-domain Ethernet links. For cross-technology Ethernet links, the automatic discovery solution based on LLDP snooping is preferable when possible. The routers exchange standard LLDP packets as defined in , and the optical nodes snoop the LLDP packets received from the local Ethernet interface and report the extracted information, such as the Chassis ID, Port ID, and System Name TLVs, to the O-PNCs. Note that the optical nodes do not actively participate in the LLDP packet exchange and do not send any LLDP packets.

Cross-technology Ethernet link Discovery The MDSC can discover a cross-technology Ethernet link by matching the plug-id values of the two LTPs reported by adjacent O-PNC and P-PNCs. In case LLDP snooping is used, the P-PNC reports the LLDP information sent by the corresponding Ethernet interface on the IP router, while the O-PNC reports the LLDP information received by the corresponding Ethernet interface on the optical node, e.g., between LTP 5-0 on PE13 and LTP 7-0 on NE11, as shown in .

Cross-technology Ethernet link discovery Link discovered by the MDSC { } LTP Plug-id reported by the PNC ]]> As described in , the LTP terminating a cross-technology Ethernet link is reported by an O-PNC in the Ethernet topology, the OTN topology model, or both, depending on the type of corresponding physical port on the optical node. It is worth noting that the discovery of cross-technology Ethernet links is based solely on the LLDP information sent by the Ethernet interfaces of the routers and snooped by the Ethernet interfaces of the optical nodes. Therefore, the MDSC can discover these links even before optical paths, supporting overlay multi-technology IP links, are set up.

Inter-domain IP Link Discovery The MDSC can discover an inter-domain Ethernet link supporting an inter-domain IP link by matching the plug-id values of the two Ethernet LTPs reported by adjacent P-PNCs. The P-PNCs report the LLDP information being sent and received from the corresponding Ethernet interfaces, e.g., between Ethernet LTP 3-1 on BR11 and Ethernet LTP 4-1 on BR21, as shown in .

Inter-domain Ethernet and IP link discovery O(4-2) | / / | |\ / / /| | / / +-------------+| / / |+-------------+ / / | / / | / +------------------------|-+ +-------------------------+ | | Supporting LTP | | Supporting LTP | | | | +--------------|----------+ +|------------------------+ / V / / V / / +-------------+/ / / \+-------------+ / / | {1}(3-1)O<................>O(4-1){1} | / / | |\ / / /| | / / | BR11 |V(*) / / (*)V| BR21 | / / | |/ / / \| | / / | {2}(3-0)O<~~~~~~~~~~~~~~~~>O(4-0){3} | / / +-------------+ / / +-------------+ / / Eth. Topology (P-PNC 1) / / Eth. Topology (P-PNC 2) / +-------------------------+ +-------------------------+ Notes: ===== (*) Supporting LTP {1} {BR11,3,BR21,4} {2} {BR11,3} {3} {BR21,4} Legend: ======= O LTP ----> Supporting LTP <...> Link discovered by the MDSC <~~~> Link inferred by the MDSC { } LTP Plug-id reported by the PNC ]]> Different information is required to be encoded by the P-PNC within the plug-id attribute of the Ethernet LTPs to discover cross-technology Ethernet links and inter-domain Ethernet links. If the P-PNC does not know a priori whether an Ethernet interface on an IP router terminates a cross-technology Ethernet link or an inter-domain Ethernet link, it must report at the MPI two Ethernet LTPs representing the same Ethernet interface, e.g., both Ethernet LTP 3-0 and Ethernet LTP 3-1, supported by LTP 3-0, as shown in .

The physical Ethernet LTP (e.g., LTP 3-0 in BR11, as shown in ) represents the physical adjacency between the Ethernet interface on an IP router and the Ethernet interface on its physically adjacent node. This node can be either an IP router (in the case of a single-technology Ethernet link) or an optical node (in the case of a cross-technology Ethernet link). Therefore, as described in , the P-PNC reports, within the plug-id attribute of this LTP, the LLDP information sent by the corresponding Ethernet interface on the IP router, such as {BR11,3} and {BR21,4} plug-id values reported by the Ethernet LTP 3-0 on BR11 and the Ethernet LTP 4-0 on BR21, as shown in .
The logical Ethernet LTP (e.g., LTP 3-1 in BR11, as shown in ), supported by a physical Ethernet LTP (e.g., LTP 3-0 in BR11, as shown in ), is used to discover the logical adjacency between Ethernet interfaces on IP routers, which can be either single-technology or multi-technology. Therefore, the P-PNC reports, within the plug-id attribute of this LTP, the LLDP information sent and received by the corresponding Ethernet interface on the IP router, such as the {BR11,3,BR21,4} plug-id values reported by the Ethernet LTP 3-1 on BR11 and the Ethernet LTP 4-1 on BR21, as shown in .

It is worth noting that in the case of inter-domain Ethernet links, the MDSC cannot discover, using the LLDP information reported in the plug-id attributes, the physical adjacency between two Ethernet interfaces on physically adjacent IP routers, because these plug-id values do not match, such as the {BR11,3} and {BR21,4} plug-id values shown in . However, the MDSC may infer the physical intra-domain Ethernet links if it knows a priori, using mechanisms outside the scope of this document, that the Ethernet interfaces on the IP routers either terminate a cross-technology or single-technology (intra-domain or inter-domain) Ethernet link, e.g., as shown in . The P-PNC can omit to report the physical Ethernet LTPs when it knows, through mechanisms outside the scope of this document, that the corresponding Ethernet interfaces terminate inter-domain Ethernet links. The MDSC can then discover an inter-domain IP link between the two IP LTPs supported by the two Ethernet LTPs terminating an inter-domain Ethernet link, discovered as described in , e.g., between IP LTP 3-2 on BR21 and IP LTP 4-2 on BR22, supported respectively by Ethernet LTP 3-1 on BR11 and Ethernet LTP 4-1 on BR21, as shown in .

Multi-technology IP Link Discovery A multi-technology intra-domain IP link and its supporting multi-technology intra-domain Ethernet link are discovered by the P-PNC like any other intra-domain IP and Ethernet links, as described in , and reported at the MPI within the packet and the Ethernet network topologies, e.g., as shown in .

Multi-technology intra-domain Ethernet and IP link discovery O(6-2) | / / | | | | | / / +---------+ | +---------+ / / | / +-----------------------------------|-----------------------+ | | Supporting Link | +---------------------------|-------------------------------+ / Ethernet Topology (P-PNC 1)| / / +-------------+ | +-------------+ / / | PE13 | V | BR11 | / / | (5-1)O<==============>O(6-1) | / / | (5-0) |\ /| (6-0) | / / +------O------+|(*) (*)|+------O------+ / / ^ \<----+ +----->/^ / +-----------------:------------------------------:----------+ : : : : : : +---------:------------------------------:------------------+ / : Ethernet or OTN Topology : / / V (O-PNC 1) V / / +------O------+ ETH/CBR +------O------+ / / | (7-0) | client sig. | (8-0) | / / | X----------+-------------------X | / / | NE11 | | | NE12 | / / +-------------+ | +-------------+ / +----------------------------|------------------------------+ | Underlay | tunnel | +----------------------------------------------------------+ / (7) | (8) / / --- | --- / / +-----\ /-----+ v +-----\ /-----+ / / | V | | V | / / | X======|================|======X | / / | NE11 | Opt. Tunnel | NE12 | / / +-------------+ +-------------+ / / Optical Topology (O-PNC 1) / +----------------------------------------------------------+ Notes: ===== (*) Supporting LTP Legend: ======= O LTP --- \ / TTP V ----> Supporting LTP or Supporting Link or Underlay tunnel <===> Link discovered by the PNC and reported at the MPI <...> Link discovered by the MDSC x---x Ethernet/CBR client signal X===X Optical tunnel ]]> The Ethernet interface 5 on the P13 router is terminating two Ethernet abstract links:

The multi-technology intra-domain Ethernet link between logical Ethernet LTP 5-1 on PE13 and the logical Ethernet LTP 6-1 on BR11;
The cross-technology Ethernet link, which is supporting that multi-technology intra-domain Ethernet link, between the physical Ethernet LTPs 5-0 on PE13 and the physical Ethernet LTP 7-0 on the optical NE11.

The P-PNC does not report any plug-id information on the logical Ethernet LTPs terminating intra-domain Ethernet links, such as the LTP 5-1 on PE13 and LTP 6-1 in BR11 shown in , since these links are discovered by the PNC. In addition, the P-PNC also reports the physical Ethernet LTPs that terminate the cross-technology Ethernet links supporting the multi-technology intra-domain Ethernet links, e.g., the Ethernet LTP 5-0 on PE13 and the Ethernet LTP 6-0 on BR11, shown in . The MDSC discovers, using the mechanisms described in , which cross-technology Ethernet links support the multi-technology intra-domain Ethernet links, e.g., the link between LTP 5-0 on PE13 and LTP 7-0 on NE11, shown in . The MDSC also discovers, from the information provided by the O-PNC and described in , which optical tunnels support the multi-technology intra-domain IP links and therefore the path within the optical network that supports a multi-technology intra-domain IP link, e.g., as shown in .

Intra-domain single-technology IP Links It is worth noting that the P-PNC may not be aware of whether an Ethernet interface on the IP router terminates a multi-technology or a single-technology intra-domain Ethernet link. In this case, the P-PNC, always reports two Ethernet LTPs for each Ethernet interface on the IP router, e.g., the Ethernet LTP 1-0 and 1-1 on PE13, shown in .

Single-technology intra-domain Ethernet and IP link discovery O(2-2) | / / | | | | | / / +---------+ | +---------+ / / | / +---------------------------------|-------------------------+ | | Supporting Link | | +-----------------------|---------------------------------+ / | / / +---------+ v +---------+ / / | (1-1)O<======================>O(2-1) | / / | |\ /| | / / | PE13 |V(*) (*)V| P16 | / / | |/ \| | / / | {1}(1-0)O<~~~~~~~~~~~~~~~~~~~~~~>O(2-0){2} | / / +---------+ +---------+ / / Ethernet Topology (P-PNC 1) / +---------------------------------------------------------+ Notes: ===== (*) Supporting LTP {1} {PE13,1} {2} {P16,2} Legend: ======= O LTP ----> Supporting LTP <===> Link discovered by the PNC and reported at the MPI <~~~> Link inferred by the MDSC { } LTP Plug-id reported by the PNC ]]> It is worth noting that in the case of intra-domain single-technology Ethernet links, the MDSC cannot discover, using the LLDP information reported in the plug-id attributes, the physical adjacency between two Ethernet interfaces on physically adjacent IP routers, because the plug-id values do not match, such as {PE13,1} and {P16,2}, as shown in . However, the MDSC may infer the physical intra-domain Ethernet links, e.g., between LTP 1-0 on PE13 and LTP 2-0 on P16, as shown in , if it knows a priori, using mechanisms outside the scope of this document, that all Ethernet interfaces on the IP routers terminate either a cross-technology or single-technology (intra-domain or inter-domain) Ethernet link, e.g., as shown in . The P-PNC can omit reporting the physical Ethernet LTP if it knows, through mechanisms outside the scope of this document, that the intra-domain Ethernet link is single-technology.

LAG Discovery The P-PNCs can discover the configuration of LAG groups within its domain and report each intra-domain LAG as an Ethernet bundle link within the Ethernet topology exposed at the MPI. This is done by bundling multiple single-domain Ethernet links, as shown in . For example, the Ethernet bundled link between Ethernet LTP 5-1 on BR21 and Ethernet LTP 6-1 on P24 is built from the Ethernet links set up respectively:

between the Ethernet LTP 1-1 on BR21 and the Ethernet LTP 2-1 on P24; and
between the Ethernet LTP 3-1 on BR21 and the Ethernet LTP 4-1 on P24.

LAG O(6-2) | / / | | | | | / / +---------+ | +---------+ / / | / +---------------------------------|-------------------------+ | | Supporting Link | | +-----------------------|---------------------------------+ / | / / +---------+ v +---------+ / / | (5-1)O<======================>O(6-1) | / / | BR21 | Bundled Link | P24 | / / | | | | / / | (3-1)O<======================>O(4-1) | / / | (1-1)O<======================>O(2-1) | / / +---------+ +---------+ / / Ethernet Topology (P-PNC 2) / +---------------------------------------------------------+ Legend: ======= O LTP <===> Link discovered by the PNC and reported at the MPI ]]> The mechanisms used by the MDSC to discover single-technology and multi-technology intra-domain LAG links are the same, with the only difference being whether the bundled links are single-technology or multi-technology. However, the mechanisms used by the MDSC to discover single-technology inter-domain LAG links between two BRs are different and outside the scope of this document, as they do not imply cross-technology coordination between packet and optical domains. As described in , the mechanisms used by the P-PNC to discover the configuration of LAG groups within its domain, such as LLDP , are outside the scope of this document. It is worth noting that according to , LLDP can be configured on a LAG group (Aggregated Port) and/or on any number of its LAG members (Aggregation Ports). If LLDP is enabled on both LAG members and groups, two types of LLDP packets are transmitted by the routers and received by the optical nodes on some cross-technology Ethernet links: one sent for the LLDP session configured at LAG member (Aggregation Port) level and another one for the LLDP session configured at LAG group (Aggregated Port) level. This could cause some issues when LLDP snooping is used to discover the cross-technology Ethernet links, as defined in . The cross-technology Ethernet link discovery is based only on the LLDP session configured on the LAG members (Aggregation Ports) to allow discovery of these links independently from the configuration of the underlay optical tunnel or from the LAG group. To avoid any ambiguity on how the optical nodes can identify which LLDP packets belong to which LLDP session, the P-PNC can disable the LLDP sessions on the LAG groups configured by the MDSC (e.g., the multi-technology single-domain LAG groups configured using the mechanisms described in ), keeping the LLDP sessions on the LAG members enabled. Another option is to rely on other mechanisms (e.g., the Port type field in the Link Aggregation TLV defined in Annex F of ) that allow the optical node to identify which LLDP packets belong to which LLDP session: the O-PNC can then use only the LLDP information from the LLDP sessions configured on the LAG members to support the cross-technology Ethernet link discovery mechanisms defined in .

L2/L3 VPN Network Services Discovery The P-PNC reports the L2/L3 VPN services configured within its domain, using the L2NM and L3NM network service models, and which packet TE tunnels (e.g., MPLS-TE or SR-TE) are used by each L2/L3 VPN service, using the L2NM and L3NM TE service mapping models. The MDSC can use the information mentioned above together with the packet TE path, packet topology, multi-technology IP links, optical topology and optical path information discovered as described in the previous sections, to discover the multi-technology path used to carry the traffic for each L2/L3 VPN service.

Inventory Discovery There are no YANG data models in IETF that could be used to report at the MPI the whole inventory information discovered by a PNC. had foreseen some work for inventory as an augmentation of the network model, but no YANG data model has been developed so far. There are also no YANG data models in IETF that could be used to correlate topology information, e.g., a link termination point (LTP), with inventory information, e.g., the physical port supporting an LTP, if any. Inventory information through MPI and correlation with topology information is identified as a gap requiring further work and outside of the scope of this draft.

Establishment of L2/L3 VPN Services with TE Requirements In this scenario the MDSC needs to setup a multi-domain L2VPN or a multi-domain L3VPN with some SLA requirements. The MDSC receives the request to setup a L2/L3 VPN network service from the OSS/Orchestration layer (see ). The MDSC translates the L2/L3 VPN SLA requirements into TE requirements (e.g., bandwidth, TE metric bounds, SRLG disjointness, nodes/links/domains inclusion/exclusion) and find the TE paths that meet these TE requirements (see ). For example, considering the L3VPN in and , the MDSC finds that:

PE13-P16-PE14 TE path already exists but does not have enough bandwidth to support the new L3VPN, as described in , and that:
- the IP link(s) between PE13 and P16 do not have enough bandwidth to support increasing the bandwidth of that TE path, as described in ;
- a new underlay optical tunnel could be setup to increase the bandwidth of the IP link(s) between PE13 and P16 to support increasing the bandwidth of that overlay TE path, as described in . The dimensioning of the underlay optical tunnel is decided by the MDSC based on the TE requirements (e.g., the bandwidth) requested by the TE path and on its multi-layer optimization policy, which is an internal MDSC implementation issue;
a new multi-domain TE path needs to be setup between PE13 and PE23, e.g., either because existing TE paths between PE13 and PE23 are not able to meet the TE and binding requirements of the L2/L3 VPN service or because there is no TE path between PE13 and PE23.

As described in , with partial summarization, the MDSC will use the TE topology information provided by the P-PNCs and the results of the path computation requests sent to the O-PNCs, as described in , to compute the multi-layer/multi-domain path between PE13 and PE23. For example, the multi-layer/multi-domain performed by the MDSC could require the setup of:

a new underlay optical tunnel between PE13 and BR11, supporting a new IP link, as described in ;
a new underlay optical tunnel between BR21 and P24 to increase the bandwidth of the IP link(s) between BR21 and P24, as described in .

When setting up the L2/L3 VPN network service requires multi-domain and multi-layer coordination, the MDSC is also responsible for coordinating the network configuration needed to realize the requested network service across the appropriate optical and packet domains. The MDSC would therefore request:

the O-PNC1 to setup a new optical tunnel between the ROADMs connected to PE13 and P16, as described in ;
the P-PNC1 to update the configuration of the existing IP link, in case of LAG, or configure a new IP link, in case of ECMP, between PE13 and P16, as described in ;
the P-PNC1 to update the bandwidth of the selected TE path between PE13 and PE14, as described in .

After that, the MDSC requests P-PNC2 to set up a TE path between BR21 and PE23, with an explicit path (BR21, P24, PE23) to constrain the new TE path to use the underlay optical tunnel setup between BR21 and P24, as described in . The P-PNC2 properly configures the routers within its domain to set up the requested path and returns the information needed for multi-domain TE path stitching. For example, in inter-domain SR-TE, the P-PNC2, knowing the node and adjacency SIDs assigned within its domain, can install the proper SR policy or hierarchical policies within BR21 and return to the MDSC the binding SID assigned to this policy in BR21. Then the MDSC requests P-PNC1 to set up a TE path between PE13 and BR11, with an explicit path (PE13, BR11) to constrain the new TE path to use the underlay optical tunnel setup between PE13 and BR11, specifying which inter-domain link should be used to send traffic to BR21 and the information for multi-domain TE path stitching, as described in (e.g., in inter-domain SR-TE, the binding SID assigned by P-PNC2 to the corresponding SR policy in BR21). The P-PNC1 properly configures the routers within its domain to set up the requested path and the multi-domain TE path stitching. For example, in inter-domain SR-TE, the P-PNC1, knowing the node and adjacency SIDs assigned within its domain and the Peer Adjacency SID assigned by P-PNC1 to the inter-domain link between BR11 and BR21, along with the binding SID assigned by P-PNC2, installs the proper policy or policies within PE13. Once the TE paths have been selected and, if needed, set up or modified, the MDSC can request both P-PNCs to configure the L3VPN and its binding with the selected TE paths, as described in .

Optical Path Computation As described in , optical path computation is usually performed by the O-PNCs. When performing multi-layer/multi-domain path computation, the MDSC can delegate single-domain optical path computation to the O-PNC. As described in , , and , without LAG, there is a one-to-one relationship between a multi-layer intra-domain IP link and its underlay optical tunnel. Therefore, the properties of an optical path between two optical TTPs, as computed by the O-PNC, can be used by the MDSC to infer the properties of the associated multi-layer single-domain IP link. As discussed in , there are two options to request an O-PNC to perform optical path computation: either via a "compute-only" TE tunnel path, using the generic TE tunnel YANG data model defined in , or via the path computation RPC defined in . This draft assumes that the path computation RPC is used. There are no YANG data models in IETF that could be used to augment the generic path computation RPC with technology-specific attributes. Optical technology-specific augmentation for the path computation RPC is identified as a gap requiring further work outside of this draft's scope.

Multi-technology IP Link Setup As described in , there is a one-to-one relationship between a multi-technology intra-domain Ethernet link and its underlay optical tunnel. Therefore, to set up a new multi-technology intra-domain IP link, the MDSC requires the O-PNC to set up the optical tunnel (using either the WDM Tunnel model or the OTN Tunnel model, if optional OTN switching is supported) within the optical network and steer client traffic between the two cross-technology Ethernet links over that optical tunnel, using either the Ethernet Client Signal Model (for frame-based transport) or the Transparent CBR Client Signal Model (for transparent transport). For example, with reference to , the MDSC can request O-PNC1 to set up an optical tunnel between optical TTPs (7) on NE11 and (8) on NE12 and steer client traffic over this tunnel between LTP (7-0) on NE11 and LTP (8-0) on NE12.

Multi-technology IP link setup O(6-2) | / / | | | | | / / +---------+ | +---------+ / / | / +-----------------------------------|-----------------------+ | | Supporting Link | +---------------------------|-------------------------------+ / Ethernet Topology (P-PNC 1)| / / +-------------+ | +-------------+ / / | PE13 | V | BR11 | / / | (5-1)O<==============>O(6-1) | / / | (5-0) |\ /| (6-0) | / / +------O------+|(*) (*)|+------O------+ / / ^ \<----+ +----->/^ / +-----------------:------------------------------:----------+ : : : : : : +---------:------------------------------:------------------+ / : Ethernet or OTN Topology : / / V (O-PNC 1) V / / +------O------+ ETH/CBR +------O------+ / / | (7-0) | client sig. | (8-0) | / / | X----------+-------------------X | / / | NE11 | | | NE12 | / / +-------------+ | +-------------+ / +----------------------------|------------------------------+ | Underlay | tunnel | +----------------------------------------------------------+ / (7) | (8) / / --- | --- / / +-----\ /-----+ v +-----\ /-----+ / / | V | | V | / / | X======|================|======X | / / | NE11 | Opt. Tunnel | NE12 | / / +-------------+ +-------------+ / / Optical Topology (O-PNC 1) / +----------------------------------------------------------+ Notes: ===== (*) Supporting LTP Legend: ======= O LTP --- \ / TTP V ----> Supporting LTP or Supporting Link or Underlay tunnel <===> Link discovered by the PNC and reported at the MPI <...> Link discovered by the MDSC x---x Ethernet/CBR client signal X===X Optical tunnel ]]> Note: is an exact copy of . After the optical tunnel has been set up and the client traffic steering configured, the two IP routers can exchange Ethernet frames between themselves, including LLDP messages. If LLDP or any other discovery mechanisms, outside the scope of this document, are used between the adjacency of the two IP routers' ports, the P-PNC can automatically discover the underlay multi-technology single-domain Ethernet link set up by the MDSC and report it to the P-PNC, as described in . Otherwise, if no automatic discovery mechanisms are used, the MDSC can configure this multi-technology single-domain Ethernet link at the MPI of the P-PNC. The two Ethernet LTPs terminating this multi-technology single-domain Ethernet link are supported by the two underlay Ethernet LTPs terminating the two cross-technology Ethernet links, e.g., LTP 5-1 on PE13 and 6-1 on BR11, as shown in . After the multi-technology single-domain Ethernet link has been configured by the MDSC or discovered by the P-PNC, the corresponding multi-technology single-domain IP link can also be configured either by the MDSC or the P-PNC. This document assumes that the IP link is configured by the P-PNC. It is worth noting that if LAG is not supported within the domain controlled by the P-PNC, the P-PNC can configure the multi-technology single-domain IP link as soon as the underlay multi-technology single-domain Ethernet link is either discovered by the P-PNC or configured by the MDSC at the MPI. However, if LAG is supported, the P-PNC lacks enough information to determine whether the discovered or configured multi-technology single-domain Ethernet link would be:

Used to support a multi-technology single-domain IP link;
Used to create a new LAG group;
Added to an existing LAG group.

The MDSC can request the P-PNC to configure a new multi-technology single-domain IP link, supported by the just discovered or configured multi-technology single-domain Ethernet link, by creating an IP link within the running datastore of the P-PNC MPI. Only the IP link, IP LTPs, and the reference to the supporting multi-technology single-domain Ethernet link are configured by the MDSC. All other configuration is provided by the P-PNC. For example, with reference to , the MDSC can request P-PNC1 to set up a multi-technology single-domain IP link between IP LTP 5-2 on PE13 and IP LTP 6-2 on BR11, supported by the multi-technology single-domain Ethernet link between ETH LTP 5-1 on PE13 and ETH LTP 6-1 on BR11. The P-PNC configures the requested multi-technology single-domain IP link and, once finished, reports it to the MDSC within the IP topology exposed at its MPI.

Multi-technology LAG Setup The P-PNC configures a new LAG group between two routers when the MDSC creates a new Ethernet bundled link at the MPI (using the bundled-link container defined in ), bundling the multi-technology single-domain Ethernet link(s) being created, as described above. When a new LAG link is created, it is recommended to configure the minimum number of active member links required to consider the LAG link as up. For example, a LAG link with three members can be considered up when only one member link fails and down when at least two member links fail. The attribute required to configure the minimum number of active member links is missing in and is identified as a gap in . It is worth noting that a new LAG group can be created to bundle one or more multi-technology single-domain Ethernet link(s). For example, with reference to , the MDSC can request P-PNC2 to set up an Ethernet bundled link between Ethernet LTP 5-1 on BR21 and Ethernet LTP 6-1 on P24, bundling the multi-technology single-domain Ethernet link between Ethernet LTP 1-1 on BR21 and Ethernet LTP 2-1 on P24. It is also worth noting that the MDSC needs to create the Ethernet LTPs terminating the Ethernet bundled link. The MDSC can request the P-PNC to configure a new multi-technology single-domain IP link, supported by the just configured Ethernet bundled link, following the same procedure described in above. For example, with a reference to , the MDSC can request the P-PNC2 to setup a multi-technology single-domain IP Link between IP LTP 5-2 on BR21 and IP LTP 6-2 on P24 supported by the Ethernet bundle link between ETH LTP 5-1 on BR21 and the Ethernet LTP 6-1 on P24.

Multi-technology LAG Update The P-PNC adds new member(s) to an existing LAG group when the MDSC updates the configuration of an existing Ethernet bundled link at the MPI, adding the multi-technology single-domain Ethernet link(s) being created, as described above. When member links are added or removed from a LAG link, the minimum number of active member links required to consider the LAG link as up may also need to be updated. For example, with reference to , the MDSC can request P-PNC2 to add the multi-technology single-domain Ethernet link set up between Ethernet LTP 3-1 on BR21 and Ethernet LTP 4-1 on P24 to the existing Ethernet bundle link set up between Ethernet LTP 5-1 on node BR21 and Ethernet LTP 6-1 on node P24. After the LAG configuration has been updated, the P-PNC can also update the bandwidth information of the multi-technology single-domain IP link supported by the updated Ethernet bundled link.

Multi-technology TE path properties Configuration The MDSC can discover the TE path properties (e.g., the list of SRLGs, the delay) of a multi-technology IP link from the TE properties of:

the IP LTPs terminating the multi-technology IP link (e.g., the list of SRLGs reported by the P-PNC using the packet TE topology model);
the optical path (e.g., the list of SRLGs reported by the O-PNC using the WDM or OTN tunnel model); and
the cross-domain links (e.g., the list of SRLGs reported by the O-PNC and P-PNC respectively, using the WSON and/or flexi-grid, the OTN and the packet TE topology models).

The MDSC can also report this information to the P-PNC by properly configuring the multi-technology IP link properties using the packet TE topology model at the packet PNC MPI. This information is used by the P-PNC at least when computing the local protection path, as described in , e.g., to ensure that the local protection path is SRLG disjoint with the primary path. It is worth noting that the list of SRLGs for a multi-technology IP link can be quite long. Implementation-specific mechanisms can be implemented by the MDSC or by the O-PNC to summarize the SRLGs of an optical tunnel. These mechanisms are implementation-specific and have no impact on the YANG models nor on the interoperability at the MPI. However, they should be carefully designed to avoid missing information: failure to do so could result in miscalculating two path candidates as being fully SRLG-disjoint when they actually share a hidden failure point.

TE Path Setup and Update This document assumes that TE path setup and update at the MPI could be done using the generic TE tunnel YANG data model, defined in , with packet technology-specific augmentations, described in . When a new TE path needs to be setup, the MDSC can use the model to request the P-PNC to set it up, properly specifying the path constraints, such as the explicit path, to ensure the P-PNC sets up a TE path that meets the end-to-end TE and binding constraints and uses the optical tunnels set up by the MDSC to support this new TE path. The model supports requesting the setup of both end-to-end as well as segment TE tunnels (within one domain). In the latter case, the technology-specific augmentations should allow the configuration of the information needed for multi-domain TE path stitching. For example, the SR-TE specific augmentations of the model should be defined to allow the MDSC to configure the binding SIDs to be used for the multi-domain SR-TE path stitching and to allow the P-PNC to report the binding SID assigned to the segment TE paths. Note that the binding SIDs assigned for multi-domain SR-TE path stitching need to be persistent across IP router and P-PNC restarts: otherwise, the multi-domain TE path would be broken until the MDSC re-learns the new binding SIDs () and reconfigures the SR policies in the other domains. Whether this persistence is provided by the IP routers, by the P-PNC, or by both, is implementation-specific; in any case, the augmentation identified above should allow the P-PNC to report the binding SIDs currently in use. The MDSC can also use the model to request the P-PNC to increase the bandwidth allocated to an existing TE path, and, if needed, also on its reverse TE path. The model supports both symmetric and asymmetric bandwidth configuration in the two directions. The MDSC also requests the P-PNC to configure local protection mechanisms. For example, the FRR local protection, as defined in in case of MPLS-TE domain or the TI-LFA local protection, as defined in in case of SR-TE domain. The mechanisms to request the configuration TI-LFA local protection for SR-TE paths using the are a gap in the current YANG models. The requested local protection mechanisms within the P-PNC domain are configured by the P-PNC through implementation specific mechanisms which are outside the scope of this document. The P-PNC takes into account the multi-layer TE path properties (e.g., SRLG information), configured by the MDSC as described in , when computing the protection configuration (e.g., in case of SR-TE domains, the TI-LFA post-convergence path or, in case of MPLS-TE domain, the FRR backup tunnel) for multi-technology single-domain IP links. SR-TE path setup and update (e.g., bandwidth increase) through MPI is identified as a gap requiring further work, which is outside of the scope of this draft.

L2/L3 VPN Network Service Setup The MDSC can use the L2NM and L3NM network service models to request the P-PNCs to setup L2/L3 VPN services, and the L2NM and L3NM TE service mapping models to request the P-PNCs to configure the PE routers to steer the L2/L3 VPN traffic to the selected TE tunnels (e.g., MPLS-TE or SR-TE). It is worth noting that the L2NM and L3NM TE service mapping models, defined in , provide a list of TE tunnel(s) that should be used to forward L2/L3 VPN traffic between the two PEs terminating the listed TE tunnel(s). If the list contains more than one TE tunnel for the same pair of PEs, these TE tunnels are used to load balance the associated L2/L3 VPN traffic between the same set of two PEs. The possibility to request splitting the traffic between multiple TE tunnels for the same PE pair in a way other than load balancing is identified as a gap requiring further work and is outside the scope of this draft.

Conclusions and Gaps The analysis provided in this document shows that the IETF YANG models described in provide good support for Packet Optical Integration (POI) scenarios for resource discovery (e.g., network topology, service, tunnels), as well as for setup of multi-layer/multi-domain L2/L3 VPN network services. The following gaps were identified that may need to be addressed by the relevant IETF Working Groups:

how both WSON and Flexi-grid topology models could be used together (through multi-inheritance): this gap has been identified in ;
network inventory model: this gap has been identified in and the solution in has been proposed to resolve it;
technology-specific augmentations of the path computation RPC, defined in for optical networks: this gap has been identified in and the solution in has been proposed to resolve it;
relationship between common discovery mechanisms applicable to access links, inter-domain IP links and cross-technology Ethernet links and the UNI topology discovery mechanism defined in : this gap has been identified in ;
a mechanism applicable to the P-PNC NBI to configure the SR-TE paths. Technology-specific augmentations of TE Tunnel model, defined in , are foreseen in section 1 of but not yet defined: this gap has been identified in ;
an attribute, which is used to configure the minimum number of active member links required to consider the LAG link as being up, is missing from the topology model defined in : this gap has been identified in ;
a mechanism to configure splitting the L2/L3 VPN traffic, between multiple TE tunnels for the same PEs pair, in a different way than load balancing: this gap has been identified in ;
a mechanism to report client connectivity constraints imposed by some muxponder design: this gap has been identified in ;
the scalability of reporting the entire inventory and detailed topology information of the packet and optical networks to the MDSC, including the characterization of the scalability constraints and of the mechanisms to address them: this gap has been identified in ;
enhancements to the TE Tunnel model, defined in , to support scenarios where multiple parallel TE paths are used in load-balancing to carry traffic between two end-points (e.g., VPN traffic between two PEs): this gap has been noted, but not analyzed, in this document.

Although not applicable to this document, it has been noted that being able to use WSON and Flexi-grid topology models together (through multi-inheritance) is not only useful for mixed fixed-grid and flexible-grid DWDM network topologies but also the only viable option for a mixed Coarse Wavelength Division Multiplexing (CWDM) and DWDM network topology. Although not applicable to this document, it has been noted that the WDM tunnel model would also support optical tunnel setup in the case of a mixed CWDM and DWDM network topology.

Security Considerations This document highlights how the ACTN architecture can deploy packet over optical infrastructure services. It highlights how existing IETF protocols and data models may be used for multi-layer services. It reuses several existing IETF protocols and data models for the MPI interfaces between each PNC (Optical or Packet) and the MDSC, including:

RESTCONF
NETCONF
PCEP
YANG

The security considerations of the ACTN framework, discussed in Section 9 of , apply to the POI scenarios analyzed in this document. The security considerations of the protocols reused at the MPIs also apply and are not repeated here: see Section 12 of for RESTCONF, Section 9 of for NETCONF, Section 10 of and for PCEP, and the Security Considerations of the YANG data models listed in . This section adds two things that are specific to the application of ACTN to POI: a threat model for the ACTN POI architecture (), since the analysis in is generic, and the security considerations for LLDP snooping (). LLDP snooping is singled out because it is the one mechanism described in this document that is particular to the POI scenarios: it is used by the PNCs to discover the cross-technology Ethernet links between the IP routers and the optical nodes () and, through them, the multi-technology IP links on which the multi-layer coordination performed by the MDSC depends. Several existing authentication and encryption practices and techniques may be used to help secure these MPI interfaces. These mechanisms include using Transport Layer Security (TLS) to provide secure transport for RESTCONF, NETCONF and PCEP. The recommendations in apply: TLS 1.2 or later should be used, and earlier versions should not be used. Each MPI is a trust boundary between the MDSC and a PNC and, in multi-vendor deployments, between controllers supplied by different vendors; the MDSC and each PNC are therefore expected to mutually authenticate (e.g., using client certificates with TLS) rather than relying on one-way authentication. Furthermore, access control techniques can also provide additional security features. Both NETCONF and RESTCONF support the Network Configuration Access Control Model (NACM) , which provides group-based (role-based) access control, ensuring that MDSC to PNC communication is based on authorised use and granular control of connectivity and resource requests. Since the operations performed over the MPIs can modify both the packet and the optical forwarding state, the MDSC and the PNCs are also expected to keep audit logs of the configuration operations they request and perform.

Threat Model for ACTN applied to POI This subsection applies the SDN threat analysis in to the ACTN POI architecture described in , at the same architectural level as the rest of this document ( provides further background). The intent is not to enumerate every possible threat, but to identify the threats that are most relevant to this architecture and how they are expected to be mitigated. A broader analysis of ACTN security considerations, across deployment scenarios beyond POI, is outside the scope of this document and is expected to be addressed in a separate document. The assets and trust boundaries of the architecture are:

The MDSC, which is the coordination point for both layers and for all the domains: it can set up, modify and tear down optical tunnels, TE paths and L2/L3 VPN network services across the whole network, and it holds the multi-layer topology, inventory and service information retrieved from all the PNCs. The MDSC is therefore a high-value target and operators should treat access to it with the same care as access to a device with control-plane adjacencies to all the IP routers and optical nodes.
The P-PNCs and O-PNCs, each with authority over its own domain, and the network elements they control.
The MPIs, which are the trust boundaries between the MDSC and each PNC and, in multi-vendor deployments, between controllers supplied by different vendors.

Note: the CMI and the MDSC NBI are outside the scope of this document.

The topology, inventory, TE and service information exchanged over the MPIs, whose confidentiality matters (it describes the structure, capacity and shared risks of the network) and whose integrity is critical, since the MDSC decisions depend on it.

Against these assets, the threats most relevant to the ACTN POI architecture, and their expected mitigations, are:

Compromised or misbehaving controller: a compromised MDSC can reroute, disrupt or disclose the traffic of every domain; a compromised PNC can do the same within its domain and can feed false information to the MDSC. Mitigations are the mutual authentication, transport security, access control and audit logging described above, and the hierarchical nature of ACTN itself: each PNC retains authority over its domain, so NACM can limit each MPI client to the operations the architecture requires of it (e.g., read access to topology and write access only to the tunnels and services the MDSC manages), and a PNC can reject requests that are inconsistent with its own view of its domain.
False or stale topology and resource information: whether injected by a compromised PNC, spoofed on the cross-technology Ethernet links (see ), or caused by lost notifications, incorrect information leads the MDSC to compute wrong paths, for example two paths considered SRLG-disjoint that share a failure point (), or to issue provisioning requests that fail or leak resources. Mitigations are the integrity protection of the MPIs, the LLDP mitigations in , and the ability of the MDSC to resynchronize its view with the PNCs (); the distributed control planes of the IP/MPLS and optical networks remain authoritative for the network state.
Unauthorized cross-layer operations: an operation requested over one MPI that results in changes in the other layer, or an MPI client with authority over one layer causing changes in the other. In the ACTN architecture, cross-layer coordination is performed only by the MDSC, and each PNC only acts on its own domain: the O-PNC and the P-PNC should therefore enforce, through NACM, that each MPI client can only perform the operations required for its role, and the O-PNC retains the validation of the optical paths it is requested to set up ().
Information disclosure: the information exchanged over the MPIs, or disclosed through LLDP on the cross-technology Ethernet links, can be used to plan further attacks. Mitigations are the confidentiality protection of the MPIs, read-access restrictions through NACM, and the LLDP mitigations in .
Resource exhaustion: controllers can be overloaded through the MPIs (e.g., by large topology retrievals, by many notification subscriptions or by repeated path computation requests), and network elements can be overloaded with LLDP traffic. Mitigations are to accept MPI requests only from authenticated and authorized clients, rate limiting and subscription filtering at the PNCs (see also the scalability gap in ), and the LLDP mitigations in .
Inconsistent packet and optical state: a multi-layer operation that succeeds in one layer and fails in the other (e.g., an optical tunnel set up without the corresponding IP link, or the reverse) leaves state that can disrupt services or be exploited. The MDSC is expected to treat multi-layer operations as coordinated sequences, to verify their outcome through the discovery mechanisms and notifications described in , and to roll back or raise an alarm when a step fails. Multi-layer fault management is further discussed in .

These mitigations rely on the security mechanisms of the protocols and data models reused by this document; this document does not define any new security mechanism.

LLDP Snooping Security Considerations Earlier in the document, LLDP is discussed as a mechanism for the PNCs to discover the intra-domain Ethernet and IP links. While LLDP provides valuable information for network management and troubleshooting, it also presents several security issues:

Eavesdropping: LLDP transmissions are not encrypted. Potentially, LLDP packets could be captured using a packet sniffer. An attacker can leverage this information to gain insights into the network topology, device types, and configurations, which could be used for further attacks;
Unauthorized Access: Information disclosed by LLDP can include device types, software versions, and network configuration details. This might help an attacker identify vulnerable devices or configurations that can be exploited to gain unauthorized access or escalate privileges within the network;
Data Manipulation: If an attacker gains access to a network device, they could manipulate LLDP information to advertise false device information, leading to potential misconfigurations or trust relationships being exploited. This can disrupt network operations or redirect traffic to malicious devices;
Denial of Service (DoS): By flooding the network with fake LLDP packets, an attacker could overwhelm network devices or management systems, potentially leading to a denial of service where legitimate network traffic is disrupted;
Spoofing: An attacker could spoof LLDP packets to impersonate other network devices. Potentially, this might lead to incorrect network mappings or trust relationships being established with malicious devices;
Lack of Authentication: LLDP does not include mechanisms for authenticating the source of LLDP messages, which means that devices accept LLDP information from any source as legitimate.

To mitigate these security issues, network administrators might implement several security measures, including:

Disabling LLDP on ports where it is not needed, especially those facing untrusted networks;
Using network segmentation and Access Control Lists (ACLs) to limit who can send and receive LLDP packets;
Using IEEE 802.1AE MAC Security (MACsec) to provide data origin authentication, integrity, and confidentiality for Ethernet frames, reducing the risk of LLDP spoofing or tampering on protected links;
Employing network monitoring and anomaly detection systems to identify unusual LLDP traffic patterns that may indicate an attack;
Regularly updating and patching network devices to address known vulnerabilities that could be exploited through information gathered via LLDP.

Operational Considerations This document has identified the need and enabling components for automating the management and control of multi-layer Service Providers' transport networks, combining the optical and microwave transport layer with the packet (IP/MPLS) layer to create a more efficient and scalable network infrastructure. This approach is particularly beneficial for Service Providers and large enterprises dealing with high bandwidth demands and looking for cost-effective ways to expand their networks. However, integrating these two traditionally separate network layers involves several operational considerations:

Network Design and Capacity Planning: Deciding the degree of integration between the packet and optical layers is critical. Furthermore, this includes determining whether to pursue a loose integration (keeping layers distinct but coordinated) or a tight integration (combining layers more closely, potentially at the hardware level) coordinated via the MDSC. Accurate forecasting and planning will also be essential to ensure that the integrated ACTN infrastructure can handle future capacity demand without excessive over-provisioning;
System Interoperability: Networks often comprise equipment from various vendors. Ensuring that packet and optical devices can interoperate seamlessly and the PNCs can manage them is crucial for a successful integration. The Service Provider must also check with the vendors to ensure they support the IETF-based technologies outlined in this document;
Performance Monitoring: The integrated POI network will require comprehensive monitoring solutions that can provide visibility to the PNCs across both packet and optical layers. Identifying and diagnosing issues may become more complex with integrated layers. Telemetry data may also be required to collect lower-layer networking health and consider network and service performance. This topic is further discussed in ;
Fault Management and Recovery: The POI networks should be resilient, including considerations for automatic protection switching and fast reroute mechanisms that span both layers. Fault isolation and recovery may become more challenging, as issues in one layer can have cascading effects on the other. Effective fault management strategies must be in place to quickly identify and rectify such issues. This topic is further discussed in ;

This document analyzes the applicability of the ACTN architecture and of the IETF YANG data models to the POI scenarios; it is not a deployment or operations guide. In particular, the following aspects depend on the capabilities of a given MDSC or PNC implementation and on the operator's deployment choices, and are not analyzed in this document:

MDSC and PNC high availability, redundancy and failover;
the mechanisms by which an MDSC detects and recovers from a divergence between its view and the state of the PNCs (e.g., after a PNC restart or a loss of notifications), including the handling of in-flight provisioning operations;
the lifecycle of the notification subscriptions () across controller restarts, and any polling fallback;
the timing of the provisioning workflows described in and , and the timeout and retry behavior at the MPIs.

To set expectations for these topics: in the scenarios analyzed in this document, the MDSC maintains a near-real-time view of the packet and optical networks and services, kept current by the topology and operational-status changes notified by the PNCs over the MPIs. The MDSC performs multi-layer and multi-domain coordination and optimization on that view; it is not part of the online real-time control loop of either network. The consistency of the network state itself is maintained by the distributed control planes of the IP/MPLS and optical networks, and fast recovery from failures relies on the protection and restoration mechanisms of each layer (see also ). Where an MDSC implementation is based on a PCE (), it inherits the redundancy and state synchronization practices of PCE deployments, as described in , and . Multi-layer fault management and service assurance are discussed in . A more complete resilience analysis of ACTN-based POI, covering availability, failure recovery, and security and trust, is left for further work. Specific Security Considerations are discussed in .

IANA Considerations This document requires no IANA actions.

References Normative References Spectral grids for WDM applications: DWDM frequency grid International Telecommunication Union IEEE Standard for Local and metropolitan area networks - Station and Media Access Control Connectivity Discovery Institute of Electrical and Electronics Engineers IEEE Standard for Local and metropolitan area networks - Link Aggregation Institute of Electrical and Electronics Engineers Framework for Abstraction and Control of TE Networks (ACTN) Traffic Engineered (TE) networks have a variety of mechanisms to facilitate the separation of the data plane and control plane. They also have a range of management and provisioning protocols to configure and activate network resources. These mechanisms represent key technologies for enabling flexible and dynamic networking. The term "Traffic Engineered network" refers to a network that uses any connection-oriented technology under the control of a distributed or centralized control plane to support dynamic provisioning of end-to- end connectivity. Abstraction of network resources is a technique that can be applied to a single network domain or across multiple domains to create a single virtualized network that is under the control of a network operator or the customer of the operator that actually owns the network resources. This document provides a framework for Abstraction and Control of TE Networks (ACTN) to support virtual network services and connectivity services. YANG Data Model for Traffic Engineering (TE) Topologies This document defines a YANG data model for representing, retrieving, and manipulating Traffic Engineering (TE) Topologies. The model serves as a base model that other technology-specific TE topology models can augment. Requirements for GMPLS-Based Multi-Region and Multi-Layer Networks (MRN/MLN) Most of the initial efforts to utilize Generalized MPLS (GMPLS) have been related to environments hosting devices with a single switching capability. The complexity raised by the control of such data planes is similar to that seen in classical IP/MPLS networks. By extending MPLS to support multiple switching technologies, GMPLS provides a comprehensive framework for the control of a multi-layered network of either a single switching technology or multiple switching technologies. In GMPLS, a switching technology domain defines a region, and a network of multiple switching types is referred to in this document as a multi-region network (MRN). When referring in general to a layered network, which may consist of either single or multiple regions, this document uses the term multi-layer network (MLN). This document defines a framework for GMPLS based multi-region / multi-layer networks and lists a set of functional requirements. This memo provides information for the Internet community. A YANG Data Model for Traffic Engineering Tunnels, Label Switched Paths, and Interfaces Cisco Systems Inc Cisco Systems Inc Alef Edge Juniper Networks Individual This document defines a YANG data model for the provisioning and management of Traffic Engineering (TE) tunnels, Label Switched Paths (LSPs), and interfaces. The model covers data pertinent to TE tunnels, TE LSPs, and TE interfaces that are independent of any technology or dataplane encapsulation. The model is divided into two YANG modules that address both device-specific and device-independent data, supporting configuration, operational state, Remote Procedure Calls (RPCs), and event notifications. A YANG Data Model for requesting path computation Huawei Technologies Nokia Telefonica Google China Unicom In certain scenarios — particularly within hierarchical Software- Defined Networking (SDN) environments—the topology information provided by a Traffic Engineering (TE) network provider may be insufficient for a client to perform end-to-end multi-domain path computation. In such cases, the client may need to delegate the computation of specific intra-domain paths to the TE provider, leveraging the resulting path segments to construct optimal multi- domain end-to-end paths. This document defines a mechanism to enable path computation requests by augmenting the Remote Procedure Calls (RPCs) specified in RFC YYYY. The augmented RPCs support path computation on demand, allowing clients to request intra-domain TE path computations from the provider while maintaining control over inter-domain path selection. Additionally, this document outlines several use cases in which such path computation requests are beneficial, particularly in environments where YANG-based management protocols—such as NETCONF or RESTCONF—are used for network automation and control. RESTCONF Protocol This document describes an HTTP-based protocol that provides a programmatic interface for accessing data defined in YANG, using the datastore concepts defined in the Network Configuration Protocol (NETCONF). JSON Encoding of Data Modeled with YANG This document defines encoding rules for representing configuration data, state data, parameters of Remote Procedure Call (RPC) operations or actions, and notifications defined using YANG as JavaScript Object Notation (JSON) text. RESTCONF Extensions to Support the Network Management Datastore Architecture This document extends the RESTCONF protocol defined in RFC 8040 in order to support the Network Management Datastore Architecture (NMDA) defined in RFC 8342. This document updates RFC 8040 by introducing new datastore resources, adding a new query parameter, and requiring the usage of the YANG library (described in RFC 8525) by RESTCONF servers implementing the NMDA. Network Management Datastore Architecture (NMDA) Datastores are a fundamental concept binding the data models written in the YANG data modeling language to network management protocols such as the Network Configuration Protocol (NETCONF) and RESTCONF. This document defines an architectural framework for datastores based on the experience gained with the initial simpler model, addressing requirements that were not well supported in the initial model. This document updates RFC 7950. The YANG 1.1 Data Modeling Language YANG is a data modeling language used to model configuration data, state data, Remote Procedure Calls, and notifications for network management protocols. This document describes the syntax and semantics of version 1.1 of the YANG language. YANG version 1.1 is a maintenance release of the YANG language, addressing ambiguities and defects in the original specification. There are a small number of backward incompatibilities from YANG version 1. This document also specifies the YANG mappings to the Network Configuration Protocol (NETCONF). YANG Library This document describes a YANG library that provides information about the YANG modules, datastores, and datastore schemas used by a network management server. Simple caching mechanisms are provided to allow clients to minimize retrieval of this information. This version of the YANG library supports the Network Management Datastore Architecture (NMDA) by listing all datastores supported by a network management server and the schema that is used by each of these datastores. A YANG Data Model for Network Topologies This document defines an abstract (generic, or base) YANG data model for network/service topologies and inventories. The data model serves as a base model that is augmented with technology-specific details in other, more specific topology and inventory data models. Dynamic Subscription to YANG Events and Datastores over RESTCONF This document provides a RESTCONF binding to the dynamic subscription capability of both subscribed notifications and YANG-Push. Subscription to YANG Notifications for Datastore Updates This document describes a mechanism that allows subscriber applications to request a continuous and customized stream of updates from a YANG datastore. Providing such visibility into updates enables new capabilities based on the remote mirroring and monitoring of configuration and operational state. Requirements for Subscription to YANG Datastores This document provides requirements for a service that allows client applications to subscribe to updates of a YANG datastore. Based on criteria negotiated as part of a subscription, updates will be pushed to targeted recipients. Such a capability eliminates the need for periodic polling of YANG datastores by applications and fills a functional gap in existing YANG transports (i.e., Network Configuration Protocol (NETCONF) and RESTCONF). Such a service can be summarized as a "pub/sub" service for YANG datastore updates. Beyond a set of basic requirements for the service, various refinements are addressed. These refinements include: periodicity of object updates, filtering out of objects underneath a requested a subtree, and delivery QoS guarantees. A YANG Data Model for Layer 3 Topologies This document defines a YANG data model for Layer 3 network topologies. Network Configuration Access Control Model The standardization of network configuration interfaces for use with the Network Configuration Protocol (NETCONF) or the RESTCONF protocol requires a structured and secure operating environment that promotes human usability and multi-vendor interoperability. There is a need for standard mechanisms to restrict NETCONF or RESTCONF protocol access for particular users to a preconfigured subset of all available NETCONF or RESTCONF protocol operations and content. This document defines such an access control model. This document obsoletes RFC 6536. Informative References IEEE Standard for Local and metropolitan area networks - Media Access Control (MAC) Security Institute of Electrical and Electronics Engineers Threat Analysis for the SDN Architecture Open Networking Foundation Threat Landscape and Good Practice Guide for Software Defined Networks/5G European Union Agency for Network and Information Security (ENISA) Service Models Explained The IETF has produced many modules in the YANG modeling language. The majority of these modules are used to construct data models to model devices or monolithic functions. A small number of YANG modules have been defined to model services (for example, the Layer 3 Virtual Private Network Service Model (L3SM) produced by the L3SM working group and documented in RFC 8049). This document describes service models as used within the IETF and also shows where a service model might fit into a software-defined networking architecture. Note that service models do not make any assumption of how a service is actually engineered and delivered for a customer; details of how network protocols and devices are engineered to deliver a service are captured in other modules that are not exposed through the interface between the customer and the provider. A Lexicography for the Interpretation of Generalized Multiprotocol Label Switching (GMPLS) Terminology within the Context of the ITU-T's Automatically Switched Optical Network (ASON) Architecture Generalized Multiprotocol Label Switching (GMPLS) has been developed by the IETF to facilitate the establishment of Label Switched Paths (LSPs) in a variety of data plane technologies and across several architectural models. The ITU-T has specified an architecture for the control of Automatically Switched Optical Networks (ASON). This document provides a lexicography for the interpretation of GMPLS terminology within the context of the ASON architecture. It is important to note that GMPLS is applicable in a wider set of contexts than just ASON. The definitions presented in this document do not provide exclusive or complete interpretations of GMPLS concepts. This document simply allows the GMPLS terms to be applied within the ASON context. This memo provides information for the Internet community. Guidelines for creation, selection, and registration of an Autonomous System (AS) This memo discusses when it is appropriate to register and utilize an Autonomous System (AS), and lists criteria for such. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Use cases, Network Scenarios and gap analysis for Packet Optical Integration (POI) with programmable pluggables under ACTN Framework Telefonica Vodafone Orange Verizon Individual This document provides general overarching guidelines for control and management of packet over optical converged networks with programmable pluggables and focuses on operators' use cases and network scenarios. It provides a set of use cases which are needed for the control and management of the packet over optical networks which comprise devices with mixes of packet and optical functions where the optical functions may be provided on programmable pluggables. The document provides a gap analysis to solve the use cases. Data Modelling and Gap Analysis of Optical Pluggables in Packet Over Optical Network Ciena Futurewei Technologies Cisco Nokia Juniper This draft outlines the pluggable module attributes within a host device. It includes representations of optical pluggable module capabilities, configuration, states, and telemetry data. These attributes draws from existing IETF standards and incorporates input from other industry forums and standards, such as ITU-T, OpenConfig, OIF and ONF TAPI, to ensure uniform structuring and consistent naming conventions. Note that the IETF terminology shall be given precedence wherever possible. In case there is a duplication of an attribute, this draft may describe how the attribute is named in the related document. Only if no attribute exists in IETF RFCs or IETF WG drafts, new attributes shall be introduced if they are needed. This draft provides a gap analysis with respect to existing IETF work in the following areas: * It provides an analysis of optical attributes in a set of IETF documents with specifications of other organizations to identify modeling gaps. * It identifies modeling needs addressing the specific aspect of pluggability of transceiver modules. The authors recognize the fact that that not all pluggable modules are coherent, not all coherent pluggable modules are DWDM capable and not all DWDM capable interfaces are implemented as pluggable modules. This analysis identifies gaps to manage the lifecycle of an optical pluggable module, from operator approval and viability assessment, to deployment, monitoring and phase-out. The lifecycle of an optical pluggable module, from operator approval and viability assessment to deployment and monitoring, is also addressed. About This Document This note is to be removed before publishing as an RFC. The latest revision of this draft can be found at https://italobusi.github.io/actn-wdm-pluggable-modelling/draft-rokui- ccamp-actn-wdm-pluggable-modelling.html. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-ietf- ccamp-actn-wdm-pluggable-modelling/. Discussion of this document takes place on the Common Control and Measurement Plane Working Group mailing list (mailto:ccamp@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/ccamp/. Subscribe at https://www.ietf.org/mailman/listinfo/ccamp/. Source for this draft and an issue tracker can be found at https://github.com/italobusi/actn-wdm-pluggable-modelling. Mechanisms for Optimizing Link Aggregation Group (LAG) and Equal-Cost Multipath (ECMP) Component Link Utilization in Networks Demands on networking infrastructure are growing exponentially due to bandwidth-hungry applications such as rich media applications and inter-data-center communications. In this context, it is important to optimally use the bandwidth in wired networks that extensively use link aggregation groups and equal-cost multipaths as techniques for bandwidth scaling. This document explores some of the mechanisms useful for achieving this. Multipath Issues in Unicast and Multicast Next-Hop Selection The effect of multipath routing on a forwarder is that the forwarder potentially has several next-hops for any given destination and must use some method to choose which next-hop should be used for a given data packet. This memo summarizes current practices, problems, and solutions. This memo provides information for the Internet community. A YANG Data Model for Optical Impairment-aware Topology Nokia Orange Nokia Nokia Huawei Technologies Provisioning an optical connection requires that path continuity, resource availability, and impairment constraints be satisfied in order to determine viable paths through the network. This process is known as Impairment-Aware Routing and Wavelength Assignment (IA-RWA) in Wavelength Switched Optical Networks (WSONs) and as Impairment- Aware Routing and Spectrum Assignment (IA-RSA) in Spectrum Switched Optical Networks (SSONs). This document defines a YANG data model for impairment-aware Traffic Engineering (TE) topologies in optical networks. The model augments the technology-agnostic YANG data model for TE topologies and provides read-only topology information, including optical impairments. Such information can be used, for example, by a Path Computation Engine (PCE) to compute optically feasible paths prior to connection establishment. Using BGP to Bind MPLS Labels to Address Prefixes This document specifies a set of procedures for using BGP to advertise that a specified router has bound a specified MPLS label (or a specified sequence of MPLS labels organized as a contiguous part of a label stack) to a specified address prefix. This can be done by sending a BGP UPDATE message whose Network Layer Reachability Information field contains both the prefix and the MPLS label(s) and whose Next Hop field identifies the node at which said prefix is bound to said label(s). This document obsoletes RFC 3107. RSVP-TE Extensions for Collecting Shared Risk Link Group (SRLG) Information This document provides extensions for Resource Reservation Protocol - Traffic Engineering (RSVP-TE), including GMPLS, to support automatic collection of Shared Risk Link Group (SRLG) information for the TE link formed by a Label Switched Path (LSP). A Framework for Network Slices in Networks Built from IETF Technologies This document describes network slicing in the context of networks built from IETF technologies. It defines the term "IETF Network Slice" to describe this type of network slice and establishes the general principles of network slicing in the IETF context. The document discusses the general framework for requesting and operating IETF Network Slices, the characteristics of an IETF Network Slice, the necessary system components and interfaces, and the mapping of abstract requests to more specific technologies. The document also discusses related considerations with monitoring and security. This document also provides definitions of related terms to enable consistent usage in other IETF documents that describe or use aspects of IETF Network Slices. A YANG Data Model for Ethernet TE Topology Huawei Technologies Huawei Technologies Futurewei Huawei Technologies CAICT China Mobile Alef Edge This document describes a YANG data model for Ethernet networks when used either as a client-layer network of an underlay transport network (e.g., an Optical Transport Network (OTN)) or as a transport network itself. A YANG Data Model for Wavelength Switched Optical Networks (WSONs) This document provides a YANG data model for the routing and wavelength assignment (RWA) TE topology in Wavelength Switched Optical Networks (WSONs). The YANG data model defined in this document conforms to the Network Management Datastore Architecture (NMDA). A YANG Data Model for Flexi-Grid Optical Networks Naudit HPCN Universidad Autonoma de Madrid Old Dog Consulting Samsung Huawei Technologies This document defines a YANG module for managing flexi-grid optical networks. The model defined in this document specifies a flexi-grid traffic engineering database that is used to describe the topology of a flexi-grid network. It is based on and augments existing YANG models that describe network and traffic engineering topologies. A YANG Data Model for Optical Transport Network Topology Huawei Technologies Huawei Technologies Individual Nokia Telefonica This document defines a YANG data model for representing, retrieving, and manipulating Optical Transport Network (OTN) topologies. It is independent of control plane protocols and captures topological and resource-related information pertaining to OTN. A YANG Data Model for WDM Tunnels Futurewei Technologies Nokia Individual Naudit HPCN Universidad Autonoma de Madrid This document defines a YANG data model for the provisioning and management of Traffic Engineering (TE) tunnels and Label Switched Paths (LSPs) in Optical Networks (Wavelength Switched Optical Networks (WSON) and Flexi-Grid Dense Wavelength Division Multiplexing (DWDM) Networks). The YANG data model defined in this document conforms to the Network Management Datastore Architecture (NMDA). A YANG Data Model for Optical Transport Network (OTN) Tunnels and Label Switched Paths Huawei Technologies Huawei Technologies Nokia Nokia CAICT This document describes the YANG data model for tunnels in OTN TE networks. The model can be used to do the configuration in order to establish the tunnel in OTN network. This work is independent with the control plane protocols. A YANG Data Model for Transport Network Client Signals Huawei Technologies Futurewei Huawei Technologies Cisco Huawei Technologies A transport network is a server-layer network to provide connectivity services to its client. The topology and tunnel information in the transport layer has already been defined by generic Traffic- engineered models and technology-specific models (e.g., OTN, WSON). However, how the client signals are accessing to the network has not been described. These information is necessary to both client and provider. This draft describes how the client signals are carried over transport network and defines YANG data models which are required during configuration procedure. More specifically, several client signal (of transport network) models including ETH, STM-n, FC and so on, are defined in this draft. YANG Data Models for Layer 3 and Packet TE Topologies Individual Individual Hewlett Packard Enterprise Cisco Systems Inc Ciena Telefonica This document defines YANG data models for layer 3 and packet traffic engineering topologies. A YANG Data Model for MPLS-TE Topology Huawei Technologies Futurewei Inc. Individual Cisco Systems, Inc. Cisco Systems, Inc. This document defines a YANG data model for representing, retrieving, and manipulating MPLS-TE network topologies. It is based on and augments existing YANG models that describe network and traffic engineering packet network topologies. This document also defines a collection of common YANG data types and groupings specific to MPLS-TE. These common types and groupings are intended to be imported by modules that model MPLS-TE technology- specific configuration and state capabilities. The YANG models defined in this document can also be used for MPLS Transport Profile (MPLS-TP) network topologies. YANG Data Model for SR and SR TE Topologies on MPLS Data Plane Alef Edge Individual Juniper Networks Juniper Networks Ciena Cisco This document defines a YANG data model for Segment Routing (SR) topology and Segment Routing (SR) traffic engineering (TE) topology, using MPLS data plane. A YANG Data Model for MPLS Traffic Engineering Tunnels Cisco Systems Inc Cisco Systems Inc IBM Corporation Juniper Networks Individual This document defines a YANG data model for the configuration and management of Multiprotocol Label Switching (MPLS) Traffic Engineering (TE) tunnels, Label Switched Paths (LSPs) and interfaces. The model augments the TE generic YANG model for MPLS packet dataplane technology. This model covers data for configuration, operational state, remote procedural calls, and event notifications. A YANG Network Data Model for Layer 3 VPNs As a complement to the Layer 3 Virtual Private Network Service Model (L3SM), which is used for communication between customers and service providers, this document defines an L3VPN Network Model (L3NM) that can be used for the provisioning of Layer 3 Virtual Private Network (L3VPN) services within a service provider network. The model provides a network-centric view of L3VPN services. The L3NM is meant to be used by a network controller to derive the configuration information that will be sent to relevant network devices. The model can also facilitate communication between a service orchestrator and a network controller/orchestrator. Traffic Engineering (TE) and Service Mapping YANG Data Model CRU Huawei Huawei Huawei Cisco Nvidia This document provides a YANG data model to map customer service models (e.g., L3VPN Service Delivery model) to Traffic Engineering (TE) models (e.g., the TE Tunnel or the Virtual Network (VN) model). These models are referred to as the TE Service Mapping Model and are applicable generically to the operator's need for seamless control and management of their VPN services with underlying TE support. The models are principally used for monitoring and diagnostics of the management systems to show how the service requests are mapped onto underlying network resources and TE models. A YANG Network Data Model for Layer 2 VPNs This document defines an L2VPN Network Model (L2NM) that can be used to manage the provisioning of Layer 2 Virtual Private Network (L2VPN) services within a network (e.g., a service provider network). The L2NM complements the L2VPN Service Model (L2SM) by providing a network-centric view of the service that is internal to a service provider. The L2NM is particularly meant to be used by a network controller to derive the configuration information that will be sent to relevant network devices. Also, this document defines a YANG module to manage Ethernet segments and the initial versions of two IANA-maintained modules that include a set of identities of BGP Layer 2 encapsulation types and pseudowire types. Applicability of the Path Computation Element (PCE) to the Abstraction and Control of TE Networks (ACTN) Abstraction and Control of TE Networks (ACTN) refers to the set of virtual network (VN) operations needed to orchestrate, control, and manage large-scale multidomain TE networks so as to facilitate network programmability, automation, efficient resource sharing, and end-to-end virtual service-aware connectivity and network function virtualization services. The Path Computation Element (PCE) is a component, application, or network node that is capable of computing a network path or route based on a network graph and applying computational constraints. The PCE serves requests from Path Computation Clients (PCCs) that communicate with it over a local API or using the Path Computation Element Communication Protocol (PCEP). This document examines the applicability of PCE to the ACTN framework. Path Computation Element (PCE) Communication Protocol (PCEP) This document specifies the Path Computation Element (PCE) Communication Protocol (PCEP) for communications between a Path Computation Client (PCC) and a PCE, or between two PCEs. Such interactions include path computation requests and path computation replies as well as notifications of specific states related to the use of a PCE in the context of Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineering. PCEP is designed to be flexible and extensible so as to easily allow for the addition of further messages and objects, should further requirements be expressed in the future. [STANDARDS-TRACK] Path Computation Element Communication Protocol (PCEP) Extensions for Stateful PCE The Path Computation Element Communication Protocol (PCEP) provides mechanisms for Path Computation Elements (PCEs) to perform path computations in response to Path Computation Client (PCC) requests. Although PCEP explicitly makes no assumptions regarding the information available to the PCE, it also makes no provisions for PCE control of timing and sequence of path computations within and across PCEP sessions. This document describes a set of extensions to PCEP to enable stateful control of MPLS-TE and GMPLS Label Switched Paths (LSPs) via PCEP. Path Computation Element Communication Protocol (PCEP) Extensions for PCE-Initiated LSP Setup in a Stateful PCE Model The Path Computation Element Communication Protocol (PCEP) provides mechanisms for Path Computation Elements (PCEs) to perform path computations in response to Path Computation Client (PCC) requests. The extensions for stateful PCE provide active control of Multiprotocol Label Switching (MPLS) Traffic Engineering Label Switched Paths (TE LSPs) via PCEP, for a model where the PCC delegates control over one or more locally configured LSPs to the PCE. This document describes the creation and deletion of PCE-initiated LSPs under the stateful PCE model. Hierarchical Stateful Path Computation Element (PCE) A stateful Path Computation Element (PCE) maintains information on the current network state received from the Path Computation Clients (PCCs), including computed Label Switched Paths (LSPs), reserved resources within the network, and pending path computation requests. This information may then be considered when computing the path for a new traffic-engineered LSP or for any associated/dependent LSPs. The path-computation response from a PCE helps the PCC to gracefully establish the computed LSP. The Hierarchical Path Computation Element (H-PCE) architecture allows the optimum sequence of interconnected domains to be selected and network policy to be applied if applicable, via the use of a hierarchical relationship between PCEs. Combining the capabilities of stateful PCE and the hierarchical PCE would be advantageous. This document describes general considerations and use cases for the deployment of stateful, but not stateless, PCEs using the hierarchical PCE architecture. An Architecture for Use of PCE and the PCE Communication Protocol (PCEP) in a Network with Central Control The Path Computation Element (PCE) is a core component of Software- Defined Networking (SDN) systems. It can compute optimal paths for traffic across a network and can also update the paths to reflect changes in the network or traffic demands. PCE was developed to derive paths for MPLS Label Switched Paths (LSPs), which are supplied to the head end of the LSP using the Path Computation Element Communication Protocol (PCEP). SDN has a broader applicability than signaled MPLS traffic-engineered (TE) networks, and the PCE may be used to determine paths in a range of use cases including static LSPs, segment routing, Service Function Chaining (SFC), and most forms of a routed or switched network. It is, therefore, reasonable to consider PCEP as a control protocol for use in these environments to allow the PCE to be fully enabled as a central controller. This document briefly introduces the architecture for PCE as a central controller, examines the motivations and applicability for PCEP as a control protocol in this environment, and introduces the implications for the protocol. A PCE-based central controller can simplify the processing of a distributed control plane by blending it with elements of SDN and without necessarily completely replacing it. This document does not describe use cases in detail and does not define protocol extensions: that work is left for other documents. Framework for PCE-Based Inter-Layer MPLS and GMPLS Traffic Engineering A network may comprise multiple layers. It is important to globally optimize network resource utilization, taking into account all layers rather than optimizing resource utilization at each layer independently. This allows better network efficiency to be achieved through a process that we call inter-layer traffic engineering. The Path Computation Element (PCE) can be a powerful tool to achieve inter-layer traffic engineering. This document describes a framework for applying the PCE-based architecture to inter-layer Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) traffic engineering. It provides suggestions for the deployment of PCE in support of multi-layer networks. This document also describes network models where PCE performs inter-layer traffic engineering, and the relationship between PCE and a functional component called the Virtual Network Topology Manager (VNTM). This memo provides information for the Internet community. Profiles for Traffic Engineering (TE) Topology Data Model and Applicability to non-TE-centric Use Cases Huawei Individual Individual Cisco Systems Inc Telefonica This document describes how profiles of the Topology YANG data model, defined in RFC8795, can be used to address applications in Traffic Engineering aware (TE-aware) deployments, irrespective of whether they are TE-centric or not. Transport Northbound Interface Applicability Statement Huawei Old Dog Consulting Huawei CAICT This document provides an analysis of the applicability of the YANG models defined by the IETF (in particular in the Traffic Engineering Architecture and Signaling (TEAS) and Common Control and Measurement Plane (CCAMP) working groups) to support ODU transit services, transparent client services, and Ethernet Private Line/Ethernet Virtual Private Line (EPL/EVPL) services over Optical Transport Network (OTN) in single and multi-domain network scenarios. This document also describes how existing YANG models can be used through several worked examples and JSON fragments. A YANG Network Data Model for Service Attachment Points (SAPs) This document defines a YANG data model for representing an abstract view of the provider network topology that contains the points from which its services can be attached (e.g., basic connectivity, VPN, network slices). Also, the model can be used to retrieve the points where the services are actually being delivered to customers (including peer networks). This document augments the 'ietf-network' data model defined in RFC 8345 by adding the concept of Service Attachment Points (SAPs). The SAPs are the network reference points to which network services, such as Layer 3 Virtual Private Network (L3VPN) or Layer 2 Virtual Private Network (L2VPN), can be attached. One or multiple services can be bound to the same SAP. Both User-to-Network Interface (UNI) and Network-to-Network Interface (NNI) are supported in the SAP data model. Fast Reroute Extensions to RSVP-TE for LSP Tunnels This document defines RSVP-TE extensions to establish backup label-switched path (LSP) tunnels for local repair of LSP tunnels. These mechanisms enable the re-direction of traffic onto backup LSP tunnels in 10s of milliseconds, in the event of a failure. Two methods are defined here. The one-to-one backup method creates detour LSPs for each protected LSP at each potential point of local repair. The facility backup method creates a bypass tunnel to protect a potential failure point; by taking advantage of MPLS label stacking, this bypass tunnel can protect a set of LSPs that have similar backup constraints. Both methods can be used to protect links and nodes during network failure. The described behavior and extensions to RSVP allow nodes to implement either method or both and to interoperate in a mixed network. [STANDARDS-TRACK] Topology Independent Fast Reroute using Segment Routing Individual Cisco Systems Cisco Systems INSA Lyon Orange Bell Canada This document presents Topology Independent Loop-free Alternate Fast Reroute (TI-LFA), aimed at providing protection of node and adjacency segments within the Segment Routing (SR) framework. This Fast Reroute (FRR) behavior builds on proven IP Fast Reroute concepts being LFAs, remote LFAs (RLFA), and remote LFAs with directed forwarding (DLFA). It extends these concepts to provide guaranteed coverage in any two-connected networks using a link-state IGP. An important aspect of TI-LFA is the FRR path selection approach establishing protection over the expected post-convergence paths from the point of local repair, reducing the operational need to control the tie-breaks among various FRR options. A Base YANG Data Model for Network Inventory Huawei Technologies Nokia Vodafone FiberCop Cisco This document defines a base YANG data model for reporting network inventory. The scope of this base model is set to be application- and technology-agnostic. The base data model can be augmented with application- and technology-specific details. YANG Data Models for requesting Path Computation in WDM Optical Networks Huawei Technologies Futurewei Technologies Nokia This document provides a mechanism to request path computation in Wavelength-Division Multiplexing (WDM) optical networks composed of Wavelength Switched Optical Networks (WSON) and Flexi-Grid Dense Wavelength Division Multiplexing (DWDM) switched technologies. This model augments the Remote Procedure Calls (RPCs) defined in RFC YYYY. [RFC EDITOR NOTE: Please replace RFC YYYY with the RFC number of draft-ietf-teas-yang-path-computation once it has been published. Network Configuration Protocol (NETCONF) The Network Configuration Protocol (NETCONF) defined in this document provides mechanisms to install, manipulate, and delete the configuration of network devices. It uses an Extensible Markup Language (XML)-based data encoding for the configuration data as well as the protocol messages. The NETCONF protocol operations are realized as remote procedure calls (RPCs). This document obsoletes RFC 4741. [STANDARDS-TRACK] PCEPS: Usage of TLS to Provide a Secure Transport for the Path Computation Element Communication Protocol (PCEP) The Path Computation Element Communication Protocol (PCEP) defines the mechanisms for the communication between a Path Computation Client (PCC) and a Path Computation Element (PCE), or among PCEs. This document describes PCEPS -- the usage of Transport Layer Security (TLS) to provide a secure transport for PCEP. The additional security mechanisms are provided by the transport protocol supporting PCEP; therefore, they do not affect the flexibility and extensibility of PCEP. This document updates RFC 5440 in regards to the PCEP initialization phase procedures. Deprecating TLS 1.0 and TLS 1.1 This document formally deprecates Transport Layer Security (TLS) versions 1.0 (RFC 2246) and 1.1 (RFC 4346). Accordingly, those documents have been moved to Historic status. These versions lack support for current and recommended cryptographic algorithms and mechanisms, and various government and industry profiles of applications using TLS now mandate avoiding these old TLS versions. TLS version 1.2 became the recommended version for IETF protocols in 2008 (subsequently being obsoleted by TLS version 1.3 in 2018), providing sufficient time to transition away from older versions. Removing support for older versions from implementations reduces the attack surface, reduces opportunity for misconfiguration, and streamlines library and product maintenance. This document also deprecates Datagram TLS (DTLS) version 1.0 (RFC 4347) but not DTLS version 1.2, and there is no DTLS version 1.1. This document updates many RFCs that normatively refer to TLS version 1.0 or TLS version 1.1, as described herein. This document also updates the best practices for TLS usage in RFC 7525; hence, it is part of BCP 195. Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) are used to protect data exchanged over a wide range of application protocols and can also form the basis for secure transport protocols. Over the years, the industry has witnessed several serious attacks on TLS and DTLS, including attacks on the most commonly used cipher suites and their modes of operation. This document provides the latest recommendations for ensuring the security of deployed services that use TLS and DTLS. These recommendations are applicable to the majority of use cases. RFC 7525, an earlier version of the TLS recommendations, was published when the industry was transitioning to TLS 1.2. Years later, this transition is largely complete, and TLS 1.3 is widely available. This document updates the guidance given the new environment and obsoletes RFC 7525. In addition, this document updates RFCs 5288 and 6066 in view of recent attacks. Applicability of Abstraction and Control of Traffic Engineered Networks (ACTN) for Packet Optical Integration (POI) service assurance Huawei Technologies Vodafone FiberCop Huawei Technologies Cisco This document extends the analysis of the applicability of Abstraction and Control of TE Networks (ACTN) architecture to Packet Optical Integration (POI) to cover multi-layer service assurance scenarios. Specifically, the ACTN architecture supports service assurance through the detection and correlation of failures across the optical and packet layers, with failure handling performed through the relevant PNC. The MDSC can also request health checks for IP services across multi-domain paths for SLA conformance assessment. The PNCs may also be configured with thresholds so that alerts are reported when relevant service or network conditions exceed defined limits. It is assumed that the underlying transport optical network carries end-to-end IP services such as L2VPN or L3VPN connectivity services, with specific Service Level Agreement (SLA) requirements. Existing IETF protocols and data models are identified for each multi-layer (packet over optical) service assurance scenario with a specific focus on the MPI (Multi-Domain Service Coordinator to Provisioning Network Controllers Interface) in the ACTN architecture. A YANG Data Model for Virtual Network (VN) Operations Samsung Electronics Huawei Cisco Individual ETRI A Virtual Network (VN) is a network provided by a service provider to a customer for the customer to use in any way it wants as though it was a physical network. This document provides a YANG data model generally applicable to any mode of VN operations. This includes VN operations as per the Abstraction and Control of TE Networks (ACTN) framework.

Additional Scenarios

OSS/Orchestration Layer The OSS/Orchestration layer is a vital part of the architecture framework for a service provider:

to abstract (through MDSC and PNCs) the underlying transport network complexity to the Business Systems Support layer;
to coordinate NFV, Transport (e.g. IP, optical and microwave networks), Fixed Access, Core and Radio domains enabling full automation of end-to-end services to the end customers;
to enable catalogue-driven service provisioning from external applications (e.g. Customer Portal for Enterprise Business services), orchestrating the design and lifecycle management of these end-to-end transport connectivity services, consuming IP and/or optical transport connectivity services upon request.

As discussed in , in this document, the MDSC interfaces with the OSS/Orchestration layer and, therefore, it performs the functions of the Network Orchestrator, defined in . The OSS/Orchestration layer requests the creation of a network service to the MDSC specifying its end-points (PEs and the interfaces towards the CEs) as well as the network service SLA and then proceeds to configuring accordingly the end-to-end customer service between the CEs in the case of an operator managed service.

MDSC NBI As explained in , the OSS/Orchestration layer can request the MDSC to setup L2/L3VPN network services (with or without TE requirements). Although the OSS/Orchestration layer interface is usually operator-specific, typically it would be using a RESTCONF/YANG interface with a more abstracted version of the MPI YANG data models used for network configuration (e.g. L3NM, L2NM). shows an example of possible control flow between the OSS/Orchestration layer and the MDSC to instantiate L2/L3 VPN network services, using the YANG data models under the definition in , , and .

Service Request Process

The VN YANG data model, defined in , whose primary focus is the CMI, can also provide VN Service configuration from an orchestrated network service point of view when the L2/L3 VPN network service has TE requirements. However, this model is not used to setup L2/L3 VPN service with no TE requirements.
- It provides the profile of VN in terms of VN members, each of which corresponds to an edge-to-edge link between customer end-points (VNAPs). It also provides the mappings between the VNAPs with the LTPs and the connectivity matrix with the VN member. The associated traffic matrix (e.g., bandwidth, latency, protection level, etc.) of VN member is expressed (i.e., via the TE-topology's connectivity matrix).
- The model also provides VN-level preference information (e.g., VN member diversity) and VN-level admin-status and operational-status.
The L2NM and L3NM YANG data models, defined in and , whose primary focus is the MPI, can also be used to provide L2VPN and L3VPN network service configuration from an orchestrated connectivity service point of view.
The TE & Service Mapping YANG data model provides TE-service mapping.
TE-service mapping provides the mapping between a L2/L3 VPN instance and the corresponding VN instances.
The TE-service mapping also provides the binding requirements as to how each L2/L3 VPN/VN instance is created concerning the underlay TE tunnels (e.g., whether they require a new and isolated set of TE underlay tunnels or not).
Site mapping provides the site reference information across L2/L3 VPN Site ID, VN Access Point ID, and the LTP of the access link.

Multi-layer and Multi-domain Resiliency

Maintenance Window Before planned maintenance operation on DWDM network takes place, IP traffic should be moved hitless to another link. MDSC must reroute IP traffic before the events takes place. It should be possible to lock IP traffic to the protection route until the maintenance event is finished, unless a fault occurs on such path.

Router Port Failure The focus is on client-side protection scheme between IP router and reconfigurable ROADM. Scenario here is to define only one port in the routers and in the ROADM muxponder board at both ends as back-up ports to recover any other port failure on client-side of the ROADM (either on the IP router port side or on the muxponder side or on the link between them). When client-side port failure occurs, alarms are raised to MDSC by IP-PNC and O-PNC (port status down, LOS etc.). MDSC checks with OP-PNC(s) that there is no optical failure in the optical layer. There can be two cases here:

LAG was defined between the IP routers at the two ends. MDSC, after checking that optical layer is fine between the two edge WDM nodes, triggers the WDM edge node re-configuration so that the IP router's back-up port with its associated muxponder port can reuse the WDM tunnel that was already in use previously by the failed IP router port and adds the new link to the LAG on the failure side. While the ROADM reconfiguration takes place, IP/MPLS traffic is using the reduced bandwidth of the IP link bundle, discarding lower priority traffic if required. Once back-up port has been reconfigured to reuse the existing WDM tunnel and the new link has been added to the LAG then original Bandwidth is recovered between the end routers. Note: in this LAG scenario it is assumed that BFD is running at LAG level so that there is nothing triggered at MPLS level when one of the link member of the LAG fails.
If there is no LAG, the benefit of this scheme is less clear. An IP router port failure would automatically trigger (through BFD failure) first a sub-50ms protection at the MPLS level: FRR (MPLS RSVP-TE case) or TI-LFA (SR-TE case) through a protection port. At the same time, the MDSC, after checking that the optical network connection is still fine, would trigger the reconfiguration of the back-up port of the IP router and of the muxponder to re-use the same WDM tunnel as the one used originally by the failed IP router port. Once everything has been correctly configured, the MDSC could suggest to the operator a re-optimization of the back-up MPLS path, back to the MPLS primary path through the back-up port of the IP router and the original WDM tunnel, if the overall cost, latency, etc. is improved. However, in this scenario, both a protection port and a back-up port are needed in the IP router, which does not lead to clear port savings. The interaction between the MPLS-level protection, the MDSC-driven back-up port reconfiguration and the subsequent re-optimization has not been analyzed in this document and is left for further work, together with the multi-layer fault management discussed in .

Muxponders The setup of a client connectivity service between two transponders is relatively clear and its implementation simple. There is a one to one relationship between the transponder's client and trunk (or DWDM) port. The client port bitrate determines the trunk port bit rate which will also determine the Baud-rate, the modulation format, the FEC etc. The controller, when asked to set up a client connectivity service, needs to find a WDM tunnel suitable to comply the DWDM port parameters. The setup of a client connectivity service between two muxponders is different since there is a one to many relationship between the muxponder's trunk (or DWDM) port and client ports. For example, there might be a 100Gb/s trunk port shared by ten 10GE client ports. The controller, when asked to set a 10GE client connectivity service between two muxponder's client ports, needs first to check whether there is already an existing WDM tunnel between the two muxponders and then take different actions:

if the WDM tunnel already exists, the controller needs only to enable the 10GE client ports to establish the 10GE client connectivity service;
if the WDM tunnel does not exist, the controller has to first establish the WDM tunnel, finding a proper optical path matching the optical parameters of the two muxponders' trunk ports (e.g., an OTSi carrying an OTU4), and then enable the 10GE client ports to establish the 10GE client connectivity service.

Since multiple client connectivity services are sharing the same WDM tunnel, a multiplexing label shall be assigned to each client connectivity service. The multiplexing label can either be a standard label (e.g., an OTN timeslot) or a vendor-specific label. The multiplexing label can be either configurable (flexible configuration) or assigned by design to each muxponder's client port (fixed configuration). In the former case, any muxponder client port can be connected with any other client port of the peer muxponder (for example client port 1 on one muxponder can be connected with client port 5 on the peer muxponder) while in the latter case only client ports with the same port number can be connected (for example client port 2 on one muxponder can be connected only with client port 2 on the peer muxponder and not with any other client port). In case of flexible configuration, since the two muxponders are under the control of the same O-PNC, the configuration of the multiplexing label, regardless of whether it is a standard or vendor-specific label, can be done by the O-PNC using mechanisms which are vendor-specific and outside the scope of this document. The MDSC can just request the O-PNC to setup a client connectivity service over a WDM tunnel. In case of fixed configuration, the multiplexing label is assigned by the muxponder but the O-PNC and MDSC needs to be aware of the connectivity constraints to avoid try and fail. It is worth noting that the current WSON and Flexi-grid topology models in and do not provide sufficient information to the MDSC about this connectivity constraint and this is identified as a gap.

Acknowledgments Some of this analysis work was supported in part by the European Commission funded H2020-ICT-2016-2 METRO-HAUL project (G.A. 761727). The authors would like to thank Young Lee for his valuable input on the initial discussions which have triggered this work as well as for his contribution to the first drafts of this document. The authors would like to thank Adrian Farrel for his review and comments to this document. The authors would like to thank Acee Lindem for his Early Routing Area Directorate (Rtgdir) Review. The authors would like to thank Ines Robles, Zheng Zhang, Nick Buraglio, and Yaron Sheffer for their IETF Last Call (LC) General Area Review Team (Genart), Routing Area Directorate (Rtgdir), Ops Directorate (Opsdir), and Security Area Directorate (Secdir) reviews. Previous versions of document were prepared using 2-Word-v2.0.template.dot. This document was prepared using kramdown.

Contributors Nokia

sergio.belotti@nokia.com

ggalimbe56@gmail.com

China Unicom

zhengyanlei@chinaunicom.cn

Cisco

asnizar@cisco.com

TIM Brasil

wcorreia@timbrasil.com.br

Hochschule Esslingen - University of Applied Sciences

michael.scharf@hs-esslingen.de

Nvidia

jefftant.ietf@gmail.com

Huawei

paolo.volpato@huawei.com

Cisco

brfoster@cisco.com

Telefonica

oscar.gonzalezdedios@telefonica.com