--- 1/draft-ietf-teas-actn-vn-yang-04.txt 2019-06-14 12:13:14.971391632 -0700 +++ 2/draft-ietf-teas-actn-vn-yang-05.txt 2019-06-14 12:13:15.083394460 -0700 @@ -1,29 +1,30 @@ TEAS Working Group Y. Lee (Editor) -Internet Draft Dhruv Dhody (Editor) -Intended Status: Standard Track Huawei -Expires: August 3, 2019 D. Ceccarelli - Ericsson - Igor Bryskin +Internet Draft Futurewei +Intended Status: Standard Track +Expires: December 13, 2019 D. Dhody (Editor) Huawei - Bin Yeong Yoon + + D. Ceccarelli + Ericsson + + I. Bryskin + Futurewei + + B. Yoon ETRI - Qin Wu - Huawei - Peter Park - KT - February 4, 2019 + June 13, 2019 A Yang Data Model for VN Operation - draft-ietf-teas-actn-vn-yang-04 + draft-ietf-teas-actn-vn-yang-05 Abstract This document provides a YANG data model generally applicable to any mode of Virtual Network (VN) operation. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. @@ -37,21 +38,21 @@ 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 August 3, 2019. + This Internet-Draft will expire on December 13, 2019. Copyright Notice Copyright (c) 2018 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 @@ -66,42 +67,42 @@ Introduction.....................................................3 1.................................................................3 1.1. Terminology...............................................4 1.2. Tree diagram..............................................4 1.3. Prefixes in Data Node Names...............................4 2. Use-case of VN Yang Model in the ACTN context..................5 2.1. Type 1 VN.................................................5 2.2. Type 2 VN.................................................6 3. High-Level Control Flows with Examples.........................7 3.1. Type 1 VN Illustration....................................7 - 3.2. Type 2 VN Illustration....................................8 - 4. VN Model Usage................................................11 - 4.1. Customer view of VN......................................11 - 4.2. Auto-creation of VN by MDSC..............................11 - 4.3. Innovative Services......................................11 - 4.3.1. VN Compute..........................................11 + 3.2. Type 2 VN Illustration....................................9 + 4. VN Model Usage................................................12 + 4.1. Customer view of VN......................................12 + 4.2. Auto-creation of VN by MDSC..............................12 + 4.3. Innovative Services......................................12 + 4.3.1. VN Compute..........................................12 4.3.2. Multi-sources and Multi-destinations................12 - 4.3.3. Others..............................................12 - 4.3.4. Summary.............................................13 - 5. VN YANG Model (Tree Structure)................................13 - 6. VN YANG Code..................................................15 - 7. JSON Example..................................................27 - 7.1. VN JSON..................................................28 - 7.2. TE-topology JSON.........................................33 - 8. Security Considerations.......................................49 - 9. IANA Considerations...........................................51 - 10. Acknowledgments..............................................51 - 11. References...................................................52 - 11.1. Normative References....................................52 - 11.2. Informative References..................................52 - 12. Contributors.................................................53 - Authors' Addresses...............................................53 + 4.3.3. Others..............................................13 + 4.3.4. Summary.............................................14 + 5. VN YANG Model (Tree Structure)................................14 + 6. VN YANG Code..................................................16 + 7. JSON Example..................................................29 + 7.1. VN JSON..................................................30 + 7.2. TE-topology JSON.........................................35 + 8. Security Considerations.......................................51 + 9. IANA Considerations...........................................52 + 10. Acknowledgments..............................................53 + 11. References...................................................54 + 11.1. Normative References....................................54 + 11.2. Informative References..................................54 + 12. Contributors.................................................55 + Authors' Addresses...............................................55 1. Introduction This document provides a YANG data model generally applicable to any mode of Virtual Network (VN) operation. The VN model defined in this document is applicable in generic sense as an independent model in and of itself. The VN model defined in this document can also work together with other customer service models such as L3SM [RFC8299], L2SM [L2SM] and L1CSM [L1CSM] to @@ -198,20 +199,27 @@ | +-----------------------+ | MDSC | +-----------------------+ Figure 1. ACTN CMI Both ACTN VN YANG and TE-topology models are used over the CMI to establish a VN over TE networks. + In the context of 5G transport application, 5G Traffic Provisioning + Manager (TPM) that provides slicing requirements to the transport + networks (i.e., MDSC) can be considered as a type of CNC. The ACTN + CMI provides the necessary interface functions between 5G and + transport networks in order to facilitate dynamic VN creation and + its lifecycle management with proper feedback loop for monitoring. + 2.1. Type 1 VN As defined in [RFC8453], a Virtual Network is a customer view of the TE network. To recapitulate VN types from [RFC8453], Type 1 VN is defined as follows: The VN can be seen as a set of edge-to-edge abstract links (a Type 1 VN). Each abstract link is referred to as a VN member and is formed as an end-to-end tunnel across the underlying networks. Such tunnels may be constructed by recursive slicing or abstraction of paths in @@ -316,78 +324,88 @@ If this VN is Type 1, the following diagram shows the message flow between CNC and MDSC to instantiate this VN using VN and TE-Topology Models. +--------+ +--------+ | CNC | | MDSC | +--------+ +--------+ | | | | CNC POST TE-topo | POST /nw:networks/nw:network/ | - model(with Conn. | nw:node/te-node-id/tet:connectivity- | - Matrix on one | matrices/tet:connectivity-matrix | - Abstract node |---------------------------------------->| + model(with Conn. | nw:node/te-node-id/ | + | tet:connectivity-matrices/ | + Matrix on one | tet:connectivity-matrix | + Abstract node |-------------------------------->| | HTTP 200 | - |<----------------------------------------| + |<--------------------------------| | | CNC POST the | POST /VN | - VN identifying |---------------------------------------->| If there is + VN identifying |-------------------------------->| If there is AP, VNAP and VN- | | multi-dest'n Members and maps | | module, then to the TE-topo | HTTP 200 | MDSC selects a - |<----------------------------------------| src or dest'n + |<--------------------------------| src or dest'n | | and update | | VN YANG CNC GET the | GET /VN | - VN YANG status |---------------------------------------->| + VN YANG status |-------------------------------->| | | - | HTTP 200 (VN with status: selected | - | VN-members in case of multi s-d | - |<----------------------------------------| + | HTTP 200 (VN with status: | + | selected VN-members | + | in case of multi s-d) | + |<--------------------------------| | | 3.2. Type 2 VN Illustration For some VN members, the customer may want to "configure" explicit routes over the path that connects its two end-points. Let us consider the following example. - VN-Member 1 L1-L4 + VN-Member 1 L1-L4 (via S3, S4, and S5) - VN-Member 2 L1-L7 (via S4 and S7) + VN-Member 2 L1-L7 (via S3, S4, S7 and S8) - VN-Member 3 L2-L4 + VN-Member 3 L2-L7 (via S9, S10, and S11) - VN-Member 4 L3-L8 (via S10) + VN-Member 4 L3-L8 (via S9, S10 and S11) Where the following topology is the underlay for Abstraction Node 1 (AN1). - S1 S2 - O---------------O - ________/ \______ \ - / \ \ - S3 / \ S4 \ S5 - L1------O----------------------O---------O------------------L4 - \ \ \ - \ \ \ - \ S6 \ S7 \ S8 - O ----------------O---------O--------------L5 - / \ / \ ____/ \_____________L6 - S9 / \ /S10 \ / - L2---------O-----O---------------------O---------------------L7 - / S11\____________________L8 - L3-------- + AN1 + ............................................ + . S1 S2 . + . O---------------O . + . ________/ \______ \ . + . / \ \ . + . S3/ \ S4 \ S5 . + L1----.-O----------------------O---------O-------.----------L4 + . \ \ \ . + . \ \ \ . + . \ S6 \ S7 \ S8 . + . O ----------------O---------O---.----------L5 + . / \ / \ ____/ \__.__________L6 + .S9 / \ /S10 \ / . + L2-----.---O-----O---------------------O----------.----------L7 + . / S11\_________.__________L8 + L3-----.-- . + ............................................ - If CNC creates the single abstract topology, the following diagram - shows the message flow between CNC and MDSC to instantiate this VN - using VN and TE-Topology Model. + There are two options depending on whether CNC or MDSC creates the + single abstract node topology. + + Case 1: + + If CNC creates the single abstract node topology, the following + diagram shows the message flow between CNC and MDSC to instantiate + this VN using VN and TE-Topology Model. +--------+ +--------+ | CNC | | MDSC | +--------+ +--------+ | | | | CNC POST TE-topo | POST /nw:networks/nw:network/ | model(with Conn. | nw:node/te-node-id/tet:connectivity- | Matrix on one | matrices/tet:connectivity-matrix | Abstract node and|---------------------------------------->| @@ -403,52 +421,64 @@ |<----------------------------------------| | | | | CNC GET the | GET /VN | VN YANG status |---------------------------------------->| | | | HTTP 200 (VN with status) | |<----------------------------------------| | | - On the other hand, if MDSC create single node topology based VN YANG - posted by the CNC, the following diagram shows the message flow - between CNC and MDSC to instantiate this VN using VN and TE-Topology - Models. + Case 2: + + On the other hand, if MDSC create the single abstract node topology + based VN YANG posted by the CNC, the following diagram shows the + message flow between CNC and MDSC to instantiate this VN using VN + and TE-Topology Models. +--------+ +--------+ | CNC | | MDSC | +--------+ +--------+ | | | | CNC POST VN | | Identifying AP, | | VNAP and VN- | POST /VN | MDSC populates - Members |---------------------------------------->| a single Abst. + Members |-------------------------------->| a single Abst. | HTTP 200 | node topology - |<----------------------------------------| by itself + |<--------------------------------| by itself | | - CNC POST the | POST /VN | - VN identifying |---------------------------------------->| - AP, VNAP and VN- | | - Members and maps | | - to the TE-topo | HTTP 200 | - |<----------------------------------------| + CNC GET VN & | GET /VN & | + POST TE-Topo | POST /nw:networks/nw:network/ | + Models (with | nw:node/te-node-id/tet: | + Conn. Matrix on | connectivity-matrices/ | + | tet:connectivity-matrix | + the Abstract Node|-------------------------------->| + and explicit | | + paths in the | | + Conn. Matrix | | + | HTTP 200 | + |<--------------------------------| | | | | CNC GET the | GET /VN | - VN YANG status |---------------------------------------->| + VN YANG status |-------------------------------->| | | | HTTP 200 (VN with status) | - |<----------------------------------------| + |<--------------------------------| | | + Section 7 provides JSON examples for both VN model and TE-topology + Connectivity Matrix sub-model to illustrate how a VN can be created + by the CNC making use of the VN module as well as the TE-topology + Connectivity Matrix module. + 4. VN Model Usage 4.1. Customer view of VN The VN-Yang model allows to define a customer view, and allows the customer to communicate using the VN constructs as described in the [ACTN-INFO]. It also allows to group the set of edge-to-edge links (i.e., VN members) under a common umbrella of VN. This allows the customer to instantiate and view the VN as one entity, making it easier for some customers to work on VN without worrying about the @@ -489,33 +519,39 @@ destinations from which the optimal source-destination may be chosen. The following YANG module is shown for describing source container and destination container. The following YANG tree shows how to model multi-sources and multi-destinations. +--rw vn +--rw vn-list* [vn-id] +--rw vn-id uint32 +--rw vn-name? string +--rw vn-topology-id? te-types:te-topology-id - +--rw abstract-node? -> /nw:networks/network/node/tet:te-node-id + +--rw abstract-node? +-> /nw:networks/network/node/tet:te-node-id +--rw vn-member-list* [vn-member-id] | +--rw vn-member-id uint32 | +--rw src - | | +--rw src? -> /ap/access-point-list/access-point-id - | | +--rw src-vn-ap-id? -> /ap/access-point-list/vn-ap/vn-ap-id + | | +--rw src? +-> /ap/access-point-list/access-point-id + | | +--rw src-vn-ap-id? +-> /ap/access-point-list/vn-ap/vn-ap-id | | +--rw multi-src? boolean {multi-src-dest}? | +--rw dest - | | +--rw dest? -> /ap/access-point-list/access-point-id - | | +--rw dest-vn-ap-id? -> /ap/access-point-list/vn-ap/vn-ap-id + | | +--rw dest? +-> /ap/access-point-list/access-point-id + | | +--rw dest-vn-ap-id? +-> /ap/access-point-list/vn-ap/vn-ap-id | | +--rw multi-dest? boolean {multi-src-dest}? - | +--rw connetivity-matrix-id? -> /nw:networks/network/node/tet:te/te- -node-attributes/connectivity-matrices/connectivity-matrix/id + | +--rw connetivity-matrix-id? +-> /nw:networks/network/node/tet:te/te-node-attributes/connectivity- +matrices/connectivity-matrix/id | +--ro oper-status? identityref +--ro if-selected? boolean {multi-src-dest}? +--rw admin-status? identityref +--ro oper-status? identityref 4.3.3. Others The VN Yang model can be easily augmented to support the mapping of VN to the Services such as L3SM and L2SM as described in [TE-MAP]. @@ -542,128 +578,161 @@ No other details need to be set by customer, making for a simplified operations for the customer. * VN Type 2: Along with VN Members, the customer could also provide an abstract topology, this topology is provided by the Abstract TE Topology Yang Model. 5. VN YANG Model (Tree Structure) module: ietf-vn - +--rw ap - | +--rw access-point-list* [access-point-id] - | +--rw access-point-id uint32 - | +--rw access-point-name? string - | +--rw max-bandwidth? te-types:te-bandwidth - | +--rw avl-bandwidth? te-types:te-bandwidth - | +--rw vn-ap* [vn-ap-id] - | +--rw vn-ap-id uint32 - | +--rw vn? -> /vn/vn-list/vn-id - | +--rw abstract-node? -> /nw:networks/network/node/tet:te-node-id - | +--rw ltp? te-types:te-tp-id - +--rw vn - +--rw vn-list* [vn-id] - +--rw vn-id uint32 - +--rw vn-name? string - +--rw vn-topology-id? te-types:te-topology-id - +--rw abstract-node? -> /nw:networks/network/node/tet:te-node-id - +--rw vn-member-list* [vn-member-id] - | +--rw vn-member-id uint32 - | +--rw src - | | +--rw src? -> /ap/access-point-list/access-point-id - | | +--rw src-vn-ap-id? -> /ap/access-point-list/vn-ap/vn-ap-id - | | +--rw multi-src? boolean {multi-src-dest}? - | +--rw dest - | | +--rw dest? -> /ap/access-point-list/access-point-id - | | +--rw dest-vn-ap-id? -> /ap/access-point-list/vn-ap/vn-ap-id - | | +--rw multi-dest? boolean {multi-src-dest}? - | +--rw connetivity-matrix-id? -> /nw:networks/network/node/tet:te/te- - node-attributes/connectivity-matrices/connectivity-matrix/id - | +--ro oper-status? identityref - +--ro if-selected? boolean {multi-src-dest}? - +--rw admin-status? identityref - +--ro oper-status? identityref - +--rw vn-level-diversity? vn-disjointness + +-rw ap + | +-rw access-point-list* [access-point-id] + | +-rw access-point-id uint32 + | +-rw access-point-name? string + | +-rw max-bandwidth? te-types:te-bandwidth + | +-rw avl-bandwidth? te-types:te-bandwidth + | +-rw vn-ap* [vn-ap-id] + | +-rw vn-ap-id uint32 + | +-rw vn? +-> /vn/vn-list/vn-id + | +-rw abstract-node? +-> /nw:networks/network/node/tet:te-node-id + | +-rw ltp? +-> /nw:networks/network/node/nt:termination-point/tet:te-tp-id + +-rw vn + +-rw vn-list* [vn-id] + +-rw vn-id uint32 + +-rw vn-name? string + +-rw vn-topology-id? te-types:te-topology-id + +-rw abstract-node? +-> /nw:networks/network/node/tet:te-node-id + +-rw vn-member-list* [vn-member-id] + | +-rw vn-member-id uint32 + | +-rw src + | | +-rw src? +-> /ap/access-point-list/access-point-id + | | +-rw src-vn-ap-id? +-> /ap/access-point-list/vn-ap/vn-ap-id + | | +-rw multi-src? boolean {multi-src-dest}? + | +-rw dest + | | +-rw dest? +-> /ap/access-point-list/access-point-id + | | +-rw dest-vn-ap-id? +-> /ap/access-point-list/vn-ap/vn-ap-id + | | +-rw multi-dest? boolean {multi-src-dest}? + | +-rw connectivity-matrix-id? +-> /nw:networks/network/node/tet:te/te-node-attribute +/connectivity-matrices/connectivity-matrix/id + | +-ro oper-status? identityref + +-ro if-selected? boolean {multi-src-dest}? + +-rw admin-status? identityref + +-ro oper-status? identityref + +-rw vn-level-diversity? vn-disjointness rpcs: - +---x vn-compute - +---w input - | +---w abstract-node? -> /nw:networks/network/node/tet:te-node-id - | +---w vn-member-list* [vn-member-id] - | | +---w vn-member-id uint32 - | | +---w src - | | | +---w src? -> /ap/access-point-list/access-point-id - | | | +---w src-vn-ap-id? -> /ap/access-point-list/vn-ap/vn-ap-id - | | | +---w multi-src? boolean {multi-src-dest}? - | | +---w dest - | | | +---w dest? -> /ap/access-point-list/access-point-id - | | | +---w dest-vn-ap-id? -> /ap/access-point-list/vn-ap/vn-ap-id - | | | +---w multi-dest? boolean {multi-src-dest}? - | | +---w connetivity-matrix-id? -> - /nw:networks/network/node/tet:te/te-node-attributes/connectivity- - matrices/connectivity-matrix/id - | +---w vn-level-diversity? vn-disjointness - +--ro output - +--ro vn-member-list* [vn-member-id] - +--ro vn-member-id uint32 - +--ro src - | +--ro src? -> /ap/access-point-list/access-point-id - | +--ro src-vn-ap-id? -> /ap/access-point-list/vn-ap/vn-ap-id - | +--ro multi-src? boolean {multi-src-dest}? - +--ro dest - | +--ro dest? -> /ap/access-point-list/access-point-id - | +--ro dest-vn-ap-id? -> /ap/access-point-list/vn-ap/vn-ap-id - | +--ro multi-dest? boolean {multi-src-dest}? - +--ro connetivity-matrix-id? -> - /nw:networks/network/node/tet:te/te-node-attributes/connectivity- - matrices/connectivity-matrix/id - +--ro if-selected? boolean {multi-src-dest}? - +--ro compute-status? Identityref + +--x vn-compute + +--w input + | +--w abstract-node? +-> /nw:networks/network/node/tet:te-node-id + | +--w vn-member-list* [vn-member-id] + | | +--w vn-member-id uint32 + | | +--w src + | | | +--w src? +-> /ap/access-point-list/access-point-id + | | | +--w src-vn-ap-id? +-> /ap/access-point-list/vn-ap/vn-ap-id + | | | +--w multi-src? boolean {multi-src-dest}? + | | +--w dest + | | | +--w dest? +-> /ap/access-point-list/access-point-id + | | | +--w dest-vn-ap-id? +-> /ap/access-point-list/vn-ap/vn-ap-id + | | | +--w multi-dest? boolean {multi-src-dest}? + | | +--w connectivity-matrix-id? +-> /nw:networks/network/node/tet:te/te-node-attributes +/connectivity-matrices/connectivity-matrix/id + | +--w vn-level-diversity? vn-disjointness + +-ro output + +-ro vn-member-list* [vn-member-id] + +-ro vn-member-id uint32 + +-ro src + | +-ro src? -> +/ap/access-point-list/access-point-id + | +-ro src-vn-ap-id? -> +/ap/access-point-list/vn-ap/vn-ap-id + | +-ro multi-src? boolean {multi-src-dest}? + +-ro dest + | +-ro dest? -> +/ap/access-point-list/access-point-id + | +-ro dest-vn-ap-id? -> +/ap/access-point-list/vn-ap/vn-ap-id + | +-ro multi-dest? boolean {multi-src-dest}? + +-ro connectivity-matrix-id? +-> /nw:networks/network/node/tet:te/te-node-attributes +/connectivity-matrices/connectivity-matrix/id + +-ro if-selected? boolean {multi-src-dest}? + +-ro compute-status? identityref 6. VN YANG Code The YANG code is as follows: - file "ietf-vn@2019-02-04.yang" + file "ietf-vn@2019-06-20.yang" module ietf-vn { + yang-version 1.1; namespace "urn:ietf:params:xml:ns:yang:ietf-vn"; prefix "vn"; /* Import network */ import ietf-network { prefix "nw"; + reference + "RFC 8345: A YANG Data Model for Network Topologies"; + } + /* Import network topology */ + import ietf-network-topology { + prefix "nt"; + reference + "RFC 8345: A YANG Data Model for Network Topologies"; } /* Import TE generic types */ import ietf-te-types { prefix "te-types"; + reference + "I-D.ietf-teas-yang-te-types: Traffic Engineering + Common YANG Types"; } /* Import Abstract TE Topology */ import ietf-te-topology { prefix "tet"; + reference + "I-D.ietf-teas-yang-te-topo: YANG Data Model for + Traffic Engineering (TE) Topologies"; } organization "IETF Traffic Engineering Architecture and Signaling (TEAS) Working Group"; contact - "Editor: Young Lee + "Editor: Young Lee : Dhruv Dhody "; description "This module contains a YANG module for the VN. It describes a VN operation module that takes place in the context of the CNC-MDSC Interface (CMI) of the ACTN architecture where the CNC is the actor of a VN Instantiation/modification /deletion."; - revision 2019-02-04 { + revision 2019-06-10 { description "initial version."; reference "TBD"; } /* * Features */ feature multi-src-dest { description @@ -774,21 +843,24 @@ leaf abstract-node { type leafref { path "/nw:networks/nw:network/nw:node/" + "tet:te-node-id"; } description "a reference to the abstract node in TE Topology"; } leaf ltp { - type te-types:te-tp-id; + type leafref { + path "/nw:networks/nw:network/nw:node/" + +"nt:termination-point/tet:te-tp-id"; + } description "Reference LTP in the TE-topology"; } } grouping access-point{ description "AP related information"; leaf access-point-id { type uint32; description @@ -875,29 +947,30 @@ "reference to dest VNAP"; } leaf multi-dest { if-feature multi-src-dest; type boolean; description "Is destination part of multi-destination, where only one of the destination is enabled"; } } - leaf connetivity-matrix-id{ + leaf connectivity-matrix-id{ type leafref { path "/nw:networks/nw:network/nw:node/tet:te/" + "tet:te-node-attributes/" + "tet:connectivity-matrices/" + "tet:connectivity-matrix/tet:id"; + } description - "reference to connetivity-matrix"; + "reference to connectivity-matrix"; } }//vn-member /* grouping policy { description "policy related to vn-member-id"; leaf local-reroute { type boolean; description "Policy to state if reroute @@ -2404,35 +2477,35 @@ Nokia Email: sergio.belotti@nokia.com Takuya Miyasaka KDDI Email: ta-miyasaka@kddi.com Authors' Addresses Young Lee (ed.) - Huawei Technologies - Email: leeyoung@huawei.com + Futurewei Technologies + Email: younglee.tx@gmail.com Dhruv Dhody (ed.) Huawei Technologies Email: dhruv.ietf@gmail.com Daniele Ceccarelli Ericsson Torshamnsgatan,48 Stockholm, Sweden Email: daniele.ceccarelli@ericsson.com Igor Bryskin Huawei - Email: Igor.Bryskin@huawei.com + Email: ibryskin@futurewei.com Bin Yeong Yoon ETRI Email: byyun@etri.re.kr Qin Wu Huawei Technologies Email: bill.wu@huawei.com Peter Park