--- 1/draft-ietf-teas-actn-vn-yang-08.txt 2020-07-13 12:14:20.003064390 -0700 +++ 2/draft-ietf-teas-actn-vn-yang-09.txt 2020-07-13 12:14:20.131067627 -0700 @@ -1,25 +1,25 @@ TEAS Working Group Y. Lee, Ed. Internet-Draft Samsung Electronics Intended status: Standards Track D. Dhody, Ed. -Expires: September 9, 2020 Huawei Technologies +Expires: January 14, 2021 Huawei Technologies D. Ceccarelli Ericsson I. Bryskin Individual B. Yoon ETRI - March 8, 2020 + July 13, 2020 - A Yang Data Model for VN Operation - draft-ietf-teas-actn-vn-yang-08 + A YANG Data Model for VN Operation + draft-ietf-teas-actn-vn-yang-09 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 in full conformance with the provisions of BCP 78 and BCP 79. @@ -27,191 +27,195 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on September 9, 2020. + This Internet-Draft will expire on January 14, 2021. Copyright Notice Copyright (c) 2020 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 + 1.1.1. Requirements Language . . . . . . . . . . . . . . . . 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 . . . . . . . . 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 3.2.1. VN and AP Usage . . . . . . . . . . . . . . . . . . . 11 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 . . . . . . . . . . . . . . . . . . . . . . . 13 4.3.4. Summary . . . . . . . . . . . . . . . . . . . . . . . 14 5. VN YANG Model (Tree Structure) . . . . . . . . . . . . . . . 14 - 6. VN YANG Code . . . . . . . . . . . . . . . . . . . . . . . . 16 - 7. JSON Example . . . . . . . . . . . . . . . . . . . . . . . . 26 - 7.1. VN JSON . . . . . . . . . . . . . . . . . . . . . . . . . 26 - 7.2. TE-topology JSON . . . . . . . . . . . . . . . . . . . . 32 - 8. Security Considerations . . . . . . . . . . . . . . . . . . . 48 - 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 50 - 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 50 - 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 50 + 6. VN YANG Model . . . . . . . . . . . . . . . . . . . . . . . . 16 + 7. JSON Example . . . . . . . . . . . . . . . . . . . . . . . . 27 + 7.1. VN JSON . . . . . . . . . . . . . . . . . . . . . . . . . 27 + 7.2. TE-topology JSON . . . . . . . . . . . . . . . . . . . . 33 + 8. Security Considerations . . . . . . . . . . . . . . . . . . . 49 + 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 51 + 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 51 + 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 51 11.1. Normative References . . . . . . . . . . . . . . . . . . 51 - 11.2. Informative References . . . . . . . . . . . . . . . . . 52 - Appendix A. Contributors Addresses . . . . . . . . . . . . . . . 53 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 54 + 11.2. Informative References . . . . . . . . . . . . . . . . . 53 + Appendix A. Performance Constraints . . . . . . . . . . . . . . 54 + Appendix B. Contributors Addresses . . . . . . . . . . . . . . . 54 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 55 1. Introduction - This document provides a YANG data model generally applicable to any - mode of Virtual Network (VN) operation. + This document provides a YANG [RFC7950] 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 [RFC8466] and L1CSM [I-D.ietf-ccamp-l1csm-yang] to provide a complete life-cycle service management and operations. The YANG model discussed in this document basically provides the following: o Characteristics of Access Points (APs) that describe customer's end point characteristics; o Characteristics of Virtual Network Access Points (VNAP) that - describe How an AP is partitioned for multiple VNs sharing the AP + describe how an AP is partitioned for multiple VNs sharing the AP and its reference to a Link Termination Point (LTP) of the Provider Edge (PE) Node; o Characteristics of Virtual Networks (VNs) that describe the - customer's VNs in terms of VN Members comprising a VN, multi- - source and/or multi-destination characteristics of VN Member, the - VN's reference to TE-topology's Abstract Node; + customer's VN in terms of multiple VN Members comprising a VN, + multi- source and/or multi-destination characteristics of the VN + Member, the VN's reference to TE-topology's Abstract Node; The actual VN instantiation and computation is performed with Connectivity Matrices sub-module of TE-Topology Model [I-D.ietf-teas-yang-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 [I-D.ietf-teas-yang-te] Model will inevitably interact with TE- Topology model for setting up actual tunnels and LSPs under the tunnels. 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]. ACTN is the primary example of the - usage of the VN Yang model. + usage of the VN YANG model. - Sections 2 and 3 provide the discussion of how the VN Yang model is + Sections 2 and 3 provide the discussion of how the VN YANG model is applicable to the ACTN context where Virtual Network Service (VNS) operation is 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. The VN operational state is included in the same tree as the configuration consistent with Network Management Datastore Architecture (NMDA) [RFC8342]. The origin of the data is indicated as per the origin metadata annotation. 1.1. Terminology Refer to [RFC8453], [RFC7926], and [RFC8309] for the key terms used in this document. +1.1.1. Requirements Language + + 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. + 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-vn | [RFCXXXX] | + | inet | ietf-inet-types | [RFC6991] | | nw | ietf-network | [RFC8345] | | nt | ietf-network-topology | [RFC8345] | - | te-types | ietf-te-types | [I-D.ietf-teas-yang-te] | + | te-types | ietf-te-types | [RFC8776] | | te-topo | ietf-te-topology | [I-D.ietf-teas-yang-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. Use-case of VN Yang Model in the ACTN context +2. Use-case of VN YANG Model in the ACTN context In this section, ACTN is being used to illustrate the general usage - of the VN yang model. The model presented in this section has the + of the VN YANG model. The model presented in this section has the following ACTN context. +-------+ | CNC | +-------+ | | VN YANG + TE-topology YANG | +-----------------------+ | 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 @@ -475,40 +479,40 @@ added later. To achieve this the 'ap' container has a leaf for 'pe' node that allows AP to be created with PE information. The vn-member (and vn) could use APs that only have PE information initially. 4. VN Model Usage 4.1. Customer view of VN - The VN-Yang model allows to define a customer view, and allows the + The VN-YANG model allows to define a customer view, and allows the customer to communicate using the VN constructs as described in the [RFC8454]. 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 [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. Auto-creation of VN by MDSC The VN could be configured at the MDSC explicitly by the CNC using - the VN yang model. In some other cases, the VN is not explicitly + the 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 VN - yang model can be used by the CNC to learn details of the underlying + 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 VN Model 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. @@ -522,175 +526,181 @@ 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 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-id vn-id +--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 vn-member-id vn-member-id | +--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? leafref | +--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 vn-level-diversity? te-types:te-path-disjointness 4.3.3. Others - The VN Yang model can be easily augmented to support the mapping of + 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 [I-D.ietf-teas-te-service-mapping-yang]. - The VN Yang model can be extended to support telemetry, performance + The VN YANG model can be extended to support telemetry, performance monitoring and network autonomics as described in [I-D.ietf-teas-actn-pm-telemetry-autonomics]. 4.3.4. Summary This section summarizes the innovative service features of the VN - Yang. + 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) o Multi-Source / Multi-Destination o Ability to support various VN and VNS Types * VN Type 1: Customer configures the VN as a set of VN Members. 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. + 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 access-point-id access-point-id | +--rw pe? | | -> /nw:networks/network/node/tet:te-node-id | +--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-ap-id access-point-id | +--rw vn? -> /vn/vn-list/vn-id | +--rw abstract-node? | | -> /nw:networks/network/node/tet:te-node-id | +--rw ltp? leafref + | +--ro max-bandwidth? te-types:te-bandwidth +--rw vn +--rw vn-list* [vn-id] - +--rw vn-id uint32 - +--rw vn-name? string + +--rw vn-id vn-id +--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 vn-member-id vn-member-id | +--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? leafref | +--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 vn-level-diversity? te-types:te-path-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 vn-member-id vn-member-id | | +---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? leafref - | +---w vn-level-diversity? vn-disjointness + | +---w vn-level-diversity? te-types:te-path-disjointness +--ro output +--ro vn-member-list* [vn-member-id] - +--ro vn-member-id uint32 + +--ro vn-member-id vn-member-id +--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? leafref +--ro if-selected? boolean | {multi-src-dest}? +--ro compute-status? identityref -6. VN YANG Code +6. VN YANG Model - The YANG code is as follows: + The YANG model is as follows: - file "ietf-vn@2020-03-08.yang" + file "ietf-vn@2020-07-13.yang" module ietf-vn { yang-version 1.1; namespace "urn:ietf:params:xml:ns:yang:ietf-vn"; prefix vn; + /* Import inet-types */ + + import ietf-inet-types { + prefix inet; + reference + "RFC 6991: Common YANG Data Types"; + } + /* Import network */ import ietf-network { prefix nw; reference "RFC 8345: A YANG Data Model for Network Topologies"; } /* Import network topology */ @@ -694,27 +704,26 @@ /* Import network topology */ import ietf-network-topology { prefix nt; reference "RFC 8345: A YANG Data Model for Network Topologies"; } /* Import TE Common types */ - import ietf-te-types { prefix te-types; reference - "I-D.ietf-teas-yang-te-types: Traffic Engineering Common - YANG Types"; + "RFC 8776: Common YANG Data Types for Traffic Engineering"; } + /* Import 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 @@ -722,53 +731,58 @@ Working Group"; contact "WG Web: WG List: 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. + CNC is the actor of a VN Instantiation/modification/deletion + as per RFC 8453. Copyright (c) 2020 IETF Trust and the persons identified as authors of the code. All rights reserved. Redistribution and use in source and binary forms, with or without modification, is permitted pursuant to, and subject to the license terms contained in, the Simplified BSD License set forth in Section 4.c of the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info). This version of this YANG module is part of RFC XXXX; see the RFC itself for full legal notices. 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 (RFC 2119) (RFC 8174) when, and only when, they appear in all capitals, as shown here."; - revision 2020-03-08 { + revision 2020-07-13 { description "initial version."; reference - "RFC XXXX: A Yang Data Model for VN Operation"; + "RFC XXXX: A YANG Data Model for VN Operation"; } + /* Features */ feature multi-src-dest { description "Support for selection of one src or destination among multiple."; + reference + "RFC 8453: Framework for Abstraction and Control of TE + Networks (ACTN)"; } /* Identity VN State*/ identity vn-state-type { description "Base identity for VN state"; } identity vn-state-up { @@ -813,206 +829,236 @@ description "State path compute in progress"; } identity vn-compute-state-computation-ok { base vn-compute-state-type; description "State path compute successful"; } - identity vn-compute-state-computatione-failed { + identity vn-compute-state-computation-failed { base vn-compute-state-type; description "State path compute failed"; } - /* typedef */ + /* Typedef */ - typedef vn-disjointness { - type bits { - bit node { - position 0; - description - "node disjoint"; - } - bit link { - position 1; + typedef vn-id { + type inet:uri; description - "link disjoint"; + "Identifier for a VN. The precise structure of the + vn-id will be up to the implementation. The + identifier SHOULD be chosen such that the same VN + will always be identified through the same + identifier, even if the data model is instantiated + in separate datastores."; } - bit srlg { - position 2; + + typedef access-point-id { + type inet:uri; description - "srlg disjoint"; - } + "Identifier for an AP. The precise structure of the + access-point-id will be up to the implementation. + The identifier SHOULD be chosen such that the same AP + will always be identified through the same + identifier, even if the data model is instantiated + in separate datastores. This type is used for both AP + and VNAP"; } + + typedef vn-member-id { + type inet:uri; description - "type of the resource disjointness for VN level applied - across all VN members in a VN"; + "Identifier for a VN member. The precise structure of + the vn-member-id will be up to the implementation. + The identifier SHOULD be chosen such that the same VN + member will always be identified through the same + identifier, even if the data model is instantiated + in separate datastores. "; } + /* Groupings */ grouping vn-ap { description "VNAP related information"; leaf vn-ap-id { - type uint32; + type access-point-id; description - "unique identifier for the referred VNAP"; + "A unique identifier for the referred VNAP"; } leaf vn { type leafref { path "/vn/vn-list/vn-id"; } description - "reference to the VN"; + "A reference to the VN"; } 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 that + "A reference to the abstract node in TE Topology that represent the VN"; } leaf ltp { type leafref { path "/nw:networks/nw:network/nw:node/" + "nt:termination-point/tet:te-tp-id"; } description - "Reference LTP in the TE-topology"; + "A reference LTP in the TE-topology"; + reference + "I-D.ietf-teas-yang-te-topo: YANG Data Model for Traffic + Engineering (TE) Topologies"; + } + leaf max-bandwidth { + type te-types:te-bandwidth; + config false; + description + "The max bandwidth of the VNAP"; } + reference + "RFC 8453: Framework for Abstraction and Control of TE + Networks (ACTN)"; } //vn-ap grouping access-point { description "AP related information"; leaf access-point-id { - type uint32; - description - "unique identifier for the referred access point"; - } - leaf access-point-name { - type string; + type access-point-id; description - "ap name"; + "A unique identifier for the referred access point"; } leaf pe { type leafref { path "/nw:networks/nw:network/nw:node/tet:te-node-id"; } description - "a reference to the PE node in the native TE Topology"; + "A reference to the PE node in the native TE Topology"; } leaf max-bandwidth { type te-types:te-bandwidth; description - "max bandwidth of the AP"; + "The max bandwidth of the AP"; } leaf avl-bandwidth { type te-types:te-bandwidth; description - "available bandwidth of the AP"; + "The available bandwidth of the AP"; } /*add details and any other properties of AP, not associated by a VN CE port, PE port etc. + */ list vn-ap { key "vn-ap-id"; uses vn-ap; description - "list of VNAP in this AP"; + "List of VNAP in this AP"; } + reference + "RFC 8453: Framework for Abstraction and Control of TE + Networks (ACTN)"; } //access-point grouping vn-member { description - "vn-member is described by this container"; + "The vn-member is described by this grouping"; leaf vn-member-id { - type uint32; + type vn-member-id; description - "vn-member identifier"; + "A vn-member identifier"; } container src { description - "the source of VN Member"; + "The source of VN Member"; leaf src { type leafref { path "/ap/access-point-list/access-point-id"; } description - "reference to source AP"; + "A reference to source AP"; } leaf src-vn-ap-id { type leafref { path "/ap/access-point-list/vn-ap/vn-ap-id"; } description - "reference to source VNAP"; + "A reference to source VNAP"; } leaf multi-src { if-feature "multi-src-dest"; type boolean; description - "Is source part of multi-source, where + "Is the source part of multi-source, where only one of the source is enabled"; } } container dest { description "the destination of VN Member"; + leaf dest { type leafref { path "/ap/access-point-list/access-point-id"; } description - "reference to destination AP"; + "A reference to destination AP"; } leaf dest-vn-ap-id { type leafref { path "/ap/access-point-list/vn-ap/vn-ap-id"; } description - "reference to dest VNAP"; + "A 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 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 connectivity-matrix"; - + "A reference to connectivity-matrix"; + reference + "I-D.ietf-teas-yang-te-topo: YANG Data Model for Traffic + Engineering (TE) Topologies"; } + reference + "RFC 8454: Information Model for Abstraction and Control of TE + Networks (ACTN)"; } //vn-member grouping vn-policy { description "policy for VN-level diverisity"; leaf vn-level-diversity { - type vn-disjointness; + type te-types:te-path-disjointness; description - "the type of disjointness on the VN level (i.e., across all + "The type of disjointness on the VN level (i.e., across all VN members)"; + } } /* Configuration data nodes */ container ap { description "AP configurations"; list access-point-list { key "access-point-id"; @@ -1013,67 +1059,65 @@ container ap { description "AP configurations"; list access-point-list { key "access-point-id"; description "access-point identifier"; uses access-point { description - "access-point information"; + "The access-point information"; } } + reference + "RFC 8453: Framework for Abstraction and Control of TE + Networks (ACTN)"; } container vn { description "VN configurations"; list vn-list { key "vn-id"; description - "a virtual network is identified by a vn-id"; + "A virtual network is identified by a vn-id"; leaf vn-id { - type uint32; - description - "a unique vn identifier"; - } - leaf vn-name { - type string; + type vn-id; description - "vn name"; + "A unique VN identifier"; } leaf vn-topology-id { type te-types:te-topology-id; description "An optional identifier to the TE Topology Model where the abstract nodes and links of the Topology can be found for Type 2 VNS"; } 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"; + "A reference to the abstract node in TE Topology"; } list vn-member-list { key "vn-member-id"; description - "List of VN-members in a VN"; + "List of vn-members in a VN"; uses vn-member; leaf oper-status { type identityref { base vn-state-type; } config false; description - "VN-member operational state."; + "The vn-member operational state."; } } leaf if-selected { if-feature "multi-src-dest"; type boolean; default "false"; config false; description "Is the vn-member is selected among the multi-src/dest options"; @@ -1089,34 +1133,37 @@ leaf oper-status { type identityref { base vn-state-type; } config false; description "VN operational state."; } uses vn-policy; } //vn-list + reference + "RFC 8453: Framework for Abstraction and Control of TE + Networks (ACTN)"; } //vn /* RPC */ rpc vn-compute { description "The VN computation without actual instantiation"; input { 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"; + "A reference to the abstract node in TE Topology"; } list vn-member-list { key "vn-member-id"; description "List of VN-members in a VN"; uses vn-member; } uses vn-policy; } output { @@ -1131,28 +1178,28 @@ default "false"; description "Is the vn-member is selected among the multi-src/dest options"; } leaf compute-status { type identityref { base vn-compute-state-type; } description - "VN-member compute state."; - + "The VN-member compute state."; } } } } //vn-compute } + 7. JSON Example This section provides json implementation examples as to how VN YANG model and TE topology model are used together to instantiate virtual networks. The example in this section includes following VN @@ -2323,137 +2374,171 @@ -------------------------------------------------------------------- name: ietf-vn namespace: urn:ietf:params:xml:ns:yang:ietf-vn prefix: vn reference: RFC XXXX (TDB) -------------------------------------------------------------------- 10. Acknowledgments - The authors would like to thank Xufeng Liu and Adrian Farrel for - their helpful comments and valuable suggestions. + The authors would like to thank Xufeng Liu, Adrian Farrel, Tom Petch, + and Kenichi Ogaki for their helpful comments and valuable + suggestions. 11. References + 11.1. Normative References [I-D.ietf-teas-yang-te] Saad, T., Gandhi, R., Liu, X., Beeram, V., and I. Bryskin, "A YANG Data Model for Traffic Engineering Tunnels and - Interfaces", draft-ietf-teas-yang-te-22 (work in - progress), November 2019. + Interfaces", draft-ietf-teas-yang-te-23 (work in + progress), March 2020. [I-D.ietf-teas-yang-te-topo] Liu, X., Bryskin, I., Beeram, V., Saad, T., Shah, H., and O. Dios, "YANG Data Model for Traffic Engineering (TE) Topologies", draft-ietf-teas-yang-te-topo-22 (work in progress), June 2019. + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, + DOI 10.17487/RFC2119, March 1997, + . + [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, DOI 10.17487/RFC3688, January 2004, . [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)", RFC 6020, DOI 10.17487/RFC6020, October 2010, . [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., and A. Bierman, Ed., "Network Configuration Protocol (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, . [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, . + [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", + RFC 6991, DOI 10.17487/RFC6991, July 2013, + . + + [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", + RFC 7950, DOI 10.17487/RFC7950, August 2016, + . + [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, . + [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC + 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, + May 2017, . + + [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", + BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, + . + [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration Access Control Model", STD 91, RFC 8341, DOI 10.17487/RFC8341, March 2018, . + [RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., + and R. Wilton, "Network Management Datastore Architecture + (NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018, + . + [RFC8345] Clemm, A., Medved, J., Varga, R., Bahadur, N., Ananthakrishnan, H., and X. Liu, "A YANG Data Model for Network Topologies", RFC 8345, DOI 10.17487/RFC8345, March 2018, . [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, . + [RFC8776] Saad, T., Gandhi, R., Liu, X., Beeram, V., and I. Bryskin, + "Common YANG Data Types for Traffic Engineering", + RFC 8776, DOI 10.17487/RFC8776, June 2020, + . + 11.2. Informative References [I-D.ietf-ccamp-l1csm-yang] Lee, Y., Lee, K., Zheng, H., Dhody, D., Dios, O., and D. Ceccarelli, "A YANG Data Model for L1 Connectivity Service - Model (L1CSM)", draft-ietf-ccamp-l1csm-yang-10 (work in - progress), September 2019. + Model (L1CSM)", draft-ietf-ccamp-l1csm-yang-11 (work in + progress), March 2020. [I-D.ietf-teas-actn-pm-telemetry-autonomics] Lee, Y., Dhody, D., Karunanithi, S., Vilata, R., King, D., and D. Ceccarelli, "YANG models for VN/TE Performance Monitoring Telemetry and Scaling Intent Autonomics", - draft-ietf-teas-actn-pm-telemetry-autonomics-01 (work in - progress), October 2019. + draft-ietf-teas-actn-pm-telemetry-autonomics-02 (work in + progress), March 2020. [I-D.ietf-teas-te-service-mapping-yang] Lee, Y., Dhody, D., Fioccola, G., WU, Q., Ceccarelli, D., and J. Tantsura, "Traffic Engineering (TE) and Service Mapping Yang Model", draft-ietf-teas-te-service-mapping- - yang-02 (work in progress), September 2019. + yang-03 (work in progress), March 2020. [RFC7926] Farrel, A., Ed., Drake, J., Bitar, N., Swallow, G., Ceccarelli, D., and X. Zhang, "Problem Statement and Architecture for Information Exchange between Interconnected Traffic-Engineered Networks", BCP 206, RFC 7926, DOI 10.17487/RFC7926, July 2016, . [RFC8299] Wu, Q., Ed., Litkowski, S., Tomotaki, L., and K. Ogaki, "YANG Data Model for L3VPN Service Delivery", RFC 8299, DOI 10.17487/RFC8299, January 2018, . [RFC8309] Wu, Q., Liu, W., and A. Farrel, "Service Models Explained", RFC 8309, DOI 10.17487/RFC8309, January 2018, . - [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", - BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, - . - - [RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., - and R. Wilton, "Network Management Datastore Architecture - (NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018, - . - [RFC8453] Ceccarelli, D., Ed. and Y. Lee, Ed., "Framework for Abstraction and Control of TE Networks (ACTN)", RFC 8453, DOI 10.17487/RFC8453, August 2018, . [RFC8454] Lee, Y., Belotti, S., Dhody, D., Ceccarelli, D., and B. Yoon, "Information Model for Abstraction and Control of TE Networks (ACTN)", RFC 8454, DOI 10.17487/RFC8454, September 2018, . [RFC8466] Wen, B., Fioccola, G., Ed., Xie, C., and L. Jalil, "A YANG Data Model for Layer 2 Virtual Private Network (L2VPN) Service Delivery", RFC 8466, DOI 10.17487/RFC8466, October 2018, . -Appendix A. Contributors Addresses +Appendix A. Performance Constraints + + At the time of creation of VN, it is natural to provide VN level + constraints and optimization criteria. It should be noted that this + YANG model rely on the TE-Topology Model [I-D.ietf-teas-yang-te-topo] + by using a reference to an abstract node to achieve this. Further, + connectivity-matrix structure is used to assign the constraints and + optimization criteria include delay, jitter etc. [RFC8776] define + some of the metric-types already and future documents are meant to + augment it. +Appendix B. Contributors Addresses Qin Wu Huawei Technologies Email: bill.wu@huawei.com Peter Park KT Email: peter.park@kt.com Haomian Zheng Huawei Technologies