--- 1/draft-ietf-teas-actn-vn-yang-01.txt 2018-09-20 09:13:50.129796853 -0700 +++ 2/draft-ietf-teas-actn-vn-yang-02.txt 2018-09-20 09:13:50.257799929 -0700 @@ -1,29 +1,29 @@ TEAS Working Group Y. Lee (Editor) -Internet Draft Dhruv Dhody +Internet Draft Dhruv Dhody (Editor) Intended Status: Standard Track Huawei -Expires: December 19, 2018 D. Ceccarelli +Expires: March 19, 2019 D. Ceccarelli Ericsson Igor Bryskin Huawei Bin Yeong Yoon ETRI Qin Wu Huawei Peter Park KT - June 19, 2018 + September 19, 2018 A Yang Data Model for ACTN VN Operation - draft-ietf-teas-actn-vn-yang-01 + draft-ietf-teas-actn-vn-yang-02 Abstract This document provides a YANG data model for the Abstraction and Control of Traffic Engineered (TE) networks (ACTN) Virtual Network Service (VNS) operation. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with @@ -37,70 +37,78 @@ 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 December 19, 2018. + This Internet-Draft will expire on March 19, 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 carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction...................................................3 1.1. Terminology...............................................4 - 2. ACTN CMI context...............................................4 - 2.1. Type 1 VN.................................................4 - 2.2. Type 2 VN.................................................5 + 1.2. Tree diagram..............................................4 + 1.3. Prefixes in Data Node Names...............................4 + 2. ACTN CMI 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. Justification of the ACTN VN Model on the CMI.................10 - 4.1. Customer view of VN......................................10 + 4. Justification of the ACTN VN Model on the CMI.................11 + 4.1. Customer view of VN......................................11 4.2. Innovative Services......................................11 4.2.1. VN Compute..........................................11 - 4.2.2. Multi-sources and Multi-destinations................11 - 4.2.3. Others..............................................12 - 4.3. Summary..................................................12 + 4.2.2. Multi-sources and Multi-destinations................12 + 4.2.3. Others..............................................13 + 4.3. Summary..................................................13 5. ACTN VN YANG Model (Tree Structure)...........................13 6. ACTN-VN YANG Code.............................................15 7. JSON Example..................................................27 7.1. ACTN VN JSON.............................................28 - 7.2. TE-topology JSON.........................................34 - 8. Security Considerations.......................................50 - 9. IANA Considerations...........................................50 - 10. Acknowledgments..............................................50 - 11. References...................................................51 - 11.1. Normative References....................................51 - 11.2. Informative References..................................51 - 12. Contributors.................................................52 - Authors' Addresses...............................................52 + 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 1. Introduction + Abstraction and Control of Traffic Engineered Networks (ACTN) + describes a set of management and control functions used to operate + one or more TE networks to construct virtual networks that can be + represented to customers and that are built from abstractions of the + underlying TE networks [RFC8453]. + This document provides a YANG data model for the Abstraction and Control of Traffic Engineered (TE) networks (ACTN) Virtual Network Service (VNS) operation that is going to be implemented for the Customer Network Controller (CNC)- Multi-Domain Service Coordinator (MSDC) interface (CMI). The YANG model on the CMI is also known as customer service model in [RFC8309]. The YANG model discussed in this document is used to operate customer-driven VNs during the VN instantiation, VN computation, and its life-cycle service management and operations. @@ -129,27 +137,53 @@ The actual VN instantiation and computation is performed with Connectivity Matrices sub-module of TE-Topology Model [TE-Topo] which provides TE network topology abstraction and management operation. Once TE-topology Model is used in triggering VN instantiation over the networks, TE-tunnel [TE-tunnel] Model will inevitably interact with TE-Topology model for setting up actual tunnels and LSPs under the tunnels. The ACTN VN operational state is included in the same tree as the configuration consistent with Network Management Datastore - Architecture (NMDA) [NMDA]. The origin of the data is indicated as - per the origin metadata annotation. + Architecture (NMDA) [RFC8342]. The origin of the data is indicated + as per the origin metadata annotation. 1.1. Terminology - Refer to [ACTN-Frame], [RFC7926], and [RFC8309] for the key terms - used in this document. + Refer to [RFC8453], [RFC7926], and [RFC8309] for the key terms used + in this document. + +1.2. Tree diagram + + A simplified graphical representation of the data model is used in + Section 5 of this this document. The meaning of the symbols in + these diagrams is defined in [RFC8340]. + +1.3. Prefixes in Data Node Names + + In this document, names of data nodes and other data model objects + are prefixed using the standard prefix associated with the + corresponding YANG imported modules, as shown in Table 1. + + +---------+------------------------------+-----------------+ + | Prefix | YANG module | Reference | + +---------+------------------------------+-----------------+ + | vn | ietf-actn-vn | [RFCXXXX] | + | nw | ietf-network | [RFC8345] | + | te-types| ietf-te-types | [TE-Tunnel] | + | te-topo | ietf-te-topology | [TE-TOPO] | + +---------+------------------------------+-----------------+ + + Table 1: Prefixes and corresponding YANG modules + + Note: The RFC Editor will replace XXXX with the number assigned to + the RFC once this draft becomes an RFC. 2. ACTN CMI context The model presented in this document has the following ACTN context. +-------+ | CNC | +-------+ | | VN YANG + TE-topology YANG @@ -158,22 +192,22 @@ | 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. 2.1. Type 1 VN - As defined in [ACTN-FW], a Virtual Network is a customer view of the - TE network. To recapitulate VN types from [ACTN-FW], Type 1 VN is + 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 the underlying networks and can encompass edge points of the customer's network, access links, intra-domain paths, and inter- domain links. @@ -387,54 +419,65 @@ |<----------------------------------------| by itself | | CNC POST the ACTN| POST /ACTN VN | VN identifying |---------------------------------------->| AP, VNAP and VN- | | Members and maps | | to the TE-topo | HTTP 200 | |<----------------------------------------| | | | | + CNC GET the ACTN | GET /ACTN VN | VN YANG status |---------------------------------------->| | | | HTTP 200 (ACTN VN with status) | |<----------------------------------------| | | -4. Justification of the ACTN VN Model on the CMI. +4. ACTN 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 details of the provider based YANG models. This is similar to the benefits of having a separate YANG model for - the customer services as described in [SERVICE-YANG], which states - that service models do not make any assumption of how a service is + the customer services as described in [RFC8309], which states that + service models do not make any assumption of how a service is actually engineered and delivered for a customer. -4.2. Innovative Services +4.2. Auto-creation of VN by MDSC -4.2.1. VN Compute + The VN could be configured at the MDSC explicitly by the CNC using + the ACTN VN yang model. In some other cases, the VN is not + explicitly configured, but created automatically by the MDSC based + on the customer service model and local policy, even in these case + the ACTN VN yang model can be used by the CNC to learn details of + the underlying VN created to meet the requirements of customer + service model. + +4.3. Innovative Services + +4.3.1. VN Compute ACTN VN supports VN compute (pre-instantiation mode) to view the full VN as a single entity before instantiation. Achieving this via path computation or "compute only" tunnel setup does not provide the same functionality. -4.2.2. Multi-sources and Multi-destinations +4.3.2. Multi-sources and Multi-destinations In creating a virtual network, the list of sources or destinations or both may not be pre-determined by the customer. For instance, for a given source, there may be a list of multiple-destinations to which the optimal destination may be chosen depending on the network resource situations. Likewise, for a given destination, there may also be multiple-sources from which the optimal source may be chosen. In some cases, there may be a pool of multiple sources and destinations from which the optimal source-destination may be chosen. The following YANG module is shown for describing source @@ -460,29 +503,29 @@ id | | +--rw dest-vn-ap-id? -> /actn/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 -4.2.3. Others +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]. The VN Yang model can be extended to support telemetry, performance monitoring and network autonomics as described in [ACTN-PM]. -4.3. Summary +4.3.4. Summary This section summarizes the innovative service features of the ACTN VN Yang. o Maintenance of AP and VNAP along with VN. o VN construct to group of edge-to-edge links o VN Compute (pre-instantiate) @@ -505,96 +548,77 @@ +--rw actn +--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? -> /actn/vn/vn-list/vn-id - | +--rw abstract-node? -> - /nw:networks/network/node/tet:te-node-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 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? -> /actn/ap/access-point- - list/access-point-id - | | +--rw src-vn-ap-id? -> /actn/ap/access-point- - list/vn-ap/vn-ap-id + | | +--rw src? -> /actn/ap/access-point-list/access-point-id + | | +--rw src-vn-ap-id? -> /actn/ap/access-point-list/vn-ap/vn-ap-id | | +--rw multi-src? boolean {multi-src-dest}? | +--rw dest - | | +--rw dest? -> /actn/ap/access-point- - list/access-point-id - | | +--rw dest-vn-ap-id? -> /actn/ap/access-point- - list/vn-ap/vn-ap-id + | | +--rw dest? -> /actn/ap/access-point-list/access-point-id + | | +--rw dest-vn-ap-id? -> /actn/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 +--rw vn-level-diversity? vn-disjointness rpcs: +---x vn-compute +---w input - | +---w abstract-node? -> - /nw:networks/network/node/tet:te-node-id + | +---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? -> /actn/ap/access-point- - list/access-point-id - | | | +---w src-vn-ap-id? -> /actn/ap/access-point- - list/vn-ap/vn-ap-id + | | | +---w src? -> /actn/ap/access-point-list/access-point-id + | | | +---w src-vn-ap-id? -> /actn/ap/access-point-list/vn-ap/vn-ap-id | | | +---w multi-src? boolean {multi-src-dest}? | | +---w dest - | | | +---w dest? -> /actn/ap/access-point- - list/access-point-id - | | | +---w dest-vn-ap-id? -> /actn/ap/access-point- - list/vn-ap/vn-ap-id + | | | +---w dest? -> /actn/ap/access-point-list/access-point-id + | | | +---w dest-vn-ap-id? -> /actn/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 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? -> /actn/ap/access-point- - list/access-point-id - | +--ro src-vn-ap-id? -> /actn/ap/access-point- - list/vn-ap/vn-ap-id + | +--ro src? -> /actn/ap/access-point-list/access-point-id + | +--ro src-vn-ap-id? -> /actn/ap/access-point-list/vn-ap/vn-ap-id | +--ro multi-src? boolean {multi-src-dest}? +--ro dest - | +--ro dest? -> /actn/ap/access-point- - list/access-point-id - | +--ro dest-vn-ap-id? -> /actn/ap/access-point- - list/vn-ap/vn-ap-id + | +--ro dest? -> /actn/ap/access-point-list/access-point-id + | +--ro dest-vn-ap-id? -> /actn/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 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 6. ACTN-VN YANG Code The YANG code is as follows: file "ietf-actn-vn@2018-02-27.yang" module ietf-actn-vn { namespace "urn:ietf:params:xml:ns:yang:ietf-actn-vn"; @@ -2233,25 +2251,93 @@ ] } ] }, ] } } 8. Security Considerations - TDB + The configuration, state, and action data defined in this document + are designed to be accessed via a management protocol with a secure + transport layer, such as NETCONF [RFC6241] or RESTCONF [RFC8040]. + The lowest NETCONF layer is the secure transport layer, and the + mandatory-to-implement secure transport is Secure Shell (SSH) + [RFC6242]. The lowest RESTCONF layer is HTTPS, and the mandatory- + to-implement secure transport is TLS [RFC8446]. + + The NETCONF access control model [RFC8341] provides the means to + restrict access for particular NETCONF users to a preconfigured + subset of all available NETCONF protocol operations and content. + + The model presented in this document is used in the interface + between the Customer Network Controller (CNC) and Multi-Domain + Service Coordinator (MDSC), which is referred to as CNC-MDSC + Interface (CMI). Therefore, many security risks such as malicious + attack and rogue elements attempting to connect to various ACTN + components. Furthermore, some ACTN components (e.g., MSDC) + represent a single point of failure and threat vector and must also + manage policy conflicts and eavesdropping of communication between + different ACTN components. + + A number of configuration data nodes defined in this document are + writable/deletable (i.e., "config true") These data nodes may be + considered sensitive or vulnerable in some network environments. + + These are the subtrees and data nodes and their + sensitivity/vulnerability: + + - access-point-list: + o access-point-id + o max-bandwidth + o avl-bandwidth + + - vn-ap: + o vn-ap-id + o vn + o abstract-node + o ltp + + - vn-list + o vn-id + o vn-topology-id + o abstract-node + + - vn-member-id + o src + o src-vn-ap-id + o dest + o dest-vn-ap-id + o connectivity-matrix-id 9. IANA Considerations - TDB + This document registers the following namespace URIs in the IETF XML + registry [RFC3688]: + + -------------------------------------------------------------------- + URI: urn:ietf:params:xml:ns:yang:ietf-actn-vn + Registrant Contact: The IESG. + XML: N/A, the requested URI is an XML namespace. + -------------------------------------------------------------------- + + This document registers the following YANG modules in the YANG + Module + + Names registry [RFC6020]: + + -------------------------------------------------------------------- + name: ietf-actn-vn + namespace: urn:ietf:params:xml:ns:yang:ietf-actn-vn + reference: RFC XXXX (TDB) + -------------------------------------------------------------------- 10. Acknowledgments The authors would like to thank Xufeng Liu for his helpful comments and valuable suggestions. 11. References 11.1. Normative References @@ -2261,47 +2347,35 @@ [TE-tunnel] T. Saad, et al., "A YANG Data Model for Traffic Engineering Tunnels and Interfaces", work in progress: draft-ietf-teas-yang-te. 11.2. Informative References [RFC7926] A. Farrel (Ed.), "Problem Statement and Architecture for Information Exchange between Interconnected Traffic- Engineered Networks", RFC 7926, July 2016. - [ACTN-REQ] Lee, et al., "Requirements for Abstraction and Control of - TE Networks", draft-ietf-teas-actn-requirements, work in - progress. - - [ACTN-FWK] D. Ceccarelli, Y. Lee [Editors], "Framework for + [RFC8453] D. Ceccarelli and Y. Lee (Editors), "Framework for Abstraction and Control of Traffic Engineered Networks", - draft-ceccarelli-teas-actn-framework, work in progress. + RFC 8453, August 2018. [TE-MAP] Y. Lee, D. Dhody, and D. Ceccarelli, "Traffic Engineering and Service Mapping Yang Model", draft-lee-teas-te- service-mapping-yang, work in progress. - [SERVICE-YANG] Q. Wu, W. Liu and A. Farrel, "Service Models - Explained", draft-wu-opsawg-service-model-explained, - work in progress. - [ACTN-PM] Y. Lee, et al., "YANG models for ACTN TE Performance Monitoring Telemetry and Network Autonomics", draft-lee- teas-actn-pm-telemetry-autonomics, work in progress. - [OIF-VTNS] Virtual Transport Network Services 1.0 Specification, IA - OIF-VTNS-1.0, April 2017. - [L1CSM] G. Fioccola, Ed. & Y. Lee, Ed., "A Yang Data Model for L1 Connectivity Service Model (L1CSM)", draft-ietf-ccamp- l1csm-yang, work in progress. - [L2SM] G. Fioccola, Ed., "A YANG Data Model for L2VPN Service Delivery", draft-ietf-l2sm-l2vpn-service-model, work in progress. [RFC8299] Q. Wu, Ed., S. Litkowski, L. Tomotaki, and K. Ogaki, "YANG Data Model for L3VPN Service Delivery", RFC 8299, January 2018. [RFC8309] Q. Wu, W. Cheng, and A. Farrel. "Service Models Explained", RFC 8309, January 2018. @@ -2299,20 +2373,30 @@ Delivery", draft-ietf-l2sm-l2vpn-service-model, work in progress. [RFC8299] Q. Wu, Ed., S. Litkowski, L. Tomotaki, and K. Ogaki, "YANG Data Model for L3VPN Service Delivery", RFC 8299, January 2018. [RFC8309] Q. Wu, W. Cheng, and A. Farrel. "Service Models Explained", RFC 8309, January 2018. + [RFC8340] M. Bjorklund and L. Berger (Editors), "YANG Tree + Diagrams", RFC 8340, March 2018. + + [RFC8345] A. Clemm, et al, "A YANG Data Model for Network + Topologies", RFC 8345, March 2018. + + [RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., + and R. Wilton, "Network Management Datastore Architecture + (NMDA)", RFC 8342, March 2018. + 12. Contributors Contributor's Addresses Haomian Zheng Huawei Technologies Email: zhenghaomian@huawei.com Xian Zhang Huawei Technologies @@ -2325,24 +2409,23 @@ Takuya Miyasaka KDDI Email: ta-miyasaka@kddi.com Authors' Addresses Young Lee (ed.) Huawei Technologies Email: leeyoung@huawei.com - Dhruv Dhody + 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