[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02

TEAS Working Group                                      Fabio Peruzzini
Internet Draft                                                      TIM
Intended status: Informational                               Italo Busi
                                                                 Huawei
                                                            Daniel King
                                                     Old Dog Consulting
                                                         Sergio Belotti
                                                                  Nokia
                                                    Gabriele Galimberti
                                                                  Cisco

Expires: April 2020                                    October 31, 2019



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


               draft-peru-teas-actn-poi-applicability-02.txt


Status of this Memo

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

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

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

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

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

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







Peruzzini et al.        Expires April 31, 2020                 [Page 1]


Internet-Draft                 ACTN POI                    October 2019


Copyright Notice

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

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

Abstract

   This document considers the applicability of ACTN to Packet Optical
   Integration (POI) and IP and Optical DWDM domain internetworking,
   and specifically the YANG models being defined by the IETF to
   support this deployment architecture.

   In this document we highlight the IETF protocols and data models
   that may be used for the ACTN and control of POI networks, with
   particular focus on the interfaces between the MDSC (Multi-Domain
   Service Coordinator) and the underlying Packet and Optical Domain
   Controllers (P-PNC and O-PNC) to support Packet Optical Integration
   (POI) use cases.

Table of Contents


   1. Introduction...................................................3
   2. Reference Scenario.............................................4
      2.1. Generic Assumptions.......................................6
   3. Scenario 1 - Multi-Layer Topology Coordination.................7
      3.1. Discovery of existing Och, ODU, IP links, IP tunnels and
           IP services...............................................7
         3.1.1. Common YANG models used at the MPIs..................7
            3.1.1.1. YANG models used at the Optical MPIs............8
            3.1.1.2. Required YANG models at the Packet MPIs.........8
         3.1.2. Inter-domain link Discovery..........................9
      3.2. Provisioning of an IP Link/LAG over DWDM.................10
         3.2.1. YANG models used at the MPIs........................10
            3.2.1.1. YANG models used at the Optical MPIs...........10
            3.2.1.2. Required YANG models at the Packet MPIs........11



Peruzzini et al.        Expires April 31, 2020                 [Page 2]


Internet-Draft                 ACTN POI                    October 2019


         3.2.2. IP Link Setup Procedure.............................11
      3.3. Provisioning of an IP link/LAG over DWDM with path
      constraints...................................................12
         3.3.1. YANG models used at the MPIs........................12
      3.4. Provisioning of an additional link member to an existing
           LAG with or without path constraints.....................12
         3.4.1. YANG models used at the MPIs........................13
   4. Multi-Layer Recovery Coordination.............................13
      4.1. Ensuring Network Resiliency during Maintenance Events....13
      4.2. Router port failure......................................13
   5. Security Considerations.......................................14
   6. Operational Considerations....................................14
   7. IANA Considerations...........................................15
   8. References....................................................15
      8.1. Normative References.....................................15
      8.2. Informative References...................................16
   9. Acknowledgments...............................................16
   10. Authors' Addresses...........................................16

1. Introduction

   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 possibly Multiprotocol Label Switching
   (MPLS) is typically realized on top of an optical transport network
   that uses Dense Wavelength Division Multiplexing (DWDM). In many
   existing network deployments, the packet and the optical networks
   are engineered and operated independently of each other. There are
   technical differences between the technologies (e.g., routers vs.
   optical switches) and the corresponding network engineering and
   planning methods (e.g., inter-domain peering optimization in IP vs.
   dealing with physical impairments in DWDM, or very different time
   scales). In addition, customers and customer needs can be different
   between a packet and an optical network, and it is not uncommon to
   use different vendors in both domains. Last but not least, state-of-
   the-art packet and optical networks use sophisticated but complex
   technologies, and for a network engineer it may not be trivial to be
   a full expert in both areas. As a result, packet and optical
   networks are often operated in technical and organizational silos.

   This separation is inefficient for many reasons. Both capital
   expenditure (CAPEX) and operational expenditure (OPEX) could be
   significantly reduced by better integrating the packet and the
   optical network. Multi-layer online topology insight can speed up
   troubleshooting (e.g., alarm correlation) and network operation
   (e.g., coordination of maintenance events), multi-layer offline



Peruzzini et al.        Expires April 31, 2020                 [Page 3]


Internet-Draft                 ACTN POI                    October 2019


   topology inventory can improve service quality (e.g., detection of
   diversity constraint violations) and multi-layer traffic engineering
   can use the available network capacity more efficiently (e.g.,
   coordination of restoration). In addition, provisioning workflows
   can be simplified or automated as needed across layers (e.g, to
   achieve bandwidth on demand, or to perform maintenance events).

   Fully leveraging these benefits requires an integration between the
   management and control of the packet and the optical network. The
   Abstraction and Control of TE Networks (ACTN) framework defines
   functions and interfaces between a Multi-Domain Service Coordinator
   (MDSC) and Provisioning Network Controllers (PNCs) that can be used
   for coordinating the packet and optical layers.

   In this document, key use cases for Packet Optical Integration (POI)
   are described both from the point of view of the optical and the
   packet layer. The objective is to explain the benefit and the impact
   for both the packet and the optical layer, and to identify the
   required interaction between both layers. Precise definitions of use
   cases can help with achieving a common understanding across
   different disciplines. The focus of the use cases are IP networks
   operated as client of optical DWDM networks. The use cases are
   ordered by increasing level of integration and complexity. For each
   multi-layer use case, the document analyzes how to use the
   interfaces and data models of the ACTN architecture.

   Understanding the level of standardization and the gaps will help to
   better assess the feasibility of integration between IP and Optical
   DWDM domain, in an end-to-end multi-vendor service provisioning
   perspective.

2. Reference Scenario

   This document is considering a network scenario with multiple
   Optical domains and multiple Packet domains.

   Figure 1 shows this scenario in case of two Optical domains and two
   Packet domains:











Peruzzini et al.        Expires April 31, 2020                 [Page 4]


Internet-Draft                 ACTN POI                    October 2019



                              +----------+
                              |   MDSC   |
                              +-----+----+
                                    |
                  +-----------+-----+------+-----------+
                  |           |            |           |
             +----+----+ +----+----+  +----+----+ +----+----+
             | P-PNC 1 | | O-PNC 1 |  | O-PNC 2 | | P-PNC 2 |
             +----+----+ +----+----+  +----+----+ +----+----+
                  |           |            |           |
                  |           \            /           |
        +-------------------+  \          /  +-------------------+
   CE  / PE             ASBR \  |        /  / ASBR            PE  \  CE
   o--/---o               o---\-|-------|--/---o               o---\--o
      \   :               :   / |       |  \   :               :   /
       \  :  AS Domain 1  :  /  |       |   \  :  AS Domain 2  :  /
        +-:---------------:-+   |       |    +-:---------------:--+
          :               :     |       |      :               :
          :               :     |       |      :               :
        +-:---------------:------+     +-------:---------------:--+
       /  :               :       \   /        :               :   \
      /   o...............o        \ /         o...............o    \
      \     Optical Domain 1       / \       Optical Domain 2       /
       \                          /   \                            /
        +------------------------+     +--------------------------+

                       Figure 1 - Reference Scenario

   The ACTN architecture, defined in [RFC8453], is used to control this
   multi-domain network where each Packet PNC (P-PNC) is responsible
   for controlling its IP domain (AS), and each Optical PNC (O-PNC) is
   responsible for controlling its Optical Domain. The MDSC is
   responsible for coordinating the whole multi-domain multi-layer
   (Packet and Optical) network. A specific standard interface (MPI)
   permits MDSC to interact with the different Provisioning Network
   Controller (O/P-PNCs). The MPI interface presents an abstracted
   topology to MDSC hiding technology-specific aspects of the network
   and hiding topology details depending on the policy chosen regarding
   the level of abstraction supported. The level of abstraction can be
   obtained based on P-PNC and O-PNC configuration parameters (e.g.
   provide the potential connectivity between any PE and any ABSR in an
   MPLS-TE network).

   The MDSC in Figure 1 is responsible for multi-domain and multi-layer
   coordination acrosso multiple Packet and Optical domains, as well as



Peruzzini et al.        Expires April 31, 2020                 [Page 5]


Internet-Draft                 ACTN POI                    October 2019


   to provide IP services to different CNCs at its CMIs (e.g., using
   L2SM, L3SM).

   The multi-domain coordination mechanisms for the IP tunnels
   supporting these IP services are outside the scope of this document
   and described in [ACTN-VPN]. In some cases, the MDSC could also rely
   on the multi-layer Packet Optical Integration mechanisms, described
   in this draft, to support multi-layer optimizations for these IP
   services and tunnels.

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

   o  The domain boundaries between the IP and Optical domains are
      congruent. In other words, one Optical domain supports
      connectivity between Routers in one and only one Packet Domain.

   o  Inter-domain links exist only between Packet domains (i.e.,
      between ASBR routers) and between Packet and Optical domains
      (i.e., between routers and ROADMs). In other words, there are no
      inter-domain links between Optical domains

   o  The interfaces between the routers and the ROADM's are "Ethernet"
      physical interfaces

   o  The interfaces between the ASBR routers are "Ethernet" physical
      interfaces

2.1. Generic Assumptions

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

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

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

   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.






Peruzzini et al.        Expires April 31, 2020                 [Page 6]


Internet-Draft                 ACTN POI                    October 2019


3. Scenario 1 - Multi-Layer Topology Coordination

   In this scenario, the MSDC needs to discover the network topology,
   at both WDM and IP layers, in terms of nodes (NEs) and links,
   including inter AS domain links as well as cross-layer links.

   Each PNC provides to the MDSC an abstract topology view of the WDM
   or of the IP topology of the domain it controls. This topology is
   abstracted in the sense that some detailed NE information is hidden
   at the MPI, and all or some of the NEs and related physical links
   are exposed as abstract nodes and logical (virtual) links, depending
   on the level of abstraction the user want. This detailed information
   is key to understand both the inter-AS domain links (seen by each
   controller as UNI interfaces but as I-NNI interfaces by the MDSC) as
   well as the cross-layer mapping between IP and WDM layer.

   The MDSC also maintains an up-to-date network inventory of both IP
   and WDM layers through the use of IETF notifications through MPI
   with the PNCs.

   For the cross-layer links it is key for MDSC to be able to correlate
   automatically the information about the physical ports from the
   routers (single link or bundle links for LAG) to client ports in the
   ROADM.

3.1. Discovery of existing Och, ODU, IP links, IP tunnels and IP
   services

   In this scenarios MDSC must be able to automatically discover
   network topology of both WDM and IP layers (links and NE, links
   between two domains).

   o  An abstract view of the WDM and IP topology must be available.

   o  MDSC must keep an up-to-date network inventory of both IP and WDM
      layers and it should be possible to correlate such information
      (e.g.: which port, lambda/OTSi, direction is used by a specific
      IP service on the WDM equipment).

   o  It should be possible at MDSC level to easily correlate WDM and
      IP layers alarms to speed-up troubleshooting.

3.1.1. Common YANG models used at the MPIs

   Both Optical and Packet PNCs use the following common topology YANG
   models at the MPI to report their abstract topologies:



Peruzzini et al.        Expires April 31, 2020                 [Page 7]


Internet-Draft                 ACTN POI                    October 2019


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

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

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

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

3.1.1.1. YANG models used at the Optical MPIs

   The Optical PNC also uses at least the following technology-specific
   topology YANG models, providing WDM and Ethernet technology-specific
   augmentations of the generic TE Topology Model:

   o  The WSON Topology Model, defined in the "ietf-wson-topology" YANG
      modules of [WSON-TOPO], or the Flexi-grid Topology Model, defined
      in the "ietf-flexi-grid-topology" YANG module of [Flexi-TOPO].

   o  The Ethernet Topology Model, defined in the "ietf-eth-te-
      topology" YANG module of [CLIENT-TOPO]

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

   The Ethernet Topology is used to report the access links between the
   IP routers and the edge ROADMs.

3.1.1.2. Required YANG models at the Packet MPIs

   The Packet PNC also uses at least the following technology-specific
   topology YANG models, providing IP and Ethernet technology-specific
   augmentations of the generic Topology Models:

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





Peruzzini et al.        Expires April 31, 2020                 [Page 8]


Internet-Draft                 ACTN POI                    October 2019


   o  The Ethernet Topology Model, defined in the "ietf-eth-te-
      topology" YANG module of [CLIENT-TOPO], which augments the TE
      Topology Model

   The Ethernet Topology Model is used to report the access links
   between the IP routers and the edge ROADMs as well as the
   inter-domain links between ASBRs, while the L3 Topology Model is
   used to report the IP network topology (e.g., IP routers and links).

3.1.2. Inter-domain link Discovery

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

   o  Links between two IP domains (ASes)

   o  Links between an IP router and a ROADM

   Both types of links are Ethernet physical links.

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

   The MDSC can understand how to merge these inter-domain links
   together using the plug-id attribute defined in the TE Topology
   Model [TE-TOPO], as described in as described in section 4.3 of [TE-
   TOPO].

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

   Both types of inter-domain links are discovered using the plug-id
   attributes reported in the Ethernet Topologies exposed by the two
   adjacent PNCs. The MDSC can also discover an inter-domain IP
   link/adjacency between the two IP LTPs, reported in the IP
   Topologies exposed by the two adjacent P-PNCs, supported by the two
   ETH LTPs of an Ethernet Link discovered between these two P-PNCs.

   Two options are possible to discover these inter-domain links:

   1. Static configuration

   2. LLDP [IEEE 802.1AB] automatic discovery





Peruzzini et al.        Expires April 31, 2020                 [Page 9]


Internet-Draft                 ACTN POI                    October 2019


   Since the static configuration requires an administrative burden to
   configure network-wide unique identifiers, the automatic discovery
   solution based on LLDP is preferable when LLDP is supported.

   As outlined in [TNBI], the encoding of the plug-id namespace as well
   as of the LLDP information within the plug-id value is
   implementation specific and needs to be consistent across all the
   PNCs.

3.2. Provisioning of an IP Link/LAG over DWDM

   In this scenario, the MSDC needs to coordinate the creation of an IP
   link, or a LAG, between two routers through a DWDM network.

   It is assumed that the MDSC has already discovered the whole network
   topology as described in section 3.1.

3.2.1. YANG models used at the MPIs

3.2.1.1. YANG models used at the Optical MPIs

   The Optical PNC uses at least the following YANG models:

   o  The TE Tunnel Model, defined in the "ietf-te" YANG module of
      [TE-TUNNEL]

   o  The WSON Tunnel Model, defined in the "ietf-wson-tunnel" YANG
      modules of [WSON-TUNNEL], or the Flexi-grid Media Channel Model,
      defined in the "ietf-flexi-grid-media-channel" YANG module of
      [Flexi-MC]

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

   The TE Tunnel model is generic and augmented by technology-specific
   models such as the WSON Tunnel Model and the Flexi-grid Media
   Channel Model.

   The WSON Tunnel Model or, alternatively, the Flexi-grid Media
   Channel Model are used to setup connectivity within the DWDM network
   depending on whether the DWDM optical network is based on fixed grid
   or flexible-grid.







Peruzzini et al.        Expires April 31, 2020                [Page 10]


Internet-Draft                 ACTN POI                    October 2019


   The Ethernet Client Signal Model is used to configure the steering
   of the Ethernet client traffic between Ethernet access links and TE
   Tunnels, which in this case could be either WSON Tunnels or
   Flexi-Grid Media Channels. This model is generic and applies to any
   technology-specific TE Tunnel: technology-specific attributes are
   provided by the technology-specific models which augment the generic
   TE-Tunnel Model.

3.2.1.2. Required YANG models at the Packet MPIs

   The Packet PNC uses at least the following topology YANG models:

   o  The Base Network Model, defined in the "ietf-network" YANG module
      of [RFC8345] (see section 3.1.1)

   o  The Base Network Topology Model, defined in the "ietf-network-
      topology" YANG module of [RFC8345] (see section 3.1.1)

   o  The L3 Topology Model, defined in the "ietf-l3-unicast-topology"
      YANG modules of [RFC8346] (see section 3.1.1.1)

   If, as discussed in section 3.2.2, IP Links created over DWDM can be
   automatically discovered by the P-PNC, the IP Topology is needed
   only to report these IP Links after being discovered by the P-PNC.

   The IP Topology can also be used to configure the IP Links created
   over DWDM.

3.2.2. IP Link Setup Procedure

   The MDSC requires the O-PNC to setup a WDM Tunnel (either a WSON
   Tunnel or a Flexi-grid Tunnel) within the DWDM network between the
   two Optical Transponders (OTs) associated with the two access links.

   The Optical Transponders are reported by the O-PNC as Trail
   Termination Points (TTPs), defined in [TE-TOPO], within the WDM
   Topology. The association between the Ethernet access link and the
   WDM TTP is reported by the Inter-Layer Lock (ILL) identifiers,
   defined in [TE-TOPO], reported by the O-PNC within the Ethernet
   Topology and WDM Topology.

   The MDSC also requires the O-PNC to steer the Ethernet client
   traffic between the two access Ethernet Links over the WDM Tunnel.






Peruzzini et al.        Expires April 31, 2020                [Page 11]


Internet-Draft                 ACTN POI                    October 2019


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

   If LLDP [IEEE 802.1AB] is used between the two routers, the P-PNC
   can automatically discover the IP Link being setup by the MDSC. The
   IP LTPs terminating this IP Link are supported by the ETH LTPs
   terminating the two access links.

   Otherwise, the MDSC needs to require the P-PNC to configure an IP
   Link between the two routers: the MDSC also configures the two ETH
   LTPs which support the two IP LTPs terminating this IP Link.

3.3. Provisioning of an IP link/LAG over DWDM with path constraints

   MDSC must be able to provision an IP link with a fixed maximum
   latency constraint, or with the minimum latency available constraint
   within each domain but as well inter-domain when required (e.g. by
   monitoring traffic KPIs trends for this IP link). Through the O-PNC
   fixed latency path/minimum latency path is chosen between PE and
   ASBR in each optical domain. Then MDSC needs to select the inter-AS
   domain with less latency (in case we have several interconnection
   links) to have the right low latency constraint fulfilled end-to-end
   across domains.

   MDSC must be able to automatically create two IP links between two
   routers, over DWDM network, with physical path diversity (avoiding
   SRLGs communicated by O-PNCs to the MDSC).

   MDSC must be responsible to route each of this IP links through
   different inter-AS domain links so that end-to-end IP links are
   fully disjoint.

   Optical connectivity must be set up accordingly by MDSC through O-
   PNCs.

3.3.1. YANG models used at the MPIs

   This is for further study

3.4. Provisioning of an additional link member to an existing LAG with
   or without path constraints

   For adding an additional link member to a LAG between two routers
   with or without path latency/diversity constraint. MDSC must be able




Peruzzini et al.        Expires April 31, 2020                [Page 12]


Internet-Draft                 ACTN POI                    October 2019


   to force additional optical connection to use the same physical path
   in the optical domain where the LAG capacity increase is required.

3.4.1. YANG models used at the MPIs

   This is for further study

4. Multi-Layer Recovery Coordination

4.1. Ensuring Network Resiliency during Maintenance Events

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

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

4.2. Router port failure

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

   There can be two cases here:

















Peruzzini et al.        Expires April 31, 2020                [Page 13]


Internet-Draft                 ACTN POI                    October 2019


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

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

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

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

5. Security Considerations

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

6. Operational Considerations

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




Peruzzini et al.        Expires April 31, 2020                [Page 14]


Internet-Draft                 ACTN POI                    October 2019


7. IANA Considerations

   This document requires no IANA actions.

8. References

8.1. Normative References

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

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

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

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

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

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

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

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

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

   [WSON-TOPO] Lee, Y. et al., " A YANG Data Model for WSON (Wavelength
             Switched Optical Networks)", draft-ietf-ccamp-wson-yang,
             work in progress.

   [Flexi-TOPO]   Lopez de Vergara, J. E. et al., "YANG data model for
             Flexi-Grid Optical Networks", draft-ietf-ccamp-flexigrid-
             yang, work in progress.

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



Peruzzini et al.        Expires April 31, 2020                [Page 15]


Internet-Draft                 ACTN POI                    October 2019


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

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

   [Flexi-MC]  Lopez de Vergara, J. E. et al., "YANG data model for
             Flexi-Grid media-channels", draft-ietf-ccamp-flexigrid-
             media-channel-yang, work in progress.

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

8.2. Informative References

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

   [ACTN-VPN]  Lee, Y. et al., " Applicability of ACTN to Support
             Packet and Optical Integration", draft-lee-teas-actn-poi-
             applicability, work in progress.

9. Acknowledgments

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

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

10. Authors' Addresses

   Fabio Peruzzini
   TIM

   Email: fabio.peruzzini@telecomitalia.it


   Italo Busi
   Huawei

   Email: Italo.busi@huawei.com





Peruzzini et al.        Expires April 31, 2020                [Page 16]


Internet-Draft                 ACTN POI                    October 2019


   Daniel King
   Old Dog Consulting

   Email: daniel@olddog.co.uk



   Sergio Belotti
   Nokia

   Email: sergio.belotti@nokia.com



   Gabriele Galimberti
   Cisco

   Email: ggalimbe@cisco.com



   Zheng Yanlei
   China Unicom

   Email: zhengyanlei@chinaunicom.cn



   Washington Costa Pereira Correia
   TIM Brasil

   Email: wcorreia@timbrasil.com.br



   Jean-Francois Bouquier
   Vodafone

   Email: jeff.bouquier@vodafone.com










Peruzzini et al.        Expires April 31, 2020                [Page 17]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/