Skip to main content

Applicability of Abstraction and Control of Traffic Engineered Networks (ACTN) to Packet Optical Integration (POI)
draft-ietf-teas-actn-poi-applicability-07

Document Type Active Internet-Draft (teas WG)
Authors Fabio Peruzzini , Jean-Francois Bouquier , Italo Busi , Daniel King , Daniele Ceccarelli
Last updated 2022-07-10
Replaces draft-peru-teas-actn-poi-applicability
Stream Internet Engineering Task Force (IETF)
Intended RFC status (None)
Formats
Stream WG state WG Document
Document shepherd (None)
IESG IESG state I-D Exists
Consensus boilerplate Unknown
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-ietf-teas-actn-poi-applicability-07
TEAS Working Group                                      Fabio Peruzzini
Internet Draft                                                      TIM
Intended status: Informational                   Jean-Francois Bouquier
                                                               Vodafone
                                                             Italo Busi
                                                                 Huawei
                                                            Daniel King
                                                     Old Dog Consulting
                                                     Daniele Ceccarelli
                                                               Ericsson

Expires: January 2023                                     July 10, 2022

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

                 draft-ietf-teas-actn-poi-applicability-07

Abstract

   This document considers the applicability of Abstraction and Control
   of TE Networks (ACTN) architecture to Packet Optical Integration
   (POI)in the context of IP/MPLS and optical internetworking. It
   identifies the YANG data models being defined by the IETF to support
   this deployment architecture and specific scenarios relevant for
   Service Providers.

   Existing IETF protocols and data models are identified for each
   multi-layer (packet over optical) scenario with a specific focus on
   the MPI (Multi-Domain Service Coordinator to Provisioning Network
   Controllers Interface)in the ACTN architecture.

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."

Peruzzini et al.       Expires January 10, 2023                [Page 1]
Internet-Draft                 ACTN POI                       July 2022

   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 April 9, 2021.

Copyright Notice

   Copyright (c) 2022 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.

Table of Contents

   1. Introduction...................................................3
      1.1. Terminology...............................................5
   2. Reference network architecture.................................7
      2.1. Multi-domain Service Coordinator (MDSC) functions.........9
         2.1.1. Multi-domain L2/L3 VPN network services.............11
         2.1.2. Multi-domain and multi-layer path computation.......14
      2.2. IP/MPLS Domain Controller and NE Functions...............17
      2.3. Optical Domain Controller and NE Functions...............19
   3. Interface protocols and YANG data models for the MPIs.........19
      3.1. RESTCONF protocol at the MPIs............................19
      3.2. YANG data models at the MPIs.............................20
         3.2.1. Common YANG data models at the MPIs.................20
         3.2.2. YANG models at the Optical MPIs.....................21
         3.2.3. YANG data models at the Packet MPIs.................22
      3.3. PCEP.....................................................23
   4. Inventory, service and network topology discovery.............24
      4.1. Optical topology discovery...............................25
      4.2. Optical path discovery...................................27
      4.3. Packet topology discovery................................27
      4.4. TE path discovery........................................28
      4.5. Inter-domain link discovery..............................29

Peruzzini et al.       Expires January 10, 2023                [Page 2]
Internet-Draft                 ACTN POI                       July 2022

         4.5.1. Cross-layer link discovery..........................30
         4.5.2. Inter-domain IP link discovery......................32
      4.6. Multi-layer IP link discovery............................34
         4.6.1. Single-layer intra-domain IP links..................37
      4.7. LAG discovery............................................39
      4.8. L2/L3 VPN network services discovery.....................41
      4.9. Inventory discovery......................................41
   5. Establishment of L2/L3 VPN network services with TE requirements
   .................................................................42
      5.1. Optical Path Computation.................................44
      5.2. Multi-layer IP link Setup................................45
         5.2.1. Multi-layer LAG setup...............................47
         5.2.2. Multi-layer LAG update..............................47
         5.2.3. Multi-layer SRLG configuration......................48
      5.3. TE Path Setup and Update.................................48
   6. Conclusions...................................................49
   7. Security Considerations.......................................50
   8. Operational Considerations....................................50
   9. IANA Considerations...........................................50
   10. References...................................................50
      10.1. Normative References....................................50
      10.2. Informative References..................................52
   Appendix A.    OSS/Orchestration Layer...........................55
      A.1.  MDSC NBI................................................55
   Appendix B.    Multi-layer and multi-domain resiliency...........58
      B.1.  Maintenance Window......................................58
      B.2.  Router port failure.....................................58
   Acknowledgments..................................................59
   Contributors.....................................................59
   Authors' Addresses...............................................61

1. Introduction

   The complete automation of the management and control of Service
   Providers transport networks (IP/MPLS, optical, and microwave
   transport networks) is vital for meeting emerging demand for high-
   bandwidth use cases, including 5G and fiber connectivity services.
   The Abstraction and Control of TE Networks (ACTN) architecture and
   interfaces facilitate the automation and operation of complex optical
   and IP/MPLS networks through standard interfaces and data models.
   This allows a wide range of network services that can be requested by
   the upper layers fulfilling almost any kind of service level
   requirements from a network perspective (e.g. physical diversity,
   latency, bandwidth, topology, etc.)

Peruzzini et al.       Expires January 10, 2023                [Page 3]
Internet-Draft                 ACTN POI                       July 2022

   Packet Optical Integration (POI) is an advanced use case of traffic
   engineering. In wide-area networks, a packet network based on the
   Internet Protocol (IP), and often Multiprotocol Label Switching
   (MPLS) or Segment Routing (SR), is typically realized on top of an
   optical transport network that uses Dense Wavelength Division
   Multiplexing (DWDM)(and optionally an Optical Transport Network
   (OTN)layer).

   In many existing network deployments, the packet and the optical
   networks are engineered and operated independently. As a result,
   there are technical differences between the technologies (e.g.,
   routers compared to optical switches) and the corresponding network
   engineering and planning methods (e.g., inter-domain peering
   optimization in IP, versus dealing with physical impairments in DWDM,
   or very different time scales). In addition, customers needs can be
   different between a packet and an optical network, and it is not
   uncommon to use different vendors in both domains. The operation of
   these complex packet and optical networks is often siloed, as these
   technology domains require specific skills sets.

   The packet/optical network deployment and operation separation are
   inefficient for many reasons. Both capital expenditure (CAPEX) and
   operational expenditure (OPEX) could be significantly reduced by
   integrating the packet and the optical networks. Multi-layer online
   topology insight can speed up troubleshooting (e.g., alarm
   correlation) and network operation (e.g., coordination of maintenance
   events), multi-layer offline topology inventory can improve service
   quality (e.g., detection of diversity constraint violations) and
   multi-layer traffic engineering can use the available network
   capacity more efficiently (e.g., coordination of restoration). In
   addition, provisioning workflows can be simplified or automated as
   needed across layers (e.g., to achieve bandwidth-on-demand or to
   perform activities during maintenance windows).

   ACTN framework enables this complete multi-layer and multi-vendor
   integration of packet and optical networks through Multi-Domain
   Service Coordinator (MDSC) and packet and optical Provisioning
   Network Controllers (PNCs).

   In this document, critical scenarios for POI are described from the
   packet service layer perspective and identified the required
   coordination between packet and optical layers to improve POI
   deployment and operation. Precise definitions of scenarios can help
   with achieving a common understanding across different disciplines.
   The focus of the scenarios are multi-domain packet networks operated
   as a client of optical networks.

Peruzzini et al.       Expires January 10, 2023                [Page 4]
Internet-Draft                 ACTN POI                       July 2022

   This document analyses the case where the packet networks support
   multi-domain SR-TE paths and the optical networks could be either a
   DWDM network or an OTN network (without DWDM layer) or multi-layer
   OTN/DWDM network. DWDM networks could be either fixed-grid or
   flexible-grid.

   Multi-layer and multi-domain scenarios, based on reference network
   described in section 2, and very relevant for Service Providers, are
   described in section 4 and in setion 5.

   For each scenario, existing IETF protocols and data models,
   identified in section 3.1 and section 3.2, are analysed with
   particular focus on the MPI in the ACTN architecture.

   For each multi-layer scenario, the document analyzes how to use the
   interfaces and data models of the ACTN architecture.

   A summary of the gaps identified in this analysis is provided in
   section 6.

   Understanding the level of standardization and the possible gaps will
   help assess the feasibility of integration between packet and optical
   DWDM domains (and optionally OTN layer) in an end-to-end multi-vendor
   service provisioning perspective.

1.1. Terminology

   This document uses the ACTN terminology defined in [RFC8453]

   In addition this document uses the following terminology.

   Customer service:

     the end-to-end service from CE to CE

   Network service:

     the PE to PE configuration including both the network service layer
     (VRFs, RT import/export policies configuration) and the network
     transport layer (e.g. RSVP-TE LSPs). This includes the
     configuration (on the PE side) of the interface towards the CE
     (e.g. VLAN, IP adress, routing protocol etc.)

   Port:

     the physical entity that transmits and receives physical signals

Peruzzini et al.       Expires January 10, 2023                [Page 5]
Internet-Draft                 ACTN POI                       July 2022

   Interface:

     a physical or logical entity that transmits and receives traffic

   Link:

     an association between two interfaces that can exchange traffic
     directly

   Ethernet link:

     a link between two Ethernet interfaces

   IP link:

     a link between two IP interfaces

   Cross-layer link:

     an Ethernet link between an Ethernet interface on a router and an
     Ethernet interface on an optical NE

   Intra-domain single-layer Ethernet link:

     an Ethernet link between between two Ethernet interfaces on
     physically adjacent routers that belong to the same P-PNC domain

   Intra-domain single-layer IP link:

     an IP link supported by an intra-domain single-layer Ethernet link

   Inter-domain single-layer Ethernet link:

     an Ethernet link between between two Ethernet interfaces on
     physically adjacent routers which belong to different P-PNC domains

   Inter-domain single-layer IP link:

     an IP link supported by an inter-domain single-layer Ethernet link.

   Intra-domain multi-layer Ethernet link:

     an Ethernet link supported by two cross-layer links and an optical
     tunnel in between

Peruzzini et al.       Expires January 10, 2023                [Page 6]
Internet-Draft                 ACTN POI                       July 2022

   Intra-domain multi-layer IP link:

     an IP link supported an intra-domain multi-layer Ethernet link

2. Reference network architecture

   This document analyses several deployment scenarios for Packet and
   Optical Integration (POI) in which ACTN hierarchy is deployed to
   control a multi-layer and multi-domain network, with two optical
   domains and two packet domains, as shown in Figure 1:

                              +----------+
                              |   MDSC   |
                              +-----+----+
                                    |
                  +-----------+-----+------+-----------+
                  |           |            |           |
             +----+----+ +----+----+  +----+----+ +----+----+
             | P-PNC 1 | | O-PNC 1 |  | O-PNC 2 | | P-PNC 2 |
             +----+----+ +----+----+  +----+----+ +----+----+
                  |           |            |           |
                  |           \            /           |
        +-------------------+  \          /  +-------------------+
   CE1 / PE1             BR1 \  |        /  / BR2             PE2 \ CE2
   o--/---o               o---\-|-------|--/---o               o---\--o
      \   :               :   / |       |  \   :               :   /
       \  : PKT domain 1  :  /  |       |   \  : PKT domain 2  :  /
        +-:---------------:-+   |       |    +-:---------------:--+
          :               :     |       |      :               :
          :               :     |       |      :               :
        +-:---------------:------+     +-------:---------------:--+
       /  :               :       \   /        :               :   \
      /   o...............o        \ /         o...............o    \
      \     optical domain 1       / \       optical domain 2       /
       \                          /   \                            /
        +------------------------+     +--------------------------+

                       Figure 1 - Reference Network

   The ACTN architecture, defined in [RFC8453], is used to control this
   multi-layer and multi-domain network where each Packet PNC (P-PNC) is
   responsible for controlling its packet domain and where each Optical
   PNC (O-PNC) in the above topology is responsible for controlling its

Peruzzini et al.       Expires January 10, 2023                [Page 7]
Internet-Draft                 ACTN POI                       July 2022

   optical domain. The packet domains controlled by the P-PNCs can be
   Autonomous Systems (ASes), defined in [RFC1930], or IGP areas, within
   the same operator network.

   The routers between the packet domains can be either AS Boundary
   Routers (ASBR) or Area Border Router (ABR): in this document, the
   generic term Border Router (BR) is used to represent either an ASBR
   or an ABR.

   The MDSC is responsible for coordinating the whole multi-domain
   multi-layer (packet and optical) network. A specific standard
   interface (MPI) permits MDSC to interact with the different
   Provisioning Network Controller (O/P-PNCs).

   The MPI interface presents an abstracted topology to MDSC hiding
   technology-specific aspects of the network and hiding topology
   details depending on the policy chosen regarding the level of
   abstraction supported. The level of abstraction can be obtained based
   on P-PNC and O-PNC configuration parameters (e.g., provide the
   potential connectivity between any PE and any BR in an SR-TE
   network).

   In the reference network of Figure 1, it is assumed that:

   o  The domain boundaries between the packet and optical domains are
      congruent. In other words, one optical domain supports
      connectivity between routers in one and only one packet domain;

   o  There are no inter-domain physical links between optical domains.
      Inter-domain physical links exist only:

       o between packet domains (i.e., between BRs belonging to
          different packet domains): these links are called inter-domain
          Ethernet or IP links within this document;

       o between packet and optical domains (i.e., between routers and
          optical NEs): these links are called cross-layer links within
          this document;

       o between customer sites and the packet network (i.e., between CE
          devices and PE routers): these links are called access links
          within this document.

   o  All the physical interfaces at inter-domain links are Ethernet
      physical interfaces.

Peruzzini et al.       Expires January 10, 2023                [Page 8]
Internet-Draft                 ACTN POI                       July 2022

   Although the new optical technologies (e.g., QSFP-DD ZR 400G) allows
   providing DWDM pluggable interfaces on the routers, the deployment of
   those pluggable optics is not yet widely adopted by the operators.
   The reason is that most operators are not yet ready to manage packet
   and optical networks in a single unified domain. The analysis of the
   unified use case is outside the scope of this draft.

   This document analyses scenarios where all the multi-layer IP links,
   supported by the optical network, are intra-domain (intra-AS/intra-
   area), such as PE-BR, PE-P, BR-P, P-P IP links. Therefore the inter-
   domain IP links are always single-layer links supported by Ethernet
   physical links.

   The analysis of scenarios with multi-layer inter-domain IP links is
   outside the scope of this document.

   Therefore, if inter-domain links between the optical domains exist,
   they would be used to support multi-domain optical services, which
   are outside the scope of this document.

   The optical network elements (NEs) within the optical domains can be
   ROADMs or OTN switches, with or without an integrated ROADM function.

2.1. Multi-domain Service Coordinator (MDSC) functions

   The MDSC in Figure 1 is responsible for multi-domain and multi-layer
   coordination across multiple packet and optical domains, as well as
   to provide multi-layer/multi-domain L2/L3 VPN network services
   requested by an OSS/Orchestration layer.

   From an implementation perspective, the functions associated with
   MDSC and described in [RFC8453] may be grouped in different ways.

   1. Both the service- and network-related functions are collapsed into
     a single, monolithic implementation, dealing with the end customer
     service requests received from the CMI (Customer MDSC Interface)
     and adapting the relevant network models. An example is represented
     in Figure 2 of [RFC8453].
   2. An implementation can choose to split the service-related and the
     network-related functions into different functional entities, as
     described in [RFC8309] and in section 4.2 of [RFC8453]. In this
     case, MDSC is decomposed into a top-level Service Orchestrator,
     interfacing the customer via the CMI, and into a Network
     Orchestrator interfacing at the southbound with the PNCs. The
     interface between the Service Orchestrator and the Network
     Orchestrator is not specified in [RFC8453].

Peruzzini et al.       Expires January 10, 2023                [Page 9]
Internet-Draft                 ACTN POI                       July 2022

   3. Another implementation can choose to split the MDSC functions
     between an "higher-level MDSC" (MDSC-H) responsible for packet and
     optical multi-layer coordination, interfacing with one Optical
     "lower-level MDSC" (MDSC-L), providing multi-domain coordination
     between the O-PNCs and one Packet MDSC-L, providing multi-domain
     coordination between the P-PNCs (see for example Figure 9 of
     [RFC8453]).
   4. Another implementation can also choose to combine the MDSC and the
     P-PNC functions together.

   In the current service provider's network deployments, at the North
   Bound of the MDSC, instead of a CNC, typically there is an
   OSS/Orchestration layer. In this case, the MDSC would implement only
   the Network Orchestration functions, as in [RFC8309] and described in
   point 2 above. Therefore, the MDSC is dealing with the network
   services requests received from the OSS/Orchestration layer.

   The functionality of the OSS/Orchestration layer and the interface
   toward the MDSC are usually operator-specific and outside the scope
   of this draft. Therefore, this document assumes that the
   OSS/Orchestrator requests the MDSC to set up L2/L3 VPN network
   services through mechanisms that are outside the scope of this
   document.

   There are two prominent workflow cases when the MDSC multi-layer
   coordination is initiated:

   o  Initiated by a request from the OSS/Orchestration layer to setup
      L2/L3 VPN network services that requires multi-layer/multi-domain
      coordination;

   o  Initiated by the MDSC itself to perform multi-layer/multi-domain
      optimizations and/or maintenance activities (e.g. rerouting LSPs
      with their associated services when putting a resource, like a
      fibre, in maintenance mode during a maintenance window).
      Unlike service fulfillment, these workflows are not related to a
      network service provisioning request being received from
      the OSS/Orchestration layer.

   The latter workflow cases are outside the scope of this document.

   This document analyses the use cases where multi-layer coordination
   is triggered by a network service request received from the
   OSS/Orchestration layer.

Peruzzini et al.       Expires January 10, 2023               [Page 10]
Internet-Draft                 ACTN POI                       July 2022

2.1.1. Multi-domain L2/L3 VPN network services

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

Peruzzini et al.       Expires January 10, 2023               [Page 11]
Internet-Draft                 ACTN POI                       July 2022

        ------
       | CE13 |___________________
        ------                    )           __________________
       ( |                         )         (                  )
      (  | PE13     P15       BR11  )       (  BR21         P24  )
     ( ____         ___       ____   )     (   ____         ___   )
    ( / H  \ _ _ _ /   \ _ _ /    \ _)_ _ _(_ /    \ _ _ _ /   \  )
   (  \____/...    \___/     \____/   )   (   \____/       \___/   )
   (          :.....                   )  (                  |     )
   (    ____       :__       ____      )  (  ____           _|__   )
    (  / S  \...../   \._._./    \__________/    \._._._._./  S \  )
     ( \____/     \___/     \____/     )  ( \____/         \____/  )
      (   |                           )    (                   |  )
       (  | PE14   P16       BR12     )    ( BR22         PE23 |  )
        ( |                          )      (                  | )
        ------                      )        (               ------
       | CE14 | ___________________)          (_____________| CE23 |
        ------                                               ------

       _____________________________         ___________________
      (                             )       (                   )
     ( ____              ____        )     (       ____          )
    ( /NE11\ __ _ _ _ _ /NE12\        )   (       /NE21\ _ _      )
   (  \____/..          \____/         )  (       \____/    \     )
   (     |   :.....  ...:   \          )  (        /         \    )
   (    _|__      :__:        \____    )  (    ___/         __\_  )
   (   /NE13\_ _ /NE14\ _ _ _ /NE15\   )  (   /NE22\ _ _ _ /NE23\ )
    (  \____/    \____/       \____/  )   (   \____/       \____/ )
     (                               )     (                     )
      (_____________________________)       (___________________)

             optical domain 1                  optical domain 2

        H / S = Hub VRF / Spoke VRF
       ____   = Inter-domain interconnections
       .....  = SR policy Path 1
       _ _ _  = SR policy Path 2

                   Figure 2 - Multi-domain L3VPN example

   There are many options to implement multi-domain L2/L3 VPNs,
   including:

     1. BGP-LU (seamless MPLS)
     2. Inter-domain RSVP-TE

Peruzzini et al.       Expires January 10, 2023               [Page 12]
Internet-Draft                 ACTN POI                       July 2022

     3. Inter-domain SR-TE

   This document provides an analysis of the inter-domain TE options,
   such as inter-domain SR-TE, for which the TE tunnel model, defined in
   [TE-TUNNEL], could be used at the MPI for intra-domain or inter-
   domain TE configuration. The analysis of other options is outside the
   scope of this draft.

   It is also assumed that:

   o  the bandwidth of each intra-domain TE path is managed by its
      respective P-PNC;

   o  technology-specific mechanisms (such as, in case of inter-domain
      SR-TE, the binding SID) are used for the inter-domain TE path
      stitching;

   o  each packet domain in Figure 2 is using technology-specific local
      protection mechanisms (such as, in case of SR-TE, TI-LFA), with
      SRLG awareness.

   In case of inter-domain SR-TE, it is also assumed that each packet
   domain in Figure 2 is implementing SR-TE and the stitching between
   two domains is done using inter-domain SR-TE.

   In this scenario, one of the key MDSC functions is to identify the
   multi-domain/multi-layer TE paths to be used to carry the L2/L3 VPN
   traffic between PEs belonging to different packet domains and to
   relay this information to the P-PNCs, to ensure that the PEs'
   forwarding tables (e.g., VRF) are properly configured to steer the
   L2/L3 VPN traffic over the intended multi-domain/multi-layer TE
   paths.

   The selection of the TE path should take into account the TE
   requirements and the binding requirements for the L2/L3 VPN network
   service.

   In general the binding requirements for a network service (e.g L2/L3
   VPN), can be summarized within three cases:

     1. The customer is asking for VPN isolation dynamically creating
        and binding tunnels to the service such that they are not shared
        by others services (e.g. VPN).
        The level of isolation can be different:
          a) Hard isolation with deterministic latency that means L2/L3
             VPN requiring a set of dedicated TE Tunnels (neither

Peruzzini et al.       Expires January 10, 2023               [Page 13]
Internet-Draft                 ACTN POI                       July 2022

             sharing with other services nor competing for bandwidth
             with other tunnels) providing deterministic latency
             performances
          b) Hard isolation but without deterministic characteristics
          c) Soft isolation that means the tunnels associated with L2/L3
             VPN are dedicated to that but can compete for bandwidth
             with other tunnels.
     2. The customer does not ask isolation, and could request a VPN
        service where associated tunnels can be shared across multiple
        VPNs.

   For each TE path (e.g., each SR-TE path) required to support the
   L2/L3 VPN network service, it is possible that:

   1. A TE path that meets the TE and binding requirements already exist
      in the network.

   2. An existing TE path could be modified (e.g., through bandwidth
      increase) to meet the TE and binding requirements:

       a. The TE path characteristics can be modified only in the packet
          layer.

       b. One or more new underlay optical tunnels need to be setup to
          support the requested changes of the overlay TE paths (multi-
          layer coordination is required).

   3. A new TE path needs to be setup to meet the TE and binding
      requirements:

       a. The new TE path reuses existing underlay optical tunnels;

       b. One or more new underlay optical tunnels need to be setup to
          support the setup of the new TE path  (multi-layer
          coordination is required).

2.1.2. Multi-domain and multi-layer path computation

   When a new TE path (e.g., a new SR-TE path) needs to be setup, the
   MDSC is also responsible to coordinate the multi-layer/multi-domain
   path computation.

   Depending on the knowledge that MDSC has of the topology and
   configuration of the underlying network domains, three approaches for
   performing multi-layer/multi-domain path computation are possible:

Peruzzini et al.       Expires January 10, 2023               [Page 14]
Internet-Draft                 ACTN POI                       July 2022

   1. Full Summarization: In this approach, the MDSC has an abstracted
      TE topology view of all of its, packet and optical, underlying
      domains.

      In this case, the MDSC does not have enough TE topology
      information to perform multi-layer/multi-domain path computation.
      Therefore the MDSC delegates the P-PNCs and O-PNCs to perform
      local path computation within their respective controlled domains
      and it uses the information returned by the P-PNCs and O-PNCs to
      compute the optimal multi-domain/multi-layer path.

      This approach presents an issue to P-PNC, which does not have the
      capability of performing a single-domain/multi-layer path
      computation, since it can not retrieve the topology information
      from the O-PNCs nor delegate the O-PNC to perform optical path
      computation.

      A possible solution could be to include a CNC function within the
      P-PNC to request the MDSC multi-domain optical path computation,
      as shown in Figure 10 of [RFC8453].

      Another solution could be to rely on the MDSC recursive hierarchy,
      as defined in section 4.1 of [RFC8453], where, for each IP and
      optical domain pair, a "lower-level MDSC" (MDSC-L) provides the
      essential multi-layer correlation and the "higher-level MDSC"
      (MDSC-H) provides the multi-domain coordination.
      In this case, the MDSC-H can get an abstact view of the underlying
      multi-layer domain topologies from its underlying MDSC-L. Each
      MDSC-L gets the full view of the IP domain topology from P-PNC and
      can get an abstracted view of the optical domain topology from its
      underlying O-PNC. In other words, topology abstraction is possible
      at the MPIs between MDSC-L and O-PNC and between MDSC-L and MDSC-
      H.

Peruzzini et al.       Expires January 10, 2023               [Page 15]
Internet-Draft                 ACTN POI                       July 2022

   2. Partial summarization: In this approach, the MDSC has full
      visibility of the TE topology of the packet network domains and an
      abstracted view of the TE topology of the optical network domains.

      The MDSC then has only the capability of performing multi-
      domain/single-layer path computation for the packet layer (the
      path can be computed optimally for the two packet domains).

      Therefore, the MDSC still needs to delegate the O-PNCs to perform
      local path computation within their respective domains and it uses
      the information received by the O-PNCs, together with its TE
      topology view of the multi-domain packet layer, to perform multi-
      layer/multi-domain path computation.

   3. Full knowledge: In this approach, the MDSC has the complete and
      enough detailed view of the TE topology of all the network domains
      (both optical and packet).

      In such case MDSC has all the information needed to perform multi-
      domain/multi-layer path computation, without relying on PNCs.

      This approach may present, as a potential drawback, scalability
      issues and, as discussed in section 2.2. of [PATH-COMPUTE],
      performing path computation for optical networks in the MDSC is
      quite challenging because the optimal paths depend also on
      vendor-specific optical attributes (which may be different in the
      two domains if they are provided by different vendors).

   This document analyses scenarios where the MDSC uses the partial
   summarization approach to coordinate multi-domain/multi-layer path
   computation.

   Typically, the O-PNCs are responsible for the optical path
   computation of services across their respective single domains.
   Therefore, when setting up the network service, they must consider
   the connection requirements such as bandwidth, amplification,
   wavelength continuity, and non-linear impairments that may affect the
   network service path.

   The methods and types of path requirements and impairments, such as
   those detailed in [OIA-TOPO], used by the O-PNC for optical path
   computation are not exposed at the MPI and therefore out of scope for
   this document.

Peruzzini et al.       Expires January 10, 2023               [Page 16]
Internet-Draft                 ACTN POI                       July 2022

2.2. IP/MPLS Domain Controller and NE Functions

   Each packet domain in Figure 1, corresponding to either an IGP area
   or an Autonomous System (AS) within the same operator network, is
   controlled by a packet domain controller (P-PNC).

   P-PNCs are responsible to setup the TE paths between any two PEs or
   BRs in their respective controlled domains, as requested by MDSC,
   and to provide topology information to the MDSC.

   For example, with reference to Figure 2, a bidirectional SR-TE path
   from PE13 in domain 1 to PE23 in domain 2 requires the MDSC to
   coordinate the actions of:

   o  P-PNC1 to push a SID list to PE13 including the Binding SID
      associated to the SR-TE path in Domain 2 with PE23 as the target
      destination (forward direction);

   o  P-PNC2 to push a SID list to PE23 with including the Binding SID
      associated to the SR-TE path in Domain 1 with PE13 as the target
      destination (reverse direction).

   With reference to Figure 3, P-PNCs are then responsible:

   1. To expose to MDSC their respective detailed TE topology

   2. To perform single-layer single-domain local TE path computation,
      when requested by MDSC between two PEs (for single-domain end-to-
      end TE path) or between PEs and BRs for an inter-domain TE path
      selected by MDSC;

   3. To configure the routers in their respective domain to setup a TE
      path: for example, in case of SR-TE, to configure the ingress PE
      or BR router with the SID list associated with an SR-TE path;

   4. To configure finally the VRF and PE-CE interfaces (Service access
      points) of the intra-domain and inter-domain network services
      requested by the MDSC.

Peruzzini et al.       Expires January 10, 2023               [Page 17]
Internet-Draft                 ACTN POI                       July 2022

          +------------------+            +------------------+
          |                  |            |                  |
          |      P-PNC1      |            |      P-PNC2      |
          |                  |            |                  |
          +--|-----------|---+            +--|-----------|---+
             | 1.TE      | 2.VPN             | 1.TE      | 2.VPN
             | Path      | Provisioning      | Path      | Provisioning
             | Config    |                   | Config    |
             V           V                   V           V
           +---------------------+         +---------------------+
      CE  / PE     TE path 1    BR\       / BR     TE path 2   PE \  CE
      o--/---o..................o--\-----/--o..................o---\--o
         \                         /     \                         /
          \        Domain 1       /       \       Domain 2        /
           +---------------------+         +---------------------+

                              End-to-end TE path
             <------------------------------------------------->

                Figure 3  Domain Controller & NE Functions

   When requesting the setup of a new TE path, the MDSC provides the P-
   PNCs with the explicit path to be created or modified. In other
   words, the MDSC can communicate to the P-PNCs the full list of nodes
   involved in the path (strict mode). In this case, the P-PNC is just
   responsible to set up that explicit TE path. For example:

   o  with SR-TE, the P-PNC just pushes to headend PE or BR the list of
      SIDs to create the explicit SR-TE path, provided by the MDSC;

   o  with RSVP-TE, the P-PNC requests the headend PE or BR to start the
      signaling of the explicit RSVP-TE path, provided by the MDSC.

   For scalability purposes, in large packet domains using SR-TE, where
   multiple engineered paths are available between any two nodes, the
   MDSC can request a loose path, together with per-domain TE
   constraints, to allow the P-PNC selecting the intra-domain SR-TE path
   meeting these constraints.

   In such a case it is mandatory that P-PNC signals back to the MDSC
   which path it has chosen so that the MDSC keeps track of the relevant
   resources utilization.

   An example of that comes from Figure 2. The SR-TE path requested by
   the MDSC touches PE13 - P16 - BR12 - BR21 - PE23. P-PNC2 knows of two

Peruzzini et al.       Expires January 10, 2023               [Page 18]
Internet-Draft                 ACTN POI                       July 2022

   possible paths with the same topology metric, e.g. BR21 - P24 - PE23
   and BR21 - BR22 - PE23, but with different load. It may prefer then
   to steer the traffic on the latter because it is less loaded.

   This exception is mentioned here for the sake of completeness but
   since the network considered in this document does not fall in this
   scenario, in the rest of the paper the assumption is that the MDSC
   always provides the explicit list of SID(s) to the P-PNCs to setup or
   modify the SR-TE path.

2.3. Optical Domain Controller and NE Functions

   The optical network provides the underlay connectivity services to
   IP/MPLS networks. The packet and optical multi-layer coordination is
   done by the MDSC, as shown in Figure 1.

   The O-PNC is responsible to:

   o  provide to the MDSC an abstract TE topology view of its underlying
      optical network resources;

   o  perform single-domain local path computation, when requested by
      the MDSC;

   o  perform optical tunnel setup, when requested by the MDSC.

   The mechanisms used by O-PNC to perform intra-domain topology
   discovery and path setup are usually vendor-specific and outside the
   scope of this document.

   Depending on the type of optical network, TE topology abstraction,
   path computation and path setup can be single-layer (either OTN or
   WDM) or multi-layer OTN/WDM. In the latter case, the multi-layer
   coordination between the OTN and WDM layers is performed by the
   O-PNC.

3. Interface protocols and YANG data models for the MPIs

   This section describes general assumptions applicable at all the MPI
   interfaces, between each PNC (Optical or Packet) and the MDSC, to
   support the scenarios discussed in this document.

3.1. RESTCONF protocol at the MPIs

   The RESTCONF protocol, as defined in [RFC8040], using the JSON
   representation defined in [RFC7951], is assumed to be used at these

Peruzzini et al.       Expires January 10, 2023               [Page 19]
Internet-Draft                 ACTN POI                       July 2022

   interfaces. In addition, extensions to RESTCONF, as defined in
   [RFC8527], to be compliant with Network Management Datastore
   Architecture (NMDA) defined in [RFC8342], are assumed to be used as
   well at these MPI interfaces and also at MDSC NBI interfaces.

3.2. YANG data models at the MPIs

   The data models used on these interfaces are assumed to use the YANG
   1.1 Data Modeling Language, as defined in [RFC7950].

3.2.1. Common YANG data models at the MPIs

   As required in [RFC8040], the "ietf-yang-library" YANG module defined
   in [RFC8525] is used to allow the MDSC to discover the set of YANG
   modules supported by each PNC at its MPI.

   Both Optical and Packet PNCs use the following common topology YANG
   data models at the MPI:

   o  The Base Network Model, defined in the "ietf-network" YANG module
      of [RFC8345];

   o  The Base Network Topology Model, defined in the "ietf-network-
      topology" YANG module of [RFC8345], which augments the Base
      Network Model;

   o  The TE Topology Model, defined in the "ietf-te-topology" YANG
      module of [RFC8795], which augments the Base Network Topology
      Model.

   Both Optical and Packet PNCs use the common TE Tunnel Model, defined
   in the "ietf-te" YANG module of [TE-TUNNEL], at the MPI.

   All the common YANG data models are generic and augmented by
   technology-specific YANG modules, as described in the following
   sections.

   Both Optical and Packet PNCs also use the Ethernet Topology Model,
   defined in the "ietf-eth-te-topology" YANG module of [CLIENT-TOPO],
   which augments the TE Topology Model with Ethernet technology-
   specific information.

   Both Optical and Packet PNCs use the following common notifications
   YANG data models at the MPI:

Peruzzini et al.       Expires January 10, 2023               [Page 20]
Internet-Draft                 ACTN POI                       July 2022

   o  Dynamic Subscription to YANG Events and Datastores over RESTCONF
      as defined in [RFC8650];

   o  Subscription to YANG Notifications for Datastores updates as
      defined in [RFC8641].

   PNCs and MDSCs are compliant with subscription requirements as stated
   in [RFC7923].

3.2.2. YANG models at the Optical MPIs

   The Optical PNC uses at least one of the following technology-
   specific topology YANG data models, which augment the generic TE
   Topology Model:

   o  The WSON Topology Model, defined in the "ietf-wson-topology" YANG
      module of [RFC9094];

   o  the Flexi-grid Topology Model, defined in the "ietf-flexi-grid-
      topology" YANG module of [Flexi-TOPO];

   o  the OTN Topology Model, as defined in the "ietf-otn-topology" YANG
      module of [OTN-TOPO].

   The optical PNC uses at least one of the following technology-
   specific tunnel YANG data models, which augments the generic TE
   Tunnel Model:

   o  The WSON Tunnel Model, defined in the "ietf-wson-tunnel" YANG
      modules of [WSON-TUNNEL];

   o  the Flexi-grid Tunnel Model, defined in the "ietf-flexi-grid-
      tunnel" YANG module of [Flexi-TUNNEL];

   o  the OTN Tunnel Model, defined in the "ietf-otn-tunnel" YANG module
      of [OTN-TUNNEL].

   The optical PNC can optionally use the generic Path Computation YANG
   RPC, defined in the "ietf-te-path-computation" YANG module of
   [PATH-COMPUTE].

   Note that technology-specific augmentations of the generic path
   computation RPC for WSON, Flexi-grid and OTN path computation RPCs
   have been identified as a gap.

Peruzzini et al.       Expires January 10, 2023               [Page 21]
Internet-Draft                 ACTN POI                       July 2022

   The optical PNC uses the Ethernet Client Signal Model, defined in the
   "ietf-eth-tran-service" YANG module of [CLIENT-SIGNAL].

3.2.3. YANG data models at the Packet MPIs

   The Packet PNC also at least the following technology-specific
   topology YANG data models:

   o  The L3 Topology Model, defined in the "ietf-l3-unicast-topology"
      YANG module of [RFC8346], which augments the Base Network Topology
      Model;

   o  the L3 specific data model including extended TE attributes (e.g.
      performance derived metrics like latency), defined in "ietf-l3-te-
      topology" and in "ietf-te-topology-packet" YANG modules of [L3-TE-
      TOPO];

   Need to check the need/applicability of the "ietf-l3-te-topology" in
   this scenario since it is not described in [SR-TE-TOPO].

   The Packet PNC also uses at least one the following technology-
   specific topology YANG data models:

   o  The MPLS-TE Topology Model, defined in the "ietf-te-mpls-topology"
      YANG module of [MPLS-TE-TOPO], which augments the TE Packet
      Topology Model;

   o  the SR Topology Model, defined in the "ietf-sr-mpls-topology" YANG
      module of [SR-TE-TOPO].

   The Packet PNC uses at least one of the following technology-specific
   tunnel YANG data models, which augments the generic TE Tunnel Model:

   o  The MPLS-TE Tunnel Model, defined in the "ietf-te-mpls" YANG
      modules of [MPLS-TE-TUNNEL];

   o  the SR-TE Tunnel Model which is to be defined as described in
      section 6.

   The packet PNC uses at least the following YANG data models:

   o  L3VPN Network Model (L3NM), defined in the "ietf-l3vpn-ntw" YANG
      module of [RFC9182];

   o  L3NM TE Service Mapping, defined in the "ietf-l3nm-te-service-
      mapping" YANG module of [TSM];

Peruzzini et al.       Expires January 10, 2023               [Page 22]
Internet-Draft                 ACTN POI                       July 2022

   o  L2VPN Network Model (L2NM), defined in the "ietf-l2vpn-ntw" YANG
      module of [L2NM];

   o  L2NM TE Service Mapping, defined in the "ietf-l2nm-te-service-
      mapping" YANG module of [TSM].

3.3. PCEP

   [RFC8637] examines the applicability of a Path Computation Element
   (PCE) [RFC5440] and PCE Communication Protocol (PCEP) to the ACTN
   framework. It further describes how the PCE architecture applies to
   ACTN and lists the PCEP extensions that are needed to use PCEP as an
   ACTN interface.  The stateful PCE [RFC8231], PCE-Initiation
   [RFC8281], stateful Hierarchical PCE (H-PCE) [RFC8751], and PCE as a
   central controller (PCECC) [RFC8283] are some of the key extensions
   that enable the use of PCE/PCEP for ACTN.

   Since the PCEP supports path computation in the packet and optical
   networks, PCEP is well suited for inter-layer path computation.
   [RFC5623] describes a framework for applying the PCE-based
   architecture to interlayer (G)MPLS traffic engineering. Furthermore,
   the section 6.1 of [RFC8751] states the H-PCE applicability for
   inter-layer or POI.

   [RFC8637] lists various PCEP extensions that apply to ACTN. It also
   lists the PCEP extension for optical network and POI.

   Note that the PCEP can be used in conjunction with the YANG data
   models described in the rest of this document. Depending on whether
   ACTN is deployed in a greenfield or brownfield, two options are
   possible:

   1. The MDSC uses a single RESTCONF/YANG interface towards each PNC to
      discover all the TE information and request TE tunnels. It may
      either perform full multi-layer path computation or delegate path
      computation to the underneath PNCs.

      This approach is desirable for operators from an multi-vendor
      integration perspective as it is simple, and we need only one type
      of interface (RESTCONF) and use the relevant YANG data models
      depending on the operator use case considered. Benefits of having
      only one protocol for the MPI between MDSC and PNC have been
      already highlighted in [PATH-COMPUTE].

Peruzzini et al.       Expires January 10, 2023               [Page 23]
Internet-Draft                 ACTN POI                       July 2022

   4. The MDSC uses the RESTCONF/YANG interface towards each PNC to
      discover all the TE information and requests the creation of TE
      tunnels. However, it uses PCEP for hierarchical path computation.

      As mentioned in Option 1, from an operator perspective, this
      option can add integration complexity to have two protocols
      instead of one, unless the RESTOCONF/YANG interface is added to an
      existing PCEP deployment (brownfield scenario).

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

4. Inventory, service and network topology discovery

   In this scenario, the MSDC needs to discover through the underlying
   PNCs:

   o  the network topology, at both optical and IP layers, in terms of
      nodes and links, including the access links, inter-domain IP links
      as well as cross-layer links;

   o  the optical tunnels supporting multi-layer intra-domain IP links;

   o  both intra-domain and inter-domain L2/L3 VPN network services
      deployed within the network;

   o  the TE paths supporting those L2/L3 VPN network services;

   o  the hardware inventory information of IP and optical equipment.

   The O-PNC and P-PNC could discover and report the hardware network
   inventory information of their equipment that is used by the
   different management layers. In the context of POI, the inventory
   information of IP and optical equipment can complement the topology
   views and facilitate the packet/optical multi-layer view, e.g., by
   providing a mapping between the lowest level LTPs in the topology
   view and corresponding physical port in the network inventory view.

   The MDSC could also discover the entire network inventory information
   of both IP and optical equipment and correlate this information with
   the links reported in the network topology.

   Reporting the entire inventory and detailed topology information of
   packet and optical networks to the MDSC may present, as a potential
   drawback, scalability issues. The analysis of the scalability of this

Peruzzini et al.       Expires January 10, 2023               [Page 24]
Internet-Draft                 ACTN POI                       July 2022

   approach and mechanisms to address potential issues is outside the
   scope of this document.

   Each PNC provides to the MDSC the topology view of the domain it
   controls, as described in section 4.1 and 4.3. The MDSC uses this
   information to discover the complete topology view of the multi-layer
   multi-domain network it controls.

   The MDSC should also maintain up-to-date inventory, service and
   network topology databases of both IP and optical layers through the
   use of IETF notifications through MPI with the PNCs when any network
   inventory/topology/service change occurs.

   It should be possible also to correlate information coming from IP
   and optical layers (e.g., which port, lambda/OTSi, and direction, is
   used by a specific IP service on the WDM equipment).

   In particular, for the cross-layer links, it is key for MDSC to
   automatically correlate the information from the PNC network
   databases about the physical ports from the routers (single link or
   bundle links for LAG) to client ports in the ROADM.

  The analysis of multi-layer fault management is outside the scope of
  this document. However, the discovered information should be
  sufficient for the MDSC to easily correlate optical and IP layers
  alarms to speed-up troubleshooting.

  Alarms and event notifications are required between MDSC and PNCs so
  that any network changes are reported almost in real-time to the MDSC
  (e.g., NE or link failure). As specified in [RFC7923], MDSC must
  subscribe to specific objects from PNC YANG datastores for
  notifications.

4.1. Optical topology discovery

   The WSON Topology Model or, alternatively, the Flexi-grid Topology
   model is used to report the DWDM network topology (e.g., ROADM nodes
   and links), depending on whether the DWDM optical network is based on
   fixed grid or flexible-grid.

   The OTN Topology Model is used to report the OTN network topology
   (e.g., OTN switching nodes and links), when the OTN switching layer
   is deployed within the optical domain.

   In order to allow the MDSC to discover the complete multi-layer and
   multi-domain network topology and to correlate it with the hardware

Peruzzini et al.       Expires January 10, 2023               [Page 25]
Internet-Draft                 ACTN POI                       July 2022

   inventory information, the O-PNCs report an abstract optical network
   topology where:

   o  one TE node is reported for each optical NE deployed within the
      optical network domain; and

   o  one TE link is reported for each OMS link and, optionally, for
      each OTN link.

   The Ethernet Topology Model is used to report the Ethernet client
   LTPs that terminate the cross-layer links: one Ethernet client LTP is
   reported for each Ethernet client interface on the optical NEs.

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

   o  the optical parameters required for optical path computation, such
      as those detailed in [OIA-TOPO];

   o  the underlay OTS links and ILAs of OMS links;

   o  the physical connectivity between the optical transponders and the
      ROADMs.

   The optical transponders and, optionally, the OTN access cards, are
   abstracted at MPI by the O-PNC as Trail Termination Points (TTPs),
   defined in [RFC8795], within the optical network topology. This
   abstraction is valid independently of the fact that optical
   transponders are physically integrated within the same WDM node or
   are physically located on a device external to the WDM node since it
   both cases the optical transponders and the WDM node are under the
   control of the same O-PNC.

   The association between the Ethernet LTPs terminating the Ethernet
   cross-layer links and the optical TTPs is reported using the Inter
   Layer Lock (ILL) identifiers, defined in [RFC8795].

   All the optical links are intra-domain and they are discovered by O-
   PNCs, using mechanisms which are outside the scope of this document,
   and reported at the MPIs within the optical network topology.

Peruzzini et al.       Expires January 10, 2023               [Page 26]
Internet-Draft                 ACTN POI                       July 2022

   In case of a multi-layer DWDM/OTN network domain, multi-layer intra-
   domain OTN links are supported by underlay DWDM tunnels, which can be
   either WSON tunnels or, alternatively, Flexi-grid tunnels, depending
   on whether the DWDM optical network is based on fixed grid or
   flexible-grid. This relationship is reported by the mechanisms
   described in section 4.2.

4.2. Optical path discovery

   The WSON Tunnel Model or, alternatively, the Flexi-grid Tunnel model,
   depending on whether the DWDM optical network is based on fixed grid
   or flexible-grid, is used to report all the DWDM tunnels established
   within the optical network.

   When the OTN switching layer is deployed within the optical domain,
   the OTN Tunnel Model is used to report all the OTN tunnels
   established within the optical network.

   The Ethernet client signal Model is used to report all the Ethernet
   connectivity provided by the underlay optical tunnels between
   Ethernet client LTPs. The underlay optical tunnels can be either DWDM
   tunnels or, when the optional OTN switching layer is deployed, OTN
   tunnels.

   The DWDM tunnels can be used as underlay tunnels to support either
   Ethernet client connectivity or multi-layer intra-domain OTN links.
   In the latter case, the hierarchical-link container, defined in [TE-
   TUNNEL], is used to reference which multi-layer intra-domain OTN
   links are supported by the underlay DWDM tunnels.

   The O-PNCs report in their operational datastores all the Ethernet
   client connectivities and all the optical tunnels deployed within
   their optical domain regarless of the mechanisms being used to set
   them up, such as the mechanisms described in section 5.2, as well as
   other mechanism (e.g., static configuration), which are outside the
   scope of this document.

4.3. Packet topology discovery

   The L3 Topology Model, SR Topology Model, TE Topology Model and the
   TE Packet Topology Model are used together to report the SR-TE
   network topology, as described in figure 2 of [SR-TE-TOPO].

   The L3 Topology Model, TE Topology Model, TE Packet Topology Model
   and MPLS-TE Topology Model are used together to report the SR-TE
   network topology, as described in [MPLS-TE-TOPO].

Peruzzini et al.       Expires January 10, 2023               [Page 27]
Internet-Draft                 ACTN POI                       July 2022

   In order to allow the MDSC to discover the complete multi-layer and
   multi-domain network topology and to correlate it with the hardware
   inventory information as well as to perform multi-domain TE path
   computation, the P-PNCs report the full packet network, including all
   the information that is required by the MDSC to perform TE path
   computation. In particular, one TE node is reported for each router
   and one TE link is reported for each intra-domain IP link. The packet
   topology also reports the IP LTPs terminating the inter-domain IP
   links.

   All the intra-domain IP links are discovered by the P-PNCs, using
   mechanisms, such as LLDP [IEEE 802.1AB], which are outside the scope
   of this document, and reported at the MPIs within the packet network
   topology.

   The Ethernet Topology Model is used to report the intra-domain
   Ethernet links supporting the intra-domain IP links as well as the
   Ethernet LTPs that might terminate cross-layer links, inter-domain
   Ethernet links or access links, as described in detail in section 4.5
   and in section 4.6.

4.4. TE path discovery

   This version of the draft assumes that discovery of existing TE
   paths, including their bandwidth, at the MPI is done using the
   generic TE tunnel YANG data model, defined in [TE-TUNNEL], with
   packet technology-specific (e.g., MPLS-TE or SR-TE) augmentations.

   Note that technology-specific augmentations of the generic path TE
   tunnel model for SR-TE path setup and discovery is outlined in
   section 1 of [TE-TUNNEL] but currently identified as a gap in section
   6.

   To enable MDSC to discover the full end-to-end TE path configuration,
   the technology-specific augmentation of the [TE-TUNNEL] should allow
   the P-PNC to report the TE path within its domain (e.g., the SID list
   assigned to an SR-TE path).

   For example, considering the L3VPN in Figure 2, the PE13-P16-PE14 TE
   path and the TE path in the reverse direction (between PE14 and PE13)
   could be reported by the P-PNC1 to the MDSC as primary and reverse
   primary TE paths of the same TE tunnel instance. The bandwidth of
   these TE paths represents the bandwidth allocated by P-PNC1 to the
   two TE paths,which can be symmetric or asymmetric in the two
   directions.

Peruzzini et al.       Expires January 10, 2023               [Page 28]
Internet-Draft                 ACTN POI                       July 2022

   The P-PNCs use the TE tunnel model to report, at the MPI, all the TE
   paths established within their packet domain regardless of the
   mechanism being used to set them up; i.e., independently on whether
   the mechanisms described in section 5.3 or other means, such as
   static configuration, which are outside the scope of this document,
   are used.

4.5. Inter-domain link discovery

   In the reference network of Figure 1, there are three types of
   inter-domain links:

   o  Inter-domain Ethernet links suppoting inter-domain IP links
      between two adjancent IP domains;

   o  Cross-layer links between an an IP domain and an adjacent optical
      domain;

   o  Access links between a CE device and a PE router.

   All the three types of links are Ethernet links.

   It is worth noting that the P-PNC may not be aware whether an
   Ethernet interface terminates a cross-layer link, an inter-domain
   Ethernet link or an access link.

   It is not yet clarified which model can be used to report the access
   links between CEs and PEs (e.g., by using the Ethernet Topology Model
   defined in [CLIENT-TOPO] or by using the SAP Model defined in
   [SAP]). This has been identified as a gap.

   The inter-domain Ethernet links and cross-layer links are discovered
   by the MDSC using the plug-id attribute, as described in section 4.3
   of [RFC8795].

   More detailed description of how the plug-id can be used to discover
   inter-domain links is also provided in section 5.1.4 of [TNBI].

   This document considers the following two options for discovering
   inter-domain links:

   1. Static configuration

   2. LLDP [IEEE 802.1AB] automatic discovery

   Other options are possible but not described in this document.

Peruzzini et al.       Expires January 10, 2023               [Page 29]
Internet-Draft                 ACTN POI                       July 2022

   As outlined in [TNBI], the encoding of the plug-id namespace and the
   specific LLDP information reported within the plug-id value, such as
   the Chassis ID and Port ID mandatory TLVs, is implementation specific
   and needs to be consistent across all the PNCs within the network.

   The static configuration requires an administrative burden to
   configure network-wide unique identifiers: it is therefore more
   viable for inter-domain Ethenet links. For the cross-layer links, the
   automatic discovery solution based on LLDP snooping is preferable
   when possible.

   The routers exchange standard LLDP packets as defined in [IEEE
   802.1AB] and the optical NEs snoop the LLDP packets received from the
   local Ethernet interface and report to the O-PNCs the extracted
   information, such as the Chassis ID, the Port ID, System Name TLVs.

   Note that the optical NEs do not actively participate in the LLDP
   packet exchange and does not send any LLDP packets.

4.5.1. Cross-layer link discovery

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

Peruzzini et al.       Expires January 10, 2023               [Page 30]
Internet-Draft                 ACTN POI                       July 2022

           +-----------------------------------------------------------+
          /             Ethernet Topology (P-PNC)                     /
         /    +-------------+                +-------------+         /
        /     |    PE13     |                |    BR11     |        /
       /      |        (5-1)O                O(6-1)        |       /
      /       |    (5-0)    |\              /|    (6-0)    |      /
     /        +------O------+|(*)        (*)|+------O------+     /
    /       {PE13,5} ^\<-----+              +----->/^ {BR11,6}  /
   +-----------------:------------------------------:----------+
                     :                              :
                     :                              :
                     :                              :
                     :                              :
            +--------:------------------------------:------------------+
           /         :                              :                 /
          / {PE13,5} v                              v {BR11,6}       /
         /    +------O------+                +------O------+        /
        /     |    (7-0)    |                |    (8-0)    |       /
       /      |             |                |             |      /
      /       |    NE11     |                |     NE12    |     /
     /        +-------------+                +-------------+    /
    /                   Ethernet Topology (O-PNC)              /
   +----------------------------------------------------------+

   Notes:
   =====
   (*) Supporting LTP

   Legenda:
   ========
     O   LTP
   ----> Supporting LTP
   <...> Link discovered by the MDSC
   {   } LTP Plug-id reported by the PNC

                   Figure 4 - Cross-layer link discovery

   It is worth noting that the discovery of cross-layer links is based
   only on the LLDP information sent by the Ethernet interfaces of the
   routers and received by the Ethernet interfaces of the optical NEs,
   Therefore the MDSC can discover these links also before overlay
   multi-layer IP links are setup.

Peruzzini et al.       Expires January 10, 2023               [Page 31]
Internet-Draft                 ACTN POI                       July 2022

4.5.2. Inter-domain IP link discovery

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

Peruzzini et al.       Expires January 10, 2023               [Page 32]
Internet-Draft                 ACTN POI                       July 2022

           +--------------------------+     +-------------------------+
          /  IP Topology (P-PNC 1)   /     /  IP Topology (P-PNC 2)  /
         /   +-------------+        /     /   +-------------+       /
        /    |    BR11     |       /     /    |    BR21     |      /
       /     |        (3-2)O<................>O(4-2)        |     /
      /      |             |\    /     /     /|             |    /
     /       +-------------+|   /     /      |+-------------+   /
    /                       |  /     /       |                 /
   +------------------------|-+     +-------------------------+
                            |                |
             Supporting LTP |                | Supporting LTP
                            |                |
                            |                |
             +--------------|----------+    +|------------------------+
            /               V         /    / V                       /
           / +-------------+/        /    /  \+-------------+       /
          /  |     {1}(3-1)O.................>O(4-1){1}     |      /
         /   |             |\      /    /    /|             |     /
        /    |    BR11     |V(*)  /    /  (*)V|     BR21    |    /
       /     |             |/    /    /      \|             |   /
      /      |     {2}(3-0)O<~~~~~~~~~~~~~~~~>O(4-0){2}     |  /
     /       +-------------+   /    /         +-------------+ /
    / Eth. Topology (P-PNC 1) /    / Eth. Topology (P-PNC 2) /
   +-------------------------+    +-------------------------+

   Notes:
   =====
   (*) Supporting LTP
   {1} {BR11,3,BR21,4}
   {2} {BR11,3}

   Legenda:
   ========
     O   LTP
   ----> Supporting LTP
   <...> Link discovered by the MDSC
   <~~~> Link inferred by the MDSC
   {   } LTP Plug-id reported by the PNC

          Figure 5 - Inter-domain Ethernet and IP link discovery

   Different information is required to be encoded within the plug-id
   attribute of the Etherent LTPs to discover cross-layer links and
   inter-domain Ethernet links.

Peruzzini et al.       Expires January 10, 2023               [Page 33]
Internet-Draft                 ACTN POI                       July 2022

   If the P-PNC does not know a priori whether an Ethernet interface on
   a router terminates a cross-layer link or an inter-domain Ethernet
   link, it has to report at the MPI two Ethernet LTPs representing the
   same Ethernet interface, e.g., both the Ethernet LTP 3-0 and the
   Ethenet LTP 3-1, supported by LTP 3-0, shown in Figure 5:

   o  The physical Ethernet LTP is used to represent the physical
      adjacency between the router Ethernet interface and either the
      adjacent router Ethernet interface (in case of a single-layer
      Ethernet link) or the optical NE Ethernet interface (in case of a
      multi-layer Ethernet link). Therefore, this LTP reports, within
      the plug-id attribute, the LLDP information sent by the
      corresponding router Ethernet interface;

   o  The logical Ethernet LTP, supported by a physical Ethernet LTP, is
      used to discover the logical adjancecy between router Ethernet
      interfaces, which can be either single-layer or multi-layer.
      Therefore, this LTP reports, within the plug-id attribute, the
      LLDP information sent and received by the corresponding router
      Ethernet interface.

   It is worth noting that in case of an inter-domain single-layer
   Ethernet link, the physical adjacency between the two router Ethernet
   interfaces cannot be discovered by the MDSC, using the LLDP
   information reported in the plug-id attributes, as shown in Figure 5.
   However, the MDSC may infer these links if it knows a priori, using
   mechanisms which are outside the scope of this document, that inter-
   domain Ethernet links are always single-layer, e.g., as shown in
   Figure 5.

   The P-PNC can omit reporting the physical Ethernet LTPs when it
   knows, by mechanisms which are outside the scope of this document,
   that the corresponding router Ethernet interfaces terminate single-
   layer inter-domain Ethernet links.

   The MDSC can then discover an inter-domain IP link between the two IP
   LTPs that are supported by the two Ethernet LTPs terminating an
   inter-domain Ethernet link, discovered as described in section 4.5.2,
   e.g., between the IP LTP 3-2 on BR21 and the IP LTP 4-2 on BR22,
   supported respectively by the Ethernet LTP 3-1 on BR11 and by the
   Ethernet LTP 4-1 on BR21, as shown in Figure 5.

4.6. Multi-layer IP link discovery

   A multi-layer intra-domain IP link and its supporting multi-layer
   intra-domain Ethernet link are discovered by the P-PNC like any other

Peruzzini et al.       Expires January 10, 2023               [Page 34]
Internet-Draft                 ACTN POI                       July 2022

   intra-domain IP and Ethernet links, as described in section 4.3, and
   reported at the MPI within the SR-TE and Ethernet network topologies,
   e.g., as shown in Figure 6.

Peruzzini et al.       Expires January 10, 2023               [Page 35]
Internet-Draft                 ACTN POI                       July 2022

           +-----------------------------------------------------------+
          /                    IP Topology (P-PNC 1)                  /
         /    +---------+                        +---------+         /
        /     |  PE13   |                        |   BR11  |        /
       /      |    (5-2)O<======================>O(6-2)    |       /
      /       |         |              |         |         |      /
     /        +---------+              |         +---------+     /
    /                                  |                        /
   +-----------------------------------|-----------------------+
                                       |
                                       | Supporting Link
                                       |
           +---------------------------|-------------------------------+
          / Ethernet Topology (P-PNC1) |                              /
         /    +-------------+          |     +-------------+         /
        /     |    PE13     |          V     |    BR11     |        /
       /      |        (5-1)O<==============>O(6-1)        |       /
      /       |    (5-0)    |\              /|    (6-0)    |      /
     /        +------O------+|(*)        (*)|+------O------+     /
    /                ^ \<----+              +----->/^           /
   +-----------------:------------------------------:----------+
                     :                              :
                     :                              :
                     :                              :
           +---------:------------------------------:------------------+
          /          V  Ethernet Topology (O-PNC 1) V                 /
         /    +------O------+                +------O------+         /
        /     |    (7-0)    |Eth. client sig.|    (8-0)    |        /
       /      |      X----------+-------------------X      |       /
      /       |    NE11     |   |            |     NE12    |      /
     /        +-------------+   |            +-------------+     /
    /                           |                               /
   +----------------------------|------------------------------+
                                | Underlay
                                | tunnel
                                |
           +-----------------------------------------------------------+
          /         __          |                   __                /
         /    +-----\/------+   v            +------\/-----+         /
        /     |      X======|================|======X      |        /
       /      |    NE11     |  Opt. Tunnel   |    NE12     |       /
      /       |             |                |             |      /
     /        +-------------+                +-------------+     /
    /                   Optical Topology (O-PNC 1)              /
   +-----------------------------------------------------------+

Peruzzini et al.       Expires January 10, 2023               [Page 36]
Internet-Draft                 ACTN POI                       July 2022

   Notes:
   =====
   (*) Supporting LTP

   Legenda:
   ========
     O   LTP
   ----> Supporting LTP or Supporting Link or Underlay tunnel
   <===> Link discovered by the PNC and reported at the MPI
   <...> Link discovered by the MDSC
   <~~~> Link inferred by the MDSC
   x---x Ethernet client signal
   X===X Optical tunnel

    Figure 6 - Multi-layer intra-domain Ethernet and IP link discovery

   The P-PNC does not report any plug-id information on the Ethernet
   LTPs terminating intra-domain Ethernet links since these links are
   discovered by the PNC.

   In addition, the P-PNC also reports the physical Ethernet LTPs that
   terminate the cross-layer links supporting the multi-layer intra-
   domain Ethernet links, e.g., the Ethernet LTP 5-0 on PE13 and the
   Ethernet LTP 6-0 on BR11, shown in Figure 6.

   The MDSC discovers, using the mechanisms described in section 4.5,
   which Ethernet cross-layer links support the multi-layer intra-domain
   Ethernet links, e.g. as shown in Figure 6.

   The MDSC also discovers, from the information provided by the O-PNC
   and described in section 4.2, which optical tunnels support the
   multi-layer intra-domain IP links and therefore the path within the
   optical network that supports a multi-layer intra-domain IP link,
   e.g., as shown in Figure 6.

4.6.1. Single-layer intra-domain IP links

   It is worth noting that the P-PNC may not be aware of whether an
   Ethernet interface on the router terminates a multi-layer or a
   single-layer intra-domain Ethernet link.

   In this case, the P-PNC, always reports two Ethernet LTPs for each
   Ethernet interface on the router, e.g., the Ethernet LTP 1-0 and 1-1
   on PE13, shown in Figure 7.

Peruzzini et al.       Expires January 10, 2023               [Page 37]
Internet-Draft                 ACTN POI                       July 2022

           +-----------------------------------------------------------+
          /                    IP Topology (P-PNC 1)                  /
         /    +---------+                        +---------+         /
        /     |  PE13   |                        |    P16  |        /
       /      |    (1-2)O<======================>O(2-2)    |       /
      /       |         |            |           |         |      /
     /        +---------+            |           +---------+     /
    /                                |                          /
   +---------------------------------|-------------------------+
                                     |
                                     | Supporting Link
                                     |
                                     |
             +------------------------|--------------------------------+
            /                         |                               /
           /  +---------+            v           +---------+         /
          /   |    (1-1)O<======================>O(2-1)    |        /
         /    |         |\                      /|         |       /
        /     |  PE13   |V(*)                (*)V|    P16  |      /
       /      |         |/                      \|         |     /
      /       | {1}(1-0)O<~~~~~~~~~~~~~~~~~~~~~~>O(2-0){2} |    /
     /        +---------+                        +---------+   /
    /                   Ethernet Topology (P-PNC 1)           /
   +---------------------------------------------------------+

   Notes:
   =====
   (*) Supporting LTP
   {1} {PE13,1}
   {2} {P16,2}

   Legenda:
   ========
     O   LTP
   ----> Supporting LTP
   <===> Link discovered by the PNC and reported at the MPI
   <~~~> Link inferred by the MDSC
   {   } LTP Plug-id reported by the PNC

    Figure 7 - Single-layer intra-domain Ethernet and IP link discovery

   In this case, the MDSC, using the plug-id information reported in the
   physical Ethernet LTPs, does not discover any cross-layer link being
   terminated by the corresponding Ethernet interface. The  MDSC may
   infer the physical intra-domain Ethernet link, e.g., between LTP 1-0
   on PE13 and LTP 2-0 on P16, as shown in Figure 7, if it knows a

Peruzzini et al.       Expires January 10, 2023               [Page 38]
Internet-Draft                 ACTN POI                       July 2022

   priori, by mechanisms which are outside the scope of this document,
   that all the Ethernet interfaces on the routers either terminates a
   cross-layer link or a single-layer intra-domain Ethernet link.

   The P-PNC can omit reporting the physical Ethernet LTP if it knows,
   by mechanisms which are outside the scope of this document, that the
   intra-domain Ethernet link is single-layer.

4.7. LAG discovery

   The P-PNCs can discover the configuration of the LAG groups within
   its domain and report each intra-domain LAG as an Ethernet bundle
   link, within the Ethernet topology exposed at the MPI.

   This is done bundling multiple single-domain Ethernet links, as shown
   in Figure 8. For example, the Ethernet bundled link between the
   Ethernet LTP 5-1 on BR21 and the Ethernet LTP 6-1 on P24, is built
   from the Ethernet links setup respectively:

   o  between the Ethernet LTP 1-1 on BR21 and the Ethernet LTP 2-1 on
      P24; and

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

Peruzzini et al.       Expires January 10, 2023               [Page 39]
Internet-Draft                 ACTN POI                       July 2022

           +-----------------------------------------------------------+
          /                    IP Topology (P-PNC 1)                  /
         /    +---------+                        +---------+         /
        /     |  BR21   |                        |    P24  |        /
       /      |    (5-2)O<======================>O(6-2)    |       /
      /       |         |            |           |         |      /
     /        +---------+            |           +---------+     /
    /                                |                          /
   +---------------------------------|-------------------------+
                                     |
                                     | Supporting Link
                                     |
                                     |
             +-----------------------|---------------------------------+
            /                        |                                /
           /  +---------+            v           +---------+         /
          /   |    (5-1)O<======================>O(6-1)    |        /
         /    |  BR21   |  Bundled Link          |    P24  |       /
        /     |         |                        |         |      /
       /      |    (3-1)O<======================>O(4-1)    |     /
      /       |    (1-1)O<======================>O(2-1)    |    /
     /        +---------+                        +---------+   /
    /                   Ethernet Topology (P-PNC 1)           /
   +---------------------------------------------------------+

   Legenda:
   ========
     O   LTP
   <===> Link discovered by the PNC and reported at the MPI

                              Figure 8 - LAG

   The mechanisms used by the MDSC to discover single-layer and multi-
   layer intra-domain LAG link is the same (the only difference being
   whether the bundled links are single-layer or multi-layer).

   Instead, the mechanisms used by the MDSC to discover single-layer
   inter-domain LAG links between two BRs are different and outside the
   scope of this document since they do not imply any cross-layer
   coordination between packet and optical domains.

   As described in section 4.3, the mechanisms used by the P-PNC to
   discover the configuration of the LAG groups within its domain, such
   as LLDP [IEEE 802.1AB], are outside the scope of this document.

Peruzzini et al.       Expires January 10, 2023               [Page 40]
Internet-Draft                 ACTN POI                       July 2022

   However, it is worth noting that according to [IEEE 802.1AB], LLDP
   can be configured on a LAG group (Aggregated Port) and/or on any
   number of its LAG members (Aggregation Ports).

   If LLDP is enabled on both LAG members and groups, two types of LLDP
   packets are transmitted by the routers and received by the optical
   NEs on some cross-layer links: one sent for the LLDP session
   configured at LAG member (Aggregation Port)level and another one for
   the LLDP session configured at LAG group (Aggregated Port)level. This
   could cause some issues when LLDP snooping is used to discover the
   cross-layer links, as defined in section 4.5.1.

   The cross-layer link discovery is based only on the LLDP session
   configured on the LAG members (Aggregation Ports) to allow discovery
   of these links independently from the configuration of the underlay
   optical tunnel or from the LAG group.

   To avoid any ambiguity on how the optical NEs can identify which LLDP
   packets belong to which LLDP session, the P-PNC can disable the LLDP
   sessions on the LAG groups configured by the MDSC (e.g., the multi-
   layer single-domain LAG groups configured using the mechanisms
   described in section 5.2.1), keeping the LLDP sessions on the LAG
   members enabled.

   Another option is to rely on other mechanisms (e.g., the Port type
   field in the Link Aggregation TLV defined in Annex F of [IEEE
   802.1AX]) that allow the optical NE to identify which LLDP packets
   belong to which LLDP session: the O-PNC can then use only the LLDP
   information from the LLDP sessions configured on the LAG members to
   support the cross-layer link discovery mechanisms defined in section
   4.5.1.

4.8. L2/L3 VPN network services discovery

   TBA

4.9. Inventory discovery

   The are no YANG data models in IETF that could be used to report at
   the MPI the whole inventory information discovered by a PNC.

   [RFC8345] had foreseen some work for inventory as an augmentation of
   the network model, but no YANG data model has been developed so far.

   There are also no YANG data models in IETF that could be used to
   correlate topology information, e.g., a link termination point (LTP),

Peruzzini et al.       Expires January 10, 2023               [Page 41]
Internet-Draft                 ACTN POI                       July 2022

   with inventory information, e.g., the physical port supporting an
   LTP, if any.

   Inventory information through MPI and correlation with topology
   information is identified as a gap requiring further work and outside
   of the scope of this draft.

5. Establishment of L2/L3 VPN network services with TE requirements

   In this scenario the MDSC needs to setup a multi-domain L2VPN or a
   multi-domain L3VPN with some SLA requirements.

   The MDSC receives the request to setup a L2/L3 VPN network service
   from the OSS/Orchestration layer (see Appendix A).

   The MDSC translates the L2/L3 VPN SLA requirements into TE
   requirements (e.g., bandwidth, TE metric bounds, SRLG disjointness,
   nodes/links/domains inclusion/exclusion) and find the TE paths that
   meet these TE requirements (see section 2.1.1).

   For example, considering the L3VPN in Figure 2, the MDSC finds that:

   o  PE13-P16-PE14 SR-TE path already exists but have not enough
      bandwidth to support the new L3VPN, as described in section 4.4;,
      and that:

       o the IP link(s) between PE13 and P16 has not enough bandwidth to
          support increasing the bandwidth of that TE path, as described
          in section 4.3;

       o a new underlay optical tunnel could be setup to increase the
          bandwidth of the IP link(s) between PE13 and P16 to support
          increasing the bandwidth of that overlay TE path, as described
          in section 5.1. The dimensioning of the underlay optical
          tunnel is decided by the MDSC based on the TE requirements
          (e.g., the bandwidth) requested by the TE path and on its
          multi-layer optimization policy, which is an internal MDSC
          implementation issue;

       o a new multi-domain TE path needs to be setup between PE13 and
          PE23, e.g., either because existing TE paths between PE13 and
          PE23 are not able to meet the TE and binding requirements of
          the L2/L3 VPN service or because there is no TE path between
          PE13 and PE23.

Peruzzini et al.       Expires January 10, 2023               [Page 42]
Internet-Draft                 ACTN POI                       July 2022

   As described in section 2.1.2, with partial summarization, the MDSC
   will use the TE topology information provided by the P-PNCs and the
   results of the path computation requests sent to the O-PNCs, as
   described in section 5.1, to compute the multi-layer/multi-domain
   path between PE13 and PE23.

   For example, the multi-layer/multi-domain performed by the MDSC could
   require the setup of:

   o  a new underlay optical tunnel between PE13 and BR11, supporting a
      new IP link, as described in section 5.2;

   o  a new underlay optical tunnel between BR21 and P24 to increase the
      bandwidth of the IP link(s) between BR21 and P24, as described in
      section 5.2.

   When the setup of the L2/L3 VPN network service requires multi-domain
   and multi-layer coordination, the MDSC is also responsible for
   coordinating the network configuration required to realize the
   request network service across the appropriate optical and packet
   domains.

   The MDSC would therefore request:

   o  the O-PNC1 to setup a new optical tunnel between the ROADMs
      connected to PE13 and P16, as described in section 5.2;

   o  the P-PNC1 to update the configuration of the existing IP link, in
      case of LAG, or configure a new IP link, in case of ECMP, between
      PE13 and P16, as described in section 5.2;

   o  the P-PNC1 to update the bandwidth of the selected TE path between
      PE13 and PE14, as described in section 5.3.

   After that, the MDSC requests P-PNC2 to setup a TE path between BR21
   and PE23, with an explicit path (BR21, P24, PE23) to constrainthis
   new TE path to use the new underlay optical tunnel setup between BR21
   and P24, as described in section 5.3. The P-PNC2 properly configures
   the routers within its domain to setup the requested path and returns
   to the MDSC the information which is needed for multi-domain TE path
   stitching. For example, in case of inter-domain SR-TE, the P-PNC2,
   knowing the node and the adjacency SIDs assigned within its domain,
   can install the proper SR policy, or hierarchical policies, within
   BR21 and returns to the MDSC the binding SID it has assigned to this
   policy in BR21.

Peruzzini et al.       Expires January 10, 2023               [Page 43]
Internet-Draft                 ACTN POI                       July 2022

   Then the MDSC requests P-PNC1 to setup a TE path between PE13 and
   BR11, with an explicit path (PE13, BR11) to constrain this new TE
   path to use the new underlay optical tunnel setup between PE13 and
   BR11, specifying also which inter-domain link should be used to send
   traffic to BR21 and the information to be used for the multi-domain
   TE path stitching, as described in section 4.4 (e.g., in case of
   inter-domain SR-TE, the binding SID  that has been assigned by P-PNC2
   to the corresponding SR policy in BR21). The P-PNC1 properly
   configures the routers within its domain to setup the requested path
   and the multi-domain TE path stitching. For example, in case of
   inter-domain SR-TE, the P-PNC1, knowing also the node and the
   adjacency SIDs assigned within its domain and the EPE SID assigned by
   P-PNC1 to the inter-domain link between BR11 and BR21, and the
   binding SID assigned by P-PNC2, installs the proper policy, or
   policies, within PE13.

   Once the TE paths have been selected and, if needed, setup/modified,
   the MDSC can request to both P-PNCs to configure the L3VPN and its
   binding with the selected TE paths using the [RFC9182] and [TSM] YANG
   data models.

   [Editor's Note] Further investigation is needed to understand how the
   binding between a L3VPN and this new end-to-end SR-TE path can be
   configured.

5.1. Optical Path Computation

   As described in section 2.1.2, the optical path computation is
   usually performed by the O-PNCs.

   When performing multi-layer/multi-domain path computation, the MDSC
   can delegate the O-PNC for single-domain optical path computation.

   As discussed in [PATH-COMPUTE], there are two options to request an
   O-PNC to perform optical path computation: either via a "compute-
   only" TE tunnel path, using the generic TE tunnel YANG data model
   defined in [TE-TUNNEL] or via the path computation RPC defined in
   [PATH-COMPUTE].

   This draft assumes that the path computation RPC is used.

   As described in sections 4.1 and 4.5, there is a one-to-one
   relationship between the router ports, the cross-layer links and the
   optical TTPs. Therefore, the properties of an optical path between
   two optical TTPs, as computed by the O-PNC, can be used by the MDSC

Peruzzini et al.       Expires January 10, 2023               [Page 44]
Internet-Draft                 ACTN POI                       July 2022

   to infer the properties of the multi-layer single-domain IP link
   between the router ports associated with the two optical TTPs.

   There are no YANG data models in IETF that could be used to augment
   the generic path computation RPC with technology-specific attributes.

   Optical technology-specific augmentation for the path computation RPC
   is identified as a gap requiring further work outside of this draft's
   scope.

5.2. Multi-layer IP link Setup

   To setup a new multi-layer IP link between two router ports, the MDSC
   requires the O-PNC to setup an optical tunnel (either a WSON Tunnel
   or a Flexi-grid Tunnel or an OTN Tunnel) within the optical network
   between the two TTPs associated, as described in section 5.1, with
   these two router Ethernet interfaces.

   The MDSC also requires the O-PNC to steer the Ethernet client traffic
   between the two cross-layer links over the optical tunnel using the
   Ethernet Client Signal Model.

   After the optical tunnel has been setup and the client traffic
   steering configured, the two IP routers can exchange Ethernet packets
   between themselves, including LLDP messages.

   For example, with a reference to Figure 6, the MDSC can request the
   O-PNC1 to setup an optical tunnel between the TTPs within NE11 and
   NE14 to steer over this tunnel the Ethernet traffic between LTP (7-0)
   on NE11 and LTP (8-0) on NE14.

   If LLDP [IEEE 802.1AB] or any other discovery mechanisms, which are
   outside the scope of this document, is used between the adjacency
   between the two routers' ports, the P-PNC can automatically discover
   the underlay multi-layer single-domain Ethernet link being set up by
   the MDSC and report it to the P-PNC, as described in section 4.6.

   Otherwise, if there are no automatic discovery mechanisms, the MDSC
   can configure this multi-layer single-domain Ethernet link at the MPI
   of the P-PNC.

   The two Ethernet LTPs terminating this multi-layer single-domain
   Ethernet link are supported by the two underlay Ethernet LTPs
   terminating the two cross-layer links, e.g., the LTP 5-1 on PE13 and
   6-1 on BR11 shown in Figure 6.

Peruzzini et al.       Expires January 10, 2023               [Page 45]
Internet-Draft                 ACTN POI                       July 2022

   After the multi-layer single-domain Ethernet link has been configured
   by the MDSC or discovered by the P-PNC, the corresponding multi-layer
   single-domain IP link can also be configured either by the MDSC or by
   the P-PNC.

   This document assumes that this IP link is configured by the P-PNC.

   It is worth noting that if LAG is not supported within the domain
   controlled by the P-PNC, the P-PNC can configure the multi-layer
   single-domain IP link as soon as the underlay multi-layer single-
   domain Ethernet link is either discovered by the P-PNC or configured
   by the MDSC at the MPI. However, if LAG is supported the P-PNC has
   not enough information to know whether the discovered/configured
   multi-layer single-domain Ethernet link would be:

   1. Used to support a multi-layer single-domain IP link;

   2. Used to create a new LAG group;

   3. Added to an existing LAG group.

   Therefore the P-PNC does not take any further action after a multi-
   layer single-domain Ethernet link is discovered or configured by the
   MDSC at the MPI.

   The MDSC can request the P-PNC to configure a new multi-layer single-
   domain IP link, supported by the the just discovered or configured
   multi-layer single-domain Ethernet link, by creating an IP link
   within the running datastore of the P-PNC MPI. Only the IP link, IP
   LTPs and the reference to the supporting multi-layer single-domain
   Ethernt link are configured by the MDSC. All the other configuration
   is provided by the P-PNC.

   For example, with a reference to Figure 6, the MDSC can request the
   P-PNC1 to setup a multi-layer single-domain IP Link between IP LTP 5-
   2 on PE13 and IP LTP 6-2 on BR11 supported by the multi-layer single-
   domain Ethernet link between ETH LTP 5-1 on PE13 and ETH LTP 6-1 on
   BR11.

   The P-PNC configures the requested multi-layer single-domain IP link
   and, once finished, reports it to the MDSC within the IP topology
   exposed at its MPI.

Peruzzini et al.       Expires January 10, 2023               [Page 46]
Internet-Draft                 ACTN POI                       July 2022

5.2.1. Multi-layer LAG setup

   The P-PNC configures a new LAG group between two routers when the
   MDSC creates at the MPI a new Ethernet bundled link (using the
   bundled-link container defined in [RFC8795]) bundling the multi-layer
   single-domain Ethernet link(s) being created, as described above.

   It is worth noting that a new LAG group can be created to bundle one
   or more multi-layer single-domain Ethernet link(s).

   For example, with a reference to Figure 8, the MDSC can request the
   P-PNC2 to setup an Ethernet bundled link between the Ethernet LTP 5-1
   on BR21 and the Ethernet LTP 6-1 on P24, bundling the multi-layer
   single-domain Ethernet link between the Etherent LTP 1-1 on BR21 and
   the Ethernet LTP 2-1 on P24.

   It is worth noting that the MDSC needs to create also the Ethernet
   LTPs terminating the Ethernet bundled link.

   The MDSC can request the P-PNC to configure a new multi-layer single-
   domain IP link, supported by the the just configured Ethernet bundled
   link, following the same procedure described in section 5.2 above.

   For example, with a reference to Figure 8, the MDSC can request the
   P-PNC2 to setup a multi-layer single-domain IP Link between IP LTP 5-
   2 on BR21 and IP LTP 6-2 on P24 supported by the Ethernet bundle link
   between ETH LTP 5-1 on BR21 and the Ethernet LTP 6-1 on P24.

5.2.2. Multi-layer LAG update

   The P-PNC adds new member(s) to an existing LAG group when the MDSC
   updates at the MPI the configuration of an existing Ethernet bundled
   link adding the multi-layer single-domain Ethernet link(s) being
   created, as described above.

   For example, with a reference to Figure 8, the MDSC can request the
   P-PNC2 to add the multi-layer single-domain Ethernet link setup
   between the Etherent LTP 3-1 on BR21 and the Ethernet LTP 4-1 on P24
   to the existing Ethernet bundle link setup between the Ethernet LTP
   5-1 on node BR21 and the Ethernet LTP 6-1 on node P24.

   After the LAG configuration has been updated, the P-PNC can also
   update the bandwidth information of the multi-layer single-domain IP
   link supported by the updated Ethernet bundled link.

Peruzzini et al.       Expires January 10, 2023               [Page 47]
Internet-Draft                 ACTN POI                       July 2022

5.2.3. Multi-layer SRLG configuration

   [Editor's Note] Add text about the configuration of multi-layer SRLG
   information (issue #45).

   It is worth noting that the list of SRLGs for a multi-layer IP link
   can be quite long. Implementation-specific mechanisms can be
   implemented by the MDSC or by the O-PNC to summarize the SRLGs of an
   optical tunnel. These mechanisms are implementation-specific and have
   no impact on the YANG models nor on the interoperability at the MPI,
   but cares have to be taken to avoid missing information.

5.3. TE Path Setup and Update

   This version of the draft assumes that TE path setup and update at
   the MPI could be done using the generic TE tunnel YANG data model,
   defined in [TE-TUNNEL], with packet technology-specific
   agumentations, described in section 3.2.3.

   When a new TE path needs to be setup, the MDSC can use the [TE-
   TUNNEL] model to request the P-PNC to set it up, properly specifying
   the path constraints, such as the explicit path, to force the P-PNC
   to setup an TE path that meets the end-to-end TE and binding
   constraints and uses the optical tunnels setup by the MDSC for the
   purpose of supporting this new TE path.

   The [TE-TUNNEL] model supports requesting the setup of both end-
   to-end as well as segment TE tunnels (within one domain).

   In the latter case, the technology-specific augmentations should
   allow the configuration of the information needed for multi-domain TE
   path stiching.

   For example, the SR-TE specific augmentations of the [TE-TUNNEL]
   model should be defined to allow the MDSC to configure the binding
   SIDs to be used for the multi-domain SR-TE path stitching and to
   allow the P-PNC to report the binding SID assigned to the segment TE
   paths. Note that the assigned binding SID should be persistent in
   case router or P-PNC rebooting.

   The MDSC can also use the [TE-TUNNEL] model to request the P-PNC to
   increase the bandwidth allocated to an existing TE path, and, if
   needed, also on its reverse TE path. The [TE-TUNNEL] model supports
   both symmetric and asymmetric bandwidth configuration in the two
   directions.

Peruzzini et al.       Expires January 10, 2023               [Page 48]
Internet-Draft                 ACTN POI                       July 2022

   [Editor's Note:] Add some text about the protection options (to
   further discuss whether to put this text here or in section 4.2.2).

   The MDSC also request the P-PNC to configure local protection
   mechanisms. For example, in case of SR-TE domain, the TI-LFA local
   protection: the mechanisms to request the configuration TI-LFA local
   protection for SR-TE paths using the [TE-TUNNEL] are a gap in the
   current YANG models.

   The requested local protection mechanisms within the P-PNC domain are
   configured by the P-PNC through implementation specific mechanisms
   which are outside the scope of this document.

   The P-PNC takes into account the multi-layer SRLG information,
   configured by the MDSC as described in section 5.2, when computing
   the protection configuration (e.g., in case of SR-TE domains, the TI-
   LFA post-convergence path for multi-layer single-domain IP links).

   SR-TE path setup and update (e.g., bandwidth increase) through MPI is
   identified as a gap requiring further work, which is outside of the
   scope of this draft.

6. Conclusions

   The analysis provided in this document has shown that the IETF YANG
   models described in 3.2 provides useful support for Packet Optical
   Integration (POI) scenarios for resource discovery (network topology,
   service, tunnels and network inventory discovery) as well as for
   supporting multi-layer/multi-domain L2/L3 VPN network services.

   Few gaps have been identified to be addressed by the relevant IETF
   Working Groups:

   o  network inventory model: this gap has been identified in section
      4.9 and the solution in [NETWORK-INVENTORY] has been proposed to
      resolve it;

   o  technology-specific augmentations of the path computation RPC,
      defined in [PATH-COMPUTE] for optical networks: this gap has been
      identified in section 5.1 and the solution in [OPTICAL-PATH-
      COMPUTE] has been proposed to resolve it;

   o  relationship between a common discovery mechanisms applicable to
      access links, inter-domain IP links and cross-layer links and the
      UNI topology discover mechanism defined in [SAP]: this gap has
      been identified in section 4.3;

Peruzzini et al.       Expires January 10, 2023               [Page 49]
Internet-Draft                 ACTN POI                       July 2022

   o  a mechanism applicable to the P-PNC NBI to configure the SR-TE
      paths. Technology-specific augmentations of TE Tunnel model,
      defined in [TE-TUNNEL], are foreseen in section 1 of [TE-TUNNEL]
      but not yet defined: this gap has been identified in section 5.3.

7. Security Considerations

   Several security considerations have been identified and will be
   discussed in future versions of this document.

8. Operational Considerations

   Telemetry data, such as collecting lower-layer networking health and
   consideration of network and service performance from POI domain
   controllers, may be required. These requirements and capabilities
   will be discussed in future versions of this document.

9. IANA Considerations

   This document requires no IANA actions.

10. References

10.1. Normative References

   [RFC7923] Voit, E. et al., "Requirements for Subscription to YANG
             Datastores", RFC 7923, June 2016.

   [RFC7950] Bjorklund, M. et al., "The YANG 1.1 Data Modeling
             Language", RFC 7950, August 2016.

   [RFC7951] Lhotka, L., "JSON Encoding of Data Modeled with YANG", RFC
             7951, August 2016.

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

   [RFC8342] Bjorklund, M. et al., "Network Management Datastore
             Architecture (NMDA)", RFC 8342, March 2018.

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

   [RFC8346] Clemm, A. et al., "A YANG Data Model for Layer 3
             Topologies", RFC8346, March 2018.

Peruzzini et al.       Expires January 10, 2023               [Page 50]
Internet-Draft                 ACTN POI                       July 2022

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

   [RFC8525] Bierman, A. et al., "YANG Library", RFC 8525, March 2019.

   [RFC8527] Bjorklund, M. et al., "RESTCONF Extensions to Support the
             Network Management Datastore Architecture", RFC 8527, March
             2019.

   [RFC8641] Clemm, A. and E. Voit, "Subscription to YANG Notifications
             for Datastore Updates", RFC 8641, September 2019.

   [RFC8650] Voit, E. et al., "Dynamic Subscription to YANG Events and
             Datastores over RESTCONF", RFC 8650, November 2019.

   [RFC8795] Liu, X. et al., "YANG Data Model for Traffic Engineering
             (TE) Topologies", RFC8795, August 2020.

   [RFC9094] Zheng H., Lee, Y. et al., "A YANG Data Model for Wavelength
             Switched Optical Networks (WSONs)", RFC 9094, August 2021.

   [IEEE 802.1AB] IEEE 802.1AB-2016, "IEEE Standard for Local and
             metropolitan area networks - Station and Media Access
             Control Connectivity Discovery", March 2016.

   [IEEE 802.1AX] IEEE 802.1AB-2014, "IEEE Standard for Local and
             metropolitan area networks - Link Aggregation", December
             2014.

   [Flexi-TOPO]   Lopez de Vergara, J. E. et al., "YANG data model for
             Flexi-Grid Optical Networks", draft-ietf-ccamp-flexigrid-
             yang, 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.

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

Peruzzini et al.       Expires January 10, 2023               [Page 51]
Internet-Draft                 ACTN POI                       July 2022

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

   [MPLS-TE-TOPO] Busi, I. et al., "A YANG Data Model for MPLS-TE
             Topology", draft-busizheng-teas-yang-te-mpls-topology, 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.

   [WSON-TUNNEL]  Lee, Y. et al., "A Yang Data Model for WSON Tunnel",
             draft-ietf-ccamp-wson-tunnel-model, work in progress.

   [Flexi-TUNNEL] Lopez de Vergara, J. E. et al., "A YANG Data Model for
             Flexi-Grid Tunnels ", draft-ietf-ccamp-flexigrid-tunnel-
             yang, work in progress.

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

   [MPLS-TE-TUNNEL]  Saad, T. et al., "A YANG Data Model for MPLS
             Traffic Engineering Tunnels", draft-ietf-teas-yang-te-mpls,
             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.

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

10.2. Informative References

   [RFC1930] J. Hawkinson, T. Bates, "Guideline for creation, selection,
             and registration of an Autonomous System (AS)", RFC 1930,
             March 1996.

   [RFC5440] Vasseur, JP. et al., "Path Computation Element (PCE)
             Communication Protocol (PCEP)", RFC 5440, March 2009.

   [RFC5623] Oki, E. et al., "Framework for PCE-Based Inter-Layer MPLS
             and GMPLS Traffic Engineering", RFC 5623, September 2009.

Peruzzini et al.       Expires January 10, 2023               [Page 52]
Internet-Draft                 ACTN POI                       July 2022

   [RFC8231] Crabbe, E. et al., "Path Computation Element Communication
             Protocol (PCEP) Extensions for Stateful PCE", RFC 8231,
             September 2017.

   [RFC8281] Crabbe, E. et al., "Path Computation Element Communication
             Protocol (PCEP) Extensions for PCE-Initiated LSP Setup in a
             Stateful PCE Model", RFC 8281, December 2017.

   [RFC8283] Farrel, A. et al., "An Architecture for Use of PCE and the
             PCE Communication Protocol (PCEP) in a Network with Central
             Control", RFC 8283, December 2017.

   [RFC8309] Q. Wu, W. Liu, and A. Farrel, "Service Model Explained",
             RFC 8309, January 2018.

   [RFC8637] Dhody, D. et al., "Applicability of the Path Computation
             Element (PCE) to the Abstraction and Control of TE Networks
             (ACTN)", RFC 8637, July 2019.

   [RFC8751] Dhody, D. et al., "Hierarchical Stateful Path Computation
             Element (PCE)", RFC 8751, March 2020.

   [RFC9182]   S. Barguil, et al., "A YANG Network Data Model for Layer
             3 VPNs", RFC 9182, February 2022.

   [L2NM]    S. Barguil, et al., "A Layer 2 VPN Network YANG Model",
             draft-ietf-opsawg-l2nm, work in progress.

   [TSM]     Y. Lee, et al., "Traffic Engineering and Service Mapping
             Yang Model", draft-ietf-teas-te-service-mapping-yang, work
             in progress.

   [TNBI]    Busi, I., Daniel, K. et al., "Transport Northbound
             Interface Applicability Statement", draft-ietf-ccamp-
             transport-nbi-app-statement, work in progress.

   [VN]      Y. Lee, et al., "A Yang Data Model for ACTN VN Operation",
             draft-ietf-teas-actn-vn-yang, work in progress.

   [OIA-TOPO]  Lee Y. et al., "A YANG Data Model for Optical Impairment-
             aware Topology", draft-ietf-ccamp-optical-impairment-
             topology-yang, work in progress.

   [SAP]     Gonzalez de Dios O. et al., "A Network YANG Model for
             Service Attachment Points (SAPs)", draft-ietf-opsawg-sap,
             work in progress.

Peruzzini et al.       Expires January 10, 2023               [Page 53]
Internet-Draft                 ACTN POI                       July 2022

   [NETWORK-INVENTORY]  Yu C. et al., "A YANG Data Model for Optical
             Network Inventory", draft-yg3bp-ccamp-optical-inventory-
             yang, work in progress.

   [OPTICAL-PATH-COMPUTE]  Busi I. et al., "YANG Data Models for
             requesting Path Computation in Optical Networks", draft-
             gbb-ccamp-optical-path-computation-yang, work in progress.

Peruzzini et al.       Expires January 10, 2023               [Page 54]
Internet-Draft                 ACTN POI                       July 2022

Appendix A. OSS/Orchestration Layer

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

   o  to abstract (through MDSC and PNCs) the underlying transport
      network complexity to the Business Systems Support layer;

   o  to coordinate NFV, Transport (e.g. IP, optical and microwave
      networks), Fixed Acess, Core and Radio domains enabling full
      automation of end-to-end services to the end customers;

   o  to enable catalogue-driven service provisioning from external
      applications (e.g. Customer Portal for Enterprise Business
      services), orchestrating the design and lifecycle management of
      these end-to-end transport connectivity services, consuming IP
      and/or optical transport connectivity services upon request.

   As discussed in section 2.1, in this document, the MDSC interfaces
   with the OSS/Orchestration layer and, therefore, it performs the
   functions of the Network Orchestrator, defined in [RFC8309].

   The OSS/Orchestration layer requests the creation of a network
   service to the MDSC specifying its end-points (PEs and the interfaces
   towards the CEs) as well as the network service SLA and then proceeds
   to configuring accordingly the end-to-end customer service between
   the CEs in the case of an operator managed service.

A.1.  MDSC NBI

   As explained in section 2, the OSS/Orchestration layer can request
   the MDSC to setup L2/L3VPN network services (with or without TE
   requirements).

   Although the OSS/Orchestration layer interface is usually operator-
   specific, typically it would be using a RESTCONF/YANG interface with
   a more abstracted version of the MPI YANG data models used for
   network configuration (e.g. L3NM, L2NM).

   Figure 9 shows an example of possible control flow between the
   OSS/Orchestration layer and the MDSC to instantiate L2/L3 VPN network
   services, using the YANG data models under the definition in [VN],
   [L2NM], [RFC9182] and [TSM].

Peruzzini et al.       Expires January 10, 2023               [Page 55]
Internet-Draft                 ACTN POI                       July 2022

               +-------------------------------------------+
               |                                           |
               |          OSS/Orchestration layer          |
               |                                           |
               +-----------------------+-------------------+
                                       |
                 1.VN    2. L2/L3NM &  |            ^
                   |          TSM      |            |
                   |           |       |            |
                   |           |       |            |
                   v           v       |      3. Update VN
                                       |
               +-----------------------+-------------------+
               |                                           |
               |                  MDSC                     |
               |                                           |
               +-------------------------------------------+

                     Figure 9 Service Request Process

   o  The VN YANG data model, defined in [VN], whose primary focus is
      the CMI, can also provide VN Service configuration from an
      orchestrated network service point of view when the L2/L3 VPN
      network service has TE requirements. However, this model is not
      used to setup L2/L3 VPN service with no TE requirements.

       o It provides the profile of VN in terms of VN members, each of
          which corresponds to an edge-to-edge link between customer
          end-points (VNAPs). It also provides the mappings between the
          VNAPs with the LTPs and the connectivity matrix with the VN
          member. The associated traffic matrix (e.g., bandwidth,
          latency, protection level, etc.) of VN member is expressed
          (i.e., via the TE-topology's connectivity matrix).

       o The model also provides VN-level preference information (e.g.,
          VN member diversity) and VN-level admin-status and
          operational-status.

   o  The L2NM and L3NM YANG data models, defined in [L2NM] and
      [RFC9182], whose primary focus is the MPI, can also be used to
      provide L2VPN and L3VPN network service configuration from a
      orchestrated connectivity service point of view.

   o  The TE & Service Mapping YANG data model [TSM] provides TE-service
      mapping.

Peruzzini et al.       Expires January 10, 2023               [Page 56]
Internet-Draft                 ACTN POI                       July 2022

       o TE-service mapping provides the mapping between a L2/L3 VPN
          instance and the corresponding VN instances.

       o The TE-service mapping also provides the binding requirements
          as to how each L2/L3 VPN/VN instance is created concerning the
          underlay TE tunnels (e.g., whether they require a new and
          isolated set of TE underlay tunnels or not).

       o Site mapping provides the site reference information across
          L2/L3 VPN Site ID, VN Access Point ID, and the LTP of the
          access link.

Peruzzini et al.       Expires January 10, 2023               [Page 57]
Internet-Draft                 ACTN POI                       July 2022

Appendix B. Multi-layer and multi-domain resiliency

B.1.  Maintenance Window

   Before planned maintenance operation on DWDM network takes place, IP
   traffic should be moved hitless to another link.

   MDSC must reroute IP traffic before the events takes place. It should
   be possible to lock IP traffic to the protection route until the
   maintenance event is finished, unless a fault occurs on such path.

B.2.  Router port failure

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

   There can be two cases here:

   a) LAG was defined between the two end routers. MDSC, after checking
      that optical layer is fine between the two end ROADMs, triggers
      the ROADM configuration so that the router back-up port with its
      associated muxponder port can reuse the OCh that was already in
      use previously by the failed router port and adds the new link to
      the LAG on the failure side.

      While the ROADM reconfiguration takes place, IP/MPLS traffic is
      using the reduced bandwidth of the IP link bundle, discarding
      lower priority traffic if required. Once back-up port has been
      reconfigured to reuse the existing OCh and new link has been added
      to the LAG then original Bandwidth is recovered between the end
      routers.

      Note: in this LAG scenario let assume that BFD is running at LAG
      level so that there is nothing triggered at MPLS level when one of
      the link member of the LAG fails.

Peruzzini et al.       Expires January 10, 2023               [Page 58]
Internet-Draft                 ACTN POI                       July 2022

   b) If there is no LAG then the scenario is not clear since a router
      port failure would automatically trigger (through BFD failure)
      first a sub-50ms protection at MPLS level :FRR (MPLS RSVP-TE case)
      or TI-LFA (MPLS based SR-TE case) through a protection port. At
      the same time MDSC, after checking that optical network connection
      is still fine, would trigger the reconfiguration of the back-up
      port of the router and of the ROADM muxponder to re-use the same
      OCh as the one used originally for the failed router port. Once
      everything has been correctly configured, MDSC Global PCE could
      suggest to the operator to trigger a possible re-optimization of
      the back-up MPLS path to go back to the  MPLS primary path through
      the back-up port of the router and the original OCh if overall
      cost, latency etc. is improved. However, in this scenario, there
      is a need for protection port PLUS back-up port in the router
      which does not lead to clear port savings.

Acknowledgments

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

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

Contributors

   Sergio Belotti
   Nokia

   Email: sergio.belotti@nokia.com

   Gabriele Galimberti
   Cisco

   Email: ggalimbe@cisco.com

   Zheng Yanlei
   China Unicom

   Email: zhengyanlei@chinaunicom.cn

Peruzzini et al.       Expires January 10, 2023               [Page 59]
Internet-Draft                 ACTN POI                       July 2022

   Anton Snitser
   Sedona

   Email: antons@sedonasys.com

   Washington Costa Pereira Correia
   TIM Brasil

   Email: wcorreia@timbrasil.com.br

   Michael Scharf
   Hochschule Esslingen - University of Applied Sciences

   Email: michael.scharf@hs-esslingen.de

   Young Lee
   Sung Kyun Kwan University

   Email: younglee.tx@gmail.com

   Jeff Tantsura
   Apstra

   Email: jefftant.ietf@gmail.com

   Paolo Volpato
   Huawei

   Email: paolo.volpato@huawei.com

   Brent Foster
   Cisco

   Email: brfoster@cisco.com

Peruzzini et al.       Expires January 10, 2023               [Page 60]
Internet-Draft                 ACTN POI                       July 2022

Authors' Addresses

   Fabio Peruzzini
   TIM

   Email: fabio.peruzzini@telecomitalia.it

   Jean-Francois Bouquier
   Vodafone

   Email: jeff.bouquier@vodafone.com

   Italo Busi
   Huawei

   Email: Italo.busi@huawei.com

   Daniel King
   Old Dog Consulting

   Email: daniel@olddog.co.uk

   Daniele Ceccarelli
   Ericsson

   Email: daniele.ceccarelli@ericsson.com

Peruzzini et al.       Expires January 10, 2023               [Page 61]