CCAMP Working Group                                             I. Busi
Internet Draft                                                   Huawei
Intended status: Informational                                  D. King
                                                     Old Dog Consulting
                                                               H. Zheng
                                                                 Huawei
                                                                  Y. Xu
                                                                  CAICT

Expires: March April 2020                                  September 12,                                    October 31, 2019

         Transport Northbound Interface Applicability Statement
            draft-ietf-ccamp-transport-nbi-app-statement-06
            draft-ietf-ccamp-transport-nbi-app-statement-07

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six
   months and may be updated, replaced, or obsoleted by other documents
   at any time.  It is inappropriate to use Internet-Drafts as
   reference material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html

   This Internet-Draft will expire on March 12, April 31, 2020.

Copyright Notice

   Copyright (c) 2019 IETF Trust and the persons identified as the
   document authors. All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document. Please review these documents
   carefully, as they describe your rights and restrictions with
   respect to this document. Code Components extracted from this
   document must include Simplified BSD License text as described in
   Section 4.e of the Trust Legal Provisions and are provided without
   warranty as described in the Simplified BSD License.

Abstract

   Transport network domains, including Optical Transport Network (OTN)
   and Wavelength Division Multiplexing (WDM) networks, are typically
   deployed based on a single vendor or technology platforms. They are
   often managed using proprietary interfaces to dedicated Element
   Management Systems (EMS), Network Management Systems (NMS) and
   increasingly Software Defined Network (SDN) controllers.

   A well-defined open interface to each domain management system or
   controller is required for network operators to facilitate control
   automation and orchestrate end-to-end services across multi-domain
   networks. These functions may be enabled using standardized data
   models (e.g. YANG), and appropriate protocol (e.g., RESTCONF).

   This document analyses provides an analysis of the applicability of the YANG
   models being defined by the IETF (Traffic Engineering Architecture and
   Signaling (TEAS) and moreover, Common Control and Measurement Plane
   (CCAMP) WGs in particular) to support ODU transit services,
   Transparent client services and EPL/EVPL Ethernet services over OTN
   single and multi-domain network scenarios.

   This document also describes how existing YANG models can be used
   through a number of worked examples and JSON fragments.

Table of Contents

   1. Introduction...................................................4
      1.1. The scope Scope of this document................................4
      1.2. Assumptions...............................................5 Document................................4
   2. Terminology....................................................6 Terminology....................................................5
   3. Conventions used Used in this document..............................7 Document..............................8
      3.1. Topology and traffic flow processing......................7 Traffic Flow Processing......................8
      3.2. JSON code.................................................8 code.................................................9
   4. Scenarios Description..........................................9 Description.........................................10
      4.1. Reference Network.........................................9 Network........................................10
      4.2. Topology Abstractions....................................13 Abstractions....................................15
      4.3. Service Configuration....................................15 Configuration....................................16
         4.3.1. ODU Transit.........................................16 Transit.........................................17
         4.3.2. EPL over ODU........................................17 ODU........................................18
         4.3.3. Other OTN Clients Services..........................18 Transparent Client Services.........................19
         4.3.4. EVPL over ODU.......................................19 ODU.......................................20
      4.4. Multi-function Access Links..............................20 Links..............................21
      4.5. Protection and Restoration Configuration.................21 Configuration.................22
         4.5.1. Linear Protection (end-to-end)......................21 (end-to-end)......................23
         4.5.2. Segmented Protection................................23 Protection................................24
      4.6. Notification.............................................23 Notification.............................................25
      4.7. Path Computation with Constraint.........................24 Constraints........................25
   5. YANG Model Analysis...........................................24 Analysis...........................................26
      5.1. YANG Models for Topology Abstraction.....................25 Abstraction.....................26
         5.1.1. Domain 1 Black Topology Abstraction.................26 Abstraction.................28
         5.1.2. Domain 2 Black Topology Abstraction.................30 Abstraction.................32
         5.1.3. Domain 3 White Topology Abstraction.................31 Abstraction.................33
         5.1.4. Multi-domain Topology Merging.......................31 Merging.......................34
      5.2. YANG Models for Service Configuration....................33 Configuration....................36
         5.2.1. ODU Transit Service.................................36 Service.................................40
            5.2.1.1. Single Domain Example..........................38 Example..........................42
         5.2.2. EPL over ODU Service................................38 Service................................42
            5.2.2.1. Single Domain Example..........................40 Example..........................45
         5.2.3. Other OTN Client Services...........................41 Services...........................45
            5.2.3.1. Single Domain Example..........................42 Example..........................46
         5.2.4. EVPL over ODU Service...............................42 Service...............................47
      5.3. YANG Models for Protection Configuration.................44 Configuration.................48
         5.3.1. Linear Protection (end-to-end)......................44 (end-to-end)......................48
         5.3.2. Segmented Protection................................50
      5.4. Notifications............................................44 Notifications............................................51
      5.5. Path Computation with Constraints........................44 Constraints........................52
   6. Security Considerations.......................................44 Considerations.......................................52
      6.1. OTN Security.............................................52
   7. IANA Considerations...........................................45 Considerations...........................................53
   8. References....................................................45 References....................................................53
      8.1. Normative References.....................................45 References.....................................53
      8.2. Informative References...................................46 References...................................54
   9. Acknowledgments...............................................47 Acknowledgments...............................................55
   Appendix A.    Validating a JSON fragment against a YANG Model...49 Model...57
      A.1.  Manipulation of JSON fragments..........................49 fragments..........................57
      A.2.  Comments in JSON fragments..............................50 fragments..............................58
      A.3.  Validation of JSON fragments: DSDL-based approach.......50 approach.......58
      A.4.  Validation of JSON fragments: why not using a an XSD-based
      approach......................................................51
      approach......................................................59
   Appendix B.    Detailed JSON Examples............................52 Examples............................60
      B.1.  JSON Examples for Topology Abstractions.................52 Abstractions.................61
         B.1.1.   JSON Code: mpi1-otn-topology.json.................52 mpi1-otn-topology.json.................61
         B.1.2.   JSON Code: mpi1-eth-topology.json.................85
      B.2.  JSON Examples for Service Configuration.................68 Configuration.................90
         B.2.1.   JSON Code: mpi1-odu2-service-config.json..........68 mpi1-odu2-service-config.json..........90
         B.2.2.   JSON Code: mpi1-odu2-tunnel-config.json...........72 mpi1-odu2-tunnel-config.json...........93
         B.2.3.   JSON Code: mpi1-epl-service-config.json...........72 mpi1-epl-service-config.json...........96

1. Introduction

   Transport network domains, including Optical Transport Network (OTN)
   and Wavelength Division Multiplexing (WDM) networks, are typically
   deployed based on a single vendor or technology platforms. They are
   often managed using proprietary interfaces to dedicated Element
   Management Systems (EMS), Network Management Systems (NMS) and
   increasingly Software Defined Network (SDN) controllers.

   Support of packet connectivity services over transport network
   domains are critical for a wide-range wide range of applications and services,
   including data center and LAN interconnects, Internet service backhauling
   backhauling, mobile backhaul and enterprise Carrier Ethernet
   services. These services are typically
   setup using stovepipe NMS and EMS platforms, often requiring
   propriety management platforms and legacy management interfaces. A clear goal of operators is to automate the setup of transport
   these connectivity services across multiple transport technology domains. network
   domains, that may utilize different technologies.

   A well-defined common open interface (API) to each domain controller and or a
   management system is pre-requisite required for network operators to control
   multi-vendor and multi-domain networks and also enable coordination
   and automation of service
   provisioning coordination/automation. provisioning. This can be achieved is facilitated by using
   standardized data models (e.g., YANG models, used together with models), and an appropriate
   protocol (e.g., RESTCONF [RFC8040]).

   This document analyses examines the applicability of the YANG models being
   defined by IETF (Traffic Engineering Architecture and Signaling
   (TEAS) and moreover, Common Control and Measurement Plane (CCAMP) WGs in
   particular) to support Optical Transport Networks (OTN) single and
   multi-domain scenarios.

1.1. The scope Scope of this document Document

   This document assumes a reference architecture, including
   interfaces, based on the Abstraction and Control of Traffic-
   Engineered Networks (ACTN), defined in [RFC8453].

   The focus of this document is on the MPI (interface interface between the Multi
   Domain Service Coordinator (MDSC) and a Physical Provisioning Network
   Controller (PNC), controlling a transport network domain). domain, called
   MDSC-PNC Interface (MPI) in [RFC8453].

   It is worth noting that the same MPI analyzed in this document could
   be used between hierarchical MDSC controllers, as shown in Figure 4
   of [RFC8453].

   Detailed analysis of the CMI (interface interface between the Customer Network
   Controller (CNC) and the MDSC) MDSC, called CNC-MDSC Interface (CMI) in
   [RFC8453], as well as of the interface between service and network
   orchestrators are outside the scope of this document. However, some when
   needed, this document describes some considerations and assumptions
   about the information are described when needed. which needs to be provided at these
   interfaces.

   The relationship between list of the current IETF YANG models and which are applicable to the type
   of ACTN interfaces
   MPI can be found in [ACTN-YANG]. Therefore, it
   considers the TE Topology YANG model defined in [TE-TOPO], with the
   OTN Topology augmentation defined in [OTN-TOPO] and the TE Tunnel
   YANG model defined in [TE-TUNNEL], with the OTN Tunnel augmentation
   defined in [OTN-TUNNEL]. It also considers the Ethernet Client
   Topology augmentation defined in [CLIENT-TOPO] as well as the Client
   Signal YANG models defined in [CLIENT-SIGNAL] for both Transparent
   and Ethernet clients.

   The ONF Technical Recommendations for Functional Requirements for the transport API as described in [ONF TR-527] and
   the ONF transport API multi-
   domain examples in Optical Networking Foundation (ONF) document [ONF GitHub] TR-527] have
   been considered taken as input for defining the reference scenarios analyzed in
   this document.

1.2. Assumptions

   This

   The analysis provided in this document is making confirms that the following assumptions:

   1. The MDSC IETF YANG
   models defined in [RFC8345], [TE-TOPO], [OTN-TOPO], [CLIENT-TOPO],
   [TE-TUNNEL], [PATH-COMPUTE], [OTN-TUNNEL] and [CLIENT-SIGNAL] can request, at the MPI, be
   used together to control a PNC multi-domain OTN network to setup support
   different types of multi-domain services, such as ODU transit
   services, Transparent client services and EPL/EVPL Ethernet
   services, over a Transit Tunnel
      Segment using multi-domain OTN connection, satisfying also the TE Tunnel YANG model:
   requirements in [ONF TR-527].

2. Terminology

   Domain: A domain, as defined in [RFC4655], is "any collection of
   network elements within a common sphere of address management or
   path computation responsibility".  Specifically, within this case, since the
      endpoints
   document, we mean a part of the E2E Tunnel are outside the domain controlled by an operator's network that PNC, the MDSC would not specify any source or destination TE
      Tunnel Termination Point (TTP), i.e., it would leave empty is under
   common management (i.e., under shared operational management using
   the
      source, destination, src-tp-id and dst-tp-id attributes of the TE
      tunnel instance, and it would use the explicit-route-object (ERO)
      or route-object-include-exclude list to specify the ingress and
      egress links for each path of the Transit Tunnel Segment.

   2. Each PNC provides to the MDSC, at the MPI, the list of available
      timeslots on the inter-domain links using the TE Topology YANG
      model and OTN Topology augmentation. The TE Topology YANG model
      in [TE-TOPO] is being updated to report the label set
      information.

   See section 1.7 of [TE-TUTORIAL] for more details.

   This document has made the following assumptions:

   1. The topology information for the Ethernet Client access links is
      modelled using the YANG model defined in [CLIENT-TOPO];

   2. The topology information for the OTN and Transparent Client
      access links is modelled using the YANG model defined in [OTN-
      TOPO];

   3. The mapping information for Ethernet and Transparent Client
      signals are modelled using the YANG model defined in [CLIENT-
      SIGNAL].

   Finally, the Network Elements (NEs) described in the scenarios used
   in the document are using ODU switching. It is assumed that the ODU
   links are pre-configured and using mechanisms such as WDM
   wavelength, which are outside the scope of this document.

2. Terminology

   Domain: A domain as defined by [RFC4655] is "any collection of
   network elements within a common sphere of address management or
   path computation responsibility".  Specifically, within this
   document we mean a part of an operator's network that is under
   common management (i.e., under shared operational management using
   the same instances same instances of a tool and the same policies).  Network
   elements will often be grouped into domains based on technology
   types, technologies,
   vendor profiles, and or geographic proximity.

   E-LINE: Ethernet Line

   EPL: Ethernet Private Line

   EVPL: Ethernet Virtual Private Line

   OTN: Optical Transport

   CNC: Customer Network

   Service: A service in the context of this document can Controller

   Connection: The data plane configuration of an LSP, within this
   document it is typically an ODU LSP. An end-to-end connection/LSP
   represents an entire connection/LSP between the connection/LSP node
   end-points. A connection/LSP segment represents a portion of the
   end-to-end connection/LSP.

   Connectivity Service: A service, or connectivity service, in the
   context of this document can be considered as some form of
   connectivity service between customer sites across the network
   operator's network [RFC8309].

   E-LINE: Ethernet Line

   EPL: Ethernet Private Line

   EVPL: Ethernet Virtual Private Line

   ILL: Inter-Layer Lock

   Link: A link, or a physical link, is used to reprent the adjacency
   between two physical nodes. The term OTN link represents a link
   between two OTN switching physical nodes.

   LSP: Label Switched Path

   LTP: Link Termination Point

   MDSC: Multi-Domain Service Coordinator

   Network Configuration: As described in [RFC8309] it describes the
   instructions provided to a controller on how to configure parts of a
   network.

   ODU: Optical Channel Data Unit

   OTU: Optical Channel Transport Unit

   OTN: Optical Transport Network

   PNC: Provisioning Network Controller

   Protection Switching: Protection switching, as defined in [ITU-T
   G.808.1] and [RFC4427], provides the capability to swith the traffic
   in case of network failurs over pre-allocated networks resourse.
   Typically linear protection methods would be used and configured to
   operate as 1+1 unidirectional, 1+1 bidirectional or 1:n
   bidirectional. This ensures fast and simple service survivability.

   Protection Transport Entity/LSP: A protection transport entity/LSP,
   as defined in [ITU-T G.808.1] and [RFC4427], represents the path
   where the "normal" user traffic is transported during protection
   switching events (e.g., when the working transport entity/LSP
   fails).

   Restoration: Restoration methods, as defined in [RFC4427], provide
   the capability to reroute and restore traffic around network
   failures without the necessity to allocate network resources as
   required for dedicated 1+1 protection schemes. On the other hand,
   restoration times are typically longer than protection switching
   times.

   Service Model: As described in [RFC8309] it describes a service and
   the parameters of the service in a portable way that can be used
   uniformly and independent of the equipment and operating
   environment.

   UNI: User Network Interface

   MDSC: Multi-Domain Service Coordinator

   CNC: Customer Network Controller

   PNC: Provisioning Network Controller

3. Conventions used

   TE Link: As defined in this document

3.1. Topology [TE-TOPO], it is an element of a TE topology,
   presented as an edge on TE graph.

   TE Tunnel: As defined in [TE-TUTORIAL], it is a connection-oriented
   service provided by a layer network of delivery of a client's data
   between source and destination tunnel termination points.

   TE Tunnel Segment: As defined in [TE-TUTORIAL], it is a part of a
   multi-domain TE tunnel that spans.

   TE Tunnel Hand-off: As defined in [TE-TUTORIAL], it is an access
   link or inter-domain link by which a multi-domain TE tunnel enters
   or exits a given network domain.

   Note - The three definitions above are currently in [TE-TUTORIAL]
   but it is expected that they will be moved to [TE-TUNNEL]. When this
   happens, the reference will be updated and the [TE-TUTORIAL]
   reference will be downgraded to Informative.

   TPN: Tributary Port Number

   TTP: Tunnel Termination Point
   Termination and Adaptation: It represents the termination of a
   server-layer connection at the node edge-point and the
   adaptation/mapping of the client layer traffic flow processing over the terminated
   server-layer connection.

   Transparent Client: As defined in [CLIENT-SIGNAL], it represents a
   client-layer signal, such as Ethernet physical interfaces, FC, STM-
   n, that cannot be switched but only mapped over a server-layer TE
   Tunnel.

   Working Transport Entity/LSP: A working transport entity/LSP, as
   defined in [ITU-T G.808.1] and [RFC4427], represents the path where
   the "normal" user traffic is transported.

   UNI: User Network Interface

3. Conventions Used in this Document

3.1. Topology and Traffic Flow Processing

   The traffic flow between different nodes is specified as an ordered
   list of nodes, separated with commas, indicating within the brackets
   the processing within each node:

      <node> [<processing>]{, <node> [<processing>]}

   The order represents the order of traffic flow being forwarded
   through the network.

   The <processing> represents the type of processing performed by the
   node, which can be just switching at a given layer
   "[(switching)]"
   "(switching-layer)" or it can also having include an adaptation of a client
   layer into a server layer "[(client) layer: "(client-layer) -> server]" server-layer" or [client
   "client-layer -> (server)],
   depending on whether the node is switching in (server-layer)", where the client round brackets are used
   to represent at which layer (client layer or in the server layer. layer) the node
   is switching.

   For example, the following traffic flow:

      R1 [(PKT) -> ODU2], S3 [(ODU2)], S5 [(ODU2)], S6 [(ODU2)],
      R3 [ODU2 -> (PKT)]

   Node R1 is switching at the packet (PKT) layer and mapping packets
   into an ODU2 before transmission to node S3. Nodes S3, S5 and S6 S6,
   are switching at the ODU2 layer: S3 sends the ODU2 traffic to S5 S5,
   which then sends it to S6 which finally sends to R3. Node R3
   terminates the ODU2 from S6 before switching at the packet (PKT)
   layer.

   The paths of working and protection transport entities are specified
   as an ordered list of nodes, separated with commas:

      <node> {, <node>}

   The order represents the order of traffic flow being forwarded
   through the network in the forward direction. In the case of
   bidirectional paths, the forward and backward directions are
   selected arbitrarily, but the convention is consistent between
   working/protection path pairs, as well as across multiple domains.

3.2. JSON code

   This document provides some detailed JSON code examples to describe
   how the YANG models being developed by the IETF (TEAS and CCAMP WG
   in particular) may be used. The scenario examples are provided using
   JSON to facilitate readability.

   Different objects need to have an identifier. The convention used to
   create mnemonic identifiers is to use the object name (e.g., S3 for
   node S3), followed by its type (e.g., NODE), separated by an "-",
   followed by "-ID". For example, the mnemonic identifier for node S3
   would be S3-NODE-ID.

   The JSON language does not support the insertion of comments that
   have been instead found to be useful when writing the examples. This
   document will insert comments into the JSON code as JSON name/value
   pair with the JSON name string starting with the "//" characters.
   For example, when describing the example of a TE Topology instance
   representing the ODU Abstract Topology exposed by the Transport PNC,
   the following comment has been added to the JSON code:

      "// comment": "ODU Abstract Topology @ MPI",

   The JSON code examples provided in this document have been validated
   against the YANG models following the validation process described
   in Appendix A, which would not consider the comments.

   In order to

   To have successful validation of the examples, some numbering scheme
   has been defined to assign identifiers to the different entities
   which would pass the syntax checks. In that case, to simplify the
   reading, another JSON name/value pair formatted as a comment and
   using the mnemonic identifiers is also provided. For example, the
   identifier of node S3 (S3-NODE-ID) has been assumed to be "10.0.0.3"
   and would be shown in the JSON code example using the two JSON
   name/value pair:

      "// te-node-id": "S3-NODE-ID",

      "te-node-id": "10.0.0.3",

   The first JSON name/value pair will be automatically removed in the
   first step of the validation process process, while the second JSON
   name/value pair will be validated against the YANG model
   definitions.

4. Scenarios Description

4.1. Reference Network

   The physical topology of the reference network is shown in Figure 1.
   It represents an OTN network composed of three transport network
   domains which provide transport connectivity services to an IP customer
   network through eight nine access links:

               ........................
   .........   :                      :
           :   :   Network domain 1   :   .............
   Customer:   :                      :   :           :
    domain :   :     S1 -------+      :   :  Network  :
           :   :    /           \     :   :  domain 3 :   ..........
       R1 ------- S3 ----- S4    \    :   :           :   :
           :   :    \        \    S2 --------+        :   :Customer
           :   :     \        \    |  :   :   \       :   : domain
           :   :      S5       \   |  :   :    \      :   :
       R2 ------+    /  \       \  |  :   :    S31 --------- R5
           :   : \  /    \       \ |  :   :   /   \   :   :
       R3 ------- S6 ---- S7 ---- S8 ------ S32   S33 ------ R6
           :   : /        |       |   :   : / \   /   :   :.......
       R4 ------+         |       |   :   :/   S34    :          :
           :   :..........|.......|...:   /    /      :          :
   ........:              |       |      /:.../.......:          :
                          |       |     /    /                   :
               ...........|.......|..../..../...                 :
               :          |       |   /    /   :    ..............
               : Network  |       |  /    /    :    :
               : domain 2 |       | /    /     :    :Customer
               :         S11 ---- S12   /      :    : domain
               :        /          | \ /       :    :
               :     S13     S14   | S15 ------------- R7
               :     |  \   /   \  |    \      :    :
               :     |   S16     \ |     \     :    :
               :     |  /         S17 -- S18 --------- R8
               :     | /             \   /     :    :
               :    S19 ---- S20 ---- S21 ------------ R9
               :                               :    :
               :...............................:    :.............

                        Figure 1 - Reference network

   This document assumes that all the Si transport network switching
   nodes
   Si are capable of switching in the electrical domain (ODU
   switching)
   and moreover, that all the Si-Sj OTN links within the
   transport network (intra-domain or inter-domain) are 100G links
   while the access Ri-Sj links are 10G links.

   It is

   This document also assumed that, assumes that within the transport network, the
   physical/optical interconnections connections supporting the Si-Sj OTN links (up to
   the OTU4 trail), are pre-configured pre-provisioned using mechanisms which are
   outside the scope of this document and are not exposed at the MPIs
   to the MDSC.

   Different transmission technologies can be used on the access links
   (e.g., Ethernet, STM-N and OTU). Section 4.3 provides more details
   about the different assumptions on the access links for different services
   types of connectivity services and section 4.4 describes the control
   of access links which can support different technology configuration
   configurations (e.g., STM-64, 10GE or OTU2) depending on the type of
   service being configured (multi-
   function (multi-function access links).

   The transport domain control architecture,

   To carry client signals (e.g., Ethernet or STM-N) over OTN, some ODU
   termination and adaptation resources need to be available on the
   physical edge nodes (e.g., node S3 and S18). The location of these
   resources within the physical node is implementation specific and
   outside the scope of standardization. This document assumes that
   these termination and adaptation resources are located on the
   physical interfaces of the edge nodes terminating the access links.
   In other words, each physical access link has a set dedicated ODU
   termination and adaptation resources.

   The transport network control architecture, shown in Figure 2,
   follows the ACTN architecture and as defined in the ACTN framework
   document [RFC8453], and uses the same functional components:

                           --------------
                          |              |
                          |     CNC      |
                          |              |
                           --------------
                                 |
             ....................|....................... CMI
                                 |
                          ----------------
                         |                |
                         |      MDSC      |
                         |                |
                          ----------------
                            /   |    \
                           /    |     \
            ............../.....|......\................ MPIs
                         /      |       \
                        /   ----------   \
                       /   |   PNC2   |   \
                      /     ----------     \
             ----------         |           \
            |   PNC1   |      -----          \
             ----------     (       )      ----------
                 |         (         )    |   PNC3   |
               -----      (  Network  )    ----------
             (       )    (  Domain 2 )        |
            (         )    (         )       -----
           (  Network  )    (       )      (       )
           (  Domain 1 )      -----       (         )
            (         )                  (  Network  )
             (       )                   (  Domain 3 )
               -----                      (         )
                                           (       )
                                             -----

                    Figure 2 - Controlling Hierarchies

   The NEs within network domains 1, 2 and 3 of Figure 1 are
   controlled, respectively, by PNC1, PNC2 and PNC3 of Figure 2. The
   MDSC control the end-to-end network through the MPIs toward the
   underlying PNCs.

   The ACTN framework facilitates the detachment separation of the network and
   service control from the underlying technology. It helps the
   customer to define the network as desired by business needs. Therefore,
   care must be taken The CMI
   is defined to keep a minimal level of dependency on the CMI (or no dependency
   at all) with respect to from the underlying network domain technologies. The MPI instead
   requires some specialization according to the domain technology.

   The control interfaces within the scope of this document are the
   three MPIs MPIs, as shown in Figure 2.

   It is worth noting that the

   The split of functionality at the MPI in the ACTN architecture
   between the MDSC (multi-domain controller) and the PNCs (domain
   controllers), is
   equivalent/analogous equivalent to the split of separation functionality which is assumed
   for in
   the ONF T-API interface when used between a multi-domain
   controller and domain controllers, interface, as described in the ONF T-API multi-domain
   use cases [ONF TR-527], as well as at TR-527]. Furthermore, this functional separation is
   similarly defined in the MEF PRESTO interface between the Service
   Orchestration Functionality (SOF) and the Infrastructure Control and
   Management (ICM) in the MEF LSO Architecture [MEF 55].

   This document does not make any assumption about the control
   architecture of the customer IP network: in line with [RFC8453], the
   CNC is just a functional component within the customer control
   architecture which is capable of requesting, at the CMI, transport requesting connectivity services on
   demand between IP routers, when needed. routers at the CMI.

   The CNC can request transport connectivity services between IP routers which
   can be attached to different transport network domains (e.g.,
   between R1 and R8 in Figure 1) or to the same transport network
   domain (e.g., between R1 and R3 in Figure 1). Since the CNC is not
   aware of the transport network controlling controller hierarchy, the mechanisms
   used by the CNC to request, at the CMI, transport request connectivity services are
   independent on at the CMI is also
   unaware whether the requested service request is spans a single-domain or
   multi-domain.
   multi-domains.

   It is assumed that the CMI allows the CNC to provide all the
   necessary information that is required needed by the MDSC to understand the
   connectivity service request and to decide determine the network
   configurations to be requested, at the MPIs, to its underlying PNCs
   to support the requested connectivity service.

   When

   The MDSC, after having received a single-domain service is requested by request from
   the CNC at the CMI (e.g., between R1 and R3 in Figure 1), the MDSC can follow
   the same procedures, described above for the multi-domain service,
   and decide the network configuration to request only at the MPI of
   the PNC controlling that domain (e.g., MPI1 of PNC1 in Figure 2).

4.2. Topology Abstractions

   Abstraction provides a selective method for representing
   connectivity information within a domain. There are multiple methods
   to abstract a network topology. This document assumes the
   abstraction method defined in [RFC7926]:

     "Abstraction is the process of applying the policy to the
     available TE information within a domain, to produce selective
     information that represents the potential ability to connect
     across the domain.  Thus, abstraction does not necessarily offer
     all possible connectivity options, but presents a general view of
     potential connectivity according to the policies that determine
     how the domain's administrator wants to allow the domain resources
     to be used."

   [RFC8453] Provides the context of topology abstraction in the ACTN
   architecture and discusses a few alternatives for the abstraction
   methods for both packet and optical networks. This is an important
   consideration since the choice of the abstraction method impacts
   protocol design and the information it carries.  According to
   [RFC8453], there are three types of topology: topologies:

   o  White topology: This is a case where the PNC provides the actual
      network topology to the MDSC without any hiding or filtering. In
      this case, the MDSC has the full knowledge of the underlying
      network topology;

   o  Black topology: The entire domain network is abstracted as a
      single virtual node with the access/egress access links and inter-domain links
      without disclosing any node internal connectivity information;

   o  Grey topology: This abstraction level is between black topology
      and white topology from a granularity point of view. This is an

   Each PNC should provide the MDSC a network topology abstraction of TE tunnels for all pairs of border nodes. We may
      further differentiate from a perspective of how to abstract
      internal TE resources between the pairs of border nodes:

       - Grey topology type A: border nodes with TE links between them
          in a full mesh fashion;

       - Grey topology type B: border nodes with some internal
          abstracted nodes and abstracted links.

   Each PNC should provide the MDSC with a network topology
   abstractions
   hiding the internal details of the physical domain network topology
   controlled by the PNC. As described in section 3 of [RFC8453], the
   level of abstraction provided by each PNC is based on the PNC
   configuration parameters and this abstraction it is independent of the abstractions
   provided by other PNCs. Therefore Therefore, it is possible that different
   PNCs provide different types of topology
   abstractions and abstractions. The MDSC can
   operate on each MPI operates on the abstract topology regardless of, and
   independently from, the type of abstraction provided by the its
   underlying PNC.

   To analyze

   For analyzing how the MDSC can operate on an abstract topologies
   independently from the topology abstraction
   provided by each PNC
   and, therefore, several PNcs that independently applied different PNCs can provide
   abstraction policies and therefore provided different topology
   abstractions, that types of
   abstract topologies, the following examples assumptions are assumed: made for the
   reference network in Figure 1:

   o  PNC1 and PNC2 provide black topology abstractions which expose at
      MPI1, and MPI2 respectively, a single virtual node (representing
      the whole network domain 1, and domain 2 respectively).

   o  PNC3 provides a white topology abstraction which exposes at MPI3
      all the physical nodes and links within network domain 3.

   The MDSC should be capable of stitching together the abstracted
   topologies provided by each PNC to build its own view of the
   multi-domain multi-
   domain network topology. The process This topology knowledge may require suitable proper
   oversight, including administrative the application of local policy, configuration
   methods, and trust models, the application of a method trust model. Methods of how to achieve this is
   manage these aspects are out of scope for this document, but
   recomandations are provided in the Security section of this
   document.

   The MDSC can also provide topology abstraction of its own view of the
   multi-domain network topology at its CMIs depending on the
   customers' needs: needs and policies: it can provide different types of
   topology abstractions at different CMIs. Analyzing the topology
   abstractions provided by the MDSC to its CMIs is outside the scope
   of this document.

4.3. Service Configuration

   In the following scenarios, it is assumed that the CNC is capable of
   requesting service connectivity services from the MDSC MDSC, for example to support
   interconnect IP routers
   connectivity. routers.

   The type of connectivity services could depend depends on the type of physical
   links (e.g. OTN link, ETH link or SDH link) between the routers and
   transport network.

   The control of different adaptations packet processing inside IP routers, including packet
   encapsualation and decapsulation, Ri (PKT -> foo) and Rj (foo ->
   PKT), are assumed to be performed by means that are not under the
   control of, and not visible to, the MDSC nor to the PNCs. Therefore,
   these mechanisms are outside the scope of this document.

4.3.1. ODU Transit

   The physical links interconnecting the IP routers and the transport
   network can be 10G OTN links.

   In this case, it is assumed that the physical/optical
   interconnections below the ODU layer (up to the OTU2 trail) are
   pre-configured
   pre-provisioned using mechanisms which are outside the scope of this
   document and not exposed at the MPIs between the PNCs and the MDSC.

   For simplicity of the description, it is also assumed that these
   interfaces are not channelized (i.e., they can only support one
   ODU2).

   To setup

   When a 10Gb IP link between R1 and R8, R8 is needed, an ODU2 end-to-end
   connection needs to be created, passing through transport network
   nodes S3, S1, S2, S31, S33, S34, S15 and S18 which belong to
   different PNC domains (multi-domain service request):

      R1 [(PKT) -> ODU2], S3 [(ODU2]), S1 [(ODU2]), S2 [(ODU2]),
      S31 [(ODU2)], S33 [(ODU2)], S34 [(ODU2)],
      S15 [(ODU2)], S18 [(ODU2)], R8 [ODU2 -> (PKT)]

   The MDSC understands that it needs receives, at the CMI,the request to establish create an ODU2 transit
   service between the access links on S3 and S18, which belong to
   different PNC domains (multi-domain service request). It The MDSC also
   decides
   determines the network configurations configuration requests to request, at the MPIs, be sent to its
   underlying PNCs, at the MPIs, to coordinate the setup of a multi-domain multi-
   domain ODU2
   segment connection segment between the access links on S3 and
   S18.

   To setup of

   When a 10Gb IP link between R1 and R3, R3 is needed, an ODU2 end-to-end
   connection needs to be created, passing through transport network
   nodes S3, S5 and S6 which belong to the same PNC domain (single-domain (single-
   domain service request):

      R1 [(PKT) -> ODU2], S3 [(ODU2)], S5 [(ODU2)], S6 [(ODU2)],
      R3 [ODU2 -> (PKT)]

   As described in section 4.1, the mechanisms mechanisms, used by the CNC at the
   CMI
   CMI, are independent on whether the service request is single-domain
   service or multi-domain.

   The MDSC can understand figure out that it needs to setup an ODU2 transit
   service between the access links on S3 and S6, which belong to the
   same PNC domain (single-domain service request) and it decides the
   proper network configuration to request PNC1.

4.3.2. EPL over ODU

   The physical links interconnecting the IP routers and the transport
   network can be 10G Ethernet physical links (10GE).

   In this case, it is assumed that the Ethernet physical interfaces
   (up to the MAC layer) are pre-configured pre-provisioned using mechanisms which are
   outside the scope of this document and not exposed at the MPIs
   between the PNCs and the MDSC.

   To setup

   When a 10Gb IP link between between R1 and R8, R8 is needed, an EPL
   service needs to be created, supported by an ODU2 end-to-end
   connection, between transport network nodes S3 and S18, passing
   through transport network nodes S1, S2, S31, S33, S34 and S15, which
   belong to different PNC domains (multi-
   domain (multi-domain service request):

      R1 [(PKT) -> ETH], S3 [ETH -> (ODU2)], S1 [(ODU2)],
      S2 [(ODU2)], S31 [(ODU2)), S33 [(ODU2)], S34 [(ODU2)],
      S15 [(ODU2)], S18 [(ODU2) -> ETH], R8 [ETH -> (PKT)]

   The MDSC understands that it needs receives, at the CMI, the request to setup create an EPL service
   between the access links on S3 and S18, which belong to different
   PNC domains (multi-domain service request). It also decides The MDSC determines the
   network configurations to request, at the MPIs, to its underlying
   PNCs, to coordinate the setup of an end-to-end ODU2 connection
   between the nodes S3 and S8, including the configuration of the
   adaptation functions inside these edge nodes, such as S3 [ETH ->
   (ODU2)] and S18 [(ODU2) -> ETH].

   To setup

   When a 10Gb IP link between R1 and R2, R2 is needed, an EPL service
   needs to be created, supported by an ODU2 end-to-end connection
   between transport network nodes S3 and S6, passing through the
   transport network node S5, which belong to the same PNC domain
   (single-domain service request):

      R1 [(PKT) -> ETH], S3 [ETH -> (PKT)] S5 [(ODU2)],
      S6 [(ODU2) -> ETH], R2 [ETH -> (PKT)]

   As described in section 4.1, the mechanisms used by the CNC at the
   CMI are independent on whether the service request is single-domain
   service or multi-domain.

   Based on the assumption above, in this case, the MDSC can understand figure out
   that it needs to setup an EPL service between the access links on S3
   and S6, which belong to the same PNC domain (single-domain service
   request) and it decides the proper network configuration to request
   PNC1.

4.3.3. Other OTN Clients Transparent Client Services

   [ITU-T G.709] defines mappings of different Transparent Client
   layers into ODU. Most of them are used to provide Private Line
   services over an OTN transport network supporting a variety of types
   of physical access links (e.g., Ethernet, SDH STM-N, Fibre Channel,
   InfiniBand, etc.) interconnecting the IP routers and the transport
   network.

   In order to setup

   When a 10Gb IP link between R1 and R8 is needed, using, with for example
   SDH physical links between the IP routers and the transport network,
   an STM-64 Private Line service needs to be created, supported by an
   ODU2 end-to-end connection, between transport network nodes S3 and
   S18, passing through transport network nodes S1, S2, S31, S33, S34
   and S15, which belong to different PNC domains (multi-domain service
   request):

      R1 [(PKT) -> STM-64], S3 [STM-64 -> (ODU2)], S1 [(ODU2)],
      S2 [(ODU2)], S31 [(ODU2)], S33 [(ODU2)], S34[(ODU2)],
      S15 [(ODU2)], S18 [(ODU2) -> STM-64], R8 [STM-64 -> (PKT)]

   As already described (section 4.1) the CNC provides the essential
   information to permit the MDSC to understand compute which type of service is
   needed, in this case, an STM-64 Private Line service Service between the
   access links on S3 and S8, and it also decides the network
   configurations, including the configuration of the adaptation
   functions inside these edge nodes, such as S3 [STM-64 -> (ODU2)] and
   S18 [(ODU2) -> STM-64].

   To setup

   When a 10Gb IP link between R1 and R3), R3 is needed, an STM-64 Private
   Line service needs to be created between R1 and R3 (single-domain
   service request):

      R1 [(PKT) -> STM-64], S3[STM-64 -> (ODU2)], S5 [(ODU2)],
      S6 [(ODU2) -> STM-64], R3[STM-64 -> (PKT)]

   As described in section 4.1, the mechanisms mechanisms, used by the CNC at the
   CMI
   CMI, are independent on whether the service request is single-domain
   service or multi-domain.

   Based on the assumption above, in this case, the MDSC can understand figure out
   that it needs to setup an STM-64 Private Line service between the
   access links on S3 and S6, which belong to the same PNC domain
   (single-domain service request) and it decides the proper network
   configuration to request PNC1.

4.3.4. EVPL over ODU

   When the physical links interconnecting the IP routers and the
   transport network are Ethernet physical links, it is also possible
   that different Ethernet services (e.g., EVPL) can share the same
   physical access link using different VLANs.

   As described in section 4.3.2, it is assumed that the Ethernet
   physical interfaces (up to the MAC layer) are pre-configured.

   To setup pre-provisioned.

   When two 1Gb IP links between R1 to R2 and between R1 and R8, R8 are
   needed, two EVPL services need to be created, supported by two ODU0 end-to-
   end
   end-to-end connections:

      R1 [(PKT) -> VLAN], S3 [VLAN -> (ODU0)], S5 [(ODU0)],
      S6 [(ODU0) -> VLAN], R2 [VLAN -> (PKT)]

      R1 [(PKT) -> VLAN], S3[VLAN -> (ODU0)], S1 [(ODU0)],
      S2 [(ODU0)], S31 [(ODU0)], S33 [(ODU0)], S34 [(ODU0)],
      S15 [(ODU0)], S18 [(ODU0) -> VLAN], R8[VLAN -> (PKT)]

   It is worth noting that the fist first EVPL service is required between
   access links which belong to the same PNC domain (single-domain
   service request) while the second EVPL service is required between
   access links which belong to different PNC domains (multi-domain
   service request).

   Since the two EVPL services are sharing the same Ethernet physical
   link between R1 and S3, different VLAN IDs are associated with
   different EVPL services: for example, VLAN IDs 10 and 20
   respectively.

   Based on the assumptions described in section 4.3.2, the CNC
   requests at sends a
   request to the CMI MDSC, at the MDSC CMI, to setup these EVPL services and the services. The
   MDSC understands will determine the network configurations to request to the
   underlying PNCs, as described in section 4.3.2.

4.4. Multi-function Access Links

   Some physical links interconnecting the IP routers and the transport
   network can be configured in different modes, e.g., as OTU2 trail or
   STM-64 or 10GE physical links.

   This configuration can be done a-priori pre-provisioned by means which are outside
   the scope of this document. In this case, these links will appear at
   the MPI as links supporting only one mode (depending on how the a-priori
   configuration) link
   has been pre-provisioned) and will be controlled at the MPI as
   discussed in section 4.3: for example, a 10G multi-function access
   link can be
   pre-configured pre-provisioned as an OTU2 trail (section 4.3.1), a 10GE
   physical link (section 4.3.2) or an STM-64 physical link (section
   4.3.3).

   It is also possible not to configure these links a-priori and let
   the MDSC (or, in case of a single-domain service request, the PNC)
   decide how to configure these links, based on the service
   configuration.

   For example, if the physical link between R1 and S3 is a
   multi-functional access link while the physical links between R4 and
   S6 and between R8 and S18 are STM-64 and 10GE physical links
   respectively, it is possible to configure either an STM-64 Private
   Line service between R1 and R4 or an EPL service between R1 and R8.

   The traffic flow between R1 and R4 can be summarized as:

      R1 [(PKT) -> STM-64], S3 [STM-64 -> (ODU2)], S5 [(ODU2)],
      S6 [(ODU2) -> STM-64], R4 [STM-64 -> (PKT)]

   The traffic flow between R1 and R8 can be summarized as:

      R1 [(PKT) -> ETH], S3 [ETH -> (ODU2)], S1 [(ODU2)],
      S2 [(ODU2)], S31 [(ODU2)), S33 [(ODU2)], S34 [(ODU2)],
      S15 [(ODU2)], S18 [(ODU2) -> ETH], R8 [ETH -> (PKT)]

   The CNC is capable to request at of requesting, via the CMI CMI, the setup either an
   STM-64 Private Line service, between R1 and R4, or an EPL service,
   between R1 and R8.

   The MDSC, based on the service being request, decides the network
   configurations to request, at the MPIs, to its underlying PNCs, to
   coordinate the setup of an end-to-end ODU2 connection, either
   between nodes S3 and S6, or between nodes S3 and S18, including the
   configuration of the adaptation functions on these edge nodes, and
   in particular whether the multi-function access link between R1 and
   S3 should operate as an STM-64 or as a 10GE physical link.

   Assumptions used in this example, as well as the service scenarios
   of sections 4.3, include:

   o  the R1-S3 and R8-S18 access links will be multi-function access
      links, which can be configured as an OTU2 trail or as an STM-64
      or a 10GE physical link;

   o  the R3-S6 access link will be a multi-function access link which
      can be configured as an OTU2 trail or as an STM-64 physical link;

   o  the R4-S6 access link is pre-provisioned as an STM-64 physical
      link;

   o  all the other access links (and, in particular, the R2-S6 access
      links) are pre-provisioned as 10GE physical links, up to the MAC
      layer.

4.5. Protection and Restoration Configuration

   Protection switching provides a pre-allocated survivability
   mechanism, typically provided via linear protection methods and
   would

   As described in [RFC4427], recovery can be configured to operate as 1+1 unidirectional (the most
   common OTN performed by either
   protection method), 1+1 bidirectional switching or 1:n
   bidirectional. restoration mechanisms. This ensures fast section
   describes only services which are protected with linear protection,
   considering both end-to-end and simple service survivability.

   Restoration methods would provide the capability to reroute segment protection, as defined in
   [ITU-T G.808.1] and
   restore connectivity traffic around network faults, without the
   network penalty imposed with dedicated 1+1 protection schemes.

   This section describes only services which are protected with linear
   protection. [RFC4427]. The description of services using
   dynamic restoration is outside the scope of this document.

   The MDSC needs to be capable of deciding determining the network configuration
   configurations to request different PNCs to coordinate the
   protection switching configuration to support protected connectivity
   services described in section 4.3.

   Since in these

   In the service examples, examples described in section 4.3, switching within
   the transport network domain is performed only in performed at the OTN ODU layer. It may
   Therefore, it is also
   be assumed that protection switching within the
   transport network
   domain is provided also occurs at the OTN ODU layer. layer, using the
   mechanisms defined in [ITU-T G.873.1].

4.5.1. Linear Protection (end-to-end)

   In order to

   To protect the connectivity services described in section 4.3 from
   failures within the OTN multi-domain transport network, the MDSC can
   decide to request its underlying PNCs to configure ODU2 linear
   protection between the access transport network edge nodes (e.g., nodes S3
   and S18 for the services setup between R1 and R8).

   It is assumed that the OTN linear protection is configured to with as 1+1
   unidirectional protection switching type, as defined type according to the definition
   in [ITU-T G.808.1] and [ITU-T G.873.1], as well as in [RFC4427].

   In these scenarios, a working transport entity and a protection
   transport entity, as defined in [ITU-T G.808.1], (or a working LSP
   and a protection LSP, as defined in [RFC4427]) should be configured
   in the data plane.

   Two cases can be considered:

   o  In one case, the working and protection transport entities pass
      through the same PNC domains:

         Working transport entity:     S3, S1, S2,
                                       S31, S33, S34,
                                       S15, S18

         Protection transport entity:  S3, S4, S8,
                                       S32,
                                       S12, S17, S18

   o  In another case, the working and protection transport entities
      can pass through different PNC domains:

         Working transport entity:     S3, S5, S7,
                                       S11, S12, S17, S18

         Protection transport entity:  S3, S1, S2,
                                       S31, S33, S34,
                                       S15, S18

   The PNCs should be capable to report of reporting to the MDSC which is the
   active transport entity, as defined in [ITU-T G.808.1], in the data
   plane.

   Given the fast dynamic of protection switching operations in the
   data plane (50ms recovery (e.g., 50ms switching time), this reporting is not
   expected to be in real-time.

   It is also worth noting that with unidirectional protection
   switching, e.g., 1+1 unidirectional protection switching, the active
   transport entity may be different in the two directions.

4.5.2. Segmented Protection

   To protect the connectivity services defined in section 4.3 from
   failures within the OTN multi-domain transport network, the MDSC can
   decide to request its underlying PNCs to configure ODU2 linear
   protection between the edge nodes of each domain.

   For example, MDSC can request PNC1 to configure linear protection
   between its edge nodes S3 and S2:

      Working transport entity:     S3, S1, S2

      Protection transport entity:  S3, S4, S8, S2

     MDSC can also request PNC2 to configure linear protection between
     its edge nodes S15 and S18:

      Working transport entity:     S15, S18

      Protection transport entity:  S15, S12, S17, S18

   MDSC can also request PNC3 to configure linear protection between
   its edge nodes S31 and S34:

      Working transport entity:     S31, S33, S34

      Protection transport entity:  S31, S32, S34

4.6. Notification

   To realize the topology update, service update and restoration
   function, following notification type types should be supported:

   1. Object create

   2. Object delete

   3. Object state change

   4. Alarm

   There are three types of topology abstraction type types defined in
   section 4.2, and the notification notifications should also be abstracted. The
   PNC and MDSC should coordinate together to determine the
   notification
   policy, policy. This will include information such as when an
   intra-domain alarm occurred, the occurred. The PNC may not report the alarm alarm, but
   it should provide notification of the service state change notification to the
   MDSC.

   Analysis and methods of how event alarms are triggered, managed and
   propagated are outside the scope of this document.

4.7. Path Computation with Constraint Constraints

   It is possible to define constraints to be taken into account during
   path computation procedures (e.g., IRO/XRO).

   For example, the CNC can request, at the CMI, an ODU transit
   service, as described in section 4.3.1, between R1 and R8 with the
   constraint to pass through the link from S2 to S31 (IRO), such that
   a qualified path could be:

      R1 [(PKT) -> ODU2], S3 [(ODU2]), S1 [(ODU2]), S2 [(ODU2]),
      S31 [(ODU2)], S33 [(ODU2)], S34 [(ODU2)],
      S15 [(ODU2)], S18 [(ODU2)], R8 [ODU2 -> (PKT)]

   If the CNC instead requested to pass through the link from S8 to
   S12, then the above path would not be qualified, while the following
   would be:

      R1 [(PKT) -> ODU2], S3[(ODU2]), S1 [(ODU2]), S2[(ODU2]),
      S8 [(ODU2]), S12[(ODU2]), S15 [(ODU2]), S18[(ODU2]), R8 [ODU2 ->
      (PKT)]

   The mechanisms mechanisms, used by the CNC to provide path constraints at the
   CMI
   CMI, are outside the scope of this document. It is assumed that the
   MDSC can understand satisfy these constraints and take them into account in its
   path computation procedures (which would decide at least which
   domains and inter-domain links) and in the path computation
   constraints to provide to its underlying PNCs, to be taken into
   account in the path computation procedures implemented by the PNCs
   (with a more detailed view of topology).

   Further detailed analysis is outside the scope of this document.

5. YANG Model Analysis

   This section analyses how the IETF YANG models can be used at the
   MPIs, between the MDSC and the PNCs, to support the scenarios
   described in section 4.

   The YANG models described in [ACTN-YANG] are assumed to be used at
   the MPI.

   Section 5.1 describes the different topology abstractions provided
   to the MDSC by each PNC via its own MPI.

   Section 5.2 describes how the MDSC can request different PNCs, via
   their own MPIs, the network configuration needed to setup the
   different services described in section 4.3.

   Section 5.3 describes how the protection scenarios can be deployed,
   including end-to-end protection and segment protection, for both
   intra-domain and inter-domain scenario.

5.1. YANG Models for Topology Abstraction

   Each

   This section analyses how each PNC reports can report its respective OTN
   abstract topology to the MDSC, as described in section 4.2, using
   the Topology YANG models, defined in [RFC8345], with the TE Topology
   YANG augmentations, provided in [TE-TOPO], and the OTN
   technology-specific YANG augmentations, defined in [OTN-TOPO]. [OTN-TOPO] or the
   Ethernet client technology-specific YANG augmentations, defined in
   [CLIENT-TOPO].

   As described in section 4.1, the OTU4 trails on inter-domain and
   intra-domain physical links are pre-provisioned and therefore not
   exposed at the MPIs. Only the TE Links they support can be exposed
   at the MPI, depending on the topology abstraction performed by the
   PNC.

   The access links can be multi-function access links, as described in
   section 4.4.

   As described in section 4.1, each physical access link has a
   dedicated set of ODU termination and adaptation resources.

   The [OTN-TOPO] model allows reporting within the OTN abstract
   topology also the access links which are capable of supporting the
   transparent client layers, defined in section 4.3.3 and in
   [CLIENT-SIGNAL]. These links can also be multi-function access links
   that can be configured as a transparent client physical links (e.g.,
   STM-64 physical link) or as an OTUk trail.

   In order to support the EPL and EVPL services, described in sections
   4.3.2 and 4.3.4, the access links, which are capable to be of being
   configured as Ethernet physical links, are reported by each PNC
   within its respective Ethernet abstract topology, using the Topology
   YANG models, defined in [RFC8345], with the TE Topology YANG
   augmentations, defined in [TE-TOPO], and the Ethernet client
   technology-specific YANG augmentations, defined in [CLIENT-TOPO].
   These links can also be multi-function access links that can be
   configured as an Ethernet physical link or as link, an OTUk trail and/or trail, or as a
   transparent client physical links (e.g., STM-64 physical link). In
   this case, these physical access links are represented in both the
   OTN and Ethernet abstract topologies.

   It

   The PNC reports the capabilities of the access or inter-domain link
   ends it can control. It is the MDSC responsibility to request
   configuration of these links matching the capabilities of both link
   ends.

   It is worth noting that in the network scenarios analyzed in this
   document (where switching is performed only in at the ODU layer), the
   Ethernet abstract topologies reported by the PNCs describes only the
   Ethernet client access links: no Ethernet TE switching capabilities
   are reported in these Ethernet abstract topologies. topologies, to report that
   the underlying networt domain is not capable to support Ethernet TE
   Tunnels/LSPs.

5.1.1. Domain 1 Black Topology Abstraction

   PNC1 provides the required black topology abstraction, as described
   in section 4.2. It exposes at MPI1 to the MDSC, two TE Topology
   instances with only one TE node each.

   The first TE Topology instance reports the domain 1 OTN abstract
   topology view (MPI1 OTN Topology), using the OTN technology-specific
   augmentations [OTN-TOPO], with only one abstract TE node (i.e., AN1)
   and
   moreover, only inter-domain and access abstract TE links (which
   represent the inter-domain physical links and the access physical
   links which can support ODU and/or ODU, or transparent client layers), layers, both), as
   shown in Figure 3 below.

                   ...................................
                   :                                 :
                   :       +-----------------+       :
                   :       |                 |       :
           (R1)- - --------|                 |-------- - -(S31)
                   : AN1-1 |                 | AN1-7 :
                   :       |                 |       :
           (R3)- - --------|                 |       :
                   : AN1-2 |       AN1       |       :
                   :       |                 |       :
           (R4)- - --------|                 |-------- - -(S32)
                   : AN1-3 |                 | AN1-6 :
                   :       |                 |       :
                   :       +-----------------+       :
                   :          |          |           :
                   :    AN1-4 |          | AN1-5     :
                   :..........|..........|...........:

                              |          |
                            (S11)      (S12)

   Figure 3 - OTN Abstract Topology exposed at MPI1 (MPI1 OTN Topology)

   The second TE Topology instance reports the domain 1 Ethernet
   abstract topology view (MPI1 ETH Topology), using the Ethernet
   technology-specific augmentations [CLIENT-TOPO], with only one
   abstract TE node (i.e., AN1) and only access abstract TE links
   (which represent the access physical links which can support
   Ethernet client layers), as shown in Figure 4 below.

                   ...................................
                   :                                 :
                   :       +-----------------+       :
                   :       |                 |       :
           (R1)- - --------|                 |       :
                   : AN1-1 |                 |       :
                   :       |                 |       :
           (R2)- - --------|                 |       :
                   : AN1-8 |       AN1       |       :
                   :       |                 |       :
                   :       |                 |       :
                   :       |                 |       :
                   :       |                 |       :
                   :       +-----------------+       :
                   :                                 :
                   :.................................:

   Figure 4 - ETH Abstract Topology exposed at MPI1 (MPI1 ETH Topology)

   As described in section 4.1, it is assumed that the

   The OTU4 trails on the inter-domain physical links (e.g., the link
   between S2 and S31) are pre-configured pre-provisioned and exposed as external TE
   Links, within the MPI1 OTN topology (e.g., the external TE Link
   terminating on AN1-7 TE Link Termination Point (LTP) abstracting the
   OTU4 trail between S2 and S31).

   In order to analyze the service scenarios of sections 4.3 and 4.4:

   o  the access link between S3 and R1 is assumed to be a
      multi-function access link, which can be configured as an OTU2
      trail or as an STM-64 or a 10GE physical link;

   o  the access link between S6 and R2 is assumed to be pre-configured
      as a 10GE physical link, up to the MAC layer;

   o  the access link between S6 and R3 is assumed to be a
      multi-function access link which can be configured as an OTU2
      trail or as an STM-64 physical link;

   o  the access link connected to router R4 is assumed to be
      pre-configured as an STM-64 physical link.

   Therefore

   The PNC1 exports at MPI1 the following external TE Links, within the
   MPI1 OTN topology: topology, representing the multi-function access links
   under its control:

   o  two abstract TE Links, terminating on LTP AN1-1 and AN1-2
      respectively, abstracting the physical access link between S3 and
      R1 and the access link between S6 and R3 respectively, reporting
      that they can support STM-64 client signals as well as ODU2
      connections;

   o  one abstract TE Link, terminating on LTP AN1-3, abstracting the
      physical access link between S6 and R4, reporting that it can
      support STM-64 client signals but no ODU2 connections.

   The information about the 10GE access link between S6 and R2 as well
   as the fact that the access link between S3 and R1 can also be
   configured as a 10GE link cannot be exposed by PNC1 within the MPI1
   OTN topology.

   Therefore, PNC1 exports at MPI1, within the MPI1 ETH topology, two
   abstract TE Links, terminating on LTP AN1-1 and AN1-8 respectively,
   abstracting the physical access link between S3 and R1 and the
   access link between S6 and R2 respectively, reporting that they can
   support Ethernet client signal with port-based and VLAN-based
   classifications. The

   PNC1 native topology would represent the
   physical network topology of should expose at MPI1 also the domain controlled ODU termination and adaptation
   resources which are available to carry client signals (e.g.,
   Ethernet or STM-N) over OTN. This information is reported by the PNC, as
   shown in Figure 5.

                  ..................................
                  :                                :
                  :     Physical Topology @
   Tunnel Termination Points (TTPs) within the MPI1 OTN Topology.

   In particular, PNC1   :
                  :                                :
                  :        +----+        +----+    :
                  :        |    |S1-1    |    |S2-3:
                  :        | S1 |--------| will report, within the MPI1 OTN Topology, one
   TTP for each access link (i.e., AN1-1, AN1-2, AN1-3 and AN1-8) and
   will assign a transition link or an inter-layer lock identifier,
   which is unique across all the TE Topologies PNC1 is exposing at
   MPI1, to each TTP and access link's LTP pair.

   For simplicity purposes, this document assigns the same number to
   the LTP-ID, TTP-ID and ILL-ID that corresponds to the same access
   link (i.e., 1, 2, 3 and 8 respectively for the LTP, TTP and
   Inter-Layer Lock (IIL) corresponding with the access links AN1-1,
   AN1-2, AN1-3 and AN1-8).

   The PNC1 native topology would represent the physical network
   topology of the domain controlled by the PNC, as shown in Figure 5.

                  ..................................
                  :                                :
                  :     Physical Topology @ PNC1   :
                  :                                :
                  :        +----+        +----+    :
                  :        |    |S1-1    |    |S2-3:
                  :        | S1 |--------| S2 |----- - -(S31)
                  :        +----+    S2-1+----+    :
                  :     S1-2/               |S2-2  :
                  :    S3-4/                |      :
                  :    +----+   +----+      |      :
                  :    |    |3 1|    |      |      :
          (R1)- - -----| S3 |---| S4 |      |      :
                  :S3-1+----+   +----+      |      :
                  :   S3-2 \        \S4-2   |      :
                  :         \S5-1    \      |      :
                  :        +----+     \     |      :
                  :        |    |      \S8-2|      :
                  :        | S5 |       \   |      :
                  :        +----+        \  |S8-1  :
          (R2)- - ------  2/    \3        \ |      :
                  :S6-1 \ /5     \1        \|      :
                  :    +----+   +----+   +----+    :
                  :    |    |   |    |   |    |S8-5:
          (R3)- - -----| S6 |---| S7 |---| S8 |----- - -(S32)
                  :S6-2+----+4 2+----+4 3+----+    :
                  :     /         |        |       :
          (R3)- - ------     S7-3 |        | S8-4  :
                  :S6-3           |        |       :
                  :...............|........|.......:

                                  |        |
                                (S11)    (S12)

              Figure 5 - Physical Topology controlled by PNC1

   The PNC1 native topology is not exposed and therefore it under PNC
   responsibility to abstract the whole domain physical topology as a
   single TE node and to maintain a mapping between the LTPs exposed at
   MPI abstract topologies and the associated physical interfaces
   controlled by the PNC:

   Physical Interface     OTN Topology LTP     ETH Topology LTP
       (Figure 5)          (Figure 3)            (Figure 4)
           S2-3               AN1-7
           S3-1               AN1-1                 AN1-1
           S6-1                                     AN1-8
           S6-2               AN1-2
           S6-3               AN1-3
           S7-3               AN1-4
           S8-4               AN1-5
           S8-5               AN1-6

   Appendix B.1.1 provides the detailed JSON code example ("mpi1-otn-
   topology.json") describing how the MPI1 ODU Topology is reported by
   the PNC1, using the [RFC8345], [TE-TOPO] and [OTN-TOPO] YANG models,
   at MPI1.

   Appendix B.1.2 provides the detailed JSON code example ("mpi1-eth-
   topology.json") describing how the MPI1 ETH Topology is reported by
   the PNC1, using the [RFC8345], [TE-TOPO] and [CLIENT-TOPO] YANG
   models, at MPI1.

   It is worth noting that this JSON code example does not provide all
   the attributes defined in the relevant YANG models, including:

   o  YANG attributes which are outside the scope of this document are
      not shown;

   o  The attributes describing the set of label values that are
      available at the inter-domain links (label-restriction container)
      are also not shown to simplify the JSON code example;

   o  The comments describing the rationale for not including some
      attributes in this JSON code example even if in the scope of this
      document are identified with the prefix "// __COMMENT" and
      included only in the first object instance (e.g., in the Access
      Link from the AN1-1 description or in the AN1-1 LTP description).

5.1.2. Domain 2 Black Topology Abstraction

   PNC2 provides the required black topology abstraction, as described
   in section 4.2, to expose to the MDSC, at MPI2, two TE Topology
   instances with only one TE node each:

   o  the first instance reports the domain 2 OTN abstract topology
      view (MPI2 OTN Topology), with only one abstract node (i.e., AN2)
      and only inter-domain and access abstract TE links (which
      represent the inter-domain physical links and the access physical
      links which can support ODU and/or ODU, or transparent client layers); layers or
      both);

   o  the instance reports the domain 2 Ethernet abstract topology view
      (MPI2 ETH Topology), with only one abstract TE node (i.e., AN2)
      and only access abstract TE links (which represent the access
      physical links which can support Ethernet client layers).

5.1.3. Domain 3 White Topology Abstraction

   PNC3 provides

   PNC2 also reports the required white topology abstraction, as described
   in section 4.2, to expose ODU termination and adaptation resources which
   are available to carry client signals (e.g., Ethernet or STM-N) over
   OTN in the MDSC, at MPI3, two TE Topology
   instances with multiple TE nodes, one for each physical node:

   o TTPs within the first instance MPI2 OTN Topology.

   In particular, PNC2 reports in both the domain 3 OTN topology view (MPI3 MPI2 OTN Topology), with four TE nodes, Topology and MPI2
   ETH Topology an AN2-1 access link which represent abstracts the four multi-function
   physical nodes (i.e. S31, S32, S33 and S34), access link between S18 and abstract TE
      links, R8, which is assumed to
   correspond to the S18-3 LTP, within the PNC2 native topology. It
   also reports in the MPI2 ETH Topology a TTP which abstracts the ODU
   termination and adaptation resources dedicated to this physical
   access link and the inter-layer lock between this TTP, and the AN2-1
   LTPs reported within the MPI2 OTN Topology and the MPI2 ETH
   Topology.

5.1.3. Domain 3 White Topology Abstraction

   PNC3 provides the required white topology abstraction, as described
   in section 4.2, to expose to the MDSC, at MPI3, two TE Topology
   instances with multiple TE nodes, one for each physical node:

   o  the first instance reports the domain 3 OTN topology view (MPI3
      OTN Topology), with four TE nodes, which represent the four
      physical nodes (i.e. S31, S32, S33 and S34), and abstract TE
      links, which represent the inter-domain and internal physical
      links;

   o  the second instance reports the domain 3 Ethernet abstract
      topology view (MPI3 ETH Topology), with only two TE nodes, which
      represent the two edge physical nodes (i.e., S31 and S33) and
      only the two access TE links which represent the access physical
      links.

   PNC3 also reports the ODU termination and adaptation resources which
   are available to carry client signals (e.g., Ethernet or STM-N) over
   OTN in the TTPs within the MPI3 OTN Topology.

5.1.4. Multi-domain Topology Merging

   As assumed at the beginning of this section,

   MDSC does not have any knowledge of the topologies of each domain
   until each PNC reports its own abstract topologies, so the MDSC
   needs to merge together these abstract topologies, provided by different
   PNCs, to build its own topology view of the multi-domain network
   (MDSC multi-domain native topology), as described in section 4.3 of
   [TE-TOPO].

   Given the topologies reported from multiple PNCs, the MDSC need to
   merge them into its multi-domain native topology.

   The topology of each domain may be in an abstracted shape (refer to
   section 5.2 of [RFC8453] for a different level of abstraction),
   while the inter-
   domain inter-domain link information must be complete and fully
   configured by the MDSC.

   The inter-domain link information is reported to the MDSC by the two
   PNCs, controlling the two ends of the inter-domain link.

   The MDSC needs to understand know how to merge together these inter-
   domain inter-domain links. One
   possibility is to use the plug-id information, defined in [TE-
   TOPO]: [TE-TOPO]:
   two inter-domain TE links, within two different MPI abstract
   topologies, terminating on two LTPs reporting the same plug-id value
   can be merged as a single intra-domain link, within any MDSC native
   topology.

   The value of the reported plug-id information can be either assigned
   by a central network authority, authority and configured within the two PNC
   domains. Alternatively, it may be discovered using an automatic
   discovery mechanisms (e.g., LMP-based, as defined in [RFC6898]).

   In case the plug-id values are assigned by a central authority, it
   is under the central authority responsibility to assign unique
   values.

   In case the plug-id values are automatically discovered, the
   information discovered by the automatic discovery mechanisms needs
   to be encoded as a bit string within the plug-id value. This
   encoding is implementation specific, implementation-specific, but the encoding rules need to
   be consistent across all the PNCs.

   In case of co-existence within the same network of multiple sources
   for the plug-id (e.g., central authority and automatic discovery or
   even different automatic discovery mechanisms), it is needed that
   the plug-id namespace is partitioned to avoid that different sources
   assign the same plug-id value to different inter-domain links. Also,
   the encoding of the plug-id namespace within the plug-id value is
   implementation specific and will need to be consistent across all
   the PNCs.

   This document assumes that the plug-id is assigned by a central
   authority, with the first octet set to 0x00 to represent the central
   authority namespace. The configuration method used, within each PNC
   domain, are outside the scope of this document.

   For example, this document assumes that the following plug-id values
   are assigned, by administrative configuration, to the inter-domain
   links shown in Figure 1:

        Inter-Domain Link     Plug-ID Value

           S2-S31               0x000231
           S7-S11               0x000711
           S8-S12               0x000812
           S8-S32               0x000832
           S12-S32              0x001232
           S15-S34              0x001534

   Based on the plug-id values, the MDSC can merge together the abstract
   topologies exposed by the underlying PNCs, as described in sections
   5.1.1, 5.1.2 and 5.1.3 above, into its multi-domain native TE topology
   topology, as shown in Figure 6.

                ........................
                :                      :
                :   Network domain 1   :   .............
                :   Black Topology     :   :           :
                :     Abstraction      :   :  Network  :
                : AN1-1                :   :  domain 3 :
        (R1)- - ----------+            :   :  (White)  :
                :          \   +--------------+        :
        (R2)- - ---------+ +  /        :   :   \       :
                :         \| /         :   :    \      :
        (R3)- - --------- AN1 --+      :   :    S31 ---- - (R5)
                :         /|\    \     :   :   /   \   :   :
        (R4)- - ---------+ | \    +--------- S32   S33 - - (R6)
                :          |  \        :   :/  \   /   :
                :          |   +---+   :   /    S34    :
                :..........|.......|...:  /:   /       :
                           |       |     / :../........:
                           |       |    /    /
                ...........|.......|.../..../....
                :          |       |  /    /    :
                : Network  |       + /    /     :
                : domain 2 |      / /    /      :
                :          |     / /    /       :
                :          |    + / +--+        :
                :          |    |/ /            :
                : Black    +--- AN2 ------------- - -(R7)
                : Topology      | |     AN2-1   :
                : Abstraction   | +-------------- - -(R8)
                :               |               :
                :               +---------------- - -(R9)
                :                               :
                :...............................:

      Figure 6 - Multi-domain Abstract Topology controlled by an MDSC

5.2. YANG Models for Service Configuration

   The service configuration procedure is assumed to be initiated (step
   1 in Figure 7) at

   This section analyses how the CMI from CNC MDSC can request the different PNCs to MDSC. Analysis of
   setup different multi-domains services, as described in section 4.3,
   using the CMI
   models TE Tunnel YANG model, defined in [TE-TUNNEL], with the OTN
   technology-specific augmentations, defined in [OTN-TUNNEL] with the
   client service YANG model defined in [CLIENT-SIGNAL].

   The service configuration procedure is assumed to be initiated (step
   1 in Figure 7) at the CMI from CNC to MDSC. Analysis of the CMI
   models is (e.g., L1CSM, L2SM, VN) is outside the scope of this
   document.

   As described in section 4.3,
   document, but it is assumed that the CMI YANG models provide all the
   information that allows the MDSC to understand that it needs to
   coordinate the setup of a multi-domain ODU data plane connection
   (which can be either an end-to-end connection or a segment
   connection) and, when needed, also the configuration of the
   adaptation functions in the edge nodes belonging to different
   domains.

                                 |
                                 | {1}
                                 V
                          ----------------
                         |           {2}  |
                         | {3}  MDSC      |
                         |                |
                          ----------------
                           ^     ^      ^
                    {3.1}  |     |      |
                 +---------+     |{3.2} |
                 |               |      +----------+
                 |               V                 |
                 |           ----------            |{3.3}
                 |          |   PNC2   |           |
                 |           ----------            |
                 |               ^                 |
                 V               | {4.2}           |
             ----------          V                 |
            |   PNC1   |       -----               V
             ----------      (Network)        ----------
                 ^          ( Domain 2)      |   PNC3   |
                 | {4.1}   (          _)      ----------
                 V          (        )            ^
               -----       C==========D           | {4.3}
             (Network)    /  (       ) \          V
            ( Domain 1)  /     -----    \       -----
           (           )/                \    (Network)
           A===========B                  \  ( Domain 3)
          / (         )                    \(           )
      AP-1   (       )                      X===========Z
               -----                         (         ) \
                                              (       )   AP-2
                                                -----

                   Figure 7 - Multi-domain Service Setup

   As an example, the objective in this section is to configure a
   transport
   connectivity service between R1 and R8, such as one of the services
   described in section 4.3. The inter-domain path is assumed to be R1
   <-> S3 <-> S1 <-> S2 <-> S31 <-> S33 <-> S34 <->S15 <-> S18 <-> R8
   (see the physical topology in Figure 1).

   According to the different client signal types, different
   adaptations can be required to be configured at the edge nodes
   (i.e., S3 and S18).

   After receiving such request, MDSC determines the domain sequence,
   i.e., domain 1 <-> domain 3 <-> domain 2, with corresponding PNCs
   and the inter-domain links (step 2 in Figure 7).

   As described in [PATH-COMPUTE], the domain sequence can be
   determined by running the MDSC own path computation on the MDSC
   native topology, defined in section 5.1.4, if and only if the MDSC
   has enough topology information. Otherwise, the MDSC can send path
   computation requests to the different PNCs (steps 2.1, 2.2 and 2.3
   in Figure 7) and use this information to determine the optimal path
   on its internal topology and therefore the domain sequence.

   The MDSC will then decompose the tunnel request into a few tunnel
   segments via tunnel models (both technology agnostic TE tunnel model
   and OTN tunnel model),
   segments and request different PNCs to setup each intra-domain TE
   tunnel segment (steps 3, 3.1, 3.2 and 3.3 in Figure 7).

   The MDSC will take care of the configuration of both the intra-
   domain TE tunnel segment segments and inter-domain TE tunnel hand-off via
   corresponding MPI
   (via (using the TE tunnel YANG model defined in
   [TE-TUNNEL] and the OTN tunnel model) YANG model augmentations defined in
   [OTN-TUNNEL]) through all the PNCs controlling the domains selected
   during path computation. More specifically, for the inter-domain TE
   tunnel hand-off, taking into account that the inter-domain links are
   all OTN links, the list of timeslots and the TPN value assigned to
   that ODUk connection at the inter-domain link needs to be configured
   by the MDSC.

   In any case, the access link

   The configuration is done only on the PNCs
   that control of the access links (e.g., PNC-1 and PNC-3) timeslots and not on the
   PNCs of transit domain(s) (e.g., PNC-2). An access link will be
   configured TPN value used by MDSC after the OTN tunnel is set up.

   Access configuration will vary and will be dependent
   ODU2 connection on each type of
   service. Further discussion and examples are provided in the
   following sub-sections.

5.2.1. ODU Transit Service

   In this scenario, described in section 4.3.1, the physical access
   links are configured as 10G OTN internal links and, as described in section
   5.1, reported by each PNC as TE Links within a PNC domain (i.e., on
   the OTN abstract
   topologies they expose to the MDSC.

   To setup this IP link, between R1 and R8, the CNC requests, at the
   CMI, the MDSC to setup an ODU transit service.

   From its native topology, shown in Figure 6, the MDSC understands,
   by means which are internal links within domain1) is outside the scope of this
   document, that R1 is
   attached to the access link terminating on AN1-1 LTP in the MPI1 OTN
   Abstract Topology (Figure 3), exposed by PNC1, and that R8 is
   attached to the access link terminating on AN2-1 LTP in the MPI2
   Abstract Topology, exposed by PNC2.

   MDSC then performs multi-domain path computation (step 2 in Figure
   7) and requests PNC1, PNC2 and PNC3, at MPI1, MPI2 and MPI3
   respectively, to setup ODU2 (Transit Segment) Tunnels within the OTN
   Abstract Topologies they expose (MPI1 OTN Abstract Topology, MPI2
   OTN Abstract Topology and MPI3 OTN Abstract Topology, respectively).

   MDSC requests, at MPI1, PNC1 to setup an ODU2 (Transit Segment)
   Tunnel with one primary path between AN-1 and AN1-7 LTPs, within the
   MPI1 OTN Abstract Topology (Figure 4), using the TE Tunnel YANG
   model, defined in [TE-TUNNEL], with the OTN technology-specific
   augmentations, defined in [OTN-TUNNEL]:

   o  Source and Destination TTPs are not specified (since it is a
      Transit Tunnel)

   o  Ingress and egress points are indicated in the route-object-
      include-exclude list of the explicit-route-objects of the primary
      path:

       o The first element references the access link terminating on
          AN1-1 LTP

       o The last two element reference respectively the inter-domain
          link terminating on AN1-7 LTP and the data plane resources
          (i.e., the list of timeslots and the TPN) used by the ODU2
          connection over that link.

   The configuration of the timeslots used by the ODU2 connection on
   the internal links within a PNC domain (i.e., on the internal links
   within domain1) is outside the scope of this document since it since it is a matter of the PNC domain internal
   implementation.

   However, the configuration of the timeslots used by the ODU2
   connection at the transport network domain boundaries (e.g., on the
   inter-domain links) needs to take into account the timeslots
   available on physical nodes belonging to different PNC domains
   (e.g., on node S2 within PNC1 domain and on node S31 within PNC3
   domain).

   The Each PNC provides to the MDSC, when at the MPI, the list of
   available timeslots on the inter-domain links using the TE Topology
   YANG model and OTN Topology augmentation. The TE Topology YANG model
   in [TE-TOPO] is being updated to report the label set information.
   See section 1.7 of [TE-TUTORIAL] for more details.

   The MDSC, when coordinating the setup of a multi-domain ODU
   connection, also configures the data plane resources (i.e., the list
   of timeslots and the TPN) to be used on the inter-domain links. The
   MDSC can know the timeslots which are available on the physical OTN
   nodes terminating the inter-domain links (e.g., S2 and S31) from the
   OTN Topology information exposed, at the MPIs, by the PNCs
   controlling the OTN physical nodes (e.g., PNC1 and PNC3 controlling
   the physical nodes S2 and S31 respectively).

   Appendix B.2.1 provides

   In any case, the detailed JSON code ("mpi1-odu2-service-
   config.json") describing how access link configuration is done only on the setup PNCs
   that control the access links (e.g., PNC-1 and PNC-3) and not on the
   PNCs of this ODU2 (Transit
   Segment) Tunnel can transit domain(s) (e.g., PNC-2). An access link will be requested
   configured by MDSC after the MDSC, using the [TE-TUNNEL] OTN tunnel is set up.

   Access configuration will vary and [OTN-TUNNEL] YANG models at MPI1.

   PNC1 knows, as will be dependent on each type of
   service. Further discussion and examples are provided in the
   following sub-sections.

5.2.1. ODU Transit Service

   In this scenario, described in section 4.3.1, the mapping table physical access
   links are configured as 10G OTN links and, as described in Section 5.1.1, that
   AN-1 and AN1-7 LTPs section
   5.1, reported by each PNC as TE Links within the MPI1 OTN Abstract Topology it exposes
   at MPI1 correspond abstract
   topologies they expose to the S3-1 and S2-3 LTPs, respectively, within
   its native topology. Therefore it performs path computation, for MDSC.

   When an
   ODU2 connection IP link, between these LTPs within its native topology, R1 and
   sets up R8 is needed, the ODU2 cross-connections within CNC requests, at
   the physical nodes S3, S1
   and S2, as CMI, the MDSC to setup an ODU transit service.

   From its native topology, shown in section 4.3.1.

   Since the R1-S3 access link is a multi-function access link, PNC1
   also configures Figure 6, the OTU2 trail before setting up MDSC understands,
   by means which are outside the ODU2
   cross-connection in node S3.

   As part scope of this document, that R1 is
   attached to the OUD2 cross-connection configuration access link terminating on AN1-1 LTP in node S2, PNC1
   configures the data plane resources (i.e., the list of timeslots MPI1 OTN
   Abstract Topology (Figure 3), exposed by PNC1, and
   the TPN), that R8 is
   attached to be used by this ODU2 connection the access link terminating on AN2-1 LTP in the S2-S31
   inter-domain link, as requested MPI2
   Abstract Topology, exposed by the MDSC.

   Following similar requests from PNC2.

   MDSC then performs multi-domain path computation (step 2 in Figure
   7) and requests PNC1, PNC2 and PNC3, at MPI1, MPI2 and MPI3
   respectively, to setup ODU2 (Transit Segment) Tunnels within the OTN
   Abstract Topologies they expose, PNC2 then
   sets up ODU2 cross-connections on nodes S31 and S33 while PNC3 sets
   up ODU2 cross-connections on nodes S15 and S18, as shown in section
   4.3.1. PNC2 also configures the OTU2 trail on the S18-R8
   multi-function access link.

5.2.1.1. Single Domain Example

   To setup an ODU2 end-to-end connection, supporting an IP link,
   between R1 expose (MPI1 OTN Abstract Topology, MPI2
   OTN Abstract Topology and R3, the CNC MPI3 OTN Abstract Topology, respectively).

   MDSC requests, at the CMI, the MDSC MPI1, PNC1 to setup an ODU transit service.

   Following the procedures described in section 5.2.1, MDSC requests
   only PCN1 to setup the ODU2 (Transit Segment)
   Tunnel with one primary path between the
   access links terminating on AN-1 and AN1-2 LTPs AN1-7 LTPs, within the
   MPI1 OTN Abstract Topology and PNC1 sets up ODU2 cross-connections on nodes
   S3, S5 and S6, as shown in section 4.3.1. PNC1 also configures the
   OTU2 trails on (Figure 4), using the R1-S3 and R3-S6 multi-function access links.

5.2.2. EPL over ODU Service

   In this scenario, described TE Tunnel YANG
   model, defined in section 4.3.2, [TE-TUNNEL], with the access links are
   configured as 10GE Links and, as described OTN technology-specific
   augmentations, defined in section 5.1, reported
   by each PNC as TE Links within the ETH abstract topologies they
   expose to the MDSC.

   To setup this IP link, between R1 [OTN-TUNNEL]:

   o  Source and R8, the CNC requests, at Destination TTPs are not specified (since it is a
      Transit Tunnel): i.e., the
   CMI, source, src-tp-id, destination and
      dst-tp-id attributes of the MDSC to setup an EPL service.

   From its native topology, shown TE tunnel instance are empty

   o  Ingress and egress points are indicated in Figure 6, the MDSC understands,
   by means which are outside route-object-
      include-exclude list of the scope explicit-route-objects of this document, that R1 is
   attached to the primary
      path:

       o The first element references the access link terminating on
          AN1-1 LTP in the MPI1 ETH
   Abstract Topology, exposed by PNC1, and that R8 is attached to

       o The last two element reference respectively the
   access inter-domain
          link terminating on AN2-1 AN1-7 LTP in and the MPI2 ETH Abstract
   Topology, exposed data plane resources
          (i.e., the list of timeslots and the TPN) used by PNC2.

   The MDSC also understands the ODU2
          connection over that it needs to coordinate link.

   Appendix B.2.1 provides the detailed JSON code ("mpi1-odu2-service-
   config.json") describing how the setup of a
   multi-domain this ODU2 (Transit
   Segment) Tunnel between can be requested by the TTPs, abstracting nodes S3 and
   S18 within MDSC, using the OTN Abstract Topologies exposed by PNC1 [TE-TUNNEL]
   and PNC2,
   respectively.

   MDSC then performs multi-domain path computation (step 2 [OTN-TUNNEL] YANG models at MPI1.

   PNC1 knows, as described in Figure
   7) the mapping table in Section 5.1.1, that
   AN-1 and then requests:

   o  PNC1, at MPI1, to setup an ODU2 (Head Segment) Tunnel AN1-7 LTPs within the MPI1 OTN Abstract Topology;

   o  PNC1, Topology it exposes
   at MPI1, MPI1 correspond to steer the Ethernet client traffic from/to AN1-1
      LTP, S3-1 and S2-3 LTPs, respectively, within the MPI1 ETH Abstract Topology, thought that ODU2
      (Head Segment) Tunnel;

   o  PNC3, at MPI3, to setup
   its native topology. Therefore it performs path computation, for an
   ODU2 (Transit Segment) Tunnel connection between these LTPs within its native topology, and
   sets up the MPI3 OTN Abstract Topology;

   o  PNC2, at MPI2, to setup ODU2 (Tail Segment) Tunnel cross-connections within the
      MPI2 OTN Abstract Topology;

   o  PNC2, at MPI2, to steer the Ethernet client traffic to/from AN2-1
      LTP, within physical nodes S3, S1
   and S2.

   Since the MPI2 ETH Abstract Topology, through that ODU2
      (Tail Segment) Tunnel.

   MDSC requests, at MPI1, R1-S3 access link is a multi-function access link, PNC1 to setup an ODU2 (Head Segment) Tunnel
   with one primary path between the source TTP and AN1-7 LTP, within
   also configures the MPI1 OTN Abstract Topology (Figure 4), using OTU2 trail before setting up the TE Tunnel YANG
   model, defined ODU2
   cross-connection in [TE-TUNNEL], with node S3.

   As part of the OTN technology-specific
   augmentations, defined OUD2 cross-connection configuration in [OTN-TUNNEL]:

   o  Only the Source TTP is specified (since it is a Head Segment
      Tunnel): therefore node S2, PNC1
   configures the Destination TTP is not specified

   o  The egress point in indicated in data plane resources (i.e., the route-object-include-exclude list of timeslots and
   the explicit-route-objects of the primary path:

       o The last two element reference respectively the inter-domain
          link terminating on AN1-7 LTP and the data plane resources
          (i.e., the list of timeslots and the TPN) TPN), to be used by the this ODU2 connection over that link.

   Appendix B.2.2 provides the detailed JSON code ("mpi1-odu2-tunnel-
   config.json") describing how on the setup of this ODU2 (Head Segment)
   Tunnel can be S2-S31 inter-
   domain link, as requested by the MDSC, using the [TE-TUNNEL] and [OTN-
   TUNNEL] YANG models at MPI1. MDSC.

   Following similar requests from MDSC requests, at MPI1, PNC1 to steer the Ethernet client traffic
   from/to AN1-2 LTP, setup ODU2 (Transit Segment)
   Tunnels within the MPI1 ETH OTN Abstract Topology (Figure 4),
   thought the MPI1 Topologies they expose, PNC2 then
   sets up ODU2 (Head Segment) Tunnel, using the Ethernet
   Client YANG model, defined in [CLIENT-SIGNAL].

   Appendix B.2.3 provides cross-connections on nodes S31 and S33 while PNC3 sets
   up ODU2 cross-connections on nodes S15 and S18. PNC2 also configures
   the detailed JSON code ("mpi1-epl-service-
   config.json") describing how OTU2 trail on the S18-R8 multi-function access link.

5.2.1.1. Single Domain Example

   To setup of this EPL service using the an ODU2 Tunnel can be requested by the MDSC, using end-to-end connection, supporting an IP link,
   between R1 and R3, the [CLIENT-SIGNAL]
   YANG model CNC requests, at MPI1.

   PNC1 knows, as described in the table CMI, the MDSC to setup
   an ODU transit service.

   Following the procedures described in section 5.1.1, that 5.2.1, MDSC requests
   only PCN1 to setup the
   tunnel source TTP ODU2 (Transit Segment) Tunnel between the
   access links terminating on AN-1 and AN1-7 LTP, AN1-2 LTPs within the MPI1 OTN
   Abstract Topology it exposes at MPI1, correspond to node S3 and S2-3 LTP,
   respectively, within its native topology. Therefore it performs path
   computation, for an ODU2 connection between node S3 and S2-3 LTP
   within its native topology, and PNC1 sets up the ODU2 cross-connections
   within the physical on nodes
   S3, S1 and S2, as shown in section 4.3.2.

   As part of the OUD2 cross-connection configuration in node S2, PNC1
   configures the data plane resources (i.e., the list of timeslots S5 and
   the TPN), to be used by this ODU2 connection on the S2-S31
   inter-domain link, as requested by the MDSC.

   After the configuration of the ODU2 cross-connection in node S3, S6. PNC1 also configures the [ETH -> (ODU)] and [(ODU2) -> ETH]
   adaptation functions, within node S3, as shown in section 4.3.2.

   Since OTU2 trails on the R1-S3 access link is a and
   R3-S6 multi-function access link, PNC1
   also configures the 10GE link before links.

5.2.2. EPL over ODU Service

   In this step.

   Following similar requests from MDSC to setup ODU2 (Segment) Tunnels
   within the OTN Abstract Topologies they expose as well as the
   steering of scenario, described in section 4.3.2, the Ethernet client traffic, PNC3 then sets up ODU2
   cross-connections on nodes S31 and S33 while PNC2 sets up ODU2
   cross-connections on nodes S15 and S18 as well access links are
   configured as the [ETH ->
   (ODU2)] and [(ODU2) -> ETH] adaptation functions in node S18, 10GE Links and, as
   shown described in section 4.3.2. PNC2 also configures 5.1, reported
   by each PNC as TE Links within the 10GE link on ETH abstract topologies they
   expose to the
   S18-R8 multi-function access link.

5.2.2.1. Single Domain Example

   To setup MDSC.

   When this IP link, between R1 and R2, R8, is needed, the CNC requests,
   at the CMI, the MDSC to setup an EPL service.

   Following the procedures described

   From its native topology, shown in section 5.2.2, Figure 6, the MDSC
   requests PCN1 to:

   o  setup an ODU2 (end-to-end) Tunnel between the TTPs, abstracting
      nodes S3 and S6 within MPI1 OTN Abstract Topology exposed by PNC1
      at MPI1;

   o  steer the Ethernet client traffic between the AN1-1 and AN1-8
      LTPs, exposed understands,
   by PNC1 within MPI1 ETH Abstract Topology, through
      that ODU2 (end-to-end) Tunnel.

   Then PNC1 sets up ODU2 cross-connections on nodes S3, S5 and S6 as
   well as the [ETH -> (ODU)] and [(ODU2) -> ETH] adaptation functions
   in nodes S3 and S6, as shown in section 4.3.2. PNC1 also configures
   the 10GE link on the R1-S3 multi-function access link (the R2-S6
   access link has been pre-configured as a 10GE link).

5.2.3. Other OTN Client Services

   In this scenario, described in section 4.3.3, the access links means which are
   configured as STM-64 links and, as described in section 5.1,
   reported by each PNC as TE Links within the OTN Abstract Topologies
   they expose to the MDSC.

   The CNC requests, at outside the CMI, MDSC to setup an STM-64 Private Line
   service between R1 and R8.

   Following similar procedures as described in section 5.2.2, MDSC
   understands that:

   o scope of this document, that R1 is
   attached to the access link terminating on AN1-1 LTP in the MPI1 OTN ETH
   Abstract Topology, exposed by PNC1, and that R8 is attached to the
   access link terminating on AN2-1 LTP in the MPI2
      OTN ETH Abstract
   Topology, exposed by PNC2; PNC2.

   As described in sections 5.1.1 and 5.1.2:

   o  the AN1-1 LTP, within the MPI1 ETH Abstract Topology, and the
      AN1-1 TTP, within the MPI1 OTN Abstract Topology, have the same
      IIL identifier (within the scope of MPI1);

   o  the AN2-1 LTP, within the MPI2 ETH Abstract Topology, and the
      AN2-1 TTP, within the MPI2 OTN Abstract Topology, have the same
      IIL identifier (within the scope of MPI2).

   Therefore, the MDSC also understands that it needs to coordinate the
   setup of a multi-domain ODU2 Tunnel between the TTPs, AN1-1 and AN2-1 TTPs,
   abstracting nodes S3 S3-1 and S18 S18-3 TTPs, within the OTN Abstract Topologies
   exposed by PNC1 and PNC2, respectively.

   The

   MDSC then performs multi-domain path computation (step 2 in Figure
   7) and then requests:

   o  PNC1, at MPI1, to setup an ODU2 (Head Segment) Tunnel within the
      MPI1 OTN Abstract Topology;

   o  PNC1, at MPI1, to steer the STM-64 transparent Ethernet client traffic from/to AN1-1
      LTP, within the MPI1 OTN ETH Abstract Topology, thought that ODU2
      (Head Segment) Tunnel;

   o  PNC3, at MPI3, to setup an ODU2 (Transit Segment) Tunnel within
      the MPI3 OTN Abstract Topology;

   o  PNC2, at MPI2, to setup ODU2 (Tail Segment) Tunnel within the
      MPI2 OTN Abstract Topology;

   o  PNC2, at MPI2, to steer the STM-64 transparent Ethernet client traffic to/from AN2-1
      LTP, within the MPI2 ETH Abstract Topology, through that ODU2
      (Tail Segment) Tunnel.

   PNC1, PNC2 and PNC3 then sets up the

   MDSC requests, at MPI1, PNC1 to setup an ODU2 cross-connections within (Head Segment) Tunnel
   with one primary path between the physical nodes S3, S1, S2, S31, S33, S15 AN1-1 TTP and S18 as well as AN1-7 LTP, within
   the
   [STM-64 -> (ODU)] and [(ODU2) -> STM-64] adaptation functions in
   nodes S3 and S18, as shown MPI1 OTN Abstract Topology (Figure 4), using the TE Tunnel YANG
   model, defined in section 4.3.3. PNC1 and PNC2 also
   configure [TE-TUNNEL], with the STM-64 links on OTN technology-specific
   augmentations, defined in [OTN-TUNNEL]:

   o  Only the R1-S3 and R8-S18 multi-function
   access links, respectively.

5.2.3.1. Single Domain Example

   To setup this IP link, between R1 Source TTP (i.e., AN1 TE-Node and R3, AN1-1 TTP) is
      specified (since it is a Head Segment Tunnel): therefore the CNC requests, at
      Destination TTP is not specified

   o  The egress point in indicated in the
   CMI, route-object-include-exclude
      list of the MDSC to setup an STM-64 Private Line service. explicit-route-objects of the primary path:

       o The MDSC and PNC1 follows similar procedures as described in section
   5.2.2.1 to set up ODU2 cross-connections last two element reference respectively the inter-domain
          link terminating on nodes S3, S5 AN1-7 LTP and S6 as
   well as the [STM-64 -> (ODU)] and [(ODU2) -> STM-64] adaptation
   functions in nodes S3 data plane resources
          (i.e., the list of timeslots and S6, as shown in section 4.3.3. PNC1 also
   configures the STM-64 links on TPN) used by the R1-S3 and R3-S6 multi-function
   access links.

5.2.4. EVPL ODU2
          connection over ODU Service

   In this scenario, described in section 4.3.4, the access links are
   configured as 10GE links, as described in section 5.2.2 above.

   The CNC requests, at that link.

   Appendix B.2.2 provides the CMI, detailed JSON code ("mpi1-odu2-tunnel-
   config.json") describing how the MDSC to setup two EVPL services:
   one between R1 and R2, and another between R1 and R8.

   Following similar procedures as described in section 5.2.2 of this ODU2 (Head Segment)
   Tunnel can be requested by the MDSC, using the [TE-TUNNEL] and
   5.2.2.1, [OTN-
   TUNNEL] YANG models at MPI1.

   MDSC understands that:

   o  R1 and R2 are attached requests, at MPI1, PNC1 to steer the access links terminating
      respectively on AN1-1 and AN1-8 LTPs in Ethernet client traffic
   from/to AN1-2 LTP, within the MPI1 ETH Abstract
      Topology, exposed by PNC1, and that R8 is attached to Topology (Figure 4),
   thought the access
      link terminating on AN2-1 LTP in MPI1 ODU2 (Head Segment) Tunnel, using the MPI2 ETH Abstract Topology,
      exposed by PNC2;

   o  to setup Ethernet
   Client YANG model, defined in [CLIENT-SIGNAL].

   Appendix Error! Reference source not found. provides the first (single-domain) EVPL service, between R1 and
      R2, it needs to coordinate detailed
   JSON code ("mpi1-epl-service-config.json") describing how the setup
   of a single-domain ODU0 this EPL service using the ODU2 Tunnel between can be requested by the TTPs, abstracting nodes S3
   MDSC, using the [CLIENT-SIGNAL] YANG model at MPI1.

   PNC1 knows, as described in the table in section 5.1.1, that the
   AN1-1 TTP and S6 the AN1-7 LTP, within the MPI1 OTN Abstract Topology exposed by PNC1;

   o
   it exposes at MPI1, correspond to setup the second (multi-domain) EPVL service, between R1 S3-1 TTP and
      R8, S2-3 LTP,
   respectively, within its native topology. Therefore it needs to coordinate the setup of a multi-domain ODU0
      Tunnel performs path
   computation, for an ODU2 connection between S3-1 TTP and S2-3 LTP
   within its native topology, and sets up the TTPs, abstracting ODU2 cross-connections
   within the physical nodes S3 S3, S1 and S18 within S2, as shown in section 4.3.2.

   As part of the
      OTN Abstract Topologies exposed by OUD2 cross-connection configuration in node S2, PNC1 and PNC2, respectively.

   To setup
   configures the first (single-domain) EVPL service between R1 and R2, data plane resources (i.e., the MDSC list of timeslots and
   the TPN), to be used by this ODU2 connection on the S2-S31 inter-
   domain link, as requested by the MDSC.

   After the configuration of the ODU2 cross-connection in node S3,
   PNC1 follows similar procedures also configures the [ETH -> (ODU)] and [(ODU2) -> ETH]
   adaptation functions, within node S3, as described shown in section
   5.2.2.1 4.3.2.

   Since the R1-S3 access link is a multi-function access link, PNC1
   also configures the 10GE link before this step.

   Following similar requests from MDSC to set setup ODU2 (Segment) Tunnels
   within the OTN Abstract Topologies they expose as well as the
   steering of the Ethernet client traffic, PNC3 then sets up ODU0 ODU2
   cross-connections on nodes S3, S5 S31 and S6 S33 while PNC2 sets up ODU2
   cross-connections on nodes S15 and S18 as well as the [VLAN [ETH -> (ODU0)]
   (ODU2)] and [(ODU0) [(ODU2) -> VLAN] ETH] adaptation
   functions, functions in nodes S3 and S6, node S18, as
   shown in section 4.3.4. PNC1 4.3.2. PNC2 also configures the 10GE link on the R1-S3
   S18-R8 multi-function access link.

   As part of the [VLAN -> (ODU0)] and [(ODU0) -> VLAN] adaptation
   functions configurations in nodes S2

5.2.2.1. Single Domain Example

   When this IP link, between R1 and S6, PNC1 configures also
   the classification rules required to associated only R2, is needed, the Ethernet
   client traffic received with VLAN ID 10 on CNC requests,
   at the CMI, the R1-S3 and R2-S6
   access links with this EVPL service. The MDSC provides this
   information to PNC1 using the [CLIENT-SIGNAL] model.

   To setup an EPL service.

   Following the second (multi-domain) EVPL service between R1 and R8,
   the MDSC, PNC1, PNC2 and PNC3 follows similar procedures as described in section 5.2.2 to setup 5.2.2, the ODU0 cross-connections MDSC
   requests PCN1 to:

   o  Setup an ODU2 (end-to-end) Tunnel between the AN1-1 and AN1-2
      TTPs, abstracting S3-1 and S6-1 TTPs, within the physical MPI1 OTN
      Abstract Topology exposed by PNC1 at MPI1;

   o  Steer the Ethernet client traffic between the AN1-1 and AN1-8
      LTPs, exposed by PNC1 within MPI1 ETH Abstract Topology, through
      that ODU2 (end-to-end) Tunnel.

   Then PNC1 sets up ODU2 cross-connections on nodes S3, S1, S2, S31, S33, S15 S5 and S18 S6 as
   well as the [VLAN [ETH -> (ODU0)] (ODU)] and [(ODU0) [(ODU2) -> VLAN] ETH] adaptation functions
   in nodes S3 and S18, S6, as shown in section 4.3.4. PNC2 4.3.2. PNC1 also configures
   the 10GE link on the R8-S18 R1-S3 multi-function access link (the R1-S3
   10GE R2-S6
   access link has been already configured when the first EVPL service
   has been setup).

   As part of the [VLAN -> (ODU0)] and [(ODU0) -> VLAN] adaptation
   functions configurations pre-provisioned as a 10GE link, as described in nodes S3 and S18, PNC1
   section 4.4).

5.2.3. Other OTN Client Services

   In this scenario, described in section 4.3.3, the access links are
   configured as STM-64 links and,
   respectively, PNC2 configure also as described in section 5.1,
   reported by each PNC as TE Links within the classification rules required OTN Abstract Topologies
   they expose to associated only the Ethernet client traffic received with VLAN ID
   20 on MDSC.

   The CNC requests, at the R1-S3 and R8-S18 access links with this EVPL service. The CMI, MDSC provides this information to PNC1 setup an STM-64 Private Line
   service between R1 and PNC2 using the
   [CLIENT-SIGNAL] model.

5.3. YANG Models for Protection Configuration

5.3.1. Linear Protection (end-to-end)

   To be discussed R8.

   Following similar procedures as described in future versions of this document.

5.4. Notifications

   Further detailed analysis section 5.2.2, MDSC
   understands that:

   o  R1 is outside the scope of this document

5.5. Path Computation with Constraints

   The path computation constraints that can be supported at the MPI
   using attached to the IETF YANG models defined access link terminating on AN1-1 LTP in [TE-TUNNEL] the
      MPI1 OTN Abstract Topology, exposed by PNC1, and [PATH-
   COMPUTE].

   When there that R8 is a technology specific network (e.g., OTN), the
   corresponding technology (e.g., OTN) model should also be used
      attached to
   specify the tunnel information access link terminating on MPI, with the constraint included AN2-1 LTP in TE Tunnel model.

   Further detailed analysis is outside the scope of this document

6. Security Considerations

   This document analyses MPI2
      OTN Abstract Topology, exposed by PNC2;

   o  it needs to coordinate the applicability setup of a multi-domain ODU2 Tunnel
      between the YANG models being
   defined by AN1-1 and AN2-1 TTPs, abstracting S3-1 and S18-3
      TTPs, within the IETF to support OTN single Abstract Topologies exposed by PNC1 and
      PNC2, respectively.

   The MDSC then performs multi-domain
   scenarios.

   Inherently OTN networks ensure privacy path computation (step 2 in
   Figure 7) and security via hard
   partitioning of traffic onto dedicated circuits. The separation of
   network traffic makes it difficult then requests:

   o  PNC1, at MPI1, to intercept data transferred
   between nodes over OTN-channelized links.

   In OTN the (General Communication setup an ODU2 (Head Segment) Tunnel within the
      MPI1 OTN Abstract Topology;

   o  PNC1, at MPI1, to steer the STM-64 transparent client traffic
      from/to AN1-1 LTP, within the MPI1 OTN Abstract Topology, thought
      that ODU2 (Head Segment) Tunnel;

   o  PNC3, at MPI3, to setup an ODU2 (Transit Segment) Tunnel within
      the MPI3 OTN Abstract Topology;

   o  PNC2, at MPI2, to setup ODU2 (Tail Segment) Tunnel within the
      MPI2 OTN Abstract Topology;

   o  PNC2, at MPI2, to steer the STM-64 transparent client traffic
      to/from AN2-1 LTP, within the MPI2 ETH Abstract Topology, through
      that ODU2 (Tail Segment) Tunnel.

   PNC1, PNC2 and PNC3 then sets up the ODU2 cross-connections within
   the physical nodes S3, S1, S2, S31, S33, S15 and S18 as well as the
   [STM-64 -> (ODU)] and [(ODU2) -> STM-64] adaptation functions in
   nodes S3 and S18, as shown in section 4.3.3. PNC1 and PNC2 also
   configure the STM-64 links on the R1-S3 and R8-S18 multi-function
   access links, respectively.

5.2.3.1. Single Domain Example

   When this IP link, between R1 and R3, is needed, the CNC requests,
   at the CMI, the MDSC to setup an STM-64 Private Line service.

   The MDSC and PNC1 follows similar procedures as described in section
   5.2.2.1 to set up ODU2 cross-connections on nodes S3, S5 and S6 as
   well as the [STM-64 -> (ODU)] and [(ODU2) -> STM-64] adaptation
   functions in nodes S3 and S6, as shown in section 4.3.3. PNC1 also
   configures the STM-64 links on the R1-S3 and R3-S6 multi-function
   access links.

5.2.4. EVPL over ODU Service

   In this scenario, described in section 4.3.4, the access links are
   configured as 10GE links, as described in section 5.2.2 above.

   The CNC requests, at the CMI, the MDSC to setup two EVPL services:
   one between R1 and R2, and another between R1 and R8.

   Following similar procedures as described in section 5.2.2 and
   5.2.2.1, MDSC understands that:

   o  R1 and R2 are attached to the access links terminating
      respectively on AN1-1 and AN1-8 LTPs in the MPI1 ETH Abstract
      Topology, exposed by PNC1, and that R8 is attached to the access
      link terminating on AN2-1 LTP in the MPI2 ETH Abstract Topology,
      exposed by PNC2;

   o  To setup the first (single-domain) EVPL service, between R1 and
      R2, it needs to coordinate the setup of a single-domain ODU0
      Tunnel between the AN1-1 and AN1-8 TTPs, abstracting S3-1 and
      S6-1 TTPs, within the OTN Abstract Topology exposed by PNC1;

   o  To setup the second (multi-domain) EPVL service, between R1 and
      R8, it needs to coordinate the setup of a multi-domain ODU0
      Tunnel between the AN1-1 and AN2-1 TTPs, abstracting nodes S3-1
      and S18-3 TTPs, within the OTN Abstract Topologies exposed by
      PNC1 and PNC2, respectively.

   To setup the first (single-domain) EVPL service between R1 and R2,
   the MDSC and PNC1 follows similar procedures as described in section
   5.2.2.1 to set up ODU0 cross-connections on nodes S3, S5 and S6 as
   well as the [VLAN -> (ODU0)] and [(ODU0) -> VLAN] adaptation
   functions, in nodes S3 and S6, as shown in section 4.3.4. PNC1 also
   configures the 10GE link on the R1-S3 multi-function access link.

   As part of the [VLAN -> (ODU0)] and [(ODU0) -> VLAN] adaptation
   functions configurations in nodes S2 and S6, PNC1 configures also
   the classification rules required to associated only the Ethernet
   client traffic received with VLAN ID 10 on the R1-S3 and R2-S6
   access links with this EVPL service. The MDSC provides this
   information to PNC1 using the [CLIENT-SIGNAL] model.

   To setup the second (multi-domain) EVPL service between R1 and R8,
   the MDSC, PNC1, PNC2 and PNC3 follows similar procedures as
   described in section 5.2.2 to setup the ODU0 cross-connections
   within the physical nodes S3, S1, S2, S31, S33, S15 and S18 as well
   as the [VLAN -> (ODU0)] and [(ODU0) -> VLAN] adaptation functions in
   nodes S3 and S18, as shown in section 4.3.4. PNC2 also configures
   the 10GE link on the R8-S18 multi-function access link (the R1-S3
   10GE link has been already configured when the first EVPL service
   has been setup).

   As part of the [VLAN -> (ODU0)] and [(ODU0) -> VLAN] adaptation
   functions configurations in nodes S3 and S18, PNC1 and,
   respectively, PNC2 configure also the classification rules required
   to associated only the Ethernet client traffic received with VLAN ID
   20 on the R1-S3 and R8-S18 access links with this EVPL service. The
   MDSC provides this information to PNC1 and PNC2 using the
   [CLIENT-SIGNAL] model.

5.3. YANG Models for Protection Configuration

5.3.1. Linear Protection (end-to-end)

   As described in section 4.5.1, the MDSC can decide to protect a
   multi-domain connectivity service by setting up ODU linear
   protection switching between edge nodes controlled by different PNCs
   (e.g., nodes S3 and S8, controlled by PNC1 and PNC2 respectively, to
   protect services between R1 and R8).

   MDSC performs path computation, as described in section 5.2, to
   compute both the paths for working and protection transport
   entities: the computed paths can pass through these same PNC domains
   or through different transit PNC domains.

   Considering the case, described in section 4.5.1, where the working
   and protection transport entities pass through the same domain, MDSC
   would perform the same steps described in section 5.2 to setup the
   ODU Tunnel and to configure the steering of the client traffic
   between the access links and the ODU Tunnel. The only differences
   are in the configuration of the ODU Tunnels.

   MDSC requests at the MPI1, PNC1 to setup an ODU2 (Head Segment)
   Tunnel within the MPI1 OTN Abstract Topology (Figure 4), using the
   TE Tunnel YANG model, defined in [TE-TUNNEL], with the OTN
   technology-specific augmentations, defined in [OTN-TUNNEL], with one
   primary path and one secondary path with1+1 protection switching
   enabled:

   o  Only the Source TTP (i.e., AN1-1 TTP) is specified (since it is a
      Head Segment Tunnel), as described in section 5.2.2;

   o  The egress point for the working transport entity in indicated in
      the route-object-include-exclude list of the explicit-route-
      objects of the primary path, as described in section 5.2.2;

   o  The protection switching end-point in indicated in the route-
      object-include-exclude list of the explicit-route-objects of the
      secondary path:

       o The first element references the TE-Node of the Source TTP
          (i.e., AN1 TE-Node);

   o  The egress point for the protection transport entity in indicated
      in the route-object-include-exclude list of the explicit-route-
      objects of the secondary path:

       o The last two element reference respectively the inter-domain
          link terminating on AN1-6 LTP and the data plane resources
          (i.e., the list of timeslots and the TPN) used by the ODU2
          connection over that link.

   PNC1 knows, as described in the table in section 5.1.1, that the
   AN1-1 TTP, AN1-7 LTP and the AN1-6 LTP, within the MPI1 OTN Abstract
   Topology it exposes at MPI1, correspond to S3-1 TTP, S2-3 LTP and
   the S8-5 LTP, respectively, within its native topology. It also
   understands, from the route-object-include-exclude list of the
   explicit-route-objects of the secondary path configuration (whose
   last two elements represent an inter-domain link), that node S3 is
   the end-point of the protection group while the other end-point is
   outside of its control domain.

   PNC1 can performs path computation within its native topology and
   setup the ODU connections in nodes S3, S1, S2, S4 and S8 as well as
   configure the protection group in node S3.

5.3.2. Segmented Protection

   Under specific policies, it is possible to deploy a segmented
   protection for multi-domain services. The configuration of the
   segmented protection can be divided into a few steps, considering
   the example in section 4.5.2, the following steps would be used.

   MDSC performs path computation, as described in section 5.2, to
   compute all the paths for working and protection transport entities,
   which pass through the same PNC domains and inter-domain links: the
   MDSC would perform the same steps described in section 5.2 to setup
   the ODU Tunnel and to configure the steering of the client traffic
   between the access links and the ODU Tunnel. The only differences
   are in the configuration of the ODU Tunnels.

   MDSC requests at the MPI1, PNC1 to setup an ODU2 (Head Segment)
   Tunnel within the MPI1 OTN Abstract Topology (Figure 4), using the
   TE Tunnel YANG model, defined in [TE-TUNNEL], with the OTN
   technology-specific augmentations, defined in [OTN-TUNNEL], with one
   primary path and one secondary path with 1+1 protection switching
   enabled:

   o  Only the Source TTP (i.e., AN1-1 TTP) is specified (since it is a
      Head Segment Tunnel), as described in section 5.2.2;

   o  The egress point (i.e., AN1-7 LTP) is indicated in the route-
      object-include-exclude list of the explicit-route-objects of the
      primary path, as described in section 5.2.2;

   o  The protection switching end-points are indicated in the route-
      object-include-exclude list of the explicit-route-objects of the
      secondary path:

       o The first element references the TE-Node of the Source TTP
          (i.e., AN1 TE-Node);

       o The last element references the TE-Node of the egress point
          (i.e., AN1 TE-Node).

   As described in section 5.2.2, PNC1 knows that the AN1-1 TTP and the
   AN1-7 LTP, within the MPI1 OTN Abstract Topology it exposes at MPI1,
   correspond to S3-1 TTP and the S2-3 LTP, respectively, within its
   native topology. It also understands, from the route-object-include-
   exclude list of the explicit-route-objects of the secondary path
   configuration (whole last element represent an abstract node
   terminating the inter-domain link used for the primary path), that
   the protection group should be terminated in nodes S3 and S2.

   PNC1 will perform path computations using its native topology and
   setup the ODU connections in nodes S3, S1, S2, S4 and S8 as well as
   configure the protection group in nodes S3 and S2.

   Following similar requests from MDSC to setup ODU2 (Segment)
   Tunnels, with segment protection, within the OTN Abstract Topologies
   they expose. PNC3 then sets up ODU2 cross-connections on nodes S31,
   S32, S33 and S34 and segment protection between nodes S31 and D34.
   PNC2 sets up ODU2 cross-connections on nodes S15, S12, S17 and S18
   and segment protection between nodes S15 and S18.

   MDSC stitch the configuration above to form its internal view of the
   end-to-end tunnel with segmented protection.

   Given the configuration above, the protection capability has been
   deployed on the tunnels. The head-end node of each domain can do the
   switching once there is a failure on one the tunnel segment. For
   example, in Network domain 1, when there is a failure on the S1-S2
   lin, the head-end nodes S2 and S3 will automatically do the
   switching to S3-S4-S8-S2. This switching will be reported to the
   corresponding PNC (PNC1 in this example) and then MDSC. Other PNCs
   (PNC2 and PNC3 in this example) will not be aware of the failure and
   switching, nor do the nodes in Network domain 2 and 3.

5.4. Notifications

   Notification mechanisms are required for the scenarios analyzed in
   this draft, as described in section 4.6.

   The notification mechanisms are protocol-dependent. It is assumed
   that the RESTCONF protocol, defined in [RFC8040], is used at the
   MPIs mentioned in this document.

   On the perspective of MPI, the MDSC is the client while the PNC is
   acting as the server of the notification. The essential event
   streams, subscription and processing rules after receiving
   notification can be found in section 6 of [RFC8040].

5.5. Path Computation with Constraints

   The path computation constraints that can be supported at the MPI
   using the IETF YANG models defined in [TE-TUNNEL] and [PATH-
   COMPUTE].

   When there is a technology-specific network (e.g., OTN), the
   corresponding technology (e.g., OTN) model should also be used to
   specify the tunnel information on MPI, with the constraint included
   in TE Tunnel model.

   Further detailed analysis is outside the scope of this document

6. Security Considerations

   This document analyses the applicability of the YANG models being
   defined by the IETF to support OTN single and multi-domain
   scenarios.

   When deploying ACTN functional components the securing of external
   interfaces and hardening of resource datastores, the protection of
   confidential information, and limiting the access of function,
   should all be carefully considered.  Section 9 of [RFC8453]
   highlights that implementations should consider encrypting data that
   flows between key components, especially when they are implemented
   at remote node. Further discussion on securing the interface between
   the MDSC and PNCs via the MDSC-PNC Interface (MPI) is discussed in
   section 9.2 of [RFC8453].

   The YANG modules highlighted in this document are designed to be
   accessed via network configuration protocols such as NETCONF
   [RFC6241] or RESTCONF [RFC8040]. When using NETCONF, utilizing a
   secure transport via Secure Shell (SSH) [RFC6242] is mandatory. If
   using RESTCONF, then secure transport via TLS [RFC8446] is
   mandatory. When using either NETCONF or RESTCONF, the use of Network
   Configuration Access Control Model (NACM) [RFC8341] may be used to
   restrict access to specific protocol operations and content.

6.1. OTN Security

   Inherently OTN networks ensure privacy and security via hard
   partitioning of traffic onto dedicated circuits. The separation of
   network traffic makes it difficult to intercept data transferred
   between nodes over OTN-channelized links.

   In OTN the (General Communication Channel) GCC is used for OAM
   functions such as performance monitoring, fault detection, and
   signaling. The GCC control channel should be secured using a
   suitable mechanism.

   There are no additional or new security considerations introduced by
   this document.

7. IANA Considerations

   This document requires no IANA actions.

8. References

8.1. Normative References

   [RFC4427] Mannie, E., Papadimitriou, D., "Recovery (Protection and
             Restoration) Terminology for Generalized Multi-Protocol
             Label Switching (GMPLS)", RFC 4427, March 2006.

   [RFC4655] Farrel, A. et al., "A Path Computation Element (PCE)-Based
             Architecture", RFC4655, August 2006.

   [RFC7926] Farrel, A. et al., "Problem Statement and Architecture for
             Information Exchange between Interconnected Traffic-
             Engineered Networks", BCP 206, RFC 7926, July 2016.

   [RFC8345] Clemm, A.,Medved, J. et al., "A Yang Data Model for
             Network Topologies", RFC8345, March 2018.

   [RFC8453] Ceccarelli, D., Lee, Y. et al., "Framework for Abstraction
             and Control of TE Networks (ACTN)", RFC8453, August 2018.

   [ITU-T G.709] ITU-T Recommendation G.709 (06/16), "Interfaces for
             the optical transport network", June 2016.

   [ITU-T G.808.1] ITU-T Recommendation G.808.1 (05/14), "Generic
             protection switching - Linear trail and subnetwork
             protection", May 2014.

   [ITU-T G.873.1] ITU-T Recommendation G.873.1 (05/14), (10/17), "Optical
             transport network (OTN): Linear protection", May 2014. October 2017.

   [TE-TOPO] Liu, X. et al., "YANG Data Model for TE Topologies",
             draft-ietf-teas-yang-te-topo, work in progress.

   [OTN-TOPO] Zheng, H. et al., "A YANG Data Model for Optical
             Transport Network Topology", draft-ietf-ccamp-otn-topo-
             yang, work in progress.

   [CLIENT-TOPO]  Zheng, H. et al., "A YANG Data Model for Client-layer
             Topology", draft-zheng-ccamp-client-topo-yang, work in
             progress.

   [TE-TUNNEL] Saad, T. et al., "A YANG Data Model for Traffic
             Engineering Tunnels and Interfaces", draft-ietf-teas-yang-
             te, work in progress.

   [PATH-COMPUTE] Busi, I., Belotti, S. et al, "Yang model for
             requesting Path Computation", draft-ietf-teas-yang-path-
             computation, work in progress.

   [OTN-TUNNEL]   Zheng, H. et al., "OTN Tunnel YANG Model", draft-
             ietf-ccamp-otn-tunnel-model, work in progress.

   [CLIENT-SIGNAL]   Zheng, H. et al., "A YANG Data Model for Optical Transport
             Network Client Signals", draft-zheng-ccamp-otn-
             client-signal-yang, draft-ietf-ccamp-client-signal-
             yang, work in progress.

8.2. Informative References

   [RFC5151] Farrel, A.

   [RFC6241] Enns, R. et al., "Inter-Domain MPLS and GMPLS Traffic
             Engineering --Resource Reservation Protocol-Traffic
             Engineering (RSVP-TE) Extensions", "Network Configuration Protocol
             (NETCONF)", RFC 6241, June 2011.

   [RFC6242] Wasserman, W., "Using the NETCONF Protocol over Secure
             Shell (SSH)", RFC 5151, February
             2008. 6242, June 2011.

   [RFC6898] Li, D. et al., "Link Management Protocol Behavior
             Negotiation and Configuration Modifications", RFC 6898,
             March 2013.

   [RFC8040] Bierman, A. et al., "RESTCONF Protocol", RFC 8040, January
             2017.

   [RFC8309] Wu, Q. et al., "Service Models Explained", RFC 8309,
             January 2018.

   [RFC8341] Bierman, A., Bjorklund, M., "Network Configuration Access
             Control Model", RFC 8341, March 2018.

   [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
             Version 1.3", RFC 8446, August 2018.

   [ACTN-YANG] Zhang, X. et al., "Applicability of YANG models for
             Abstraction and Control of Traffic Engineered Networks",
             draft-zhang-teas-actn-yang, work in progress.

   [RFC-FOLD]  Watsen, K. et al., "Handling Long Lines in Artwork in
             Internet-Drafts and RFCs", draft-ietf-netmod-artwork-
             folding, work in progress

   [TE-TUTORIAL]  Bryskin, I. et al., "TE Topology and Tunnel Modeling
             for Transport Networks", draft-ietf-teas-te-topo-and-
             tunnel-modeling, work in progress

   [ONF TR-527] ONF Technical Recommendation TR-527, "Functional
             Requirements for Transport API", June 2016.

   [ONF GitHub] ONF Open Transport (SNOWMASS),
             <https://github.com/OpenNetworkingFoundation/Snowmass-
             ONFOpenTransport>

   [MEF 55] Metro Ethernet Forum, "Lifecycle Service Orchestration
             (LSO): Reference Architecture and Framework", Technical
             Specification MEF 55, March 2016,
             <https://www.mef.net/Assets/Technical_Specifications/PDF/M
             EF_55.pdf>

9. Acknowledgments

   The authors would like to thank all members of the Transport NBI
   Design Team involved in the definition of use cases, gap analysis
   and guidelines for using the IETF YANG models at the Northbound
   Interface (NBI) of a Transport SDN Controller.

   The authors would like to thank Xian Zhang, Anurag Sharma, Sergio
   Belotti, Tara Cummings, Michael Scharf, Karthik Sethuraman, Oscar
   Gonzalez de Dios, Hans Bjursrom and Italo Busi for having initiated
   the work on gap analysis for transport NBI and having provided
   foundations work for the development of this document.

   The authors would like to thank the authors of the TE Topology and
   Tunnel YANG models [TE-TOPO] and [TE-TUNNEL], in particular, Igor
   Bryskin, Vishnu Pavan Beeram, Tarek Saad and Xufeng Liu, for their
   support in addressing any gap identified during the analysis work.

   The authors would like to thank Henry Yu and Aihua Guo for their
   input and review of the URIs structures used within the JSON code
   examples.

   This work was supported in part by the European Commission funded
   H2020-ICT-2016-2 METRO-HAUL project (G.A. 761727).

   This document was prepared using 2-Word-v2.0.template.dot.

Appendix A. Validating a JSON fragment against a YANG Model

   The objective is to have a tool that allows validating whether a
   piece of JSON code embedded in an Internet-Draft is compliant with a
   YANG model without using a client/server.

A.1.  Manipulation of JSON fragments

   This section describes the various ways JSON fragments are used in
   the I-D processing and how to manage them.

   Let's call "folded-JSON" the JSON embedded in the I-D: it fits the
   72 chars width and it is acceptable for it to be invalid JSON.

   We then define "unfolded-JSON" a valid JSON fragment having the same
   contents of the "folded-JSON " without folding, i.e. limits on the
   text width. The folding/unfolding operation may be done according to
   [RFC-FOLD]. The "unfolded-JSON" can be edited by the authors using
   JSON editors with the advantages of syntax validation and pretty-
   printing.

   Both the "folded" and the "unfolded" JSON fragments can include
   comments having descriptive fields and directives we'll describe
   later to facilitate the reader and enable some automatic processing.

   The presence of comments in the "unfolded-JSON" fragment makes it an
   invalid JSON encoding of YANG data. Therefore we call "naked JSON"
   the JSON where the comments have been stripped out: not only it is
   valid JSON but it is a valid JSON encoding of YANG data.

   The following schema resumes these definitions:

                       unfold_it -->             stripper -->

             Folded-JSON           Unfolded-JSON             Naked JSON

                       <-- fold_it              <-- author edits

   <=72-chars?    MUST              MAY                      MAY    must              may                      may

   valid JSON?     MAY             MUST                     MUST     may             must                     must

   JSON-encoding   MAY              MAY                     MUST
   of YANG data data?   may              may                     must

   Our validation toolchain has been designed to take a JSON in any of
   the three formats and validate it automatically against a set of
   relevant YANG modules using available open-source tools. It can be
   found at: https://github.com/GianmarcoBruno/json-yang/

A.2.  Comments in JSON fragments

   We found useful to introduce two kinds of comments, both defined as
   key-value pairs where the key starts with "//":

   - free-form descriptive comments, e.g."// COMMENT" : "refine this"
   to describe properties of JSON fragments.

   - machine-usable directives e.g. "// __REFERENCES__DRAFTS__" : {
   "ietf-routing-types@2017-12-04": "rfc8294",} which can be used to
   automatically download from the network the relevant I-Ds or RFCs
   and extract from them the YANG models of interest. This is
   particularly useful to keep consistency when the drafting work is
   rapidly evolving.

A.3.  Validation of JSON fragments: DSDL-based approach

   The idea is to generate a JSON driver file (JTOX) from YANG, then
   use it generate a JSON driver file (JTOX) from YANG, then
   use it to translate JSON to XML and validate it against the DSDL
   schemas, as shown in Figure 8.

   Useful link: https://github.com/mbj4668/pyang/wiki/XmlJson
                           (2)
               YANG-module ---> DSDL-schemas (RNG,SCH,DSRL)
                      |                  |
                      | (1)              |
                      |                  |
      Config/state  JTOX-file            | (4)
             \        |                  |
              \       |                  |
               \      V                  V
      JSON-file------------> XML-file ----------------> Output
                 (3)

           Figure 8 - DSDL-based approach for JSON code validation

   In order to allow the use of comments following the convention
   defined in section 3, without impacting the validation process,
   these comments will be automatically removed from the JSON-file that
   will be validate.

A.4.  Validation of JSON fragments: why not using an XSD-based approach

   This approach has been analyzed and discarded because no longer
   supported by pyang.

   The idea is to convert YANG to translate XSD, JSON to XML and validate it
   against the DSDL
   schemas, XSD, as shown in Figure 8.

   Useful link: https://github.com/mbj4668/pyang/wiki/XmlJson

                           (2) 9:

                     (1)
         YANG-module ---> DSDL-schemas (RNG,SCH,DSRL)
                      |                  |
                      | (1)              |
                      |                  |
      Config/state  JTOX-file            | (4) XSD-schema - \       (3)
                                        +--> Validation
         JSON-file------> XML-file ----/
                     (2)

           Figure 9 - XSD-based approach for JSON code validation

   The pyang support for the XSD output format was deprecated in 1.5
   and removed in 1.7.1. However pyang 1.7.1 is necessary to work with
   YANG 1.1 so the process shown in Figure 9 will stop just at step
   (1).

Appendix B. Detailed JSON Examples

   The JSON code examples provided in this appendix have been validated
   using the tools in Appendix A and folded using the tool in [RFC-
   FOLD].

B.1.  JSON Examples for Topology Abstractions

B.1.1.   JSON Code: mpi1-otn-topology.json

   This is the JSON code reporting the OTN Topology @ MPI1:

   ========== NOTE: '\\' line wrapping per BCP XXX (RFC XXXX) ==========

   {
     "// __LAST_UPDATE__": "October 21, 2019",
     "// __TITLE__": "ODU Black Topology @ MPI1",
     "// __REFERENCE_DRAFTS__": {
       "ietf-routing-types@2017-12-04": "rfc8294",
       "ietf-te-types@2019-07-05": "draft-ietf-teas-yang-te-types-10",
       "ietf-layer1-types@2019-09-09": "draft-ietf-ccamp-layer1-types-0\
   \2",
       "ietf-network@2018-02-26": "rfc8345",
       "ietf-network-topology@2018-02-26": "rfc8345",
       "ietf-te-topology@2019-02-07": "draft-ietf-teas-yang-te-topo-22",
       "ietf-otn-topology@2019-07-07": "draft-ietf-ccamp-otn-topo-yang-\
   \08"
     },
     "// __MISSING_ATTRIBUTES__": true,
     "ietf-network:networks": {
       "network": [
         {
           "network-id": "providerId/201/clientId/300/topologyId/otn-bl\
   \ack-topology",
           "network-types": {
             "ietf-te-topology:te-topology": {
               "ietf-otn-topology:otn-topology": {}
             }
           },
           "ietf-te-topology:te-topology-identifier": {
             "provider-id": 201,
             "client-id": 300,
             "topology-id": "otn-black-topology"
           },
           "// __COMMENT__ ietf-te-topology:te": "presence container re\
   \quires: provider-id, client-id and te-topology-id",
           "ietf-te-topology:te": {
             "name": "OTN Black Topology @ MPI1"
           },
           "ietf-network:node": [
             {
               "// __NODE__:__DESCRIPTION__": {
                 "name": "AN1",
                 "identifier": "10.0.0.1",
                 "type": "Abstract Node",
                 "physical node(s)": "The whole network domain 1"
               },
               "node-id": "10.0.0.1",
               "ietf-te-topology:te-node-id": "10.0.0.1",
               "ietf-te-topology:te": {
                 "te-node-attributes": {
                   "name": "AN11",
                   "is-abstract": "",
                   "admin-status": "up"
                 },
                 "oper-status": "up",
                 "tunnel-termination-point": [
                   {
                     "// __COMMENT__ tunnel-tp-id": "AN1-1 TTP-ID (1 ->\
   \        |                  | 0x01 -> 'AQ==')",
                     "tunnel-tp-id": "AQ==",
                     "name": "AN1-1 OTN TTP",
                     "// __COMMENT__ encoding and switching-capability"\
   \: "OTN (ODU)",
                     "switching-capability": "ietf-te-types:switching-o\
   \tn",
                     "encoding": "ietf-te-types:lsp-encoding-oduk",
                     "// __COMMENT__ inter-layer-lock-id": "{ AN1-1 ILL\
   \-ID (1) }",
                     "inter-layer-lock-id": [
                       1
                     ],
                     "admin-status": "up",
                     "oper-status": "up"
                   },
                   {
                     "// __COMMENT__ tunnel-tp-id": "AN1-2 TTP-ID (2 ->\
   \       |                  | 0x02 -> 'Ag==')",
                     "tunnel-tp-id": "Ag==",
                     "name": "AN1-2 OTN TTP",
                     "// __COMMENT__ encoding and switching-capability"\
   \: "OTN (ODU)",
                     "switching-capability": "ietf-te-types:switching-o\
   \tn",
                     "encoding": "ietf-te-types:lsp-encoding-oduk",
                     "// __COMMENT__ inter-layer-lock-id": "{ AN1-2 ILL\
   \-ID (2) }",
                     "inter-layer-lock-id": [
                       2
                     ],
                     "admin-status": "up",
                     "oper-status": "up"
                   },
                   {
                     "// __COMMENT__ tunnel-tp-id": "AN1-3 TTP-ID (3 ->\
   \      V                  V
      JSON-file------------> XML-file ----------------> Output 0x03 -> 'Awo=')",
                     "tunnel-tp-id": "Awo=",
                     "name": "AN1-3 OTN TTP",
                     "// __COMMENT__ encoding and switching-capability"\
   \: "OTN (ODU)",
                     "switching-capability": "ietf-te-types:switching-o\
   \tn",
                     "encoding": "ietf-te-types:lsp-encoding-oduk",
                     "// __COMMENT__ inter-layer-lock-id": "{ AN1-3 ILL\
   \-ID (3)

           Figure }",
                     "inter-layer-lock-id": [
                       3
                     ],
                     "admin-status": "up",
                     "oper-status": "up"
                   },
                   {
                     "// __COMMENT__ tunnel-tp-id": "AN1-8 TTP-ID (8 ->\
   \ 0x08 -> 'CA==')",
                     "tunnel-tp-id": "CA==",
                     "name": "AN1-8 OTN TTP",
                     "// __COMMENT__ encoding and switching-capability"\
   \: "OTN (ODU)",
                     "switching-capability": "ietf-te-types:switching-o\
   \tn",
                     "encoding": "ietf-te-types:lsp-encoding-oduk",
                     "// __COMMENT__ inter-layer-lock-id": "{ AN1-8 ILL\
   \-ID (1) }",
                     "inter-layer-lock-id": [
                       8 - DSDL-based approach for JSON code validation

   In order to allow the use of comments following the convention
   defined in section 3, without impacting the validation process,
   these comments will be automatically removed from the JSON-file that
   will be validate.

A.4.  Validation of JSON fragments: why not using a XSD-based approach

   This approach has been analyzed
                     ],
                     "admin-status": "up",
                     "oper-status": "up"

                   }
                 ]
               },
               "ietf-network-topology:termination-point": [
                 {
                   "// __DESCRIPTION__:__LTP__": {
                     "name": "AN1-1 LTP",
                     "link type(s)": "Multi-function (OTU2, STM-64 and discarded because no longer
   supported by pyang.

   The idea \
   \10GE)",
                     "physical node": "S3",
                     "unnumberd/ifIndex": 1,
                     "port type": "tributary port",
                     "connected to": "R1"
                   },
                   "tp-id": "1",
                   "ietf-te-topology:te-tp-id": 1,
                   "ietf-te-topology:te": {
                     "name": "AN1-1 LTP",
                     "interface-switching-capability": [
                       {
                         "// __COMMENT__ encoding and switching-capabil\
   \ity": "OTN (ODU)",
                         "switching-capability": "ietf-te-types:switchi\
   \ng-otn",
                         "encoding": "ietf-te-types:lsp-encoding-oduk",
                         "max-lsp-bandwidth": [
                           {
                             "priority": 0,
                             "te-bandwidth": {
                               "ietf-otn-topology:odu-type": "ietf-laye\
   \r1-types:ODU2"
                             }
                           }
                         ]
                       }
                     ],
                     "// __NOT-PRESENT__ inter-domain-plug-id": "Use of\
   \ plug-id for access Link is to convert YANG to XSD, JSON to XML and validate it
   against outside the XSD, as shown in Figure 9: scope of this document",
                     "// __COMMENT__ inter-layer-lock-id": "{ AN1-1 ILL\
   \-ID (1)
         YANG-module ---> XSD-schema - }",
                     "inter-layer-lock-id": [
                       1
                     ],
                     "admin-status": "up",
                     "oper-status": "up",
                     "ietf-otn-topology:client-svc": {
                       "client-facing": true,
                       "supported-client-signal": [
                         "ietf-layer1-types:STM-64"
                       ]
                     }
                   }
                 },
                 {
                   "// __DESCRIPTION__:__LTP__": {
                     "name": "AN1-2 LTP",
                     "link type(s)": "Multi-function (OTU2 and STM-64)",
                     "physical node": "S6",
                     "unnumberd/ifIndex": 2,
                     "port type": "tributary port",
                     "connected to": "R3"
                   },
                   "tp-id": "2",
                   "ietf-te-topology:te-tp-id": 2,
                   "ietf-te-topology:te": {
                     "name": "AN1-2 LTP",
                     "interface-switching-capability": [
                       {
                         "// __COMMENT__ encoding and switching-capabil\
   \ity": "OTN (ODU)",
                         "switching-capability": "ietf-te-types:switchi\
   \ng-otn",
                         "encoding": "ietf-te-types:lsp-encoding-oduk",
                         "max-lsp-bandwidth": [
                           {
                             "priority": 0,
                             "te-bandwidth": {
                               "ietf-otn-topology:odu-type": "ietf-laye\
   \r1-types:ODU2"
                             }
                           }
                         ]
                       }
                     ],
                     "// __NOT-PRESENT__ inter-domain-plug-id": "Use of\
   \       (3)
                                        +--> Validation
         JSON-file------> XML-file ----/
                     (2)

           Figure 9 - XSD-based approach for JSON code validation

   The pyang support plug-id for the XSD output format was deprecated in 1.5
   and removed in 1.7.1. However pyang 1.7.1 access Link is necessary to work with
   YANG 1.1 so outside the process shown in Figure 9 will stop just at step
   (1).

Appendix B. Detailed JSON Examples

   The JSON code examples provided in scope of this appendix have been validated
   using the tools in Appendix A and folded using the tool in [RFC-
   FOLD].

B.1.  JSON Examples for Topology Abstractions

B.1.1.   JSON Code: mpi1-otn-topology.json

   This document",
                     "// __COMMENT__ inter-layer-lock-id": "{ AN1-2 ILL\
   \-ID (2) }",
                     "inter-layer-lock-id": [
                       2
                     ],
                     "admin-status": "up",
                     "oper-status": "up",
                     "ietf-otn-topology:client-svc": {
                       "client-facing": true,
                       "supported-client-signal": [
                         "ietf-layer1-types:STM-64"
                       ]
                     }
                   }
                 },
                 {
                   "// __DESCRIPTION__:__LTP__": {
                     "name": "AN1-3 LTP",
                     "link type(s)": "STM-64",
                     "physical node": "S6",
                     "unnumberd/ifIndex": 3,
                     "port type": "tributary port",
                     "connected to": "R4"
                   },
                   "tp-id": "3",
                   "ietf-te-topology:te-tp-id": 3,
                   "ietf-te-topology:te": {
                     "name": "AN1-3 LTP",
                     "// __NOT-PRESENT__ interface-switching-capability\
   \": "STM-64 Access Link only (no ODU switching)",
                     "// __NOT-PRESENT__ inter-domain-plug-id": "Use of\
   \ plug-id for access Link is outside the JSON code reporting the OTN Topology @ MPI:

   ========== NOTE: '\\' line wrapping per BCP XX (RFC XXXX) =========== scope of this document",
                     "// __COMMENT__ inter-layer-lock-id": "{ AN1-3 ILL\
   \-ID (3) }",
                     "inter-layer-lock-id": [
                       3
                     ],
                     "admin-status": "up",
                     "oper-status": "up",
                     "ietf-otn-topology:client-svc": {
                       "client-facing": true,
                       "supported-client-signal": [
                         "ietf-layer1-types:STM-64"
                       ]
                     }
                   }

                 },
                 {
                   "// __TITLE__": __DESCRIPTION__:__LTP__": {
                     "name": "AN1-4 LTP",
                     "link type(s)": "OTU4",
                     "physical node": "S7",
                     "unnumberd/ifIndex": 3,
                     "port type": "inter-domain port",
                     "connected to": "S11"
                   },
                   "tp-id": "4",
                   "ietf-te-topology:te-tp-id": 4,
                   "ietf-te-topology:te": {
                     "name": "AN1-4 LTP",
                     "interface-switching-capability": [
                       {
                         "// __COMMENT__ encoding and switching-capabil\
   \ity": "OTN (ODU)",
                         "switching-capability": "ietf-te-types:switchi\
   \ng-otn",
                         "encoding": "ietf-te-types:lsp-encoding-oduk",
                         "max-lsp-bandwidth": [
                           {
                             "priority": 0,
                             "te-bandwidth": {
                               "ietf-otn-topology:odu-type": "ietf-laye\
   \r1-types:ODU4"
                             }
                           }
                         ]
                       }
                     ],
                     "// __COMMENT__ inter-domain-plug-id": "S7-S11 Plu\
   \g-id (0x000711 -> AAcR)",
                     "inter-domain-plug-id": "AAcR",
                     "// __NOT-PRESENT__ inter-layer-lock-id": "ODU Black Topology @ MPI1", Ser\
   \ver Layer topology not exposed",
                     "admin-status": "up",
                     "oper-status": "up",
                     "// __LAST_UPDATE__": "October 18, 2018", __NOT-PRESENT__ ietf-otn-topology:client-svc":\
   \ "OTN inter-domain link"
                   }
                 },
                 {
                   "// __DESCRIPTION__:__LTP__": {
                     "name": "AN1-5 LTP",
                     "link type(s)": "OTU4",
                     "physical node": "S8",
                     "unnumberd/ifIndex": 4,
                     "port type": "inter-domain port",
                     "connected to": "S12"
                   },
                   "tp-id": "5",
                   "ietf-te-topology:te-tp-id": 5,
                   "ietf-te-topology:te": {
                     "name": "AN1-5 LTP",
                     "interface-switching-capability": [
                       {
                         "// __COMMENT__ encoding and switching-capabil\
   \ity": "OTN (ODU)",
                         "switching-capability": "ietf-te-types:switchi\
   \ng-otn",
                         "encoding": "ietf-te-types:lsp-encoding-oduk",
                         "max-lsp-bandwidth": [
                           {
                             "priority": 0,
                             "te-bandwidth": {
                               "ietf-otn-topology:odu-type": "ietf-laye\
   \r1-types:ODU4"
                             }
                           }
                         ]
                       }
                     ],
                     "// __COMMENT__ inter-domain-plug-id": "S8.S12 Plu\
   \g-id (0x000812 -> AAgS)",
                     "inter-domain-plug-id": "AAgS",
                     "// __NOT-PRESENT__ inter-layer-lock-id": "ODU Ser\
   \ver Layer topology not exposed",
                     "admin-status": "up",
                     "oper-status": "up",
                     "// __NOT-PRESENT__ ietf-otn-topology:client-svc":\
   \ "OTN inter-domain link"
                   }
                 },
                 {
                   "// __DESCRIPTION__:__LTP__": {
                     "name": "AN1-6 LTP",
                     "link type(s)": "OTU4",
                     "physical node": "S8",
                     "unnumberd/ifIndex": 5,
                     "port type": "inter-domain port",
                     "connected to": "S32"
                   },
                   "tp-id": "6",
                   "ietf-te-topology:te-tp-id": 6,
                   "ietf-te-topology:te": {
                     "name": "AN1-6 LTP",
                     "interface-switching-capability": [
                       {
                         "// __COMMENT__ encoding and switching-capabil\
   \ity": "OTN (ODU)",
                         "switching-capability": "ietf-te-types:switchi\
   \ng-otn",
                         "encoding": "ietf-te-types:lsp-encoding-oduk",
                         "max-lsp-bandwidth": [
                           {
                             "priority": 0,
                             "te-bandwidth": {
                               "ietf-otn-topology:odu-type": "ietf-laye\
   \r1-types:ODU4"
                             }
                           }
                         ]
                       }
                     ],
                     "// __COMMENT__ inter-domain-plug-id": "S8.S32 Plu\
   \g-id (0x000832 -> AAgy)",
                     "inter-domain-plug-id": "AAgy",
                     "// __MISSING_ATTRIBUTES__": true, __NOT-PRESENT__ inter-layer-lock-id": "ODU Ser\
   \ver Layer topology not exposed",
                     "admin-status": "up",
                     "oper-status": "up",
                     "// __REFERENCE_DRAFTS__": {
       "ietf-routing-types@2017-12-04": "rfc8294",
       "ietf-otn-types@2017-10-30": "draft-ietf-ccamp-otn-tunnel-model-\
   \01",
       "ietf-network@2018-02-26": "rfc8345",
       "ietf-network-topology@2018-02-26": "rfc8345",
       "ietf-te-types@2018-06-12": "draft-ietf-teas-yang-te-15",
       "ietf-te-topology@2018-06-15": "draft-ietf-teas-yang-te-topo-18",
       "ietf-otn-topology@2017-10-30": "draft-ietf-ccamp-otn-topo-yang-\
   \02" __NOT-PRESENT__ ietf-otn-topology:client-svc":\
   \ "OTN inter-domain link"
                   }
                 },
                 {
                   "// __RESTCONF_OPERATION__": __DESCRIPTION__:__LTP__": {
       "operation": "GET",
       "url": "http://{{PNC1-ADDR}}/restconf/data/ietf-network:networks"
                     "name": "AN1-7 LTP",
                     "link type(s)": "OTU4",
                     "physical node": "S2",
                     "unnumberd/ifIndex": 3,
                     "port type": "inter-domain port",
                     "connected to": "S31"
                   },
     "ietf-network:networks":
                   "tp-id": "7",
                   "ietf-te-topology:te-tp-id": 7,
                   "ietf-te-topology:te": {
       "network":
                     "name": "AN1-7 LTP",
                     "interface-switching-capability": [
                       {
           "network-id": "providerId/201/clientId/300/topologyId/otn-bl\
   \ack-topology",
           "network-types":
                         "// __COMMENT__ encoding and switching-capabil\
   \ity": "OTN (ODU)",
                         "switching-capability": "ietf-te-types:switchi\
   \ng-otn",
                         "encoding": "ietf-te-types:lsp-encoding-oduk",
                         "max-lsp-bandwidth": [
                           {
             "ietf-te-topology:te-topology":
                             "priority": 0,
                             "te-bandwidth": {
               "ietf-otn-topology:otn-topology": {}
                               "ietf-otn-topology:odu-type": "ietf-laye\
   \r1-types:ODU4"
                             }
           },
           "ietf-te-topology:provider-id": 201,
           "ietf-te-topology:client-id": 300,
           "ietf-te-topology:te-topology-id": "otn-black-topology",
                           }
                         ]
                       }
                     ],
                     "// ietf-te-topology:te": "presence container requires: prov\
   \ider, client and te-topology-id",
           "ietf-te-topology:te": {
             "name": "OTN Black Topology @ MPI1"
           }, __COMMENT__ inter-domain-plug-id": "S2-S31 Plu\
   \g-id (0x000231 -> AAIx)",
                     "inter-domain-plug-id": "AAIx",
                     "// ietf-network:node": "Access LTPs to be reviewed in a fut\
   \ure update",
           "ietf-network:node": __NOT-PRESENT__ inter-layer-lock-id": "ODU Ser\
   \ver Layer topology not exposed",
                     "admin-status": "up",
                     "oper-status": "up",
                     "// __NOT-PRESENT__ ietf-otn-topology:client-svc":\
   \ "OTN inter-domain link"
                   }
                 }
               ]
             }
           ],
           "ietf-network-topology:link": [
             {
               "// __NODE__:__DESCRIPTION__": __DESCRIPTION__:__LINK__": {
                 "name": "AN1",
                 "identifier": "10.0.0.1", "Access Link from AN1-1",
                 "type": "Abstract Node", "Multi-function access link (OTU2, STM-64 and \
   \10GE)",
                 "physical node(s)": "whole network domain 1" link": "Link from S3-1 to R1"
               },
               "node-id": "10.0.0.1",
               "ietf-te-topology:te-node-id":
               "link-id": "teNodeId/10.0.0.1/teLinkId/1",
               "source": {
                 "source-node": "10.0.0.1",
                 "source-tp": 1
               },
               "// __NOT-PRESENT__ destination": "access link",
               "ietf-te-topology:te": {
                 "te-node-attributes":
                 "te-link-attributes": {
                   "name": "AN11",
                   "admin-status": "up", "Access Link from AN1-1",
                   "// __NOT-PRESENT__ external-domain": "The plug-id i\
   \s used instead of this container",
                   "// __DISCUSS__ __NOT-PRESENT__ is-abstract": "To be discussed with \
   \TE Topology authors", "The access link i\
   \s not abstract",
                   "interface-switching-capability": [
                     {
                       "// __COMMENT__ encoding and switching-capabilit\
   \y": "OTN (ODU)",
                       "switching-capability": "ietf-te-types:switching\
   \-otn",
                       "encoding": "ietf-te-types:lsp-encoding-oduk",
                       "max-lsp-bandwidth": [
                         {
                           "priority": 0,
                           "te-bandwidth": {
                             "ietf-otn-topology:odu-type": "ietf-layer1\
   \-types:ODU2"
                           }
                         }
                       ]
                     }
                   ],
                   "// __COMMENT__ label-restrictions": "Outside the sc\
   \ope of this JSON example",
                   "max-link-bandwidth": {
                     "te-bandwidth": {
                       "ietf-otn-topology:odulist": [
                         {
                           "odu-type": "ietf-layer1-types:ODU2",
                           "number": 1
                         }

                       ]
                     }
                   },
                   "max-resv-link-bandwidth": {
                     "te-bandwidth": {
                       "ietf-otn-topology:odulist": [
                         {
                           "odu-type": "ietf-layer1-types:ODU2",
                           "number": 1
                         }
                       ]
                     }
                   },
                   "unreserved-bandwidth": [
                     {
                       "priority": 0,
                       "te-bandwidth": {
                         "ietf-otn-topology:odulist": [
                           {
                             "odu-type": "ietf-layer1-types:ODU2",
                             "number": 1
                           }
                         ]
                       }
                     }
                   ],
                   "// __DISCUSS__ underlay-topology": "To be discussed\ __NOT-PRESENT__ ietf-otn-topology:tsg": "Access \
   \Link with TE Topology authors" no HO-ODU termination and LO-ODU switching",
                   "admin-status": "up"
                 },
                 "oper-status": "up",
                 "// __DISCUSS__ tunnel-termination-point": [] __NOT-PRESENT__ is-transitional": "It is not a tra\
   \nsitional link"
               }
             },
               "ietf-network-topology:termination-point": [
             {
               "// __DESCRIPTION__:__LTP__": __DESCRIPTION__:__LINK__": {
                 "name": "AN1-1 LTP",
                     "link type(s)": "OTU-2", "Access Link from AN1-2",
                 "type": "Multi-function access link (OTU2 and STM-64)",
                 "physical node": "S3",
                     "unnumberd/ifIndex": 1,
                     "port type": "tributary port",
                     "connected to": "R1" link": "Link from S6-2 to R3"
               },
                   "tp-id": "1",
                   "ietf-te-topology:te-tp-id": 1,
               "link-id": "teNodeId/10.0.0.1/teLinkId/2",
               "source": {
                 "source-node": "10.0.0.1",
                 "source-tp": 2
               },
               "// __NOT-PRESENT__ destination": "access link",
               "ietf-te-topology:te": {
                 "te-link-attributes": {
                   "name": "AN1-1 LTP",
                     "admin-status": "up",
                     "// __DISCUSS__ interface-switching-capability": "\
   \See "Access Link attributes (teNodeId/10.0.0.1/teLinkId/1)", from AN1-2",
                   "// __DISCUSS__ inter-domain-plug-id": "Access Lin\
   \k", __NOT-PRESENT__ external-domain": "The plug-id i\
   \s used instead of this container",
                   "// __NOT-PRESENT__ is-abstract": "The access link i\
   \s not abstract",
                   "interface-switching-capability": [
                     {
                       "// __COMMENT__ inter-layer-lock-id": "Empty: OTN \
   \Links are pre-configured",
                     "oper-status": "up", encoding and switching-capabilit\
   \y": "OTN (ODU)",
                       "switching-capability": "ietf-te-types:switching\
   \-otn",
                       "encoding": "ietf-te-types:lsp-encoding-oduk",
                       "max-lsp-bandwidth": [
                         {
                           "priority": 0,
                           "te-bandwidth": {
                             "ietf-otn-topology:odu-type": "ietf-layer1\
   \-types:ODU2"
                           }
                         }
                       ]
                     }
                   ],
                   "// __DISCUSS__ ietf-otn-topology:supported-payloa\
   \d-types": "List __COMMENT__ label-restrictions": "Outside the sc\
   \ope of ODU clients?", this JSON example",
                   "max-link-bandwidth": {
                     "te-bandwidth": {
                       "ietf-otn-topology:odulist": [
                         {
                           "odu-type": "ietf-layer1-types:ODU2",
                           "number": 1
                         }
                       ]
                     }
                   },
                   "max-resv-link-bandwidth": {
                     "te-bandwidth": {
                       "ietf-otn-topology:odulist": [
                         {
                           "odu-type": "ietf-layer1-types:ODU2",
                           "number": 1
                         }
                       ]
                     }
                   },
                   "unreserved-bandwidth": [
                     {
                       "priority": 0,
                       "te-bandwidth": {
                         "ietf-otn-topology:odulist": [
                           {
                             "odu-type": "ietf-layer1-types:ODU2",
                             "number": 1
                           }
                         ]
                       }
                     }
                   ],
                   "// __DISCUSS__ ietf-otn-topology:client-facing": __NOT-PRESENT__ ietf-otn-topology:tsg": "Access \

   \true
   \Link with no HO-ODU termination and LO-ODU switching",
                   "admin-status": "up"
                 },
                 "oper-status": "up",
                 "// __NOT-PRESENT__ is-transitional": "It is not a tra\
   \nsitional link"
               }
             },
             {
               "// __DESCRIPTION__:__LTP__": __DESCRIPTION__:__LINK__": {
                 "name": "AN1-2 LTP",
                     "link type(s)": "OTU-4", "Access Link from AN1-3",
                 "type": "STM-64 Access link",
                 "physical node": "S2",
                     "unnumberd/ifIndex": 1,
                     "port type": "inter-domain port",
                     "connected to": "S31" link": "Link from S6-3 to R4"
               },
                   "tp-id": "2",
                   "ietf-te-topology:te-tp-id": 2,
               "link-id": "teNodeId/10.0.0.1/teLinkId/3",
               "source": {
                 "source-node": "10.0.0.1",
                 "source-tp": 3
               },
               "// __NOT-PRESENT__ destination": "access link",
               "ietf-te-topology:te": {
                 "te-link-attributes": {
                   "name": "AN1-2 LTP",
                     "admin-status": "up", "Access Link from AN1-3",
                   "// __NOT-PRESENT__ external-domain": "The plug-id i\

   \s used instead of this container",
                   "// __NOT-PRESENT__ is-abstract": "The access link i\
   \s not abstract",
                   "// __NOT-PRESENT__ interface-switching-capability":\
   \ "STM-64 Access Link only (no ODU switching)",
                   "// __DISCUSS__ interface-switching-capability": "\
   \See __NOT-PRESENT__ max-link-bandwidth": "STM-64 Acc\
   \ess Link attributes (teNodeId/10.0.0.1/teLinkId/2)", only (no ODU switching)",
                   "// __DISCUSS__ inter-domain-plug-id": "Inter-doma\
   \in Link",
                     "oper-status": "up", __NOT-PRESENT__ max-resv-link-bandwidth": "STM-6\
   \4 Access Link only (no ODU switching)",
                   "// __DISCUSS__ ietf-otn-topology:supported-payloa\
   \d-types": "Empty? (inter-domain OTN link)", __NOT-PRESENT__ unreserved-bandwidth": "STM-64 A\
   \ccess Link only (no ODU switching)",
                   "// __DEFAULT__ ietf-otn-topology:client-facing": __NOT-PRESENT__ ietf-otn-topology:tsg": "STM-64 \
   \false
   \Access Link only (no HO-ODU termination and LO-ODU switching)",
                   "admin-status": "up"
                 },
                 "oper-status": "up",
                 "// __NOT-PRESENT__ is-transitional": "It is not a tra\
   \nsitional link"
               }
             },
             {
               "// __DESCRIPTION__:__LTP__": __DESCRIPTION__:__LINK__": {
                 "name": "AN1-3 LTP",
                     "link type(s)": "OTU-2", "Inter-domain Link from AN1-4",
                 "type": "OTU4 inter-domain link",
                 "physical node": "S6",
                     "unnumberd/ifIndex": 1,
                     "port type": "tributary port",
                     "connected to": "R2" link": "Link from S7-3 to S11"
               },
                   "tp-id": "3",
                   "ietf-te-topology:te-tp-id": 3,
               "link-id": "teNodeId/10.0.0.1/teLinkId/4",
               "source": {
                 "source-node": "10.0.0.1",
                 "source-tp": 4
               },
               "// __NOT-PRESENT__ destination": "inter-domain link",
               "ietf-te-topology:te": {
                 "te-link-attributes": {
                   "name": "AN1-3 LTP",
                     "admin-status": "up",
                     "// __DISCUSS__ interface-switching-capability": "\
   \See "Inter-domain Link attributes (teNodeId/10.0.0.1/teLinkId/3)",
                     "// __DISCUSS__ inter-domain-plug-id": "Access Lin\
   \k",
                     "oper-status": "up", from AN1-4",
                   "// __DISCUSS__ ietf-otn-topology:supported-payloa\
   \d-types": "List __NOT-PRESENT__ external-domain": "The plug-id i\
   \s used instead of ODU clients?", this container",
                   "// __DISCUSS__ ietf-otn-topology:client-facing": \
   \true __NOT-PRESENT__ is-abstract": "The access link i\
   \s not abstract",
                   "interface-switching-capability": [
                     {
                       "// __COMMENT__ encoding and switching-capabilit\
   \y": "OTN (ODU)",
                       "switching-capability": "ietf-te-types:switching\

   \-otn",
                       "encoding": "ietf-te-types:lsp-encoding-oduk",
                       "max-lsp-bandwidth": [
                         {
                           "priority": 0,
                           "te-bandwidth": {
                             "ietf-otn-topology:odu-type": "ietf-layer1\
   \-types:ODU4"
                           }
                         }
                       ]
                     }
                   ],
                   "// __COMMENT__ label-restrictions": "Outside the sc\
   \ope of this JSON example",
                   "max-link-bandwidth": {
                     "te-bandwidth": {
                       "ietf-otn-topology:odulist": [
                         {
                           "odu-type": "ietf-layer1-types:ODU4",
                           "number": 1
                         },
                         {
                   "// __DESCRIPTION__:__LTP__":
                           "odu-type": "ietf-layer1-types:ODU2",
                           "number": 10
                         },
                         {
                     "name": "AN1-4 LTP",
                     "link type(s)": "OTU-4",
                     "physical node": "S8",
                     "unnumberd/ifIndex": 1,
                     "port type": "inter-domain port",
                     "connected to": "S32"
                           "odu-type": "ietf-layer1-types:ODU0",
                           "number": 80
                         }
                       ]
                     }
                   },
                   "tp-id": "4",
                   "ietf-te-topology:te-tp-id": 4,
                   "ietf-te-topology:te":
                   "max-resv-link-bandwidth": {
                     "name": "AN1-4 LTP",
                     "admin-status": "up",
                     "// __DISCUSS__ interface-switching-capability": "\
   \See Link attributes (teNodeId/10.0.0.1/teLinkId/4)",
                     "// __DISCUSS__ inter-domain-plug-id": "Inter-doma\
   \in Link",
                     "oper-status": "up",
                     "// __DISCUSS__ ietf-otn-topology:supported-payloa\
   \d-types": "Empty? (inter-domain OTN link)",
                     "// __DEFAULT__ ietf-otn-topology:client-facing": \
   \false
                     "te-bandwidth": {
                       "ietf-otn-topology:odulist": [
                         {
                           "odu-type": "ietf-layer1-types:ODU4",
                           "number": 1
                         },
                         {
                           "odu-type": "ietf-layer1-types:ODU2",
                           "number": 10
                         },
                         {
                           "odu-type": "ietf-layer1-types:ODU0",
                           "number": 80
                         }
                       ]
                     }
                   },
                   "unreserved-bandwidth": [
                     {
                   "// __DESCRIPTION__:__LTP__":
                       "priority": 0,
                       "te-bandwidth": {
                     "name": "AN1-5 LTP",
                     "link type(s)": "OTU-4",
                     "physical node": "S8",
                     "unnumberd/ifIndex": 5,
                     "port type": "inter-domain port",
                     "connected to": "S12"
                         "ietf-otn-topology:odulist": [
                           {
                             "odu-type": "ietf-layer1-types:ODU4",
                             "number": 1
                           },
                   "tp-id": "5",
                   "ietf-te-topology:te-tp-id": 5,
                   "ietf-te-topology:te":
                           {
                     "name": "AN1-5 LTP",
                     "admin-status": "up",
                     "// __DISCUSS__ interface-switching-capability": "\
   \See Link attributes (teNodeId/10.0.0.1/teLinkId/5)",
                     "// __DISCUSS__ inter-domain-plug-id": "Inter-doma\
   \in Link",
                             "odu-type": "ietf-layer1-types:ODU2",
                             "number": 10
                           },
                           {
                             "odu-type": "ietf-layer1-types:ODU0",
                             "number": 80
                           }
                         ]
                       }
                     }
                   ],
                   "ietf-otn-topology:tsg": "ietf-layer1-types:tsg-1.25\
   \G",
                   "admin-status": "up"
                 },
                 "oper-status": "up",
                 "// __DISCUSS__ ietf-otn-topology:supported-payloa\
   \d-types": "Empty? (inter-domain OTN link)",
                     "// __DEFAULT__ ietf-otn-topology:client-facing": \
   \false __NOT-PRESENT__ is-transitional": "It is not a tra\
   \nsitional link"
               }
             },
             {
               "// __DESCRIPTION__:__LTP__": __DESCRIPTION__:__LINK__": {
                 "name": "AN1-6 LTP",
                     "link type(s)": "OTU-4", "Inter-domain Link from AN1-5",
                 "type": "OTU4 inter-domain link",
                 "physical node": "S7",
                     "unnumberd/ifIndex": 4,
                     "port type": "inter-domain port",
                     "connected to": "S11" link": "Link from S8-4 to S12"
               },
                   "tp-id": "6",
                   "ietf-te-topology:te-tp-id": 6,
               "link-id": "teNodeId/10.0.0.1/teLinkId/5",
               "source": {
                 "source-node": "10.0.0.1",
                 "source-tp": 5
               },
               "// __NOT-PRESENT__ destination": "inter-domain link",
               "ietf-te-topology:te": {
                 "te-link-attributes": {
                   "name": "AN1-6 LTP",
                     "admin-status": "up",
                     "// __DISCUSS__ interface-switching-capability": "\
   \See "Inter-domain Link attributes (teNodeId/10.0.0.1/teLinkId/6)", from AN1-5",
                   "// __DISCUSS__ inter-domain-plug-id": "Inter-doma\
   \in Link",
                     "oper-status": "up", __NOT-PRESENT__ external-domain": "The plug-id i\
   \s used instead of this container",
                   "// __DISCUSS__ ietf-otn-topology:supported-payloa\
   \d-types": "Empty? (inter-domain OTN link)", __NOT-PRESENT__ is-abstract": "The access link i\
   \s not abstract",
                   "interface-switching-capability": [
                     {
                       "// __DEFAULT__ ietf-otn-topology:client-facing": \
   \false __COMMENT__ encoding and switching-capabilit\
   \y": "OTN (ODU)",
                       "switching-capability": "ietf-te-types:switching\
   \-otn",
                       "encoding": "ietf-te-types:lsp-encoding-oduk",
                       "max-lsp-bandwidth": [
                         {
                           "priority": 0,
                           "te-bandwidth": {
                             "ietf-otn-topology:odu-type": "ietf-layer1\
   \-types:ODU4"
                           }
                         }
                       ]
                     }
                   ],
                   "// __COMMENT__ label-restrictions": "Outside the sc\
   \ope of this JSON example",
                   "max-link-bandwidth": {
                     "te-bandwidth": {
                       "ietf-otn-topology:odulist": [
                         {
                           "odu-type": "ietf-layer1-types:ODU4",
                           "number": 1
                         },
                         {
                   "// __DESCRIPTION__:__LTP__":
                           "odu-type": "ietf-layer1-types:ODU2",
                           "number": 10
                         },
                         {
                     "name": "AN1-7 LTP",
                     "link type(s)": "OTU-2",
                     "physical node": "S6",
                     "unnumberd/ifIndex": 2,
                     "port type": "tributary port",
                     "connected to": "R3"
                           "odu-type": "ietf-layer1-types:ODU0",
                           "number": 80
                         }
                       ]
                     }
                   },
                   "tp-id": "7",
                   "ietf-te-topology:te-tp-id": 7,
                   "ietf-te-topology:te":
                   "max-resv-link-bandwidth": {
                     "name": "AN1-7 LTP",
                     "admin-status": "up",
                     "// __DISCUSS__ interface-switching-capability": "\
   \See Link attributes (teNodeId/10.0.0.1/teLinkId/7)",
                     "// __DISCUSS__ inter-domain-plug-id": "Access Lin\
   \k",
                     "oper-status": "up",
                     "// __DISCUSS__ ietf-otn-topology:supported-payloa\
   \d-types": "List of ODU clients?",
                     "// __DISCUSS__ ietf-otn-topology:client-facing": \
   \true
                     "te-bandwidth": {
                       "ietf-otn-topology:odulist": [
                         {
                           "odu-type": "ietf-layer1-types:ODU4",
                           "number": 1
                         },
                         {
                           "odu-type": "ietf-layer1-types:ODU2",
                           "number": 10
                         },
                         {
                           "odu-type": "ietf-layer1-types:ODU0",
                           "number": 80
                         }
                       ]
                     }
                   },
                   "unreserved-bandwidth": [
                     {
                       "priority": 0,
                       "te-bandwidth": {
                         "ietf-otn-topology:odulist": [
                           {
                             "odu-type": "ietf-layer1-types:ODU4",
                             "number": 1
                           },
                           {
                             "odu-type": "ietf-layer1-types:ODU2",
                             "number": 10
                           },
                           {
                             "odu-type": "ietf-layer1-types:ODU0",
                             "number": 80
                           }
                         ]
                       }
                     }

                   ],
                   "ietf-otn-topology:tsg": "ietf-layer1-types:tsg-1.25\
   \G",
                   "admin-status": "up"
                 },
                 "oper-status": "up",
                 "// ietf-network-topology:link": "Access links to be reviewe\
   \d in __NOT-PRESENT__ is-transitional": "It is not a future update",
           "ietf-network-topology:link": [ tra\
   \nsitional link"
               }
             },
             {
               "// __DESCRIPTION__:__LINK__": {
                 "name": "Access "Inter-domain Link from AN1-1", AN1-6",
                 "type": "access "OTU4 inter-domain link",
                 "physical link": "Link from S3-1 S8-5 to R1" S32"
               },
               "link-id": "teNodeId/10.0.0.1/teLinkId/1", "teNodeId/10.0.0.1/teLinkId/6",
               "source": {
                 "source-node": "10.0.0.1",
                 "source-tp": 6
               },
               "// __NOT-PRESENT__ destination": "inter-domain link",
               "ietf-te-topology:te": {
                 "te-link-attributes": {
                   "name": "Access "Inter-domain Link from AN1-1",
                   "// __DISCUSS__ access-type": "Can we assume point-t\
   \o-point as the default value?",
                   "access-type": "point-to-point", AN1-6",
                   "// __COMMENT__ __NOT-PRESENT__ external-domain": "Empty: the plug-i\
   \d is "The plug-id i\
   \s used instead of this container",
                   "// __DISCUSS__ __NOT-PRESENT__ is-abstract": "To be discussed with \
   \TE Topology authors",
                   "// __DISCUSS__ underlay": "To be discussed with TE \
   \Topology authors",
                   "admin-status": "up", "The access link i\
   \s not abstract",
                   "interface-switching-capability": [
                     {
                       "// __COMMENT__ encoding and switching-capabilit\
   \y": "OTN (ODU)",
                       "switching-capability": "ietf-te-types:switching\
   \-otn",
                       "encoding": "ietf-te-types:lsp-encoding-oduk",
                       "max-lsp-bandwidth": [
                         {
                           "priority": 0,
                           "// __DISCUSS__ te-bandwidth": "ODU2"
                           "te-bandwidth": {
                             "ietf-otn-topology:odu-type": "ietf-layer1\
   \-types:ODU4"
                           }
                         }

                       ]
                     }
                   ],
                   "// __COMMENT__ label-restrictions": "Not described \
   \in "Outside the sc\
   \ope of this JSON example",
                   "// __DISCUSS__ link-protection-type": "Can we assum\
   \e unprotected as the default value?",
                   "link-protection-type": "unprotected",
                   "max-link-bandwidth": {
                     "// __DISCUSS__ te-bandwidth": "1xODU2"
                     "te-bandwidth": {
                       "ietf-otn-topology:odulist": [
                         {
                           "odu-type": "ietf-layer1-types:ODU4",
                           "number": 1
                         },
                         {
                           "odu-type": "ietf-layer1-types:ODU2",
                           "number": 10
                         },
                         {
                           "odu-type": "ietf-layer1-types:ODU0",
                           "number": 80
                         }
                       ]
                     }
                   },
                   "max-resv-link-bandwidth": {
                     "// __DISCUSS__ te-bandwidth": "1xODU2"
                     "te-bandwidth": {
                       "ietf-otn-topology:odulist": [
                         {
                           "odu-type": "ietf-layer1-types:ODU4",
                           "number": 1
                         },
                         {
                           "odu-type": "ietf-layer1-types:ODU2",
                           "number": 10
                         },
                         {
                           "odu-type": "ietf-layer1-types:ODU0",
                           "number": 80
                         }
                       ]
                     }
                   },
                   "unreserved-bandwidth": [
                     {
                       "priority": 0,
                       "// __DISCUSS__ te-bandwidth": "1xODU2"
                       "te-bandwidth": {
                         "ietf-otn-topology:odulist": [
                           {
                             "odu-type": "ietf-layer1-types:ODU4",
                             "number": 1
                           },
                           {
                             "odu-type": "ietf-layer1-types:ODU2",
                             "number": 10
                           },
                           {
                             "odu-type": "ietf-layer1-types:ODU0",
                             "number": 80
                           }
                         ]
                       }
                     }
                   ],
                   "ietf-otn-topology:tsg": "ietf-layer1-types:tsg-1.25\
   \G",
                   "admin-status": "up"
                 },
                 "oper-status": "up",
                 "// __EMPTY__ __NOT-PRESENT__ is-transitional": "It is not a transitio\
   \nal link",
                 "// __DISCUSS__ underlay ": "To be discussed with TE T\
   \opology authors"
               },
               "source": {
                 "source-node": "10.0.0.1",
                 "source-tp": 1
               },
               "// __EMPTY__ destination": "access tra\
   \nsitional link"
               }
             },
             {
               "// __DESCRIPTION__:__LINK__": {
                 "name": "Inter-domain Link from AN1-2", AN1-7",
                 "type": "inter-domain "OTU4 inter-domain link",
                 "physical link": "Link from S2-1 S2-3 to S31"
               },
               "link-id": "teNodeId/10.0.0.1/teLinkId/2", "teNodeId/10.0.0.1teLinkId/7",
               "source": {
                 "source-node": "10.0.0.1",
                 "source-tp": 7
               },
               "// __NOT-PRESENT__ destination": "inter-domain link",
               "ietf-te-topology:te": {
                 "te-link-attributes": {
                   "name": "Inter-domain Link from AN1-2", AN1-7",
                   "// __DISCUSS__ access-type": "Can we assume point-t\
   \o-point as the default value?",
                   "access-type": "point-to-point", __NOT-PRESENT__ external-domain": "The plug-id i\
   \s used instead of this container",
                   "// __DISCUSS__ __NOT-PRESENT__ is-abstract": "To be discussed with \
   \TE Topology authors",
                   "// __DISCUSS__ underlay": "To be discussed with TE \
   \Topology authors",
                   "admin-status": "up", "The access link i\
   \s not abstract",
                   "interface-switching-capability": [
                     {
                       "// __COMMENT__ encoding and switching-capabilit\
   \y": "OTN (ODU)",
                       "switching-capability": "ietf-te-types:switching\
   \-otn",
                       "encoding": "ietf-te-types:lsp-encoding-oduk",
                       "max-lsp-bandwidth": [
                         {
                           "priority": 0,
                           "te-bandwidth": {
                             "ietf-otn-topology:odu-type": "ietf-layer1\
   \-types:ODU4"
                           }
                         }
                       ]
                     }
                   ],
                   "// __DISCUSS__ te-bandwidth": "ODU4" __COMMENT__ label-restrictions": "Outside the sc\
   \ope of this JSON example",
                   "max-link-bandwidth": {
                     "te-bandwidth": {
                       "ietf-otn-topology:odulist": [
                         {
                           "odu-type": "ietf-layer1-types:ODU4",
                           "number": 1
                         },
                         {
                           "odu-type": "ietf-layer1-types:ODU2",
                           "number": 10
                         },
                         {
                           "odu-type": "ietf-layer1-types:ODU0",
                           "number": 80
                         }
                       ]
                     }
                   },
                   "max-resv-link-bandwidth": {
                     "te-bandwidth": {
                       "ietf-otn-topology:odulist": [
                         {
                           "odu-type": "ietf-layer1-types:ODU4",
                           "number": 1
                         },
                         {
                           "odu-type": "ietf-layer1-types:ODU2",
                           "number": 10
                         },
                         {
                           "odu-type": "ietf-layer1-types:ODU0",
                           "number": 80
                         }
                       ]
                     }
                   },
                   "unreserved-bandwidth": [
                     {
                       "priority": 0,
                       "te-bandwidth": {
                         "ietf-otn-topology:odulist": [
                           {
                             "odu-type": "ietf-layer1-types:ODU4",
                             "number": 1
                           },
                           {
                             "odu-type": "ietf-layer1-types:ODU2",
                             "number": 10
                           },
                           {
                             "odu-type": "ietf-layer1-types:ODU0",
                             "number": 80
                           }
                         ]
                       }
                     }
                   ],
                   "ietf-otn-topology:tsg": "ietf-layer1-types:tsg-1.25\
   \G",
                   "admin-status": "up"
                 },
                 "oper-status": "up",
                 "// __NOT-PRESENT__ is-transitional": "It is not a tra\
   \nsitional link"
               }
             }

           ]
         }
       ]
     }
   }

B.1.2.   JSON Code: mpi1-eth-topology.json

   This is the JSON code reporting the ETH Topology @ MPI1:

   ========== NOTE: '\\' line wrapping per BCP XXX (RFC XXXX) ==========

   {
     "// __DISCUSS__ label-restrictions": "To be adde\
   \d?"
                     }
                   ], __LAST_UPDATE__": "October 16, 2019",
     "// __DISCUSS__ link-protection-type": "Can we assum\
   \e unprotected as the default value?",
                   "link-protection-type": "unprotected",
                   "max-link-bandwidth": __TITLE__": "ETH Black Topology @ MPI1",
     "// __REFERENCE_DRAFTS__": {
       "ietf-routing-types@2017-12-04": "rfc8294",
       "ietf-te-types@2019-07-05": "draft-ietf-teas-yang-te-types-10",
       "ietf-network@2018-02-26": "rfc8345",
       "ietf-network-topology@2018-02-26": "rfc8345",
       "ietf-te-topology@2019-02-07": "draft-ietf-teas-yang-te-topo-22",
       "ietf-eth-tran-types@2019-03-27": "draft-ietf-ccamp-client-signa\
   \l-yang-00",
       "ietf-eth-te-topology@2019-07-08": "draft-zheng-ccamp-client-top\
   \o-yang-06"
     },
     "// __DISCUSS__ te-bandwidth": "1xODU4, ..." __MISSING_ATTRIBUTES__": true,
     "ietf-network:networks": {
       "network": [
         {
           "network-id": "providerId/201/clientId/300/topologyId/eth-bl\
   \ack-topology",
           "network-types": {
             "ietf-te-topology:te-topology": {
               "ietf-eth-te-topology:eth-tran-topology": {}
             }
           },
                   "max-resv-link-bandwidth":
           "ietf-te-topology:te-topology-identifier": {
             "provider-id": 201,
             "client-id": 300,
             "te-topology-id": "eth-black-topology"
           },
           "// __DISCUSS__ te-bandwidth": "1xODU4, ..." __COMMENT__ ietf-te-topology:te": "presence container re\
   \quires: provider-id, client-id and te-topology-id",
           "ietf-te-topology:te": {
             "name": "ETH Black Topology @ MPI1"
           },
                   "unreserved-bandwidth":
           "ietf-network:node": [
             {
                       "priority": 0,
               "// __DISCUSS__ te-bandwidth": "1xODU4, ..."
                     }
                   ] __NODE__:__DESCRIPTION__": {
                 "name": "AN1",
                 "identifier": "10.0.0.1",
                 "type": "Abstract Node",
                 "physical node(s)": "The whole network domain 1"
               },
                 "oper-status": "up",
               "node-id": "10.0.0.1",
               "ietf-te-topology:te-node-id": "10.0.0.1",
               "// __EMPTY__ is-transitional": "It __COMMENT__ supporting-node": "Not used because topo\
   \logy hierarchy is not a transitio\
   \nal link",
                 "// __DISCUSS__ underlay ": "To be discussed with TE T\
   \opology authors"
               },
               "source": outside the scope of this JSON example",
               "ietf-te-topology:te": {
                 "source-node": "10.0.0.1",
                 "source-tp": 2
                 "te-node-attributes": {
                   "name": "AN11",
                   "is-abstract": {},
                   "admin-status": "up"
                 },
                 "oper-status": "up",
                 "// __EMPTY__ destination": "inter-domain link" __NOT-PRESENT__ tunnel-termination-point": "ETH Ac\
   \cess Links only (no ETH TE switching)"
               },
               "ietf-network-topology:termination-point": [
                 {
                   "// __DESCRIPTION__:__LINK__": __DESCRIPTION__:__LTP__": {
                     "name": "Access Link from AN1-3",
                 "type": "access link", "AN1-1 LTP",
                     "link type(s)": "Multi-function (OTU2, STM-64 and \
   \10GE)",
                     "physical link": "Link from S6-1 to R2" node": "S3",
                     "unnumberd/ifIndex": 1,
                     "port type": "tributary port",
                     "connected to": "R1"
                   },
               "link-id": "teNodeId/10.0.0.1/teLinkId/3",
                   "tp-id": "1",
                   "ietf-te-topology:te-tp-id": 1,
                   "ietf-te-topology:te": {
                 "te-link-attributes": {
                     "name": "Access "AN1-1 LTP",
                     "// __NOT-PRESENT__ interface-switching-capability\
   \": "ETH Access Link from AN1-3", only (no ETH TE switching)",
                     "// __DISCUSS__ access-type": "Can we assume point-t\
   \o-point as __COMMENT__ inter-domain-plug-id": "Use of plu\
   \g-id for access Link is outside the default value?",
                   "access-type": "point-to-point",
                   "// __DISCUSS__ is-abstract": "To be discussed with \
   \TE Topology authors", scope of this document",
                     "// __DISCUSS__ underlay": "To be discussed with TE \
   \Topology authors", __COMMENT__ inter-layer-lock-id": "AN1-1 ILL-I\
   \D (1)",
                     "inter-layer-lock-id": [
                       1
                     ],
                     "admin-status": "up",
                   "interface-switching-capability": [
                     "oper-status": "up"
                   },
                   "// __COMMENT__ ingress-bandwidth-profile": "Outside\
   \ the scope of this JSON example",
                   "ietf-eth-te-topology:eth-svc": {
                       "switching-capability": "ietf-te-types:switching\
   \-otn",
                       "encoding": "ietf-te-types:lsp-encoding-oduk",
                       "max-lsp-bandwidth":
                     "client-facing": true,
                     "supported-classification": {
                       "port-classification": true,
                       "vlan-classification": {
                         "vlan-tag-classification": true,
                         "outer-tag": {
                           "supported-tag-types": [
                             "ietf-eth-tran-types:classify-c-vlan"
                           ],
                           "vlan-range": "1-4094"
                         }
                       }
                     },
                     "supported-vlan-operations": {
                       "transparent-vlan-operations": true
                     }
                   }
                 },
                 {
                   "// __DESCRIPTION__:__LTP__": {
                     "name": "AN1-8 LTP",
                     "link type(s)": "10GE",
                     "physical node": "S6",
                     "unnumberd/ifIndex": 1,
                     "port type": "tributary port",
                     "connected to": "R2"
                   },
                   "tp-id": "8",
                   "ietf-te-topology:te-tp-id": 8,
                   "ietf-te-topology:te": {
                           "priority": 0,
                     "name": "AN1-8 LTP",
                     "// __DISCUSS__ te-bandwidth": "ODU2"
                         }
                       ], __COMMENT__ inter-layer-lock-id": "AN1-8 ILL-I\
   \D (8)",
                     "// __NOT-PRESENT__ interface-switching-capability\
   \": "ETH Access Link only (no ETH TE switching)",
                     "// __DISCUSS__ label-restrictions": "To be adde\
   \d?"
                     } __COMMENT__ inter-domain-plug-id": "Use of plu\
   \g-id for access Link is outside the scope of this document",
                     "inter-layer-lock-id": [
                       8
                     ],
                     "admin-status": "up",
                     "oper-status": "up"
                   },
                   "// __DISCUSS__ link-protection-type": "Can we assum\
   \e unprotected as __COMMENT__ ingress-bandwidth-profile": "Outside\
   \ the default value?",
                   "link-protection-type": "unprotected",
                   "max-link-bandwidth": scope of this JSON example",
                   "ietf-eth-te-topology:eth-svc": {
                     "// __DISCUSS__ te-bandwidth": "1xODU2"
                   },
                   "unreserved-bandwidth": [
                     "client-facing": true,
                     "supported-classification": {
                       "priority": 0,
                       "// __DISCUSS__ te-bandwidth": "1xODU2"
                     }
                   ],
                   "max-resv-link-bandwidth":
                       "port-classification": true,
                       "vlan-classification": {
                     "// __DISCUSS__ te-bandwidth": "1xODU2"
                         "vlan-tag-classification": true,
                         "outer-tag": {
                           "supported-tag-types": [
                             "ietf-eth-tran-types:classify-c-vlan"
                           ],
                           "vlan-range": "1-4094"
                         }
                       }
                     },
                 "oper-status": "up",
                 "// __EMPTY__ is-transitional": "It is not a transitio\
   \nal link",
                 "// __DISCUSS__ underlay ": "To be discussed with TE T\
   \opology authors"
               },
               "source":
                     "supported-vlan-operations": {
                 "source-node": "10.0.0.1",
                 "source-tp": 3
               },
               "// __EMPTY__ destination": "access link"
             },
                       "transparent-vlan-operations": true
                     }
                   }
                 }
               ]
             }
           ],
           "ietf-network-topology:link": [
             {
               "// __DESCRIPTION__:__LINK__": {
                 "name": "Inter-domain "Access Link from AN1-4", AN1-1",
                 "type": "inter-domain link", "Multi-function access link (OTU2, STM-64 and \
   \10GE)",
                 "physical link": "Link from S8-1 S3-1 to S32" R1"
               },
               "link-id": "teNodeId/10.0.0.1/teLinkId/4", "teNodeId/10.0.0.1/teLinkId/1",
               "source": {
                 "source-node": "10.0.0.1",
                 "source-tp": 1
               },
               "// __NOT-PRESENT__ destination": "access link",
               "ietf-te-topology:te": {
                 "te-link-attributes": {
                   "name": "Inter-domain "Access Link from AN1-4", AN1-1",
                   "// __DISCUSS__ access-type": "Can we assume point-t\
   \o-point as the default value?",
                   "access-type": "point-to-point", __NOT-PRESENT__ external-domain": "The plug-id i\
   \s used instead of this container",
                   "// __DISCUSS__ __NOT-PRESENT__ is-abstract": "To be discussed with \
   \TE Topology authors", "The access link i\
   \s not abstract",
                   "// __DISCUSS__ underlay": "To be discussed with TE __NOT-PRESENT__ interface-switching-capability":\
   \
   \Topology authors",
                   "admin-status": "up",
                   "interface-switching-capability": [
                     {
                       "switching-capability": "ietf-te-types:switching\
   \-otn",
                       "encoding": "ietf-te-types:lsp-encoding-oduk",
                       "max-lsp-bandwidth": [
                         {
                           "priority": 0,
                           "// __DISCUSS__ te-bandwidth": "ODU4"
                         }
                       ], "ETH Access Link only (no ETH TE switching)",
                   "// __DISCUSS__ __NOT-PRESENT__ label-restrictions": "To be adde\
   \d?"
                     }
                   ],
                   "// __DISCUSS__ link-protection-type": "Can we assum\
   \e unprotected as the default value?",
                   "link-protection-type": "unprotected",
                   "max-link-bandwidth": { "ETH Access\
   \ Link only (no ETH TE switching)",
                   "// __DISCUSS__ te-bandwidth": "1xODU4, ..."
                   },
                   "unreserved-bandwidth": [
                     {
                       "priority": 0, __NOT-PRESENT__ max-link-bandwidth": "ETH Access\
   \ Link only (no ETH TE switching)",
                   "// __DISCUSS__ te-bandwidth": "1xODU4, ..."
                     }
                   ],
                   "max-resv-link-bandwidth": { __NOT-PRESENT__ max-resv-link-bandwidth": "ETH A\
   \ccess Link only (no ETH TE switching)",
                   "// __DISCUSS__ te-bandwidth": "1xODU4, ..."
                   } __NOT-PRESENT__ unreserved-bandwidth": "ETH Acce\
   \ss Link only (no ETH TE switching)",
                   "admin-status": "up"
                 },
                 "oper-status": "up",
                 "// __EMPTY__ __NOT-PRESENT__ is-transitional": "It is not a transitio\
   \nal link",
                 "// __DISCUSS__ underlay ": "To be discussed with TE T\
   \opology authors"
               },
               "source": {
                 "source-node": "10.0.0.1",
                 "source-tp": 4
               },
               "// __EMPTY__ destination": "inter-domain "It is not a tra\
   \nsitional link"
               }
             },
             {
               "// __DESCRIPTION__:__LINK__": {
                 "name": "Inter-domain "Access Link from AN1-5", AN1-8",
                 "type": "inter-domain "10GE access link",
                 "physical link": "Link from S8-5 S6-1 to S12" R2"
               },
               "link-id": "teNodeId/10.0.0.1/teLinkId/5", "teNodeId/10.0.0.1/teLinkId/8",
               "source": {
                 "source-node": "10.0.0.1",
                 "source-tp": 8
               },
               "// __NOT-PRESENT__ destination": "access link",
               "ietf-te-topology:te": {
                 "te-link-attributes": {
                   "name": "Inter-domain "Access Link from AN1-5", AN1-8",
                   "// __DISCUSS__ access-type": "Can we assume point-t\
   \o-point as the default value?",
                   "access-type": "point-to-point", __NOT-PRESENT__ external-domain": "The plug-id i\

   \s used instead of this container",
                   "// __DISCUSS__ __NOT-PRESENT__ is-abstract": "To be discussed with \
   \TE Topology authors", "The access link i\
   \s not abstract",
                   "// __DISCUSS__ underlay": "To be discussed with TE __NOT-PRESENT__ interface-switching-capability":\
   \
   \Topology authors",
                   "admin-status": "up",
                   "interface-switching-capability": [
                     {
                       "switching-capability": "ietf-te-types:switching\
   \-otn",
                       "encoding": "ietf-te-types:lsp-encoding-oduk",
                       "max-lsp-bandwidth": [
                         {
                           "priority": 0,
                           "// __DISCUSS__ te-bandwidth": "ODU4"
                         }
                       ], "ETH Access Link only (no ETH TE switching)",
                   "// __DISCUSS__ __NOT-PRESENT__ label-restrictions": "To be adde\
   \d?"
                     }
                   ],
                   "// __DISCUSS__ link-protection-type": "Can we assum\
   \e unprotected as the default value?",
                   "link-protection-type": "unprotected",
                   "max-link-bandwidth": { "ETH Access\
   \ Link only (no ETH TE switching)",
                   "// __DISCUSS__ te-bandwidth": "1xODU4, ..."
                   },
                   "max-resv-link-bandwidth": { __NOT-PRESENT__ max-link-bandwidth": "ETH Access\
   \ Link only (no ETH TE switching)",
                   "// __DISCUSS__ te-bandwidth": "1xODU4, ..."
                   },
                   "unreserved-bandwidth": [
                     {
                       "priority": 0, __NOT-PRESENT__ max-resv-link-bandwidth": "ETH A\
   \ccess Link only (no ETH TE switching)",
                   "// __DISCUSS__ te-bandwidth": "1xODU4, ..."
                     }
                   ] __NOT-PRESENT__ unreserved-bandwidth": "ETH Acce\
   \ss Link only (no ETH TE switching)",
                   "admin-status": "up"
                 },
                 "oper-status": "up",
                 "// __EMPTY__ __NOT-PRESENT__ is-transitional": "It is not a transitio\
   \nal link", tra\
   \nsitional link"
               }
             }
           ]
         }
       ]
     }
   }

B.2.  JSON Examples for Service Configuration

B.2.1.   JSON Code: mpi1-odu2-service-config.json

   This is the JSON code reporting the ODU2 transit service
   configuration @ MPI1:

   ========== NOTE: '\\' line wrapping per BCP XXX (RFC XXXX) ==========

   {
     "// __DISCUSS__ underlay ": "To be discussed with TE T\
   \opology authors"
               },
               "source": __LAST_UPDATE__": "October 23, 2019",
     "// __TITLE__": "ODU2 Service Configuration @ MPI1",
     "// __REFERENCE_DRAFTS__": {
                 "source-node": "10.0.0.1",
                 "source-tp": 5
       "ietf-routing-types@2017-12-04": "rfc8294",
       "ietf-te-types@2019-07-05": "draft-ietf-teas-yang-te-types-10",
       "ietf-layer1-types@2019-09-09": "draft-ietf-ccamp-layer1-types-0\
   \2",
       "ietf-te@2019-04-09": "draft-ietf-teas-yang-te-21",
       "ietf-otn-tunnel@2019-10-23": "draft-ietf-ccamp-otn-tunnel-model\
   \-08"
     },
     "// __EMPTY__ destination": "inter-domain link"
             },
             { __MISSING_ATTRIBUTES__": true,
     "// __DESCRIPTION__:__LINK__": __RESTCONF_OPERATION__": {
                 "name": "Inter-domain Link from AN1-6",
                 "type": "inter-domain link",
                 "physical link": "Link from S7-4 to S11"
       "operation": "POST",
       "url": "http://{{PNC1-ADDR}}/restconf/data/ietf-te:te/tunnels"
     },
               "link-id": "teNodeId/10.0.0.1/teLinkId/6",
               "ietf-te-topology:te":
     "ietf-te:te": {
                 "te-link-attributes":
       "tunnels": {
                   "name": "Inter-domain Link from AN1-6",
                   "// __DISCUSS__ access-type": "Can we assume point-t\
   \o-point as the default value?",
                   "access-type": "point-to-point",
                   "// __DISCUSS__ is-abstract": "To be discussed with \
   \TE Topology authors",
                   "// __DISCUSS__ underlay": "To be discussed with TE \
   \Topology authors",
                   "admin-status": "up",
                   "interface-switching-capability":
         "tunnel": [
           {
                       "switching-capability": "ietf-te-types:switching\
   \-otn",
             "name": "mpi1-odu2-service",
             "// __COMMENT__ identifier": "ODU2-SERVICE-TUNNEL-ID @ MPI\
   \1",
             "identifier": 1,
             "description": "ODU2 Service implemented by ODU2 OTN Tunne\
   \l Segment @ MPI1",
             "// __COMMENT__ encoding and switching-type": "OTN (ODU)",
             "encoding": "ietf-te-types:lsp-encoding-oduk",
                       "max-lsp-bandwidth": [
                         {
                           "priority": 0,
             "switching-type": "ietf-te-types:switching-otn",
             "// __DISCUSS__ te-bandwidth": "ODU4"
                         }
                       ], __NOT-PRESENT__ source": "Transit tunnel segment",
             "// __DISCUSS__ label-restrictions": "To be adde\
   \d?"
                     }
                   ], __NOT-PRESENT__ src-tp-id": "Transit tunnel segment",
             "// __DISCUSS__ link-protection-type": "Can we assum\
   \e unprotected as the default value?",
                   "link-protection-type": "unprotected",
                   "max-link-bandwidth": __NOT-PRESENT__ destination": "Transit tunnel segment",
             "// __NOT-PRESENT__ dst-tp-id": "Transit tunnel segment",
             "bidirectional": true,
             "// __ DEFAULT __ protection": {
               "// __DISCUSS__ te-bandwidth": "1xODU4, ..." __ DEFAULT __ enable": false
             },
                   "max-resv-link-bandwidth":
             "// __ DEFAULT __ restoration": {
               "// __DISCUSS__ te-bandwidth": "1xODU4, ..." __ DEFAULT __ enable": false
             },
                   "unreserved-bandwidth":
             "// __COMMENT__ te-topology-identifier": "ODU Black Topolo\
   \gy @ MPI1",
             "te-topology-identifier": {
               "provider-id": 201,
               "client-id": 300,
               "topology-id": "otn-black-topology"
             },
             "te-bandwidth": {
               "ietf-otn-tunnel:odu-type": "ietf-layer1-types:ODU2"
             },
             "provisioning-state": "ietf-te-types:tunnel-state-up",
             "p2p-primary-paths": {
               "p2p-primary-path": [
                 {
                       "priority": 0,
                   "name": "mpi1-odu2-service-primary-path",
                   "// __DISCUSS__ __NOT-PRESENT__ te-bandwidth": "1xODU4, ..."
                     }
                   ]
                 },
                 "oper-status": "up",
                 "// __EMPTY__ is-transitional": "It "The tunnel bandw\
   \idth is not a transitio\
   \nal link", used",
                   "explicit-route-objects-always": {
                     "route-object-include-exclude": [
                       {
                         "// __DISCUSS__ underlay ": "To be discussed with TE T\
   \opology authors"
               },
               "source": __COMMENT__": "Tunnel hand-off OTU2 ingres\
   \s interface (S3-1 -> AN1-1)",
                         "index": 1,
                         "explicit-route-usage": "ietf-te-types:route-i\
   \nclude-object",
                         "unnumbered-link-hop": {
                 "source-node":
                           "// __COMMENT__ node-id": "AN1 NODE-ID",
                           "node-id": "10.0.0.1",
                 "source-tp": 6
               },
                           "// __EMPTY__ destination": "inter-domain link" __COMMENT__ link-tp-id": "AN1-1 LTP",
                           "link-tp-id": 1,
                           "// __DEFAULT__ hop-type": "strict",
                           "// __DEFAULT__ direction": "outgoing"
                         }
                       },
                       {
                         "// __DESCRIPTION__:__LINK__": {
                 "name": "Access Link from AN1-7",
                 "type": "access link",
                 "physical link": "Link from S6-2 to R3"
               },
               "link-id": "teNodeId/10.0.0.1teLinkId/7",
               "ietf-te-topology:te": __COMMENT__": "Tunnel hand-off ODU2 ingres\
   \s label (ODU2 over OTU2) at S3-1 (AN1-1)",
                         "index": 2,
                         "explicit-route-usage": "ietf-te-types:route-i\
   \nclude-object",
                         "label-hop": {
                 "te-link-attributes":
                           "te-label": {
                   "name": "Access Link from AN1-7",
                   "// __DISCUSS__ access-type": "Can we assume point-t\
   \o-point as the default value?",
                   "access-type": "point-to-point",
                             "ietf-otn-tunnel:tpn": 1,
                             "// __DISCUSS__ is-abstract": "To be discussed with __NOT-PRESENT__ ietf-otn-tunnel:tsg": \
   \TE Topology authors",
   \"Not applicable for ODUk over OTUk",
                             "// __DISCUSS__ underlay": "To be discussed with TE \
   \Topology authors",
                   "admin-status": "up",
                   "interface-switching-capability": [ __NOT-PRESENT__ ietf-otn-tunnel:ts-lis\
   \t": "Not applicable for ODUk over OTUk",
                             "// __DEFAULT__ direction": "forward"
                           }
                         }
                       },
                       {
                       "switching-capability": "ietf-te-types:switching\
   \-otn",
                       "encoding": "ietf-te-types:lsp-encoding-oduk",
                       "max-lsp-bandwidth": [
                         "// __COMMENT__": "Tunnel hand-off OTU4 egress\
   \ interface (S2-3 -> AN1-7)",
                         "index": 3,
                         "explicit-route-usage": "ietf-te-types:route-i\

   \nclude-object",
                         "unnumbered-link-hop": {
                           "priority": 0,
                           "// __DISCUSS__ te-bandwidth": "ODU2"
                         }
                       ], __COMMENT__ node-id": "AN1 Node",
                           "node-id": "10.0.0.1",
                           "// __DISCUSS__ label-restrictions": "To be adde\
   \d?"
                     }
                   ], __COMMENT__ link-tp-id": "AN1-7 LTP",
                           "link-tp-id": 7,
                           "// __DISCUSS__ link-protection-type": "Can we assum\
   \e unprotected as the default value?",
                   "link-protection-type": "unprotected",
                   "max-link-bandwidth": { __DEFAULT__ hop-type": "strict",
                           "// __DISCUSS__ te-bandwidth": "1xODU2" __DEFAULT__ direction": "outgoing"
                         }
                       },
                   "max-resv-link-bandwidth":
                       {
                         "// __DISCUSS__ te-bandwidth": "1xODU2"
                   },
                   "unreserved-bandwidth": [ __COMMENT__": "Tunnel hand-off ODU2 egress\
   \ label (ODU2 over OTU4) at S2-3 (AN1-7)",
                         "index": 4,
                         "explicit-route-usage": "ietf-te-types:route-i\
   \nclude-object",
                         "label-hop": {
                       "priority": 0,
                           "te-label": {
                             "ietf-otn-tunnel:tpn": 1,
                             "ietf-otn-tunnel:tsg": "ietf-layer1-types:\
   \tsg-1.25G",
                             "ietf-otn-tunnel:ts-list": "1-8",
                             "// __DISCUSS__ te-bandwidth": "1xODU2" __DEFAULT__ direction": "forward"
                           }
                         }
                       }
                     ]
                 },
                 "oper-status": "up",
                 "// __EMPTY__ is-transitional": "It is not a transitio\
   \nal link",
                 "// __DISCUSS__ underlay ": "To be discussed with TE T\
   \opology authors"
               },
               "source": {
                 "source-node": "10.0.0.1",
                 "source-tp": 7
               },
               "// __EMPTY__ destination": "access link"
                   }
                 }
               ]
             }
           }
         ]
       }
     }

B.2.  JSON Examples for Service Configuration

B.2.1.
   }

B.2.2.   JSON Code: mpi1-odu2-service-config.json mpi1-odu2-tunnel-config.json

   This is the JSON code reporting the ODU2 transit service head tunnel segment
   configuration @ MPI: MPI1:

   ========== NOTE: '\\' line wrapping per BCP XX XXX (RFC XXXX) =========== ==========
   {
     "// __LAST_UPDATE__": "October 23, 2019",
     "// __TITLE__": "ODU2 Service Tunnel Configuration @ MPI1",
     "// __LAST_UPDATE__": "October 22, 2018",
     "// __MISSING_ATTRIBUTES__": true,
     "// __REFERENCE_DRAFTS__": {
       "ietf-routing-types@2017-12-04": "rfc8294",
       "ietf-otn-types@2018-06-07": "draft-ietf-ccamp-otn-tunnel-model-\
   \02",
       "ietf-te-types@2018-07-01": "draft-ietf-teas-yang-te-16",
       "ietf-te@2018-07-01": "draft-ietf-teas-yang-te-16",
       "ietf-otn-tunnel@2018-06-07":
       "ietf-te-types@2019-07-05": "draft-ietf-teas-yang-te-types-10",
       "ietf-layer1-types@2019-09-09": "draft-ietf-ccamp-layer1-types-0\
   \2",
       "ietf-te@2019-04-09": "draft-ietf-teas-yang-te-21",
       "ietf-otn-tunnel@2019-10-23": "draft-ietf-ccamp-otn-tunnel-model\
   \-02"
   \-08"
     },
     "// __MISSING_ATTRIBUTES__": true,
     "// __RESTCONF_OPERATION__": {
       "operation": "PUT", "POST",
       "url": "http://{{PNC1-ADDR}}/restconf/data/ietf-te:te" "http://{{PNC1-ADDR}}/restconf/data/ietf-te:te/tunnels"
     },
     "ietf-te:te": {
       "tunnels": {
         "tunnel": [
           {
             "name": "mpi1-odu2-service", "mpi1-odu2-tunnel",
             "// __COMMENT__ identifier": "ODU2-SERVICE-TUNNEL-ID "ODU2-TUNNEL-ID @ MPI1",
             "identifier": 1, 2,
             "description": "ODU2 Service implemented by "TNBI Example for an ODU2 OTN Tunne\
   \l Segment Head Tunnel Segme\
   \nt @ MPI1",
             "// __COMMENT__ encoding and switching-type": "ODU", "OTN (ODU)",
             "encoding": "ietf-te-types:lsp-encoding-oduk ", "ietf-te-types:lsp-encoding-oduk",
             "switching-type": "ietf-te-types:switching-otn",
             "// __COMMENT__ source": "None: transit tunnel segment",
             "// destination": "None: transit tunnel segment", "AN1 Node-ID",
             "source": "10.0.0.1",
             "// __COMMENT__ src-tp-id": "None: transit tunnel segment",
             "// dst-tp-id": "None: transit tunnel segment", "AN1-1 TTP-ID (1 -> 0x01 -> '0\
   \1')",
             "src-tp-id": "01",
             "// ietf-otn-tunnel:src-client-signal": "None: ODU transit\
   \ __NOT-PRESENT__ destination": "Head tunnel segment",
             "// ietf-otn-tunnel:dst-client-signal": "None: ODU transit\
   \ __NOT-PRESENT__ dst-tp-id": "Head tunnel segment",
             "bidirectional": true,
             "// protection": "No protection",
             "// __ DEFAULT __ protection": {
               "// __ DEFAULT __ enable": false
             },
             "// restoration": "No restoration",
             "// __ DEFAULT __ restoration": {
               "// __ DEFAULT __ enable": false
             },
             "// __COMMENT__ te-topology-identifier": "ODU Black Topology @ MPI1",
             "te-topology-identifier": {
               "provider-id": 201,
               "client-id": 300,
               "topology-id": "otn-black-topology"
             },
             "te-bandwidth": {
               "ietf-otn-tunnel:odu-type": "ietf-otn-types:prot-ODU2"
             },
             "// hierarchical-link": "None: transit tunnel segment",
             "p2p-primary-paths": {
               "p2p-primary-path": [
                 {
                   "name": "mpi1-odu2-service-primary-path",
                   "path-scope": "ietf-te-types:path-scope-segment",
                   "// te-bandwidth": "None: only the tunnel bandwidth \
   \needs to be specified in transport applications",
                   "explicit-route-objects": {
                     "route-object-include-exclude": [
                       {
                         "// comment": "Tunnel hand-off OTU2 ingress in\
   \terface (S3-1)",
                         "index": 1,
                         "explicit-route-usage": "ietf-te-types:route-i\
   \nclude-ero",
                         "num-unnum-hop": {
                           "// node-id": "AN1 Node",
                           "node-id": "10.0.0.1",
                           "// link-tp-id": "AN1-1 LTP",
                           "link-tp-id": 1,
                           "hop-type": "STRICT",
                           "direction": "INCOMING"
                         }
                       },
                       {
                         "// comment": "Tunnel hand-off ODU2 ingress la\
   \bel (ODU2 over OTU2) at S3-1",
                         "index": 2,
                         "explicit-route-usage": "ietf-te-types:route-i\
   \nclude-ero",

Internet-Draft  Transport NBI Applicability-Statement    September 20199

                         "label-hop": Topolo\

   \gy @ MPI1",
             "te-topology-identifier": {
                           "te-label":
               "provider-id": 201,
               "client-id": 300,
               "topology-id": "otn-black-topology"
             },
             "te-bandwidth": {
                             "// __ DISCUSS __ odu-label": "How are HO-\
   \ODU (ODUk over OTUk) label represented?",
                             "// __ DISCUSS __ direction": "Check with \
   \TE Tunnel authors",
                             "direction": "FORWARD "
                           }
                         }
               "ietf-otn-tunnel:odu-type": "ietf-layer1-types:ODU2"
             },
             "provisioning-state": "ietf-te-types:tunnel-state-down",
             "p2p-primary-paths": {
               "p2p-primary-path": [
                 {
                   "name": "mpi1-odu2-tunnel-primary-path",
                   "// comment": __NOT-PRESENT__ te-bandwidth": "The tunnel bandw\
   \idth is used",
                   "explicit-route-objects-always": {
                     "route-object-include-exclude": [
                       {
                         "// __COMMENT__": "Tunnel hand-off OTU4 egress int\
   \erface (S2-1)", egress\
   \ interface (AN1-7 LTP)",
                         "index": 3, 1,
                         "explicit-route-usage": "ietf-te-types:route-i\
   \nclude-ero",
                         "num-unnum-hop":
   \nclude-object",
                         "unnumbered-link-hop": {
                           "// __COMMENT__ node-id": "AN1 Node", NODE-ID",
                           "node-id": "10.0.0.1",
                           "// __COMMENT__ link-tp-id": "AN1-2 LTP", "AN1-7 LTP-ID",
                           "link-tp-id": 1,
                           "hop-type": "STRICT",
                           "direction": "OUTGOING" 7,
                           "// __DEFAULT__ hop-type": "strict",
                           "// __DEFAULT__ direction": "outgoing"
                         }
                       },
                       {
                         "// comment": __COMMENT__": "Tunnel hand-off ODU2 egress lab\
   \el egress\
   \ label (ODU2 over OTU4) at S2-1", OTU4)",
                         "index": 4, 2,
                         "explicit-route-usage": "ietf-te-types:route-i\
   \nclude-ero",
   \nclude-object",
                         "label-hop": {
                           "te-label": {
                             "ietf-otn-tunnel:tpn": 1, 2,
                             "ietf-otn-tunnel:tsg": "ietf-otn-types:tsg\
   \-1.25G", "ietf-layer1-types:\
   \tsg-1.25G",
                             "ietf-otn-tunnel:ts-list": "1-8", "9-16",
                             "// __ DISCUSS __ __DEFAULT__ direction": "Check with \
   \TE Tunnel authors",
                             "direction": "FORWARD " "forward"
                           }
                         }
                       }
                     ]
                   }
                 }
               ]
             }
           }
         ]
       }
     }
   }

B.2.2.   JSON Code: mpi1-odu2-tunnel-config.json

   The JSON code for this use case will be added in a future version of
   this document

   An incomplete version is located on GitHub at:

   https://github.com/danielkinguk/transport-nbi

B.2.3.   JSON Code: mpi1-epl-service-config.json

   The

   This is the JSON code reporting the EPL service configuration @ MPI:

   ========== NOTE: '\\' line wrapping per BCP XXX (RFC XXXX) ==========

   {
     "// __LAST_UPDATE__": "October 16, 2019",
     "// __TITLE__": "EPL Configuration @ MPI1",
     "// __REFERENCE_DRAFTS__": {
       "ietf-routing-types@2017-12-04": "rfc8294",
       "ietf-te-types@2019-07-05": "draft-ietf-teas-yang-te-types-10",
       "ietf-eth-tran-types@2019-03-27": "draft-ietf-ccamp-client-signa\
   \l-yang-00",
       "ietf-eth-tran-service@2019-03-27": "draft-ietf-ccamp-client-sig\
   \nal-yang-00"
     },
     "// __MISSING_ATTRIBUTES__": true,
     "// __RESTCONF_OPERATION__": {
       "operation": "POST",
       "url": "http://{{PNC1-ADDR}}/restconf/data/ietf-eth-tran-service\
   \:etht-svc/etht-svc-instances"
     },
     "ietf-eth-tran-service:etht-svc": {
       "etht-svc-instances": [
         {
           "etht-svc-name": "mpi1-epl-service",
           "etht-svc-descr": "TNBI Example for this use case will be added in a future version an EPL over ODU2 Service\

   \ @ MPI1",
           "// __DEFAULT__ etht-svc-type": "ietf-eth-tran-types:p2p-svc\
   \",
           "// __COMMENT__ te-topology-identifier": "ETH Black Topology\
   \ @ MPI1",
           "te-topology-identifier": {
             "provider-id": 201,
             "client-id": 300,
             "topology-id": "eth-black-topology"
           },
           "etht-svc-end-points": [
             {
               "// __COMMENT__": "10GE Service End-Point at the access \
   \interface (S3-1 -> AN1-1)",
               "etht-svc-end-point-name": "mpi1-epl-an1-1-service-end-p\
   \oint",
               "etht-svc-end-point-descr": "Ethernet Service End-Point \
   \at S3-1 (AN1-1) access link",
               "etht-svc-access-points": [
                 {
                   "// __COMMENT__": "10GE Service Access Point at the \
   \access interface (S3-1 -> AN1-1)",
                   "etht-svc-end-point-name": "mpi-epl-an1-1-service-ac\
   \cess-point",
                   "// __COMMENT__ access-node-id": "AN1 NODE-ID",
                   "access-node-id": "10.0.0.1",
                   "// __COMMENT__ access-ltp-id": "AN1-1 LTP-ID",
                   "access-ltp-id": 1
                 }
               ]
             }
           ],
           "service-classification-type": "ietf-eth-tran-types:port-cla\
   \ssification",
           "// __COMMENT__ ingress-egress-bandwidth-profile": "Outside \
   \the scope of this document

   An incomplete version is located on GitHub at:

   https://github.com/danielkinguk/transport-nbi JSON example",
           "// __NOT-PRESENT__ vlan-operations": "Transparent VLAN oper\
   \ations",
           "etht-svc-tunnels": [
             {
               "// __COMMENT__ tunnel-name": "ODU2 Head Tunnel Segment \
   \@ MPI1",
               "tunnel-name": "mpi1-odu2-tunnel"
             }

           ],
           "admin-status": "ietf-te-types:tunnel-admin-state-up"
         }
       ]
     }
   }
   Authors' Addresses

   Italo Busi (Editor)
   Huawei

   Email: italo.busi@huawei.com

   Daniel King (Editor)
   Old Dog Consulting

   Email: daniel@olddog.co.uk

   Haomian Zheng (Editor)
   Huawei

   Email: zhenghaomian@huawei.com

   Yunbin Xu (Editor)
   CAICT

   Email: xuyunbin@ritt.cn

   Yang Zhao
   China Mobile

   Email: zhaoyangyjy@chinamobile.com

   Sergio Belotti
   Nokia

   Email: sergio.belotti@nokia.com

   Gianmarco Bruno
   Ericsson

   Email: gianmarco.bruno@ericsson.com
   Young Lee
   Sung Kyun Kwan University
   Huawei

   Email: younglee.tx@gmail.com leeyoung@huawei.com

   Victor Lopez
   Telefonica

   Email: victor.lopezalvarez@telefonica.com

   Carlo Perocchio
   Ericsson

   Email: carlo.perocchio@ericsson.com

   Ricard Vilalta
   CTTC

   Email: ricard.vilalta@cttc.es

   Michael Scharf
   Hochschule Esslingen - University of Applied Sciences

   Email: michael.scharf@hs-esslingen.de

   Dieter Beller
   Nokia

   Email: dieter.beller@nokia.com