Internet DRAFT - draft-ietf-teas-actn-yang

draft-ietf-teas-actn-yang



TEAS WG                                                       Young Lee
Internet Draft                                                  Samsung
Intended status: Informational                            Haomian Zheng
Expires: September 7, 2023                                       Huawei
                                                     Daniele Ceccarelli
                                                                  Cisco
                                                         Bin Yeong Yoon
                                                                   ETRI
                                                         Sergio Belotti
                                                                  Nokia
                                   
                                                          March 7, 2023
 
                                    
   Applicability of YANG models for Abstraction and Control of Traffic 
                          Engineered Networks 
                                    
                      draft-ietf-teas-actn-yang-11 

Abstract 

   Abstraction and Control of TE Networks (ACTN) refers to the set of 
   virtual network operations needed to orchestrate, control and manage 
   large-scale multi-domain TE networks, so as to facilitate network 
   programmability, automation, efficient resource sharing, and end-to-
   end virtual service aware connectivity and network function 
   virtualization services. 
 
   This document explains how the different types of YANG models 
   defined in the Operations and Management Area and in the Routing 
   Area are applicable to the ACTN framework. This document also shows 
   how the ACTN architecture can be satisfied using classes of data 
   model that have already been defined, and discusses the 
   applicability of specific data models that are under development. It 
   also highlights where new data models may need to be developed. 

Status of this Memo                  

   This Internet-Draft is submitted to IETF 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. 



 
 
 
Lee, et al.            Expires September 7 2023                [Page 1] 

Internet-Draft                ACTN YANG                      March 2023 
    

   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 September 7, 2023. 

Copyright Notice 

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

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

 
Table of Contents 

    
   1. Introduction ................................................. 3 
      1.1. Conventions Used in This Document ....................... 3 
   2. Abstraction and Control of TE Networks (ACTN) Architecture ... 3 
   3. Service Models ............................................... 5 
   4. Service Model Mapping to ACTN ................................ 7 
      4.1. Customer Service Models in the ACTN Architecture (CMI) .. 7 
      4.2. Service Delivery Models in ACTN Architecture ............ 8 
      4.3. Network Configuration Models in ACTN Architecture (MPI).. 8 
      4.4. Device Models in ACTN Architecture (SBI) ............... 10 
   5. Examples of Using Different Types of YANG Models ............ 10 
      5.1. Topology Collection .................................... 10 
      5.2. Connectivity over Two Nodes ............................ 11 
      5.3. VN example ............................................. 11 
      5.4. Data Center-Interconnection Example .................... 12 

 
 
Lee, et al.            Expires September 7, 2023                [Page 2] 

Internet-Draft                ACTN YANG                      March 2023 
    

         5.4.1. CMI (CNC-MDSC Interface) ......................... 14 
         5.4.2. MPI (MDSC-PNC Interface) ......................... 14 
         5.4.3. SBI (Southbound interface between PNC and devices).14 
   6. Security ................................................... 15 
   7. IANA Considerations ........................................ 15 
   8. Acknowledgements ........................................... 15 
   9. References ................................................. 15 
      9.1. Informative References ................................ 15 
   10. Contributors .............................................. 18 
   Authors' Addresses ............................................ 19 
    
1. Introduction 

   Abstraction and Control of TE Networks (ACTN) describes a method for 
   operating a Traffic Engineered (TE) network (such as an MPLS-TE 
   network or a layer 1 transport network) to provide connectivity and 
   virtual network for customers of the TE network. The services 
   provided can be tuned to meet the requirements (such as traffic 
   patterns, quality, and reliability) of the applications hosted by 
   the customers. More details about ACTN can be found in Section 2. 

   Data models are a representation of objects that can be configured 
   or monitored within a system. Within the IETF, YANG [RFC6241] is the 
   language of choice for documenting data models, and YANG models have 
   been produced to allow configuration or modelling of a variety of 
   network devices, protocol instances, and network services. YANG data 
   models have been classified in [RFC8199] and [RFC8309]. 

   This document shows how the ACTN architecture can be satisfied using 
   various classes of data model that have already been defined, and 
   discusses the applicability of specific data models that are under 
   development. It also highlights where new data models may need to be 
   developed.  

1.1. Conventions Used in This Document 

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",   
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and   
   "OPTIONAL" in this document are to be interpreted as described in   
   BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all   
   capitals, as shown here. 

2. Abstraction and Control of TE Networks (ACTN) Architecture 

   [RFC8453] describes the architecture model for ACTN including the 
   entities (Customer Network Controller (CNC), Multi-domain Service 

 
 
Lee, et al.            Expires September 7, 2023                [Page 3] 

Internet-Draft                ACTN YANG                      March 2023 
    

   Coordinator (MDSC), and Provisioning Network Controller (PNC)) and 
   their interfaces. 
    
   Figure 1 depicts a high-level control and interface architecture for 
   ACTN and is a reproduction of Figure 3 from [RFC8453]. A number of 
   key ACTN interfaces exist for deployment and operation of ACTN-based 
   networks. These are highlighted in Figure 1 (ACTN Interfaces) below: 

           +--------------+      +---------------+      +--------------+ 
           |    CNC-A     |      |     CNC-B     |      |     CNC-C    | 
           |(DC provider) |      |     (ISP)     |      |     (MVNO)   | 
           +--------------+      +---------------+      +--------------+ 
                \                        |                         / 
   Business      \                       |                        / 
   Boundary  =====\======================|=======================/====== 
   Between         \                     | CMI                  / 
   Customer &       -----------          |        -------------- 
   Network Provider            \         |       / 
                              +---------------------+ 
                              |        MDSC         | 
                              +---------------------+ 
                               /         |       \ 
                     ----------          |MPI     ------------- 
                    /                    |                     \ 
             +-------+               +-------+              +-------+ 
             |  PNC  |               |  PNC  |              |  PNC  | 
             +-------+               +-------+              +-------+ 
                | GMPLS             /      |                 /   \ 
                | trigger          /       |SBI         SBI /     \ 
             --------         -----        |               /       \ 
            (        )       (     )       |              /         \ 
           -         -      ( Phys. )      |             /       ----- 
           (  GMPLS   )      ( Net )       |            /       (     ) 
          (  Physical  )       ----        |           /       ( Phys. ) 
           (  Network )                 -----        -----      ( Net ) 
            -        -                 (     )      (     )      ----- 
             (       )                (  Phys. )   (  Phys. ) 
             --------                  ( Net )      ( Net ) 
                                        -----        ----- 
 
 
                        Figure 1 : ACTN Interfaces 

   The interfaces and functions are described below (without modifying 
   the definitions) in [RFC8453]: 

         

 
 
Lee, et al.            Expires September 7, 2023                [Page 4] 

Internet-Draft                ACTN YANG                      March 2023 
    

       The CNC-MDSC Interface (CMI) is an interface between a CNC and 
        an MDSC. This interface is used to communicate the service 
        request or application demand. A request will include specific 
        service properties, for example, services type, bandwidth and 
        constraint information. These constraints SHOULD be measurable 
        by MDSC and therefore visible to CNC via CMI. The CNC can also 
        request the creation of the virtual network based on underlying 
        physical resources to provide network services for the 
        applications. The CNC can provide the end-point 
        information/characteristics together with traffic matrix 
        specifying specific customer constraints.  The MDSC may also 
        report potential network topology availability if queried for 
        current capability from the Customer Network Controller. 
        Performance monitoring is also applicable in CMI, which enables 
        the MDSC to report network parameters/telemetries that may 
        guide the CNC to create/change their services.  
      
       The MDSC-PNC Interface (MPI) is an interface between a MDSC and 
        a PNC. It allows the MDSC to communicate requests to 
        create/delete connectivity or to modify bandwidth reservations 
        in the physical network. In multi-domain environments, each PNC 
        is responsible for a separate domain. The MDSC needs to 
        establish multiple MPIs, one for each PNC and perform 
        coordination between them to provide cross-domain connectivity. 
        MPI plays an important role for multi-vendor mechanism, inter-
        operability can be achieved by standardized interface modules.  
 
       The South-Bound Interface (SBI) is the provisioning interface 
        for creating forwarding state in the physical network, 
        requested via the PNC. The SBI is not in the scope of ACTN, 
        however, it is included in this document so that it can be 
        compared to models in [RFC8309]. 

3. Service Models 

   [RFC8309] introduces a reference architecture to explain the nature 
   and usage of service YANG models in the context of service 
   orchestration. Figure 2 below depicts this relationship and is a 
   reproduction of Figure 2 from [RFC8309]. Four models depicted in 
   Figure 2 are defined as follows:  

       Customer Service Model:  A customer service model is used to 
        describe a service as offer or delivered to a customer by a 
        network operator.   
       Service Delivery Model:  A service delivery model is used by a 
        network operator to define and configure how a service is 
        provided by the network. 
 
 
Lee, et al.            Expires September 7, 2023                [Page 5] 

Internet-Draft                ACTN YANG                      March 2023 
    

       Network Configuration Model: A network configuration model is 
        used by a network orchestrator to provide network-level 
        configuration model to a controller.  
       Device Configuration Model: A device configuration model is 
        used by a controller to configure physical network elements.  

 
 
                                                 Customer 
                            ------------------   Service  ---------- 
                           |                  |  Model   |          | 
                           |     Service      |<-------->| Customer | 
                           |   Orchestrator   |          |          | 
                           |                  |           ---------- 
                            ------------------ 
                              .            .              ----------- 
                             .              .      ......|Application| 
                            .                .     :     |  BSS/OSS  | 
                           .                  .    :      ----------- 
                          .  Service Delivery  .   : 
                          .       Model        .   : 
                 ------------------    ------------------ 
                |                  |  |                  | 
                |     Network      |  |     Network      | 
                |   Orchestrator   |  |   Orchestrator   | 
                |                  |  |                  | 
                .------------------    ------------------. 
               .         :                       :        . 
              .          : Network Configuration :         . 
              .          :        Model          :         . 
      ------------     ------------     ------------    ------------ 
     |            |   |            |   |            |  |            | 
     | Controller |   | Controller |   | Controller |  | Controller | 
     |            |   |            |   |            |  |            | 
      ------------     ------------     ------------    ------------ 
         :              .       .                 :            : 
         :             .         .      Device    :            : 
         :            .           . Configuration :            : 
         :            .           .     Model     :            : 
     ---------     ---------   ---------     ---------      --------- 
    | Network |   | Network | | Network |   | Network |    | Network | 
    | Element |   | Element | | Element |   | Element |    | Element | 
     ---------     ---------   ---------     ---------      --------- 
                                    
            Figure 2: An SDN Architecture with a Service Orchestrator 
                                    



 
 
Lee, et al.            Expires September 7, 2023                [Page 6] 

Internet-Draft                ACTN YANG                      March 2023 
    

4. Service Model Mapping to ACTN 

   YANG models coupled with the RESTCONF/NETCONF protocol 
   [RFC6241][RFC8040] provides solutions for the ACTN framework. This 
   section explains which types of YANG models apply to each of the 
   ACTN interfaces.  
    
   Refer to Figure 5 of [RFC8453] for details of the mapping between 
   ACTN functions and service models. In summary, the following 
   mappings are held between and Service Yang Models in [RFC8309] and 
   the ACTN interfaces in [RFC8453].  
    
      o Customer Service Model <-> CMI 
      o Service Delivery Model <-> MPI 
      o Network Configuration Model <-> MPI 
      o Device Configuration Model <-> SBI  

    
4.1. Customer Service Models in the ACTN Architecture (CMI) 

   Customer Service Models, which are used between a customer and a 
   service orchestrator as in [RFC8309], should be used between the CNC 
   and MDSC (e.g., CMI) serving as providing a simple intent-like 
   model/interface.  

   Among the key functions of Customer Service Models on the CMI is the 
   service request. A request will include specific service properties, 
   including: service type and its characteristics, bandwidth, 
   constraint information, and end-point characteristics.  

   The following table provides a list of functions needed to build the 
   CMI. They are mapped with Customer Service Models.  

     Function                   Yang Model 
     ----------------------------------------------------------- 
     VN Service Request                   [ACTN-VN-YANG] 
     VN Computation Request               [ACTN-VN-YANG]* 
      TE & Service Mapping                [TE-Service-Mapping]** 
     VN Performance Monitoring Telemetry  [ACTN-PM-Telemetry]***   
     Topology Abstraction                 [RFC8795]**** 
     Layer 1 Connectivity Service Model   [L1CSM] 
     Layer 2 VPN Service Model            [RFC8466] 
     Layer 3 VPN Service Model            [RFC8299] 
                        
 

 
 
Lee, et al.            Expires September 7, 2023                [Page 7] 

Internet-Draft                ACTN YANG                      March 2023 
    

   *VN computation request in the CMI context means network path 
   computation request based on customer service connectivity request 
   constraints prior to the instantiation of a VN creation.  

   **[TE-Service-Mapping] provides a mapping and cross-references 
   between service models (e.g., L3SM, L2SM, L1CSM) and TE model via 
   [ACTN-VN-YANG] and [RFC8795]. This model can be used as either 
   Customer Service Models, or Service Delivery model described in 
   Section 4.2.  

   ***ietf-actn-te-kpi-telemetry model in [ACTN-PM-Telemetry] describes 
   performance telemetry for ACTN VN model. This module also allows 
   autonomic traffic engineering scaling intent configuration mechanism 
   on the VN level. Scale in/out criteria might be used for network 
   autonomics in order the controller to react to a certain set of 
   variations in monitored parameters. Moreover, this module also 
   provides mechanism to define aggregated telemetry parameters as a 
   grouping of underlying VN level telemetry parameters. 

   ****RFC8795's Connectivity Matrices/Matrix construct can be used to 
   instantiate VN Service via a suitable referencing and mapping with 
   [ACTN-VN-YANG].  

4.2. Service Delivery Models in ACTN Architecture  

   The Service Delivery Models where the service orchestration and the 
   network orchestration could be implemented as separate components as 
   seen in [RFC8309]. On the other hand, from an ACTN architecture 
   point of view, the service delivery model between the service 
   orchestrator and the network orchestrator is an internal interface 
   between sub-components of the MDSC in a single MDSC model.  
    
   In the MDSC hierarchical model where there are multiple MDSCs, the 
   interface between the top MDSC and the bottom MDSC can be mapped to 
   service delivery models.  
    
4.3. Network Configuration Models in ACTN Architecture (MPI) 

   The Network Configuration Models is used between the network 
   orchestrator and the controller in [RFC8309]. In ACTN, this model is 
   used primarily between a MDSC and a PNC. The Network Configuration 
   Model can be also used for the foundation of more advanced models, 
   like hierarchical MDSCs (see Section 4.5)  

   The Network Configuration Model captures the parameters which are 
   network wide information.  

 
 
Lee, et al.            Expires September 7, 2023                [Page 8] 

Internet-Draft                ACTN YANG                      March 2023 
    

   The following table provides a list of functions needed to build the 
   MPI. They are mapped with Network Configuration Yang Models. Note 
   that various Yang models are work in progress.  

       Function                 Yang Model 
      -------------------------------------------------------- 
       Configuration Scheduling         [Schedule] 
       Path computation                 [PATH_COMPUTATION-API] 
       Tunnel/LSP Provisioning          [TE-tunnel] 
       Topology Abstraction             [RFC8795] 
       Service Provisioning             [Client-signal]&[TE-tunnel]* 
          
       Client Topology Abstraction      [Client-topo] 
       OTN Topology Abstraction         [OTN-topo] 
       WSON Topology Abstraction        [RFC9094] 
       Flexi-grid Topology Abstraction  [Flexi-topo] 
       Microwave Topology Abstraction   [MW-topo] 
       Client Signal Description        [Client-signal] 
       OTN Tunnel Model                 [OTN-Tunnel] 
       WSON TE Tunnel Model             [WSON-Tunnel] 
       Flexi-grid Tunnel Model          [Flexigrid-Tunnel] 
       Service Performance Monitoring   [client-pm] 
       Layer 2 VPNs                     [L2nm] 
       Layer 3 VPNs                     [L3nm] 
       MPLS-TE topo                     [mpls-te-topo] 
       MPLS-TE Tunnel                   [mpls-te-tunnel] 
       MPLS-TE SR                       [mpls-te-sr] 
    
   * This function is a combination of tunnel set up and client signal 
   description. Usually a tunnel is setting up first to get prepared to 
   carry a client signal, in order to do the service provisioning. Then 
   the client signal is adapted to the established tunnel. It is worth 
   noting that various tunnel models such as [OTN-Tunnel] and [WSON-
   Tunnel] can be used together with the [TE-tunnel] model to construct 
   technology-specific tunnels, and carry different types of client 
   signals. More details can be found in [Client-signal].  

   [TE-topo-tunnel] provides the clarification and example usage for TE 
   topology model [RFC8795] and TE tunnel model [TE-tunnel]. [T-NBI 
   Applicability] provides a summary on the applicability of existing 
   YANG model usage in the current network configuration, especially 
   for transport network.  

    


 
 
Lee, et al.            Expires September 7, 2023                [Page 9] 

Internet-Draft                ACTN YANG                      March 2023 
    

4.4. Device Models in ACTN Architecture (SBI) 

   Note that SBI is not in the scope of ACTN, as there is already 
   mature protocol solutions for various purpose on the device level of 
   ACTN architecture, such as RSVP-TE, OSPF-TE and so on. The 
   interworking of such protocols and ACTN controller hierarchies can 
   be found in [gmpls-controller-inter-work].  

   For the device YANG models are used for per-device configuration 
   purpose, they can be used between the PNC and the physical 
   network/devices. One example of Device Models is ietf-te-device yang 
   module defined in [TE-tunnel]. 

    

5. Examples of Using Different Types of YANG Models  

   This section provides some examples on the usage of IETF YANG models 
   in the network operation. A few typical generic scenarios are 
   involved. In [T-NBI Applicability], there are more transport-related 
   scenarios and examples.  

5.1. Topology Collection 

   Before any connection is requested and delivered, the controller 
   needs to understand the network topology. The topology information 
   is exchanged among controllers with topology models, such as 
   [RFC8795]. Moreover, technology-specific topology reporting may use 
   the model described in [OTN-topo] [RFC9094], and [Flexi-topo] for 
   OTN, WSON and Flexi-grid, respectively. By collecting the network 
   topology, each controller can therefore construct a local database, 
   which can be used for the further service deployment. 

   There can be different types of abstraction applied between each 
   pair of controllers, corresponding method can be found in [RFC8453]. 
   The technology-specific features may be hidden after abstraction, to 
   make the network easier for the user to operate.  

   When there is a topology change in the physical network, the PNC 
   should report the change to upper level of controllers via updating 
   messages using topology models. Accordingly, such changes is 
   propagated between different controllers for further 
   synchronization.  




 
 
Lee, et al.            Expires September 7, 2023               [Page 10] 

Internet-Draft                ACTN YANG                      March 2023 
    

5.2. Connectivity over Two Nodes  

   The service models, such as described in [RFC8299], [RFC8466] and 
   [L1CSM] provide a customer service model which can be used in 
   provider networks. 

   It would be used as follows in the ACTN architecture: 

       A CNC uses the service models to specify the two client nodes 
        that are to be connected, and also indicates the amount of 
        traffic (i.e., the bandwidth required) and payload type. What 
        may be additionally specified is the SLA that describes the 
        required quality and resilience of the service. 
         
       The MDSC uses the information in the request to pick the right 
        network (domain) and also to select the provider edge nodes 
        corresponding to the customer edge nodes.  

        If there are multiple domains, then the MDSC needs to 
        coordinate across domains to set up network tunnels to deliver 
        a service. Thus coordination includes, but is not limited to, 
        picking the right domain sequence to deliver a service.  

        Additionally, an MDSC can initiate the creation of a tunnel (or 
        tunnel segment) in order to fulfill the service request from 
        CNC based on path computation upon the overall topology 
        information it synthesized from different PNCs. The based model 
        that can cater this purpose is the TE tunnel model specified in 
        [TE-tunnel]. Technology-specific tunnel configuration may use 
        the model described in [OTN-Tunnel] [WSON-Tunnel], and 
        [Flexigrid-Tunnel] for OTN, WSON and Flexi-grid, respectively. 

       Then, the PNCs need to decide the explicit route of such a 
        tunnel or tunnel segment (in case of multiple domains) for each 
        domain, and then create such a tunnel using protocols such as 
        PCEP and RSVP-TE or using per-hop configuration.  

5.3. VN example 

   The service model defined in [ACTN-VN-YANG] describes a virtual 
   network (VN) as a service which is a set of multiple connectivity 
   services:  

       A CNC will request VN to the MDSC by specifying a list of VN 
        members. Each VN member specifies either a single connectivity 
        service, or a source with multiple potential destination points 

 
 
Lee, et al.            Expires September 7, 2023               [Page 11] 

Internet-Draft                ACTN YANG                      March 2023 
    

        in the case that the precise destination sites are to be 
        determined by MDSC.  
         
           o In the first case, the procedure is the same as the 
             connectivity service, except that in this case, there is a 
             list of connections requested.  
              
           o In the second case, where the CNC requests the MDSC to 
             select the right destination out of a list of candidates, 
             the MDSC needs to evaluate each candidate and then choose 
             the best one and reply with the chosen destination for a 
             given VN member.  After this is selected, the connectivity 
             request setup procedure is the same as in the connectivity 
             example in section 5.2. 
      

   After the VN is set up, a successful reply message is sent from MDSC 
   to CNC, indicating the VN is ready. This message can also be 
   achieved by using the model defined in [ACTN-VN-YANG]. 

5.4. Data Center-Interconnection Example 

   This section describes more concretely how existing YANG models 
   described in Section 4 map to an ACTN data center interconnection 
   use case. Figure 3 shows a use-case which shows service policy-
   driven Data Center selection and is a reproduction of Figure A.1 
   from [RFC8454]. 

    

    















 
 
Lee, et al.            Expires September 7, 2023               [Page 12] 

Internet-Draft                ACTN YANG                      March 2023 
    

                             +----------------+ 
                             |       CNC      | 
                             |   (Global DC   | 
                             |   Operation    | 
                             |    Control)    | 
                             +--------+-------+ 
                                      | |   VN Requirement/Policy: 
                    CMI:              | |  - Endpoint/DC location info 
                 Service model        | |  - Endpoint/DC dynamic  
                                      | |    selection policy   
                                      | |    (for VM migration, DR, LB)  
                                      | v 
                            +---------+---------+ 
                            |  Multi-domain     | Service policy-driven  
                            |Service Coordinator| dynamic DC selection 
              MPI:          +-----+---+---+-----+   
    Network Configuration         |   |   | 
    Model                         |   |   | 
                 +----------------+   |   +---------------+ 
                 |                    |                   | 
           +-----+-----+       +------+-----+      +------+-----+ 
           |  PNC for  |       |  PNC for   |      |  PNC for   | 
           | Transport |       | Transport  |      | Transport  | 
           | Network A |       | Network B  |      | network C  | 
           +-----------+       +------------+      +------------+ 
   Device        |                    |                   | 
   Model         |                    |                   | 
                 |                    |                   | 
+---+      ------               ------              ------       +---+ 
|DC1|--////      \\\\       ////      \\\\      ////      \\\\---+DC5| 
+---+ |              |     |              |    |              |  +---+ 
      |     TN A     +-----+     TN B     +----+      TN C    | 
      /              |     |              |    |              | 
     / \\\\      ////     / \\\\      ////      \\\\      //// 
   +---+   ------        /      ------    \         ------ \ 
   |DC2|                /                  \                \+---+ 
   +---+               /                    \                |DC6| 
                     +---+                   \ +---+         +---+ 
                     |DC3|                    \|DC4| 
                     +---+                     +---+ 
    
                                                DR: Disaster Recovery           
                                                LB: Load Balancing  
    
             Figure 3: Service Policy-driven Data Center Selection 
                                        
 
 
Lee, et al.            Expires September 7, 2023               [Page 13] 

Internet-Draft                ACTN YANG                      March 2023 
    

   Figure 3 shows how VN policies from the CNC (Global Data Center 
   Operation) are incorporated by the MDSC to support multi-destination 
   applications. Multi-destination applications refer to applications 
   in which the selection of the destination of a network path for a 
   given source needs to be decided dynamically to support such 
   applications.  

   Data Center selection problems arise for VM mobility, disaster 
   recovery and load balancing cases. VN's policy plays an important 
   role for virtual network operation. Policy can be static or dynamic. 
   Dynamic policy for data center selection may be placed as a result 
   of utilization of data center resources supporting VMs. The MDSC 
   would then incorporate this information to meet the objective of 
   this application. 

        5.4.1. CMI (CNC-MDSC Interface) 

   [ACTN-VN-YANG] is used to express the definition of a VN, its VN 
   creation request, the service objectives (metrics, QoS parameters, 
   etc.), dynamic service policy when VM needs to be moved from one 
   Data Center to another Data Center, etc. This service model is used 
   between the CNC and the MDSC (CMI). The CNC in this use-case is an 
   external entity that wants to create a VN and operates on the VN.  

        5.4.2. MPI (MDSC-PNC Interface) 

   The Network Configuration Model is used between the MDSC and the 
   PNCs. Based on the Customer Service Model's request, the MDSC will 
   need to translate the service model into the network configuration 
   model to instantiate a set of multi-domain connections between the 
   prescribed sources and the destinations. The MDSC will also need to 
   dynamically interact with the CNC for dynamic policy changes 
   initiated by the CNC. Upon the determination of the multi-domain 
   connections, the MDSC will need to use the network configuration 
   model such as [TE-tunnel] to interact with each PNC involved on the 
   path. [RFC8795] is used to for the purpose of underlying domain 
   network abstraction from the PNC to the MDSC.  

        5.4.3. SBI (Southbound interface between PNC and devices) 

   The Device Model can be used between the PNC and its underlying 
   devices that are controlled by the PNC. The PNC will need to trigger 
   signaling using any mechanisms it employees (e.g. [RSVP-TE-YANG]) to 
   provision its domain path segment. There can be a plethora of 
   choices how to control/manage its domain network. The PNC is 
   responsible to abstract its domain network resources and update it 

 
 
Lee, et al.            Expires September 7, 2023               [Page 14] 

Internet-Draft                ACTN YANG                      March 2023 
    

   to the MDSC. Note that this interface is not in the scope of ACTN. 
   This section is provided just for an illustration purpose.  

6. Security  

   This document is an informational draft. When the models mentioned 
   in this draft are implemented, detailed security consideration will 
   be given in such work.  
    
   How security fits into the whole architecture has the following 
   components:  

   - the use of Restconf security between components 

   - the use of authentication and policy to govern which services can 
   be requested by different parties.  

   - how security may be requested as an element of a service and 
   mapped down to protocol security mechanisms as well as separation 
   (slicing) of physical resources) 

    
7. IANA Considerations 

   This document requires no IANA actions. 

8. Acknowledgements 

   We thank Adrian Farrel for providing useful comments and suggestions 
   for this draft.  

9. References 

9.1. Informative References 

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate              
             Requirement Levels", BCP 14, RFC 2119, DOI 
             10.17487/RFC2119, March 1997,              
             <https://www.rfc-editor.org/info/rfc2119>. 

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC            
             2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,           
             May 2017, <https://www.rfc-editor.org/info/rfc8174>. 

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

 
 
Lee, et al.            Expires September 7, 2023               [Page 15] 

Internet-Draft                ACTN YANG                      March 2023 
    

   [RFC8199] D. Bogdanovic, B. Claise, and C. Moberg, "YANG Module 
             Classification", RFC 8199.  

   [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,         
             and A. Bierman, Ed., "Network Configuration Protocol          
             (NETCONF)", RFC 6241. 

   [RFC8040] A. Bierman, M. Bjorklund, and K. Watsen, "RESTCONF 
             Protocol", RFC 8040.  

   [RFC8453] D. Ceccarelli and Y. Lee, "Framework for Abstraction and 
             Control of Traffic Engineered Networks", RFC8453.  

   [RFC8466] B. Wen, G. Fioccola, C. Xie, L. Jalil, "A YANG Data Model 
             for L2VPN Service Delivery", RFC8466.  

   [RFC8299] Q. Wu, S. Litkowski, L. Tomotaki, K.Ogaki, "YANG Data 
             Model for L3VPN Service Delivery", RFC8299. 

   [RFC8454] Y. Lee & S. Belotti, "Information Model for Abstraction 
             and Control of TE Networks (ACTN)", RFC8454.  

   [RSVP-TE-YANG] T. Saad (Editor), "A YANG Data Model for Resource 
             Reservation Protocol (RSVP)", draft-ietf-teas-yang-rsvp, 
             work in progress.  

   [RFC8795] X. Liu, et. al., "YANG Data Model for TE Topologies", 
             RFC8795.  

   [TE-tunnel] T. Saad (Editor), "A YANG Data Model for Traffic 
             Engineering Tunnels and Interfaces", draft-ietf-teas-yang-
             te, work in progress.  

   [ACTN-VN-YANG] Y. Lee (Editor), "A Yang Data Model for ACTN VN 
             Operation", draft-lee-teas-actn-vn-yang, work in progress.  

   [L1CSM] G. Fioccola, K. Lee, Y. Lee, D. Dhody, O. Gonzalez de-Dios, 
             D. Ceccarelli, "A Yang Data Model for L1 Connectivity 
             Service Model (L1CSM)", draft-ietf-ccamp-l1csm-yang, work 
             in progress. 

   [Schedule] X. Liu, et. al., "A YANG Data Model for Configuration 
             Scheduling", draft-liu-netmod-yang-schedule, work in 
             progress.  



 
 
Lee, et al.            Expires September 7, 2023               [Page 16] 

Internet-Draft                ACTN YANG                      March 2023 
    

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

   [RFC9094] Y. Lee, et. al., "A Yang Data Model for WSON Optical 
             Networks", RFC 9094.  

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

   [MW-topo] M. Ye, et. al., "A YANG Data Model for Microwave 
             Topology", draft-ietf-ccamp-mw-topo-yang, work in 
             progress.  

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

   [ACTN-PM-Telemetry] Y. Lee, D. Dhody, S. Karunanithi, R. Vilalta, D. 
             King, and D. Ceccarelli, "YANG models for ACTN TE 
             Performance Monitoring Telemetry and Network Autonomics", 
             draft-ietf-teas-actn-pm-telemetry-autonomics, work in 
             progress.                                                         

   [WSON-Tunnel] Y. Lee, D. Dhody, V. Lopez, D. King, B. Yoon, and R. 
             Vilalta, "A Yang Data Model for WSON Tunnel", draft-ietf-
             ccamp-wson-tunnel-model, work in progress.  

   [Flexigrid-Tunnel] J. Vergara, D. Perdices, V. Lopez, O. Gonzalez de 
             Dios, D. King, Y. Lee, and G. Galimberti, "YANG data model 
             for Flexi-Grid media-channels", draft-ietf-ccamp-
             flexigrid-media-channel-yang, work in progress.  

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

   [Client-topo] H. Zheng, et al, "A YANG Data Model for Ethernet TE            
             Topology", draft-ietf-ccamp-eth-client-te-topo-yang, work 
             in progress. 

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



 
 
Lee, et al.            Expires September 7, 2023               [Page 17] 

Internet-Draft                ACTN YANG                      March 2023 
    

   [T-NBI Applicability] I. Busi, et al, "Transport Northbound 
             Interface Applicability Statement and Use Cases", draft-
             ietf-ccamp-transport-nbi-app-statement, work in progress.  

   [gmpls-controller-inter-work] H. Zheng, et al, "Interworking of 
             GMPLS Control and Centralized Controller System", draft-
             ietf-teas-gmpls-controller-inter-work, work in progress.  

   [client-pm] H. Zheng, et al, "A YANG Data Model for Client Signal 
             Performance Monitoring", draft-zheng-ccamp-client-pm-yang, 
             work in progress.  

   [L2nm] M. Boucadair, et al, "A YANG Network Data Model for Layer 2 
             VPNs", draft-ietf-opsawg-l2nm, work in progress.  

   [L3nm] S. Barguil, et al, "A Layer 3 VPN Network YANG Model", draft-
             ietf-opsawg-l3sm-l3nm, work in progress.  

   [mpls-te-topo] I. Busi, et al, "A YANG Data Model for MPLS-TE 
             Topology", draft-busizheng-teas-yang-te-mpls-topology, 
             work in progress. 

   [mpls-te-tunnel] T. Saad, et al, "A YANG Data Model for MPLS Traffic 
             Engineering Tunnels", draft-ietf-teas-yang-te-mpls, work 
             in progress.  

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

10. Contributors 

Contributor's Addresses 

   Dhruv Dhody 
   Huawei Technologies 
    
   Email: dhruv.ietf@gmail.com 
    
   Xian Zhang 
   Huawei Technologies 
    
   Email: zhang.xian@huawei.com  
    
   Oscar Gonzalez de Dios 

 
 
Lee, et al.            Expires September 7, 2023               [Page 18] 

Internet-Draft                ACTN YANG                      March 2023 
    

   Telefonica 
   Email: oscar.gonzalezdedios@telefonica.com  
    
   Jong Yoon Shin  
   SKT 
   Email: jongyoon.shin@sk.com  
    
    
    
Authors' Addresses 

   Young Lee 
   Samsung 
   Korea 
   Email: younglee.tx@gmail.com 
    
   Haomian Zheng 
   Huawei Technologies 
   Email: zhenghaomian@huawei.com 
    
   Daniele Ceccarelli 
   Cisco 
   Email: daniele.ietf@gmail.com 
  
   Bin Yeong Yoon 
   ETRI  
   Email: byyun@etri.re.kr 
    
   Sergio Belotti 
   Nokia 
   Email: sergio.belotti@nokia.com  
    












 
 
Lee, et al.            Expires September 7, 2023               [Page 19]