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-12

Document Type Active Internet-Draft (teas WG)
Authors Fabio Peruzzini , Jean-Francois Bouquier , Italo Busi , Daniel King , Daniele Ceccarelli
Last updated 2024-07-05
Replaces draft-peru-teas-actn-poi-applicability
RFC stream Internet Engineering Task Force (IETF)
Intended RFC status (None)
Formats
Additional resources Mailing list discussion
Stream WG state WG Document
Document shepherd Vishnu Pavan Beeram
IESG IESG state I-D Exists
Consensus boilerplate Unknown
Telechat date (None)
Responsible AD (None)
Send notices to vbeeram@juniper.net
draft-ietf-teas-actn-poi-applicability-12
Traffic Engineering Architecture and Signaling              F. Peruzzini
Internet-Draft                                                       TIM
Intended status: Informational                            J.-F. Bouquier
Expires: 6 January 2025                                         Vodafone
                                                                 I. Busi
                                                                  Huawei
                                                                 D. King
                                                      Old Dog Consulting
                                                           D. Ceccarelli
                                                                   Cisco
                                                             5 July 2024

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

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 defined by the IETF to support this
   deployment architecture and specific scenarios relevant to Service
   Providers.

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

About This Document

   This note is to be removed before publishing as an RFC.

   The latest revision of this draft can be found at https://IETF-TEAS-
   WG.github.io/actn-poi/draft-ietf-teas-actn-poi-applicability.html.
   Status information for this document may be found at
   https://datatracker.ietf.org/doc/draft-ietf-teas-actn-poi-
   applicability/.

   Discussion of this document takes place on the Traffic Engineering
   Architecture and Signaling Working Group mailing list
   (mailto:teas@ietf.org), which is archived at
   https://mailarchive.ietf.org/arch/browse/teas/.  Subscribe at
   https://www.ietf.org/mailman/listinfo/teas/.

Peruzzini, et al.        Expires 6 January 2025                 [Page 1]
Internet-Draft                  ACTN POI                       July 2024

   Source for this draft and an issue tracker can be found at
   https://github.com/IETF-TEAS-WG/actn-poi.

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).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

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

   This Internet-Draft will expire on 6 January 2025.

Copyright Notice

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

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

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   4
     1.1.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   5
   2.  Reference Network Architecture  . . . . . . . . . . . . . . .   7
     2.1.  Multi-domain Service Coordinator (MDSC) functions . . . .  10
       2.1.1.  Multi-domain L2/L3 VPN Network Services . . . . . . .  11
       2.1.2.  Multi-domain and Multi-layer Path Computation . . . .  16
     2.2.  IP/MPLS Domain Controller and IP router Functions . . . .  17
     2.3.  Optical Domain Controller and NE Functions  . . . . . . .  20
   3.  Interface Protocols and YANG Data Models for the MPIs . . . .  20
     3.1.  RESTCONF Protocol at the MPIs . . . . . . . . . . . . . .  20
     3.2.  YANG Data Models at the MPIs  . . . . . . . . . . . . . .  21
       3.2.1.  Common YANG Data Models at the MPIs . . . . . . . . .  21

Peruzzini, et al.        Expires 6 January 2025                 [Page 2]
Internet-Draft                  ACTN POI                       July 2024

       3.2.2.  YANG models at the Optical MPIs . . . . . . . . . . .  22
       3.2.3.  YANG data models at the Packet MPIs . . . . . . . . .  23
     3.3.  Path Computation Element Protocol (PCEP)  . . . . . . . .  24
   4.  Inventory, Service and Network Topology Discovery . . . . . .  25
     4.1.  Optical Topology Discovery  . . . . . . . . . . . . . . .  26
     4.2.  Optical Path Discovery  . . . . . . . . . . . . . . . . .  29
     4.3.  Packet Topology Discovery . . . . . . . . . . . . . . . .  30
     4.4.  TE Path Discovery . . . . . . . . . . . . . . . . . . . .  31
     4.5.  Inter-domain Link Discovery . . . . . . . . . . . . . . .  32
       4.5.1.  Cross-technology Ethernet link Discovery  . . . . . .  33
       4.5.2.  Inter-domain IP Link Discovery  . . . . . . . . . . .  35
     4.6.  Multi-technology IP Link Discovery  . . . . . . . . . . .  37
       4.6.1.  Intra-domain single-technology IP Links . . . . . . .  39
     4.7.  LAG Discovery . . . . . . . . . . . . . . . . . . . . . .  41
     4.8.  L2/L3 VPN Network Services Discovery  . . . . . . . . . .  43
     4.9.  Inventory Discovery . . . . . . . . . . . . . . . . . . .  44
   5.  Establishment of L2/L3 VPN Services with TE Requirements  . .  44
     5.1.  Optical Path Computation  . . . . . . . . . . . . . . . .  46
     5.2.  Multi-technology IP Link Setup  . . . . . . . . . . . . .  47
       5.2.1.  Multi-technology LAG Setup  . . . . . . . . . . . . .  50
       5.2.2.  Multi-technology LAG Update . . . . . . . . . . . . .  51
       5.2.3.  Multi-technology TE path properties Configuration . .  51
     5.3.  TE Path Setup and Update  . . . . . . . . . . . . . . . .  52
     5.4.  L2/L3 VPN Network Service Setup . . . . . . . . . . . . .  53
   6.  Conclusions . . . . . . . . . . . . . . . . . . . . . . . . .  54
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .  55
     7.1.  LLDP Snooping Security Considerations . . . . . . . . . .  56
   8.  Operational Considerations  . . . . . . . . . . . . . . . . .  57
   9.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  58
   10. References  . . . . . . . . . . . . . . . . . . . . . . . . .  58
     10.1.  Normative References . . . . . . . . . . . . . . . . . .  58
     10.2.  Informative References . . . . . . . . . . . . . . . . .  62
   Appendix A.  Additional Scenarios . . . . . . . . . . . . . . . .  65
     A.1.  OSS/Orchestration Layer . . . . . . . . . . . . . . . . .  65
       A.1.1.  MDSC NBI  . . . . . . . . . . . . . . . . . . . . . .  66
     A.2.  Multi-layer and Multi-domain Resiliency . . . . . . . . .  67
       A.2.1.  Maintenance Window  . . . . . . . . . . . . . . . . .  67
       A.2.2.  Router Port Failure . . . . . . . . . . . . . . . . .  68
     A.3.  Muxponders  . . . . . . . . . . . . . . . . . . . . . . .  69
   Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  70
   Contributors  . . . . . . . . . . . . . . . . . . . . . . . . . .  70
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  71

Peruzzini, et al.        Expires 6 January 2025                 [Page 3]
Internet-Draft                  ACTN POI                       July 2024

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

   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 other vendors in both domains.  The operation of
   these complex packet and optical networks is often siloed, as these
   technology domains require specific skill sets.

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

Peruzzini, et al.        Expires 6 January 2025                 [Page 4]
Internet-Draft                  ACTN POI                       July 2024

   This document uses packet-based Traffic Engineered (TE) service
   examples.  These are described as "TE-path" in this document.  Unless
   otherwise stated, these TE services may be instantiated using RSVP-
   TE-based or SR-TE-based, forwarding plane mechanisms.

   The ACTN framework enables the complete multi-technology and multi-
   vendor integration of packet and optical networks through a Multi-
   Domain Service Coordinator (MDSC), and packet and optical
   Provisioning Network Controllers (PNCs).

   This document describes critical scenarios for POI from the packet
   service layer perspective and identifies the required coordination
   between packet and optical layers to improve POI deployment and
   operation.  These scenarios focus on multi-domain packet networks
   operated as a client of optical networks.

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

   Multi-technology and multi-domain scenarios, based on the reference
   network described in Section 2 and very relevant for Service
   Providers, are described in Section 4 and Section 5.

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

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

   A summary of the gaps identified in this analysis is provided in
   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.

Peruzzini, et al.        Expires 6 January 2025                 [Page 5]
Internet-Draft                  ACTN POI                       July 2024

   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 address, routing protocol
      etc.).

   Technology domain:  short for "switching technology domain", defined
      as "region" in [RFC5212], where the term "region" is applied to
      (GMPLS) control domains.

   PNC Domain:  part of the network under control of a single PNC
      instance.  It is subject to the capabilities of the PNC which
      technology is controlled.

   Port:  The physical entity that transmits and receives physical
      signals.

   Interface:  A physical or logical entity that transmits and receives
      traffic.

   Link:  An association between two interfaces that can exchange
      traffic directly.

   Intra-domain link:  a link between two adjacent nodes that belong to
      the same PNC domain.

   Inter-domain link:  a link between two adjacent nodes that belong to
      different PNC domains.

   Ethernet link:  A link between two Ethernet interfaces.

   Single-technology Ethernet link:  An Ethernet link between two
      Ethernet interfaces on physically adjacent IP routers.

   Multi-technology Ethernet link:  An Ethernet link between between two
      Ethernet interfaces on logically adjacent IP routers, which is
      supported by an underlay tunnel in a different technology domain.

   Cross-technology Ethernet link:  An Ethernet link between an Ethernet
      interface on an IP router and an Ethernet interface on a
      physically adjacent optical node.

   Inter-domain Ethernet link:  An Ethernet link between between two
      Ethernet interfaces on physically adjacent IP routers that belong
      to different P-PNC domains.

   Single-technology intra-domain Ethernet link:  An Ethernet link

Peruzzini, et al.        Expires 6 January 2025                 [Page 6]
Internet-Draft                  ACTN POI                       July 2024

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

   Multi-technology intra-domain Ethernet link:  An Ethernet link
      between between two Ethernet interfaces on logically adjacent IP
      routers that belong to the same P-PNC domain, which is supported
      by supported by two cross-technology Ethernet links and an optical
      tunnel in between.

   IP link:  A link between two IP interfaces.

   Single-technology intra-domain IP link:  An IP link supported by a
      single-technology intra-domain Ethernet link.

   Inter-domain IP link:  An IP link supported by an inter-domain
      Ethernet link.

   Multi-technology intra-domain IP link:  An IP link supported by a
      multi-technology intra-domain 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-technology and multi-domain network with two optical
   domains and two packet domains, as shown in Figure 1:

Peruzzini, et al.        Expires 6 January 2025                 [Page 7]
Internet-Draft                  ACTN POI                       July 2024

                               +----------+
                               |   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-technology 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 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 IP routers between the packet domains can be either AS Boundary
   Routers (ASBR) or Area Border Router (ABR): in this document, the
   generic term Border Router (BR) is used to represent either an ASBR
   or an ABR.

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

Peruzzini, et al.        Expires 6 January 2025                 [Page 8]
Internet-Draft                  ACTN POI                       July 2024

   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 a packet
   network).

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

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

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

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

      -  between packet and optical domains (i.e., between routers and
         optical nodes): these links are called cross-technology
         Ethernet links within this document;

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

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

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

   This document analyses scenarios where all the multi-technology 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-technology links supported by
   Ethernet physical links.

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

Peruzzini, et al.        Expires 6 January 2025                 [Page 9]
Internet-Draft                  ACTN POI                       July 2024

   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 nodes within the optical domains can be either:

   *  WDM nodes, as defined in
      [I-D.ietf-ccamp-optical-impairment-topology-yang], with an
      integrated ROADM functions and with or without integrated optical
      transponders;

   *  OTN nodes, with integrated an OTN cross-connect function and with
      or without integrated ROADM functions or optical transponders.

2.1.  Multi-domain Service Coordinator (MDSC) functions

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

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

   1.  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].

   3.  Another implementation can choose to split the MDSC functions
       between an "higher-level MDSC" (MDSC-H) responsible for packet
       and optical multi-technology 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]).

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

   4.  Another implementation can also choose to combine the MDSC and
       the P-PNC functions.

   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] described in point 2
   above.  Therefore, the MDSC deals 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 outside this document's scope.

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

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

   *  The MDSC initiates them 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 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.

2.1.1.  Multi-domain L2/L3 VPN Network Services

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

Peruzzini, et al.        Expires 6 January 2025                [Page 11]
Internet-Draft                  ACTN POI                       July 2024

        ------
       | CE13 |    Packet Domain 1              Packet Domain 2
        ------ ____________________            __________________
        ( |                         )         (                  )
       (  | PE13     P15       BR11  )       (  BR21       P24     )
      (   |____         ___       ____ )      ( ____      ___       )
     (    /    \ _ _ _ /   \ _ _ /    \________/    \    /   \     )
    (     \____/       \___/     \___ /        \____/    \_ _/     )
   (   PE14  :\_ _               /      )  (    /  :      : \__     )
   (    ____  :   \__ P16    ___/      )  (  __/_             _\__  )
    (  /    \  :  /   \- - -/    \__________/    \ :_ _ _ :_ /    \  )
    (  \____/     \___/     \____/     )  ( \____/           \____/ )
      (  / :   :    :         :  BR12  )   (   :    :     :     |  )
       (/                              )   ( BR22           PE23|   )
    ------ :   :    :         :       )      ( :     :    :     |  )
   | CE14 | (__ ____ _________ _____)           (_____ ___ _ ------
    ------ :   :    :         :                :      :   : | CE23 |
                                                             ------
           :   :    :         :                :      :   :
          _ ___ ____ _________ ________         ______ ___ _______
         ( :   :    :         :        )       :      :   :       )
        (      ____  :      ____        )     (      ____  .. ..   )
       (   :  /    \_ _ _ _/    \ NE12   )   ( :    /    \ _    :   )
      (  NE11 \____/ :     \____/         )  ( NE21 \____/   \     )
      (    :  /    \    _ _ /  \          )  ( :     /        \ :   )
      (   ___/      \:_|        \____    )  (   .___/         _\__  )
      (  /    \_ _ /    \ _ _ _ /    \   )  (   /    \ _ _ _ /    \  )
       ( \____/    \____/       \____/  )    (  \____/       \____/  )
        ( NE13      NE14         NE15   )     (  NE22         NE23  )
         (_____________________________)       (___________________)

                Optical Domain 1                  Optical Domain 2

          _____  = Inter-domain links
          .. ..  = Cross-layer links
          _ _ _  = Intra-domain links

                Figure 2: Multi-domain VPN topology example

Peruzzini, et al.        Expires 6 January 2025                [Page 12]
Internet-Draft                  ACTN POI                       July 2024

        ------
       | CE13 |    Packet Domain 1              Packet Domain 2
        ------ ____________________            _________________
        ( |                         )         (                 )
       (  | PE13     P15       BR11  )       (  BR21       P24    )
      (   |____         ___       ____ )      ( ____     ___       )
     (    / H  \       /   \     /    \________/..  \   / ..\ ..  )
    (     \____/.....  \___/     \___ / .. .. ..___:/   \___/   : )
   (   PE14  :      :              .. .. )  (             :        )
   (    ____  :    _:_ P16   ____ :     )  ( ____  :          __:_ )
    (  / S  \  :  / ..\     /   ..__________/    \        :  /  S \ )
    (  \____/     \__:/     \____/     )  ( \____/ :         \____/ )
      (  / :   :     :          :BR12  )   (              :     |  )
       (/  :         :                 )   ( BR22  :        PE23|   )
    ------ :   :     :          :     )      (            :     | )
   | CE14 |:(__ _____:__________ ___)           (__:______ __ ------
    ------ :   :      :         :                         :  | CE23 |
           :           :                           :          ------
           :   :       :        :                         :
          _:___________:________ ______         ___:______ _______
         ( :   :       :        :      )       (          : .. .. )
        (  :   ____    :    ____        )     (     :____          )
       (   :  / .. \.. : ../ .. \ NE12   )   (      /..  \      :   )
      (  NE11 \____/   :   \____/         )  ( NE21 \__:_/          )
      (    :           :                  )  (                  :  )
      (   _:__      ___:         ____    )  (    ____  : ..  ____  )
      (  / :..\..../...:\       /    \   )  (   /    \      /.. :\  )
       ( \____/    \____/       \____/  )    (  \____/      \____/  )
        ( NE13      NE14         NE15   )     (  NE22        NE23  )
         (_____________________________)       (__________________)

                Optical Domain 1                  Optical Domain 2

           H / S = Hub VRF / Spoke VRF

          .....  = Intra-domain TE Path 1 {PE13, P16, NE14, NE13, PE14}
          .. ..  = Inter-domain TE Path 2 {PE13, NE11, NE12, BR12,
                   BR11, BR21, NE21, NE23, P24, PE23}

                Figure 3: Multi-domain VPN TE paths example

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

   1.  BGP-LU ([RFC8277])

   2.  Inter-domain RSVP-TE

Peruzzini, et al.        Expires 6 January 2025                [Page 13]
Internet-Draft                  ACTN POI                       July 2024

   3.  Inter-domain SR-TE

   This document analyses the inter-domain TE options for which the TE
   tunnel model, defined in [I-D.ietf-teas-yang-te], 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:

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

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

   *  each packet domain in Figure 2 uses technology-specific local
      protection mechanisms (such as Fast Reroute (FRR) in case of MPLS-
      TE or Topology Independent Loop-free Alternate Fast Reroute (TI-
      LFA) in case of SR-TE), with the awareness of multi-technology TE
      path properties (e.g., SRLG).

   In the case of inter-domain TE-paths, it is also assumed that each
   packet domain in Figure 2 and Figure 3 implements the same TE
   technology, and the stitching between two domains is done using
   inter-domain 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 to dynamically create
       and bind tunnels to the service so that they are not shared by
       other services (e.g.  VPN).

       The level of isolation can be different:

Peruzzini, et al.        Expires 6 January 2025                [Page 14]
Internet-Draft                  ACTN POI                       July 2024

       a.  Hard isolation with deterministic latency means L2/L3 VPN
           requires a set of dedicated TE Tunnels (neither 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 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 for isolation and could request a VPN
       service where associated tunnels can be shared across multiple
       VPNs.

   For each 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
       exists 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).

   This document analyses scenarios where only one TE path is used to
   carry the VPN traffic between PEs.  Scenarios, where multiple
   parallel TE paths are used in load-balancing to carry the VPN traffic
   between PEs, are possible but their analysis is outside the scope of
   this document.

Peruzzini, et al.        Expires 6 January 2025                [Page 15]
Internet-Draft                  ACTN POI                       July 2024

2.1.2.  Multi-domain and Multi-layer Path Computation

   When a new TE path needs to be setup, the MDSC is also responsible
   for coordinating 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:

   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.  Then, 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 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 abstract 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.

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

Peruzzini, et al.        Expires 6 January 2025                [Page 16]
Internet-Draft                  ACTN POI                       July 2024

       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.  It uses
       the information received by the O-PNCs and 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 a 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
       [I-D.ietf-teas-yang-path-computation], 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
       different vendors provide them).

   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 [I-D.ietf-ccamp-optical-impairment-topology-yang],
   used by the O-PNC for optical path computation are not exposed at the
   MPI and therefore out of scope for this document.

2.2.  IP/MPLS Domain Controller and IP router 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).

Peruzzini, et al.        Expires 6 January 2025                [Page 17]
Internet-Draft                  ACTN POI                       July 2024

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

   For example, for inter-domain SR-TE, the setup bidirectional SR-TE
   path from PE13 in domain 1 to PE23 in domain 2, as shown in Figure 3,
   requires the MDSC to coordinate the actions of:

   *  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);

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

   With reference to Figure 4, 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;

   4.  To configure 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 6 January 2025                [Page 18]
Internet-Draft                  ACTN POI                       July 2024

           +------------------+            +------------------+
           |                  |            |                  |
           |      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 4: Domain Controller & node 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 complete 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:

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

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

   To scale in large SR-TE packet domains, the MDSC can provide P-PNC a
   loose path, together with per-domain TE constraints.  The P-PNC can
   then select the complete path within its domain.

   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.

   From the Figure 3 example, the TE path requested by the MDSC touches
   PE13 - P16 - BR12 - BR21 - PE23.  P-PNC2 is aware of two paths with
   the same topology metric, e.g.  BR21 - P24 - PE23 and BR21 - BR22 -
   PE23, but with different loads.  It may prefer to steer the traffic
   on the latter because it is less loaded.

Peruzzini, et al.        Expires 6 January 2025                [Page 19]
Internet-Draft                  ACTN POI                       July 2024

   For the purposes of this document it is assumed that the MDSC always
   provides the explicit list of all the hops to the P-PNCs to setup or
   modify the TE path.

2.3.  Optical Domain Controller and NE Functions

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

   The O-PNC is responsible to:

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

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

   *  perform optical tunnel 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 to 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
   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.

Peruzzini, et al.        Expires 6 January 2025                [Page 20]
Internet-Draft                  ACTN POI                       July 2024

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

   This section describes the YANG data models that are applicable to
   the Packet and Optical MPIs.  Some of these YANG data models can be
   optional depending on the specific network configuration detailed in
   Section 4 and Section 5.

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 can use the following common topology
   YANG data models at the MPI:

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

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

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

   Optical and Packet PNCs can use the common TE Tunnel Model, defined
   in the "ietf-te" YANG module of [I-D.ietf-teas-yang-te], 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 can also use the Ethernet Topology
   Model, defined in the "ietf-eth-te-topology" YANG module of
   [I-D.ietf-ccamp-eth-client-te-topo-yang], which augments the TE
   Topology Model with Ethernet technology-specific information.

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

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

Peruzzini, et al.        Expires 6 January 2025                [Page 21]
Internet-Draft                  ACTN POI                       July 2024

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

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

3.2.2.  YANG models at the Optical MPIs

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

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

   *  the Flexi-grid Topology Model, defined in the "ietf-flexi-grid-
      topology" YANG module of [I-D.ietf-ccamp-flexigrid-yang];

   *  the OTN Topology Model, as defined in the "ietf-otn-topology" YANG
      module of [I-D.ietf-ccamp-otn-topo-yang].

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

   *  The WDM Tunnel Model, defined in the "ietf-wdm-tunnel" YANG module
      of [I-D.ietf-ccamp-wdm-tunnel-yang];

   *  the OTN Tunnel Model, defined in the "ietf-otn-tunnel" YANG module
      of [I-D.ietf-ccamp-otn-tunnel-model].

   The optical PNC can use the generic Path Computation YANG RPC,
   defined in the "ietf-te-path-computation" YANG module of
   [I-D.ietf-teas-yang-path-computation].

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

   The optical PNC uses can use the following client signal YANG data
   models:

   *  the CBR Client Signal Model, defined in the "ietf-trans-client-
      service" YANG module of [I-D.ietf-ccamp-client-signal-yang];

   *  the Ethernet Client Signal Model, defined in the "ietf-eth-tran-
      service" YANG module of [I-D.ietf-ccamp-client-signal-yang].

Peruzzini, et al.        Expires 6 January 2025                [Page 22]
Internet-Draft                  ACTN POI                       July 2024

3.2.3.  YANG data models at the Packet MPIs

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

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

   *  the Packet TE Topology Mode, defined in the "ietf-te-topology-
      packet" YANG module of [I-D.ietf-teas-yang-l3-te-topo], which
      augments the generic TE Topology Model;

   *  The MPLS-TE Topology Model, defined in the "ietf-te-mpls-topology"
      YANG module of [I-D.ietf-teas-yang-te-mpls-topology], which
      augments the TE Packet Topology Model with or without the L3 TE
      Topology Model, defined in "ietf-l3-te-topology" YANG module of
      [I-D.ietf-teas-yang-l3-te-topo];

   *  the SR Topology Model, defined in the "ietf-sr-mpls-topology" YANG
      module of [I-D.ietf-teas-yang-sr-te-topo].

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

   *  The MPLS-TE Tunnel Model, defined in the "ietf-te-mpls" YANG
      modules of [I-D.ietf-teas-yang-te-mpls];

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

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

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

   *  L3NM TE Service Mapping, defined in the "ietf-l3nm-te-service-
      mapping" YANG module of [I-D.ietf-teas-te-service-mapping-yang];

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

   *  L2NM TE Service Mapping, defined in the "ietf-l2nm-te-service-
      mapping" YANG module of [I-D.ietf-teas-te-service-mapping-yang].

Peruzzini, et al.        Expires 6 January 2025                [Page 23]
Internet-Draft                  ACTN POI                       July 2024

3.3.  Path Computation Element Protocol (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 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,
   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 the 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 perform full multi-layer path computation or delegate path
       computation to the underneath PNCs.

       This approach is desirable for operators from a multi-vendor
       integration perspective as it is simple.  We need only one type
       of interface (RESTCONF) and use the relevant YANG data models
       depending on the operator use case considered.  The benefits of
       having only one protocol for the MPI between MDSC and PNC have
       already been highlighted in
       [I-D.ietf-teas-yang-path-computation].

   2.  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 RESTCONF/YANG interface is added to an
       existing PCEP deployment (brownfield scenario).

Peruzzini, et al.        Expires 6 January 2025                [Page 24]
Internet-Draft                  ACTN POI                       July 2024

   Section 4 and Section 5 of this draft analyze 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:

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

   *  the optical tunnels supporting multi-technology intra-domain IP
      links;

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

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

   *  the hardware inventory information of IP and optical equipment.

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

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

   Reporting the entire inventory and detailed topology information of
   packet and optical networks to the MDSC may present scalability
   issues as a potential drawback.  The analysis of the scalability of
   this approach and mechanisms to address potential issues is outside
   the scope of this document.

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

Peruzzini, et al.        Expires 6 January 2025                [Page 25]
Internet-Draft                  ACTN POI                       July 2024

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

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

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

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

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

4.1.  Optical Topology Discovery

   The WSON Topology Model and the Flexi-grid Topology model can be used
   to report the DWDM network topology (e.g., WDM nodes and OMS links),
   depending on whether the DWDM optical network is based on fixed-grid
   or flexible-grid or a mix of fixed-grid and flexible-grid.

   It is worth noting that, as described in Appendix I of
   [ITU-T_G.694.1], a fixed-grid can also be described as a flexible
   grid with constraints: for example a 50GHz fixed-grid can be
   described as a flexible-grid which supports only m=4 and values of n
   which are only multiplier of 8.

   As a consequence:

   *  A flexible-grid DWDM network topology can only be reported using
      the Flexi-grid Topology model;

   *  A fixed-grid DWDM network topology, can be reported using either
      the WSON Topology model or the Flexi-grid Topology model;

Peruzzini, et al.        Expires 6 January 2025                [Page 26]
Internet-Draft                  ACTN POI                       July 2024

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

   Clarifying how both WSON and Flexi-grid topology models could be used
   together (e.g., through multi-inheritance as described in
   [I-D.ietf-teas-te-topology-profiles]) has been identified as a gap.

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

   To allow the MDSC to discover the complete multi-layer and multi-
   domain network topology and to correlate it with the hardware
   inventory information, the O-PNCs report an abstract optical network
   topology where:

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

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

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

   *  the optical parameters required for optical path computation, such
      as those detailed in
      [I-D.ietf-ccamp-optical-impairment-topology-yang];

   *  the underlay OTS links and ILAs of OMS links;

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

   The OTN Topology Model also reports the CBR client LTPs that
   terminates the cross-technology Ethernet links: once CBR client LTP
   is reported for each CBR or multi-function client interface on the
   optical nodes (see sections 4.4 and 5.1 of
   [I-D.ietf-ccamp-transport-nbi-app-statement] for the description of
   multi-function client interfaces).

   The Ethernet Topology Model reports the Ethernet client LTPs that
   terminate the cross-technology Ethernet links: one Ethernet client
   LTP is reported for each Ethernet or multi-function client interface
   on the optical nodes.

Peruzzini, et al.        Expires 6 January 2025                [Page 27]
Internet-Draft                  ACTN POI                       July 2024

   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 and abstracted as a single WDM TE Node at
   the O-MPI.

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

   For example, with a reference to Figure 5, the ILL values X and Y are
   used to associated the client LTPs (7-0) in NE11 and (8-0) in NE12
   with the corresponding optical TTPs (7) in NE11 and (8) in NE12,
   respectively.

Peruzzini, et al.        Expires 6 January 2025                [Page 28]
Internet-Draft                  ACTN POI                       July 2024

            +----------------------------------------------------------+
           /                                                          /
          /            <X>                      <Y>                  /
         /    +------O------+                +------O------+        /
        /     |    (7-0)    |                |    (8-0)    |       /
       /      |             |                |             |      /
      /       |    NE11     |                |     NE12    |     /
     /        +-------------+                +-------------+    /
    /                Ethernet or OTN Topology (O-PNC 1)        /
   +-----------------------------------------------------------+

            +----------------------------------------------------------+
           /    <X> (7)                            (8) <Y>            /
          /         ---                            ---               /
         /    +-----\ /-----+                +-----\ /-----+        /
        /     |      V      |                |      V      |       /
       /      |             |                |             |      /
      /       |    NE11     |                |    NE12     |     /
     /        +-------------+                +-------------+    /
    /                   Optical Topology (O-PNC 1)             /
   +----------------------------------------------------------+

   Legenda:
   ========
     O   LTP
    ---
    \ /  TTP
     V
   <   > Inter-Layer Lock-id reported by the PNC

              Figure 5: Multi-layer optical topology discovery

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

   In case of a multi-layer DWDM/OTN network domain, multi-layer intra-
   domain OTN links are supported by underlay WDM tunnels: this
   relationship is reported by the mechanisms described in Section 4.2.

4.2.  Optical Path Discovery

   The WDM Tunnel Model is used to report all the WDM tunnels
   established within the optical network.

Peruzzini, et al.        Expires 6 January 2025                [Page 29]
Internet-Draft                  ACTN POI                       July 2024

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

   The Ethernet client signal model and the Transparent CBR client
   signal model are used to report all the connectivity services
   provided by the underlay optical tunnels between Ethernet or CBR
   client LTPs, depending on whether the connectivity service is frame-
   based or transparent.  The underlay optical tunnels can be either WDM
   tunnels or, when the optional OTN switching layer is deployed, OTN
   tunnels.

   The WDM tunnels can be used to support either Ethernet or CBR client
   signals or multi-layer intra-domain OTN links.  In the latter case,
   the hierarchical-link container, defined in [I-D.ietf-teas-yang-te],
   associates the underlay WDM tunnel with the supported multi-layer
   intra-domain OTN link and it allows discovery of the multi-layer path
   supporting all the connectivity services provided by the optical
   network.

   The O-PNCs report in their operational datastores all the Ethernet
   and CBR client connectivities and all the optical tunnels deployed
   within their optical domain regardless of the mechanisms being used
   to set them up, such as the mechanisms described in 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 is used report the IP network topology.

   The L3 Topology Model, SR Topology Model, TE Topology Model and the
   TE Packet Topology Model are used together to report the SR-TE
   network topology, as described in Figure 2 of
   [I-D.ietf-teas-yang-sr-te-topo].

   The TE Topology Model, TE Packet Topology Model and MPLS-TE Topology
   Model are used together to report the MPLS-TE network topology, as
   described in [I-D.ietf-teas-yang-te-mpls-topology].

   As described in [I-D.ietf-teas-yang-l3-te-topo], the relationship
   between the IP network topology and the MPLS-TE network topology
   depends on whether the two network topologies are congruent or not:
   in the latter case, the L3 TE Topology Model is used, together with
   the L3 Topology Model to provide the association between the two
   network topologies.

Peruzzini, et al.        Expires 6 January 2025                [Page 30]
Internet-Draft                  ACTN POI                       July 2024

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

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

   All the intra-domain Ethernet and 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 Ethernet or the packet network topology.

4.4.  TE Path Discovery

   We assume that the discovery of existing TE paths, including their
   bandwidth, at the MPI is done using the generic TE tunnel YANG data
   model, defined in [I-D.ietf-teas-yang-te], 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 [I-D.ietf-teas-yang-te] but are 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 [I-D.ietf-teas-yang-te]
   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 TE path 1 in one
   direction (PE13-P16-PE14) and the TE path in the reverse direction
   (between PE14 and PE13) should be reported by the P-PNC1 to the MDSC
   as TE primary and primary-reverse paths of the same TE tunnel
   instance.  The bandwidth of these TE paths represents the bandwidth
   allocated by P-PNC1 to the two TE paths, which can be symmetric or
   asymmetric in the two directions.

Peruzzini, et al.        Expires 6 January 2025                [Page 31]
Internet-Draft                  ACTN POI                       July 2024

   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:

   *  Inter-domain Ethernet links supporting inter-domain IP links
      between two adjacent IP domains;

   *  Cross-technology Ethernet links between an an IP domain and an
      adjacent optical domain;

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

   All the three types of links are Ethernet links.

   It is worth noting that the P-PNC may not be aware whether an
   Ethernet interface terminates a cross-technology Ethernet link, an
   inter-domain Ethernet link or an access link.  The TE Topology Model
   supports the discovery for all these types of links with no need for
   the P-PNC to know the type of inter-domain link.

   There are two possible models to report the access links between CEs
   and PEs: the TE Topology Model, defined in [RFC8795], or the Service
   Attachment Points (SAP) Model, defined in [RFC9408].

   Although the discovery of access links is outside the scope of this
   document, clarifying the relationship between these two models has
   been identified as a gap.

   The inter-domain Ethernet links and cross-technology Ethernet links
   are discovered by the MDSC using the plug-id attribute, as described
   in section 4.3 of [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
   [I-D.ietf-ccamp-transport-nbi-app-statement].

   The plug-id attribute can also be used to discover the access-links,
   but the analysis of the access-link discovery is outside the scope of
   this document.

Peruzzini, et al.        Expires 6 January 2025                [Page 32]
Internet-Draft                  ACTN POI                       July 2024

   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.

   As outlined in [I-D.ietf-ccamp-transport-nbi-app-statement], 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 Ethernet links.  For the cross-technology
   Ethernet links, the automatic discovery solution based on LLDP
   snooping is preferable when possible.

   The routers exchange standard LLDP packets as defined in
   [IEEE_802.1AB] and the optical nodes 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 nodes do not actively participate in the LLDP
   packet exchange and does not send any LLDP packets.

4.5.1.  Cross-technology Ethernet link Discovery

   The MDSC can discover a cross-technology Ethernet link by matching
   the plug-id values of the two LTPs reported by 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 IP
   router while the O-PNC reports the LLDP information received by the
   corresponding Ethernet interface on the optical node, e.g., between
   LTP 5-0 on PE13 and LTP 7-0 on NE11, as shown in Figure 6.

Peruzzini, et al.        Expires 6 January 2025                [Page 33]
Internet-Draft                  ACTN POI                       July 2024

           +-----------------------------------------------------------+
          /             Ethernet Topology (P-PNC)                     /
         /    +-------------+                +-------------+         /
        /     |    PE13     |                |    BR11     |        /
       /      |             |                |             |       /
      /       |    (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 or OTN Topology (O-PNC)          /
   +----------------------------------------------------------+

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

             Figure 6: Cross-technology Ethernet link discovery

   As described in Section 4.1, the LTP terminating a cross-technology
   Ethernet link is reported by an O-PNC in the Ethernet topology or in
   the OTN topology model or in both models, depending on the type of
   corresponding physical port on the optical node.

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

Peruzzini, et al.        Expires 6 January 2025                [Page 34]
Internet-Draft                  ACTN POI                       July 2024

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

           +--------------------------+     +-------------------------+
          /  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){3}     |  /
     /       +-------------+   /    /         +-------------+ /
    / Eth. Topology (P-PNC 1) /    / Eth. Topology (P-PNC 2) /
   +-------------------------+    +-------------------------+

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

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

Peruzzini, et al.        Expires 6 January 2025                [Page 35]
Internet-Draft                  ACTN POI                       July 2024

           Figure 7: Inter-domain Ethernet and IP link discovery

   Different information is required to be encoded by the P-PNC within
   the plug-id attribute of the Ethernet LTPs to discover cross-
   technology Ethernet links and inter-domain Ethernet links.

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

   *  The physical Ethernet LTP (e.g., LTP 3-0 in BR11, as shown in
      Figure 7) is used to represent the physical adjacency between the
      Ethernet interface on an IP router and the Ethernet interface on
      its physically adjacent node, which can be either an IP router (in
      case of a single-technology Ethernet link) or an optical node (in
      case of a multi-technology Ethernet link).  Therefore, as
      described in Section 4.5.1, the P-PNC reports, within the plug-id
      attribute of this LTP, the LLDP information sent by the
      corresponding Ethernet interface on the IP router; such as the
      {BR11,3} and {BR21,4} plug-id values reported, respectively, by
      the Ethernet LTP 3-0 on BR11 and by the Ethernet LTP 4-0 on BR21,
      as shown in Figure 7;

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

   It is worth noting that in case of an inter-domain Ethernet links,
   the MDSC cannot discover, using the LLDP information reported in the
   plug-id attributes, the physical adjacency between the two Ethernet
   interfaces on physically adjacent IP routers, because these two plug-
   id values do not match, such as the plug-id values {BR11,3} and
   {BR21,4} shown in Figure 7.  However, the MDSC may infer the physical
   intra-domain Ethernet links if it knows a priori, using mechanisms
   which are outside the scope of this document, that the Ethernet
   interfaces on the IP routers either terminates a cross-technology
   link or a single-technology (intra-domain or inter-domain) Ethernet
   link, e.g., as shown in Figure 7.

Peruzzini, et al.        Expires 6 January 2025                [Page 36]
Internet-Draft                  ACTN POI                       July 2024

   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 Ethernet interfaces terminate 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 7.

4.6.  Multi-technology IP Link Discovery

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

           +-----------------------------------------------------------+
          /                    IP Topology (P-PNC 1)                  /
         /    +---------+                        +---------+         /
        /     |  PE13   |                        |   BR11  |        /
       /      |    (5-2)O<======================>O(6-2)    |       /
      /       |         |              |         |         |      /
     /        +---------+              |         +---------+     /
    /                                  |                        /
   +-----------------------------------|-----------------------+
                                       |
                                       | Supporting Link
                                       |
           +---------------------------|-------------------------------+
          / Ethernet Topology (P-PNC 1)|                              /
         /    +-------------+          |     +-------------+         /
        /     |    PE13     |          V     |    BR11     |        /
       /      |        (5-1)O<==============>O(6-1)        |       /
      /       |    (5-0)    |\              /|    (6-0)    |      /
     /        +------O------+|(*)        (*)|+------O------+     /
    /                ^ \<----+              +----->/^           /
   +-----------------:------------------------------:----------+
                     :                              :
                     :                              :
                     :                              :
           +---------:------------------------------:------------------+
          /          :   Ethernet or OTN Topology   :                 /
         /           V          (O-PNC 1)           V                /
        /     +------O------+    ETH/CBR     +------O------+        /

Peruzzini, et al.        Expires 6 January 2025                [Page 37]
Internet-Draft                  ACTN POI                       July 2024

       /      |    (7-0)    |  client sig.   |    (8-0)    |       /
      /       |      X----------+-------------------X      |      /
     /        |    NE11     |   |            |     NE12    |     /
    /         +-------------+   |            +-------------+    /
   +----------------------------|------------------------------+
                                | Underlay
                                | tunnel
                                |
            +----------------------------------------------------------+
           /        (7)         |                  (8)                /
          /         ---         |                  ---               /
         /    +-----\ /-----+   v            +-----\ /-----+        /
        /     |      V      |                |      V      |       /
       /      |      X======|================|======X      |      /
      /       |    NE11     |  Opt. Tunnel   |    NE12     |     /
     /        +-------------+                +-------------+    /
    /                   Optical Topology (O-PNC 1)             /
   +----------------------------------------------------------+

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

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

        Figure 8: Multi-technology intra-domain Ethernet and IP link
                                 discovery

   The P-PNC does not report any plug-id information on the logical
   Ethernet LTPs terminating intra-domain Ethernet links, such as the
   LTP 5-1 on PE13 and LTP 6-1 in BR11 shown in Figure 8, since these
   links are discovered by the PNC.

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

Peruzzini, et al.        Expires 6 January 2025                [Page 38]
Internet-Draft                  ACTN POI                       July 2024

   The MDSC discovers, using the mechanisms described in Section 4.5,
   which cross-technology Ethernet links support the multi-technology
   intra-domain Ethernet links, e.g., the link between LTP 5-0 on PE13
   and LTP 7-0 on NE11, shown in Figure 8.

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

4.6.1.  Intra-domain single-technology IP Links

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

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

Peruzzini, et al.        Expires 6 January 2025                [Page 39]
Internet-Draft                  ACTN POI                       July 2024

           +-----------------------------------------------------------+
          /                    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 9: Single-technology intra-domain Ethernet and IP link
                                 discovery

   It is worth noting that in case of an intra-domain single-technology
   Ethernet links, the MDSC cannot discover, using the LLDP information
   reported in the plug-id attributes, the physical adjacency between
   the two Ethernet interfaces on physically adjacent IP routers,
   because the two plug-id values do not match, such as the plug-id
   values {PE13,1} and {P16,2} shown in Figure 9.  However, the MDSC may

Peruzzini, et al.        Expires 6 January 2025                [Page 40]
Internet-Draft                  ACTN POI                       July 2024

   infer the physical intra-domain Ethernet links, e.g., between LTP 1-0
   on PE13 and LTP 2-0 on P16, as shown in Figure 9, if it knows a
   priori, using mechanisms which are outside the scope of this
   document, that all the Ethernet interfaces on the IP routers either
   terminates a cross-technology or a single-technology (intra-domain or
   inter-domain) Ethernet link, e.g., as shown in Figure 9.

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

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 10.  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:

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

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

Peruzzini, et al.        Expires 6 January 2025                [Page 41]
Internet-Draft                  ACTN POI                       July 2024

           +-----------------------------------------------------------+
          /                    IP Topology (P-PNC 2)                  /
         /    +---------+                        +---------+         /
        /     |  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 2)           /
   +---------------------------------------------------------+

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

                               Figure 10: LAG

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

   Instead, the mechanisms used by the MDSC to discover single-
   technology inter-domain LAG links between two BRs are different and
   outside the scope of this document since they do not imply any cross-
   technology 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 6 January 2025                [Page 42]
Internet-Draft                  ACTN POI                       July 2024

   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
   nodes on some cross-technology Ethernet links: one sent for the LLDP
   session configured at LAG member (Aggregation Port)level and another
   one for the LLDP session configured at LAG group (Aggregated
   Port)level.  This could cause some issues when LLDP snooping is used
   to discover the cross-technology Ethernet links, as defined in
   Section 4.5.1.

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

   To avoid any ambiguity on how the optical nodes can identify which
   LLDP packets belong to which LLDP session, the P-PNC can disable the
   LLDP sessions on the LAG groups configured by the MDSC (e.g., the
   multi-technology single-domain LAG groups configured using the
   mechanisms described in 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 node to identify which LLDP
   packets belong to which LLDP session: the O-PNC can then use only the
   LLDP information from the LLDP sessions configured on the LAG members
   to support the cross-technology Ethernet link discovery mechanisms
   defined in Section 4.5.1.

4.8.  L2/L3 VPN Network Services Discovery

   The P-PNC reports the L2/L3 VPN services configured within its
   domain, using the L2NM and L3NM network service models, and which
   packet TE tunnels (e.g., MPLS-TE or SR-TE) are used by each L2/L3 VPN
   service, using the L2NM and L3NM TE service mapping models.

   The MDSC can use the information mentioned above together with the
   packet TE path, packet topology, multi-technology IP links, optical
   topology and optical path information discovered as described in the
   previous sections, to discover the multi-technology path used to
   carry the traffic for each L2/L3 VPN service.

Peruzzini, et al.        Expires 6 January 2025                [Page 43]
Internet-Draft                  ACTN POI                       July 2024

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),
   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 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 and Figure 3, the MDSC
   finds that:

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

      -  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;

      -  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;

Peruzzini, et al.        Expires 6 January 2025                [Page 44]
Internet-Draft                  ACTN POI                       July 2024

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

   As described in 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:

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

   *  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:

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

   *  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 Equal Cost
      Multi-Path (ECMP), between PE13 and P16, as described in
      Section 5.2;

   *  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 constrain this
   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,

Peruzzini, et al.        Expires 6 January 2025                [Page 45]
Internet-Draft                  ACTN POI                       July 2024

   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.

   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, as described in Section 5.4.

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 described in Section 4.1, Section 4.5 and Section 4.6, there is a
   one-to-one relationship between a multi-layer intra-domain IP link
   and its underlay optical tunnel.  Therefore, the properties of an
   optical path between two optical TTPs, as computed by the O-PNC, can
   be used by the MDSC to infer the properties of the associated multi-
   layer single-domain IP link.

   As discussed in [I-D.ietf-teas-yang-path-computation], 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 [I-D.ietf-teas-yang-te] or via the
   path computation RPC defined in
   [I-D.ietf-teas-yang-path-computation].

   This draft assumes that the path computation RPC is used.

Peruzzini, et al.        Expires 6 January 2025                [Page 46]
Internet-Draft                  ACTN POI                       July 2024

   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-technology IP Link Setup

   As described in Section 5.1, there is a one-to-one relationship
   between a multi-technology intra-domain IP link and its underlay
   optical tunnel.

   Therefore, to setup a new multi-technology intra-domain IP link, the
   MDSC requires the O-PNC to setup the optical tunnel (using either the
   WDM Tunnel model or the OTN Tunnel model, if the optional OTN
   switching is supported) within the optical network and to steer the
   client traffic between the two cross-technology Ethernet links over
   that optical tunnel, using either the Ethernet Client Signal Model
   (for frame-based transport) or the Transparent CBR Client Signal
   Model (for transparent transport).

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

           +-----------------------------------------------------------+
          /                    IP Topology (P-PNC 1)                  /
         /    +---------+                        +---------+         /
        /     |  PE13   |                        |   BR11  |        /
       /      |    (5-2)O<======================>O(6-2)    |       /
      /       |         |              |         |         |      /
     /        +---------+              |         +---------+     /
    /                                  |                        /
   +-----------------------------------|-----------------------+
                                       |
                                       | Supporting Link
                                       |
           +---------------------------|-------------------------------+
          / Ethernet Topology (P-PNC 1)|                              /
         /    +-------------+          |     +-------------+         /
        /     |    PE13     |          V     |    BR11     |        /
       /      |        (5-1)O<==============>O(6-1)        |       /
      /       |    (5-0)    |\              /|    (6-0)    |      /
     /        +------O------+|(*)        (*)|+------O------+     /
    /                ^ \<----+              +----->/^           /
   +-----------------:------------------------------:----------+

Peruzzini, et al.        Expires 6 January 2025                [Page 47]
Internet-Draft                  ACTN POI                       July 2024

                     :                              :
                     :                              :
                     :                              :
           +---------:------------------------------:------------------+
          /          :   Ethernet or OTN Topology   :                 /
         /           V          (O-PNC 1)           V                /
        /     +------O------+    ETH/CBR     +------O------+        /
       /      |    (7-0)    |  client sig.   |    (8-0)    |       /
      /       |      X----------+-------------------X      |      /
     /        |    NE11     |   |            |     NE12    |     /
    /         +-------------+   |            +-------------+    /
   +----------------------------|------------------------------+
                                | Underlay
                                | tunnel
                                |
            +----------------------------------------------------------+
           /        (7)         |                  (8)                /
          /         ---         |                  ---               /
         /    +-----\ /-----+   v            +-----\ /-----+        /
        /     |      V      |                |      V      |       /
       /      |      X======|================|======X      |      /
      /       |    NE11     |  Opt. Tunnel   |    NE12     |     /
     /        +-------------+                +-------------+    /
    /                   Optical Topology (O-PNC 1)             /
   +----------------------------------------------------------+

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

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

                 Figure 11: Multi-technology IP link setup

   Note: Figure 11 is an exact copy of Figure 8.

Peruzzini, et al.        Expires 6 January 2025                [Page 48]
Internet-Draft                  ACTN POI                       July 2024

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

   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 IP routers' ports, the P-PNC can automatically
   discover the underlay multi-technology 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-technology single-domain Ethernet link at
   the MPI of the P-PNC.

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

   After the multi-technology single-domain Ethernet link has been
   configured by the MDSC or discovered by the P-PNC, the corresponding
   multi-technology single-domain IP link can also be configured either
   by the MDSC or 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-technology
   single-domain IP link as soon as the underlay multi-technology
   single-domain Ethernet link is either discovered by the P-PNC or
   configured by the MDSC at the MPI.  However, if LAG is supported the
   P-PNC has not enough information to know whether the discovered/
   configured multi-technology single-domain Ethernet link would be:

   1.  Used to support a multi-technology 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-
   technology 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-technology
   single-domain IP link, supported by the the just discovered or
   configured multi-technology single-domain Ethernet link, by creating

Peruzzini, et al.        Expires 6 January 2025                [Page 49]
Internet-Draft                  ACTN POI                       July 2024

   an IP link within the running datastore of the P-PNC MPI.  Only the
   IP link, IP LTPs and the reference to the supporting multi-technology
   single-domain Ethernet link are configured by the MDSC.  All the
   other configuration is provided by the P-PNC.

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

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

5.2.1.  Multi-technology 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-
   technology single-domain Ethernet link(s) being created, as described
   above.

   When a new LAG link is created, it is also recommended to configure
   the minimum number of active member links required to consider the
   LAG link as being up.  For example, a LAG link with three members can
   be considered up when only one member link fails and down when at
   least two member links fail.

   The attribute required to configure the minimum number of active
   member links is missing in [I-D.ietf-ccamp-eth-client-te-topo-yang]
   and this is identified as a gap in Section 6.

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

   For example, with a reference to Figure 10, 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-
   technology single-domain Ethernet link between the Ethernet 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.

Peruzzini, et al.        Expires 6 January 2025                [Page 50]
Internet-Draft                  ACTN POI                       July 2024

   The MDSC can request the P-PNC to configure a new multi-technology
   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 10, the MDSC can request the
   P-PNC2 to setup a multi-technology single-domain IP Link between IP
   LTP 5-2 on BR21 and IP LTP 6-2 on P24 supported by the Ethernet
   bundle link between ETH LTP 5-1 on BR21 and the Ethernet LTP 6-1 on
   P24.

5.2.2.  Multi-technology 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-technology single-domain Ethernet link(s) being
   created, as described above.

   When member links are added or removed from a LAG link, the minimum
   number of active member links required to consider the LAG link as
   being up may also need to be updated.

   For example, with a reference to Figure 10, the MDSC can request the
   P-PNC2 to add the multi-technology single-domain Ethernet link setup
   between the Ethernet 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-technology single-
   domain IP link supported by the updated Ethernet bundled link.

5.2.3.  Multi-technology TE path properties Configuration

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

   *  the IP LTPs terminating the multi-technology IP link (e.g., the
      list of SRLGs reported by the P-PNC using the packet TE topology
      model);

   *  the optical path (e.g., the list of SRLGs reported by the O-PNC
      using the WDM or OTN tunnel model); and

   *  the cross-domain links (e.g., the list of SRLGs reported by the
      O-PNC and P-PNC respectively, using the WSON and/or flexi-grid,
      the OTN and the packet TE topology models).

Peruzzini, et al.        Expires 6 January 2025                [Page 51]
Internet-Draft                  ACTN POI                       July 2024

   The MDSC can also report this information to the P-PNC by properly
   configuring the multi-technology IP link properties using the packet
   TE topology model at the packet PNC MPI.

   This information is used by the P-PNC at least when computing the
   local protection path, as described in Section 5.3, e.g., to ensure
   that the local protection path is SRLG disjoint with the primary
   path.

   It is worth noting that the list of SRLGs for a multi-technology IP
   link can be quite long.  Implementation-specific mechanisms can be
   implemented by the MDSC or by the O-PNC to summarize the SRLGs of an
   optical tunnel.  These mechanisms are implementation-specific and
   have no impact on the YANG models nor on the interoperability at the
   MPI, 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 [I-D.ietf-teas-yang-te], with packet technology-specific
   augmentations, described in Section 3.2.3.

   When a new TE path needs to be setup, the MDSC can use the
   [I-D.ietf-teas-yang-te] 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 [I-D.ietf-teas-yang-te] model supports requesting the setup of
   both end-to-end as well as segment TE tunnels (within one domain).

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

   For example, the SR-TE specific augmentations of the
   [I-D.ietf-teas-yang-te] 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 IP router or P-PNC rebooting.

Peruzzini, et al.        Expires 6 January 2025                [Page 52]
Internet-Draft                  ACTN POI                       July 2024

   The MDSC can also use the [I-D.ietf-teas-yang-te] 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
   [I-D.ietf-teas-yang-te] model supports both symmetric and asymmetric
   bandwidth configuration in the two directions.

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

   The MDSC also request the P-PNC to configure local protection
   mechanisms.  For example, the FRR local protection, as defined in
   [RFC4090] in case of MPLS-TE domain or the TI-LFA local protection,
   as defined in [I-D.ietf-rtgwg-segment-routing-ti-lfa] in case of SR-
   TE domain.  The mechanisms to request the configuration TI-LFA local
   protection for SR-TE paths using the [I-D.ietf-teas-yang-te] are a
   gap in the current YANG models.

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

   The P-PNC takes into account the multi-layer TE path properties
   (e.g., SRLG information), configured by the MDSC as described in
   Section 5.2.3, when computing the protection configuration (e.g., in
   case of SR-TE domains, the TI-LFA post-convergence path or, in case
   of MPLS-TE domain, the FRR backup tunnel) for multi-technology
   single-domain IP links.

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

5.4.  L2/L3 VPN Network Service Setup

   The MDSC can use the L2NM and L3NM network service models to request
   the P-PNCs to setup L2/L3 VPN services and the L2NM and L3NM TE
   service mapping models to request the P-PNCs to configure the PE
   routers to steer the L2/L3 VPN traffic to the selected TE tunnels
   (e.g., MPLS-TE or SR-TE).

   It is worth noting that the L2NM and L3NM TE service mapping models,
   defined in [I-D.ietf-teas-te-service-mapping-yang], provide a list of
   TE tunnel(s) that should be used to forward L2/L3 VPN traffic between
   the two PEs terminating the listed TE tunnel(s).  If the list
   contains more than one TE tunnel for the same pair of PEs, these TE
   tunnels are used for load balancing the associated L2/L3 VPN traffic
   between the same set of two PEs.

Peruzzini, et al.        Expires 6 January 2025                [Page 53]
Internet-Draft                  ACTN POI                       July 2024

   The possibility to request splitting the traffic, between multiple TE
   tunnels for the same PEs pair, in a different way than load balancing
   is identified as a gap requiring further work and 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:

   *  how both WSON and Flexi-grid topology models could be used
      together (through multi-inheritance): this gap has been identified
      in Section 4.1;.

   *  network inventory model: this gap has been identified in
      Section 4.9 and the solution in
      [I-D.ietf-ivy-network-inventory-yang] has been proposed to resolve
      it;

   *  technology-specific augmentations of the path computation RPC,
      defined in [I-D.ietf-teas-yang-path-computation] for optical
      networks: this gap has been identified in Section 5.1 and the
      solution in [I-D.ietf-ccamp-optical-path-computation-yang] has
      been proposed to resolve it;

   *  relationship between a common discovery mechanisms applicable to
      access links, inter-domain IP links and cross-technology Ethernet
      links and the UNI topology discover mechanism defined in
      [RFC9408]: this gap has been identified in Section 4.3;

   *  a mechanism applicable to the P-PNC NBI to configure the SR-TE
      paths.  Technology-specific augmentations of TE Tunnel model,
      defined in [I-D.ietf-teas-yang-te], are foreseen in section 1 of
      [I-D.ietf-teas-yang-te] but not yet defined: this gap has been
      identified in Section 5.3;

   *  an attribute, which is used to configure the minimum number of
      active member links required to consider the LAG link as being up,
      is missing from the topology model defined in
      [I-D.ietf-ccamp-eth-client-te-topo-yang]: this gap has been
      identified in Section 5.2.1;

Peruzzini, et al.        Expires 6 January 2025                [Page 54]
Internet-Draft                  ACTN POI                       July 2024

   *  a mechanism to configure splitting the L2/L3 VPN traffic, between
      multiple TE tunnels for the same PEs pair, in a different way than
      load balancing: this gap has been identified in Section 5.4;

   *  a mechanism to report client connectivity constraints imposed by
      some muxponder design: this gap has been identified in
      Appendix A.3.

   Although not applicable to this document, it has been noted that
   being able to use WSON and Flexi-grid topology models together
   (through multi-inheritance) is not only useful in cases of mixed
   fixed-grid and flexible-grid DWDM network topology but also the only
   viable option in case of a mixed CWDM and DWDM network topology.

   Although not applicable to this document, it has been noted that the
   WDM tunnel model would support also optical tunnel setup in case of a
   mixed CWDM and DWDM network topology.

   Although not analysed in this document, it has been noted that the TE
   Tunnel model, defined in [I-D.ietf-teas-yang-te], needs also to be
   enhanced to support scenarios where multiple parallel TE paths are
   used in load-balancing to carry the traffic between two end-points
   (e.g., VPN traffic between two PEs).

7.  Security Considerations

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

   *  RESTCONF

   *  NETCONF

   *  PCEP

   *  YANG

Peruzzini, et al.        Expires 6 January 2025                [Page 55]
Internet-Draft                  ACTN POI                       July 2024

   Several existing authentication and encryption practices and
   techniques may be used to help secure these MPI interfaces.  These
   mechanisms include using Transport Layer Security (TLS) to provide
   secure transport for RESTCONF, NETCONF and PCEP.  Furthermore, access
   control techniques can also provide additional security.  NETCONF
   supports an Access Control Model (NACM), and RESCONF supports Role
   Based Access Control (RBAC), which should also ensure that MDSC to
   PNC communication is based on authorised use and granular control of
   connectivity and resource requests.

7.1.  LLDP Snooping Security Considerations

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

   *  Eavesdropping: LLDP transmissions are not encrypted.  Potentially,
      LLDP packets could be captured using a packet sniffer.  An
      attacker can leverage this information to gain insights into the
      network topology, device types, and configurations, which could be
      used for further attacks;

   *  Unauthorized Access: Information disclosed by LLDP can include
      device types, software versions, and network configuration
      details.  This might help an attacker identify vulnerable devices
      or configurations that can be exploited to gain unauthorized
      access or escalate privileges within the network;

   *  Data Manipulation: If an attacker gains access to a network
      device, they could manipulate LLDP information to advertise false
      device information, leading to potential misconfigurations or
      trust relationships being exploited.  This can disrupt network
      operations or redirect traffic to malicious devices;

   *  Denial of Service (DoS): By flooding the network with fake LLDP
      packets, an attacker could overwhelm network devices or management
      systems, potentially leading to a denial of service where
      legitimate network traffic is disrupted;

   *  Spoofing: An attacker could spoof LLDP packets to impersonate
      other network devices.  Potentially, this might lead to incorrect
      network mappings or trust relationships being established with
      malicious devices;

   *  Lack of Authentication: LLDP does not include mechanisms for
      authenticating the source of LLDP messages, which means that
      devices accept LLDP information from any source as legitimate.

Peruzzini, et al.        Expires 6 January 2025                [Page 56]
Internet-Draft                  ACTN POI                       July 2024

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

   *  Disabling LLDP on ports where it is not needed, especially those
      facing untrusted networks;

   *  Using network segmentation and Access Control Lists (ACLs) to
      limit who can send and receive LLDP packets;

   *  Employing network monitoring and anomaly detection systems to
      identify unusual LLDP traffic patterns that may indicate an
      attack;

   *  Regularly updating and patching network devices to address known
      vulnerabilities that could be exploited through information
      gathered via LLDP.

8.  Operational Considerations

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

   *  Network Design and Capacity Planning: Deciding the degree of
      integration between the packet and optical layers is critical.
      Furthermore, this includes determining whether to pursue a loose
      integration (keeping layers distinct but coordinated) or a tight
      integration (combining layers more closely, potentially at the
      hardware level) coordinated via the MDSC.  Accurate forecasting
      and planning will also be essential to ensure that the integrated
      ACTN infrastructure can handle future capacity demand without
      excessive over-provisioning;

   *  System Interoperability: Networks often comprise equipment from
      various vendors.  Ensuring that packet and optical devices can
      interoperate seamlessly and the PNCs can manage them is crucial
      for a successful integration.  The Service Provider must also
      check with the vendors to ensure they support the IETF-based
      technologies outlined in this document;

Peruzzini, et al.        Expires 6 January 2025                [Page 57]
Internet-Draft                  ACTN POI                       July 2024

   *  Performance Monitoring: The integrated POI network will require
      comprehensive monitoring solutions that can provide visibility to
      the PNCs across both packet and optical layers.  Identifying and
      diagnosing issues may become more complex with integrated layers.
      Telemetry data may also be required to collect lower-layer
      networking health and consider network and service performance.
      This topic is further discussed in [ACTN Assurance];

   *  Fault Management and Recovery: The POI networks should be
      resilient, including considerations for automatic protection
      switching and fast reroute mechanisms that span both layers.
      Fault isolation and recovery may become more challenging, as
      issues in one layer can have cascading effects on the other.
      Effective fault management strategies must be in place to quickly
      identify and rectify such issues.  This topic is further discussed
      in [ACTN Assurance];

   Specific Security Considerations are discussed in Section 7.

9.  IANA Considerations

   This document requires no IANA actions.

10.  References

10.1.  Normative References

   [I-D.ietf-ccamp-client-signal-yang]
              Zheng, H., Guo, A., Busi, I., Snitser, A., and C. Yu, "A
              YANG Data Model for Transport Network Client Signals",
              Work in Progress, Internet-Draft, draft-ietf-ccamp-client-
              signal-yang-12, 29 January 2024,
              <https://datatracker.ietf.org/doc/html/draft-ietf-ccamp-
              client-signal-yang-12>.

   [I-D.ietf-ccamp-eth-client-te-topo-yang]
              Yu, C., Zheng, H., Guo, A., Busi, I., Xu, Y., Zhao, Y.,
              and X. Liu, "A YANG Data Model for Ethernet TE Topology",
              Work in Progress, Internet-Draft, draft-ietf-ccamp-eth-
              client-te-topo-yang-06, 12 April 2024,
              <https://datatracker.ietf.org/doc/html/draft-ietf-ccamp-
              eth-client-te-topo-yang-06>.

Peruzzini, et al.        Expires 6 January 2025                [Page 58]
Internet-Draft                  ACTN POI                       July 2024

   [I-D.ietf-ccamp-flexigrid-yang]
              de Madrid, U. A., Burrero, D. P., King, D., Lee, Y., and
              H. Zheng, "A YANG Data Model for Flexi-Grid Optical
              Networks", Work in Progress, Internet-Draft, draft-ietf-
              ccamp-flexigrid-yang-16, 29 January 2024,
              <https://datatracker.ietf.org/doc/html/draft-ietf-ccamp-
              flexigrid-yang-16>.

   [I-D.ietf-ccamp-otn-topo-yang]
              Zheng, H., Busi, I., Liu, X., Belotti, S., and O. G. de
              Dios, "A YANG Data Model for Optical Transport Network
              Topology", Work in Progress, Internet-Draft, draft-ietf-
              ccamp-otn-topo-yang-19, 25 June 2024,
              <https://datatracker.ietf.org/doc/html/draft-ietf-ccamp-
              otn-topo-yang-19>.

   [I-D.ietf-ccamp-otn-tunnel-model]
              Zheng, H., Busi, I., Belotti, S., Lopez, V., and Y. Xu,
              "OTN Tunnel YANG Model", Work in Progress, Internet-Draft,
              draft-ietf-ccamp-otn-tunnel-model-21, 6 June 2024,
              <https://datatracker.ietf.org/doc/html/draft-ietf-ccamp-
              otn-tunnel-model-21>.

   [I-D.ietf-ccamp-wdm-tunnel-yang]
              Guo, A., Belotti, S., Galimberti, G., de Madrid, U. A.,
              and D. P. Burrero, "A YANG Data Model for WDM Tunnels",
              Work in Progress, Internet-Draft, draft-ietf-ccamp-wdm-
              tunnel-yang-01, 1 March 2024,
              <https://datatracker.ietf.org/doc/html/draft-ietf-ccamp-
              wdm-tunnel-yang-01>.

   [I-D.ietf-teas-yang-l3-te-topo]
              Liu, X., Bryskin, I., Beeram, V. P., Saad, T., Shah, H.
              C., and O. G. de Dios, "YANG Data Model for Layer 3 TE
              Topologies", Work in Progress, Internet-Draft, draft-ietf-
              teas-yang-l3-te-topo-17, 23 June 2024,
              <https://datatracker.ietf.org/doc/html/draft-ietf-teas-
              yang-l3-te-topo-17>.

   [I-D.ietf-teas-yang-path-computation]
              Busi, I., Belotti, S., de Dios, O. G., Sharma, A., and Y.
              Shi, "A YANG Data Model for requesting path computation",
              Work in Progress, Internet-Draft, draft-ietf-teas-yang-
              path-computation-22, 14 February 2024,
              <https://datatracker.ietf.org/doc/html/draft-ietf-teas-
              yang-path-computation-22>.

Peruzzini, et al.        Expires 6 January 2025                [Page 59]
Internet-Draft                  ACTN POI                       July 2024

   [I-D.ietf-teas-yang-sr-te-topo]
              Liu, X., Bryskin, I., Beeram, V. P., Saad, T., Shah, H.
              C., and S. Litkowski, "YANG Data Model for SR and SR TE
              Topologies on MPLS Data Plane", Work in Progress,
              Internet-Draft, draft-ietf-teas-yang-sr-te-topo-19, 4 July
              2024, <https://datatracker.ietf.org/doc/html/draft-ietf-
              teas-yang-sr-te-topo-19>.

   [I-D.ietf-teas-yang-te]
              Saad, T., Gandhi, R., Liu, X., Beeram, V. P., and I.
              Bryskin, "A YANG Data Model for Traffic Engineering
              Tunnels, Label Switched Paths and Interfaces", Work in
              Progress, Internet-Draft, draft-ietf-teas-yang-te-36, 2
              February 2024, <https://datatracker.ietf.org/doc/html/
              draft-ietf-teas-yang-te-36>.

   [I-D.ietf-teas-yang-te-mpls]
              Saad, T., Gandhi, R., Liu, X., Beeram, V. P., and I.
              Bryskin, "A YANG Data Model for MPLS Traffic Engineering
              Tunnels", Work in Progress, Internet-Draft, draft-ietf-
              teas-yang-te-mpls-04, 26 May 2023,
              <https://datatracker.ietf.org/doc/html/draft-ietf-teas-
              yang-te-mpls-04>.

   [I-D.ietf-teas-yang-te-mpls-topology]
              Busi, I., Guo, A., Liu, X., Saad, T., and R. Gandhi, "A
              YANG Data Model for MPLS-TE Topology", Work in Progress,
              Internet-Draft, draft-ietf-teas-yang-te-mpls-topology-00,
              18 March 2024, <https://datatracker.ietf.org/doc/html/
              draft-ietf-teas-yang-te-mpls-topology-00>.

   [IEEE_802.1AB]
              Institute of Electrical and Electronics Engineers, "IEEE
              Standard for Local and metropolitan area networks -
              Station and Media Access Control Connectivity Discovery",
              IEEE 802.1AB-2016 , March 2016,
              <https://ieeexplore.ieee.org/document/7433915>.

   [IEEE_802.1AX]
              Institute of Electrical and Electronics Engineers, "IEEE
              Standard for Local and metropolitan area networks - Link
              Aggregation", IEEE 802.1AX-2014 , December 2014,
              <https://ieeexplore.ieee.org/document/7055197>.

Peruzzini, et al.        Expires 6 January 2025                [Page 60]
Internet-Draft                  ACTN POI                       July 2024

   [ITU-T_G.694.1]
              International Telecommunication Union, "Spectral grids for
              WDM applications: DWDM frequency grid", ITU-T
              Recommendation G.694.1 , October 2020,
              <https://www.itu.int/rec/T-REC-G.694.1-202010-I>.

   [RFC5212]  Shiomoto, K., Papadimitriou, D., Le Roux, JL., Vigoureux,
              M., and D. Brungard, "Requirements for GMPLS-Based Multi-
              Region and Multi-Layer Networks (MRN/MLN)", RFC 5212,
              DOI 10.17487/RFC5212, July 2008,
              <https://www.rfc-editor.org/rfc/rfc5212>.

   [RFC7923]  Voit, E., Clemm, A., and A. Gonzalez Prieto, "Requirements
              for Subscription to YANG Datastores", RFC 7923,
              DOI 10.17487/RFC7923, June 2016,
              <https://www.rfc-editor.org/rfc/rfc7923>.

   [RFC7950]  Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language",
              RFC 7950, DOI 10.17487/RFC7950, August 2016,
              <https://www.rfc-editor.org/rfc/rfc7950>.

   [RFC7951]  Lhotka, L., "JSON Encoding of Data Modeled with YANG",
              RFC 7951, DOI 10.17487/RFC7951, August 2016,
              <https://www.rfc-editor.org/rfc/rfc7951>.

   [RFC8040]  Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
              Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017,
              <https://www.rfc-editor.org/rfc/rfc8040>.

   [RFC8342]  Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K.,
              and R. Wilton, "Network Management Datastore Architecture
              (NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018,
              <https://www.rfc-editor.org/rfc/rfc8342>.

   [RFC8345]  Clemm, A., Medved, J., Varga, R., Bahadur, N.,
              Ananthakrishnan, H., and X. Liu, "A YANG Data Model for
              Network Topologies", RFC 8345, DOI 10.17487/RFC8345, March
              2018, <https://www.rfc-editor.org/rfc/rfc8345>.

   [RFC8346]  Clemm, A., Medved, J., Varga, R., Liu, X.,
              Ananthakrishnan, H., and N. Bahadur, "A YANG Data Model
              for Layer 3 Topologies", RFC 8346, DOI 10.17487/RFC8346,
              March 2018, <https://www.rfc-editor.org/rfc/rfc8346>.

   [RFC8453]  Ceccarelli, D., Ed. and Y. Lee, Ed., "Framework for
              Abstraction and Control of TE Networks (ACTN)", RFC 8453,
              DOI 10.17487/RFC8453, August 2018,
              <https://www.rfc-editor.org/rfc/rfc8453>.

Peruzzini, et al.        Expires 6 January 2025                [Page 61]
Internet-Draft                  ACTN POI                       July 2024

   [RFC8525]  Bierman, A., Bjorklund, M., Schoenwaelder, J., Watsen, K.,
              and R. Wilton, "YANG Library", RFC 8525,
              DOI 10.17487/RFC8525, March 2019,
              <https://www.rfc-editor.org/rfc/rfc8525>.

   [RFC8527]  Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K.,
              and R. Wilton, "RESTCONF Extensions to Support the Network
              Management Datastore Architecture", RFC 8527,
              DOI 10.17487/RFC8527, March 2019,
              <https://www.rfc-editor.org/rfc/rfc8527>.

   [RFC8641]  Clemm, A. and E. Voit, "Subscription to YANG Notifications
              for Datastore Updates", RFC 8641, DOI 10.17487/RFC8641,
              September 2019, <https://www.rfc-editor.org/rfc/rfc8641>.

   [RFC8650]  Voit, E., Rahman, R., Nilsen-Nygaard, E., Clemm, A., and
              A. Bierman, "Dynamic Subscription to YANG Events and
              Datastores over RESTCONF", RFC 8650, DOI 10.17487/RFC8650,
              November 2019, <https://www.rfc-editor.org/rfc/rfc8650>.

   [RFC8795]  Liu, X., Bryskin, I., Beeram, V., Saad, T., Shah, H., and
              O. Gonzalez de Dios, "YANG Data Model for Traffic
              Engineering (TE) Topologies", RFC 8795,
              DOI 10.17487/RFC8795, August 2020,
              <https://www.rfc-editor.org/rfc/rfc8795>.

   [RFC9094]  Zheng, H., Lee, Y., Guo, A., Lopez, V., and D. King, "A
              YANG Data Model for Wavelength Switched Optical Networks
              (WSONs)", RFC 9094, DOI 10.17487/RFC9094, August 2021,
              <https://www.rfc-editor.org/rfc/rfc9094>.

10.2.  Informative References

   [I-D.ietf-ccamp-optical-impairment-topology-yang]
              Beller, D., Le Rouzic, E., Belotti, S., Galimberti, G.,
              and I. Busi, "A YANG Data Model for Optical Impairment-
              aware Topology", Work in Progress, Internet-Draft, draft-
              ietf-ccamp-optical-impairment-topology-yang-16, 5 July
              2024, <https://datatracker.ietf.org/doc/html/draft-ietf-
              ccamp-optical-impairment-topology-yang-16>.

   [I-D.ietf-ccamp-optical-path-computation-yang]
              Busi, I., Guo, A., and S. Belotti, "YANG Data Models for
              requesting Path Computation in WDM Optical Networks", Work
              in Progress, Internet-Draft, draft-ietf-ccamp-optical-
              path-computation-yang-03, 1 March 2024,
              <https://datatracker.ietf.org/doc/html/draft-ietf-ccamp-
              optical-path-computation-yang-03>.

Peruzzini, et al.        Expires 6 January 2025                [Page 62]
Internet-Draft                  ACTN POI                       July 2024

   [I-D.ietf-ccamp-transport-nbi-app-statement]
              Busi, I., King, D., Zheng, H., and Y. Xu, "Transport
              Northbound Interface Applicability Statement", Work in
              Progress, Internet-Draft, draft-ietf-ccamp-transport-nbi-
              app-statement-17, 10 July 2023,
              <https://datatracker.ietf.org/doc/html/draft-ietf-ccamp-
              transport-nbi-app-statement-17>.

   [I-D.ietf-ivy-network-inventory-yang]
              Yu, C., Belotti, S., Bouquier, J., Peruzzini, F., and P.
              Bedard, "A YANG Data Model for Network Inventory", Work in
              Progress, Internet-Draft, draft-ietf-ivy-network-
              inventory-yang-01, 4 March 2024,
              <https://datatracker.ietf.org/doc/html/draft-ietf-ivy-
              network-inventory-yang-01>.

   [I-D.ietf-rtgwg-segment-routing-ti-lfa]
              Bashandy, A., Litkowski, S., Filsfils, C., Francois, P.,
              Decraene, B., and D. Voyer, "Topology Independent Fast
              Reroute using Segment Routing", Work in Progress,
              Internet-Draft, draft-ietf-rtgwg-segment-routing-ti-lfa-
              16, 29 June 2024, <https://datatracker.ietf.org/doc/html/
              draft-ietf-rtgwg-segment-routing-ti-lfa-16>.

   [I-D.ietf-teas-actn-vn-yang]
              Lee, Y., Dhody, D., Ceccarelli, D., Bryskin, I., and B. Y.
              Yoon, "A YANG Data Model for Virtual Network (VN)
              Operations", Work in Progress, Internet-Draft, draft-ietf-
              teas-actn-vn-yang-29, 22 June 2024,
              <https://datatracker.ietf.org/doc/html/draft-ietf-teas-
              actn-vn-yang-29>.

   [I-D.ietf-teas-te-service-mapping-yang]
              Lee, Y., Dhody, D., Fioccola, G., Wu, Q., Ceccarelli, D.,
              and J. Tantsura, "Traffic Engineering (TE) and Service
              Mapping YANG Data Model", Work in Progress, Internet-
              Draft, draft-ietf-teas-te-service-mapping-yang-15, 16
              March 2024, <https://datatracker.ietf.org/doc/html/draft-
              ietf-teas-te-service-mapping-yang-15>.

   [I-D.ietf-teas-te-topology-profiles]
              Busi, I., Liu, X., Bryskin, I., Saad, T., and O. G. de
              Dios, "Profiles for Traffic Engineering (TE) Topology Data
              Model and Applicability to non-TE Use Cases", Work in
              Progress, Internet-Draft, draft-ietf-teas-te-topology-
              profiles-01, 19 April 2024,
              <https://datatracker.ietf.org/doc/html/draft-ietf-teas-te-
              topology-profiles-01>.

Peruzzini, et al.        Expires 6 January 2025                [Page 63]
Internet-Draft                  ACTN POI                       July 2024

   [RFC1930]  Hawkinson, J. and T. Bates, "Guidelines for creation,
              selection, and registration of an Autonomous System (AS)",
              BCP 6, RFC 1930, DOI 10.17487/RFC1930, March 1996,
              <https://www.rfc-editor.org/rfc/rfc1930>.

   [RFC4090]  Pan, P., Ed., Swallow, G., Ed., and A. Atlas, Ed., "Fast
              Reroute Extensions to RSVP-TE for LSP Tunnels", RFC 4090,
              DOI 10.17487/RFC4090, May 2005,
              <https://www.rfc-editor.org/rfc/rfc4090>.

   [RFC5440]  Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation
              Element (PCE) Communication Protocol (PCEP)", RFC 5440,
              DOI 10.17487/RFC5440, March 2009,
              <https://www.rfc-editor.org/rfc/rfc5440>.

   [RFC5623]  Oki, E., Takeda, T., Le Roux, JL., and A. Farrel,
              "Framework for PCE-Based Inter-Layer MPLS and GMPLS
              Traffic Engineering", RFC 5623, DOI 10.17487/RFC5623,
              September 2009, <https://www.rfc-editor.org/rfc/rfc5623>.

   [RFC8231]  Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path
              Computation Element Communication Protocol (PCEP)
              Extensions for Stateful PCE", RFC 8231,
              DOI 10.17487/RFC8231, September 2017,
              <https://www.rfc-editor.org/rfc/rfc8231>.

   [RFC8277]  Rosen, E., "Using BGP to Bind MPLS Labels to Address
              Prefixes", RFC 8277, DOI 10.17487/RFC8277, October 2017,
              <https://www.rfc-editor.org/rfc/rfc8277>.

   [RFC8281]  Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path
              Computation Element Communication Protocol (PCEP)
              Extensions for PCE-Initiated LSP Setup in a Stateful PCE
              Model", RFC 8281, DOI 10.17487/RFC8281, December 2017,
              <https://www.rfc-editor.org/rfc/rfc8281>.

   [RFC8283]  Farrel, A., Ed., Zhao, Q., Ed., Li, Z., and C. Zhou, "An
              Architecture for Use of PCE and the PCE Communication
              Protocol (PCEP) in a Network with Central Control",
              RFC 8283, DOI 10.17487/RFC8283, December 2017,
              <https://www.rfc-editor.org/rfc/rfc8283>.

   [RFC8309]  Wu, Q., Liu, W., and A. Farrel, "Service Models
              Explained", RFC 8309, DOI 10.17487/RFC8309, January 2018,
              <https://www.rfc-editor.org/rfc/rfc8309>.

Peruzzini, et al.        Expires 6 January 2025                [Page 64]
Internet-Draft                  ACTN POI                       July 2024

   [RFC8637]  Dhody, D., Lee, Y., and D. Ceccarelli, "Applicability of
              the Path Computation Element (PCE) to the Abstraction and
              Control of TE Networks (ACTN)", RFC 8637,
              DOI 10.17487/RFC8637, July 2019,
              <https://www.rfc-editor.org/rfc/rfc8637>.

   [RFC8751]  Dhody, D., Lee, Y., Ceccarelli, D., Shin, J., and D. King,
              "Hierarchical Stateful Path Computation Element (PCE)",
              RFC 8751, DOI 10.17487/RFC8751, March 2020,
              <https://www.rfc-editor.org/rfc/rfc8751>.

   [RFC9182]  Barguil, S., Gonzalez de Dios, O., Ed., Boucadair, M.,
              Ed., Munoz, L., and A. Aguado, "A YANG Network Data Model
              for Layer 3 VPNs", RFC 9182, DOI 10.17487/RFC9182,
              February 2022, <https://www.rfc-editor.org/rfc/rfc9182>.

   [RFC9291]  Boucadair, M., Ed., Gonzalez de Dios, O., Ed., Barguil,
              S., and L. Munoz, "A YANG Network Data Model for Layer 2
              VPNs", RFC 9291, DOI 10.17487/RFC9291, September 2022,
              <https://www.rfc-editor.org/rfc/rfc9291>.

   [RFC9408]  Boucadair, M., Ed., Gonzalez de Dios, O., Barguil, S., Wu,
              Q., and V. Lopez, "A YANG Network Data Model for Service
              Attachment Points (SAPs)", RFC 9408, DOI 10.17487/RFC9408,
              June 2023, <https://www.rfc-editor.org/rfc/rfc9408>.

Appendix A.  Additional Scenarios

A.1.  OSS/Orchestration Layer

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

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

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

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

Peruzzini, et al.        Expires 6 January 2025                [Page 65]
Internet-Draft                  ACTN POI                       July 2024

   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.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 12 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
   [I-D.ietf-teas-actn-vn-yang], [RFC9291], [RFC9182] and
   [I-D.ietf-teas-te-service-mapping-yang].

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

                     Figure 12: Service Request Process

Peruzzini, et al.        Expires 6 January 2025                [Page 66]
Internet-Draft                  ACTN POI                       July 2024

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

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

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

   *  The L2NM and L3NM YANG data models, defined in [RFC9291] 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.

   *  The TE & Service Mapping YANG data model
      [I-D.ietf-teas-te-service-mapping-yang] provides TE-service
      mapping.

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

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

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

A.2.  Multi-layer and Multi-domain Resiliency

A.2.1.  Maintenance Window

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

Peruzzini, et al.        Expires 6 January 2025                [Page 67]
Internet-Draft                  ACTN POI                       July 2024

   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.

A.2.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 the IP router port side or on the muxponder side or on the
   link between them).  When client-side port failure occurs, alarms are
   raised to MDSC by IP-PNC and O-PNC (port status down, LOS etc.).
   MDSC checks with OP-PNC(s) that there is no optical failure in the
   optical layer.

   There can be two cases here:

   1.  LAG was defined between the IP routers at the two ends.  MDSC,
       after checking that optical layer is fine between the two edge
       WDM nodes, triggers the WDM edge node re-configuration so that
       the IP router's back-up port with its associated muxponder port
       can reuse the WDM tunnel that was already in use previously by
       the failed IP router port and adds the new link to the LAG on the
       failure side.

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

       Note: in this LAG scenario 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.

   2.  If there is no LAG then the scenario is not clear since a IP
       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 IP router and of the
       muxponder to re-use the same WDM tunnel as the one used
       originally for the failed IP router port.  Once everything has
       been correctly configured, MDSC Global PCE could suggest to the

Peruzzini, et al.        Expires 6 January 2025                [Page 68]
Internet-Draft                  ACTN POI                       July 2024

       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 IP router and the original WDM tunnel if overall
       cost, latency etc. is improved.  However, in this scenario, there
       is a need for protection port PLUS back-up port in the IP router
       which does not lead to clear port savings.

A.3.  Muxponders

   The setup of a client connectivity service between two transponders
   is relatively clear and its implementation simple.

   There is a one to one relationship between the tranponder's client
   and trunk (or DWDM) port.  The client port bitrate determines the
   trunk port bit rate which will also determine the Baud-rate, the
   modulation format, the FEC etc.

   The controller, when asked to set up a client connectivity service,
   needs to find a WDM tunnel suitable to comply the DWDM port
   parameters.

   The setup of a client connectivity service between two muxponders is
   different since there is a one to many relationship between the
   muxponder's trunk (or DWDM) port and client ports.  For example,
   there might be a 100Gb/s trunk port shared by ten 10GE client ports.

   The controller, when asked to set a 10GE client connectivity service
   between two muxponder's client ports, needs first to check whether
   there is already an existing WDM tunnel between the two muxponders
   and then take different actions:

   1.  if the WDM tunnel already exists, the controller needs only to
       enable the 10GE client ports to establish the 10GE client
       connectivity service;

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

   Since multiple client connectivity services are sharing the same WDM
   tunnel, a multiplexing label shall be assigned to each client
   connectivity service.  The multiplexing label can either be a
   standard label (e.g., an OTN timeslot) or a vendor-specific label.
   The multiplexing label can be either configurable (flexible
   configuration) or assigned by design to each muxponder's client port
   (fixed configuration).  In the former case, any muxponder client port

Peruzzini, et al.        Expires 6 January 2025                [Page 69]
Internet-Draft                  ACTN POI                       July 2024

   can be connected with any other client port of the peer muxponder
   (for example client port 1 on one muxponder can be connected with
   client port 5 on the peer muxponder) while in the latter case only
   client ports with the same port number can be connected (for example
   client port 2 on one muxponder can be connected only with client port
   2 on the peer muxponder and not with any other client port).

   In case of flexible configuration, since the two muxponders are under
   the control of the same O-PNC, the configuration of the multiplexing
   label, regardless of whether it is a standard or vendor-specific
   label, can be done by the O-PNC using mechanisms which are vendor-
   specific and outside the scope of this document.  The MDSC can just
   request the O-PNC to setup a client connectivity service over a WDM
   tunnel.

   In case of fixed configuration, the multiplexing label is assigned by
   the muxponder but the O-PNC and MDSC needs to be aware of the
   connectivity constraints to avoid try and fail.

   It is worth noting that the current WSON and Flexi-grid topology
   models in [RFC9094] and [I-D.ietf-ccamp-flexigrid-yang] do not
   provide sufficient information to the MDSC about this connectivity
   constraint and this is identified as a gap.

Acknowledgments

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

   Previous versions of document were prepared using 2-Word-
   v2.0.template.dot.

   This document was prepared using kramdown.

Contributors

   Sergio Belotti
   Nokia
   Email: sergio.belotti@nokia.com

   Gabriele Galimberti
   Email: ggalimbe56@gmail.com

   TBD

Peruzzini, et al.        Expires 6 January 2025                [Page 70]
Internet-Draft                  ACTN POI                       July 2024

   Anton Snitser
   Cisco
   Email: asnizar@cisco.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

   Oscar Gonzalez de Dios
   Telefonica
   Email: oscar.gonzalezdedios@telefonica.com

Authors' Addresses

   Fabio Peruzzini
   TIM
   Email: fabio.peruzzini@telecomitalia.it

Peruzzini, et al.        Expires 6 January 2025                [Page 71]
Internet-Draft                  ACTN POI                       July 2024

   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
   Cisco
   Email: daniele.ietf@gmail.com

Peruzzini, et al.        Expires 6 January 2025                [Page 72]