draft-ietf-teas-actn-vn-yang-04.txt   draft-ietf-teas-actn-vn-yang-05.txt 
TEAS Working Group Y. Lee (Editor) TEAS Working Group Y. Lee (Editor)
Internet Draft Dhruv Dhody (Editor) Internet Draft Futurewei
Intended Status: Standard Track Huawei Intended Status: Standard Track
Expires: August 3, 2019 D. Ceccarelli Expires: December 13, 2019 D. Dhody (Editor)
Ericsson
Igor Bryskin
Huawei Huawei
Bin Yeong Yoon
D. Ceccarelli
Ericsson
I. Bryskin
Futurewei
B. Yoon
ETRI ETRI
Qin Wu
Huawei
Peter Park
KT
February 4, 2019 June 13, 2019
A Yang Data Model for VN Operation A Yang Data Model for VN Operation
draft-ietf-teas-actn-vn-yang-04 draft-ietf-teas-actn-vn-yang-05
Abstract Abstract
This document provides a YANG data model generally applicable to any This document provides a YANG data model generally applicable to any
mode of Virtual Network (VN) operation. mode of Virtual Network (VN) operation.
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with This Internet-Draft is submitted to IETF in full conformance with
the provisions of BCP 78 and BCP 79. the provisions of BCP 78 and BCP 79.
skipping to change at page 1, line 48 skipping to change at page 1, line 49
months and may be updated, replaced, or obsoleted by other documents months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as at any time. It is inappropriate to use Internet-Drafts as
reference material or to cite them other than as "work in progress." reference material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html 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 Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 32 skipping to change at page 2, line 32
Introduction.....................................................3 Introduction.....................................................3
1.................................................................3 1.................................................................3
1.1. Terminology...............................................4 1.1. Terminology...............................................4
1.2. Tree diagram..............................................4 1.2. Tree diagram..............................................4
1.3. Prefixes in Data Node Names...............................4 1.3. Prefixes in Data Node Names...............................4
2. Use-case of VN Yang Model in the ACTN context..................5 2. Use-case of VN Yang Model in the ACTN context..................5
2.1. Type 1 VN.................................................5 2.1. Type 1 VN.................................................5
2.2. Type 2 VN.................................................6 2.2. Type 2 VN.................................................6
3. High-Level Control Flows with Examples.........................7 3. High-Level Control Flows with Examples.........................7
3.1. Type 1 VN Illustration....................................7 3.1. Type 1 VN Illustration....................................7
3.2. Type 2 VN Illustration....................................8 3.2. Type 2 VN Illustration....................................9
4. VN Model Usage................................................11 4. VN Model Usage................................................12
4.1. Customer view of VN......................................11 4.1. Customer view of VN......................................12
4.2. Auto-creation of VN by MDSC..............................11 4.2. Auto-creation of VN by MDSC..............................12
4.3. Innovative Services......................................11 4.3. Innovative Services......................................12
4.3.1. VN Compute..........................................11 4.3.1. VN Compute..........................................12
4.3.2. Multi-sources and Multi-destinations................12 4.3.2. Multi-sources and Multi-destinations................12
4.3.3. Others..............................................12 4.3.3. Others..............................................13
4.3.4. Summary.............................................13 4.3.4. Summary.............................................14
5. VN YANG Model (Tree Structure)................................13 5. VN YANG Model (Tree Structure)................................14
6. VN YANG Code..................................................15 6. VN YANG Code..................................................16
7. JSON Example..................................................27 7. JSON Example..................................................29
7.1. VN JSON..................................................28 7.1. VN JSON..................................................30
7.2. TE-topology JSON.........................................33 7.2. TE-topology JSON.........................................35
8. Security Considerations.......................................49 8. Security Considerations.......................................51
9. IANA Considerations...........................................51 9. IANA Considerations...........................................52
10. Acknowledgments..............................................51 10. Acknowledgments..............................................53
11. References...................................................52 11. References...................................................54
11.1. Normative References....................................52 11.1. Normative References....................................54
11.2. Informative References..................................52 11.2. Informative References..................................54
12. Contributors.................................................53 12. Contributors.................................................55
Authors' Addresses...............................................53 Authors' Addresses...............................................55
1. Introduction 1. Introduction
This document provides a YANG data model generally applicable to any This document provides a YANG data model generally applicable to any
mode of Virtual Network (VN) operation. mode of Virtual Network (VN) operation.
The VN model defined in this document is applicable in generic sense 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 as an independent model in and of itself. The VN model defined in
this document can also work together with other customer service this document can also work together with other customer service
models such as L3SM [RFC8299], L2SM [L2SM] and L1CSM [L1CSM] to models such as L3SM [RFC8299], L2SM [L2SM] and L1CSM [L1CSM] to
skipping to change at page 5, line 26 skipping to change at page 5, line 26
| |
+-----------------------+ +-----------------------+
| MDSC | | MDSC |
+-----------------------+ +-----------------------+
Figure 1. ACTN CMI Figure 1. ACTN CMI
Both ACTN VN YANG and TE-topology models are used over the CMI to Both ACTN VN YANG and TE-topology models are used over the CMI to
establish a VN over TE networks. 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 2.1. Type 1 VN
As defined in [RFC8453], a Virtual Network is a customer view of the 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 TE network. To recapitulate VN types from [RFC8453], Type 1 VN is
defined as follows: defined as follows:
The VN can be seen as a set of edge-to-edge abstract links (a Type 1 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 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 as an end-to-end tunnel across the underlying networks. Such tunnels
may be constructed by recursive slicing or abstraction of paths in may be constructed by recursive slicing or abstraction of paths in
skipping to change at page 8, line 15 skipping to change at page 8, line 21
+---------------+ +---------------+
L1 ------| |------ L4 L1 ------| |------ L4
L2 ------| AN 1 |------ L7 L2 ------| AN 1 |------ L7
L3 ------| |------ L8 L3 ------| |------ L8
+---------------+ +---------------+
If this VN is Type 1, the following diagram shows the message flow 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 between CNC and MDSC to instantiate this VN using VN and TE-Topology
Models. Models.
+--------+ +--------+ +--------+ +--------+
| CNC | | MDSC | | CNC | | MDSC |
+--------+ +--------+ +--------+ +--------+
| | | |
| | | |
CNC POST TE-topo | POST /nw:networks/nw:network/ | CNC POST TE-topo | POST /nw:networks/nw:network/ |
model(with Conn. | nw:node/te-node-id/tet:connectivity- | model(with Conn. | nw:node/te-node-id/ |
Matrix on one | matrices/tet:connectivity-matrix | | tet:connectivity-matrices/ |
Abstract node |---------------------------------------->| Matrix on one | tet:connectivity-matrix |
| HTTP 200 | Abstract node |-------------------------------->|
|<----------------------------------------| | HTTP 200 |
| | |<--------------------------------|
CNC POST the | POST /VN | | |
VN identifying |---------------------------------------->| If there is CNC POST the | POST /VN |
AP, VNAP and VN- | | multi-dest'n VN identifying |-------------------------------->| If there is
Members and maps | | module, then AP, VNAP and VN- | | multi-dest'n
to the TE-topo | HTTP 200 | MDSC selects a Members and maps | | module, then
|<----------------------------------------| src or dest'n to the TE-topo | HTTP 200 | MDSC selects a
| | and update |<--------------------------------| src or dest'n
| | VN YANG | | and update
CNC GET the | GET /VN | | | VN YANG
VN YANG status |---------------------------------------->| CNC GET the | GET /VN |
| | 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 3.2. Type 2 VN Illustration
For some VN members, the customer may want to "configure" explicit For some VN members, the customer may want to "configure" explicit
routes over the path that connects its two end-points. Let us routes over the path that connects its two end-points. Let us
consider the following example. 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 Where the following topology is the underlay for Abstraction Node 1
(AN1). (AN1).
S1 S2 AN1
O---------------O ............................................
________/ \______ \ . S1 S2 .
/ \ \ . O---------------O .
S3 / \ S4 \ S5 . ________/ \______ \ .
L1------O----------------------O---------O------------------L4 . / \ \ .
\ \ \ . S3/ \ S4 \ S5 .
\ \ \ L1----.-O----------------------O---------O-------.----------L4
\ S6 \ S7 \ S8 . \ \ \ .
O ----------------O---------O--------------L5 . \ \ \ .
/ \ / \ ____/ \_____________L6 . \ S6 \ S7 \ S8 .
S9 / \ /S10 \ / . O ----------------O---------O---.----------L5
L2---------O-----O---------------------O---------------------L7 . / \ / \ ____/ \__.__________L6
/ S11\____________________L8 .S9 / \ /S10 \ / .
L3-------- L2-----.---O-----O---------------------O----------.----------L7
. / S11\_________.__________L8
L3-----.-- .
............................................
If CNC creates the single abstract topology, the following diagram There are two options depending on whether CNC or MDSC creates the
shows the message flow between CNC and MDSC to instantiate this VN single abstract node topology.
using VN and TE-Topology Model.
+--------+ +--------+ 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 | | MDSC |
+--------+ +--------+ +--------+ +--------+
| | | |
| | | |
CNC POST TE-topo | POST /nw:networks/nw:network/ | CNC POST TE-topo | POST /nw:networks/nw:network/ |
model(with Conn. | nw:node/te-node-id/tet:connectivity- | model(with Conn. | nw:node/te-node-id/tet:connectivity- |
Matrix on one | matrices/tet:connectivity-matrix | Matrix on one | matrices/tet:connectivity-matrix |
Abstract node and|---------------------------------------->| Abstract node and|---------------------------------------->|
Explicit paths in| | Explicit paths in| |
The conn. Matrix | HTTP 200 | The conn. Matrix | HTTP 200 |
skipping to change at page 10, line 25 skipping to change at page 10, line 42
|<----------------------------------------| |<----------------------------------------|
| | | |
| | | |
CNC GET the | GET /VN | CNC GET the | GET /VN |
VN YANG status |---------------------------------------->| VN YANG status |---------------------------------------->|
| | | |
| HTTP 200 (VN with status) | | HTTP 200 (VN with status) |
|<----------------------------------------| |<----------------------------------------|
| | | |
On the other hand, if MDSC create single node topology based VN YANG Case 2:
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.
+--------+ +--------+ On the other hand, if MDSC create the single abstract node topology
| CNC | | MDSC | 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 POST VN | | +--------+ +--------+
Identifying AP, | | | CNC | | MDSC |
VNAP and VN- | POST /VN | MDSC populates +--------+ +--------+
Members |---------------------------------------->| a single Abst. | |
| HTTP 200 | node topology | |
|<----------------------------------------| by itself CNC POST VN | |
| | Identifying AP, | |
CNC POST the | POST /VN | VNAP and VN- | POST /VN | MDSC populates
VN identifying |---------------------------------------->| Members |-------------------------------->| a single Abst.
AP, VNAP and VN- | | | HTTP 200 | node topology
Members and maps | | |<--------------------------------| by itself
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: |
CNC GET the | GET /VN | Conn. Matrix on | connectivity-matrices/ |
VN YANG status |---------------------------------------->| | tet:connectivity-matrix |
| | the Abstract Node|-------------------------------->|
| HTTP 200 (VN with status) | and explicit | |
|<----------------------------------------| paths in the | |
| | Conn. Matrix | |
| HTTP 200 |
|<--------------------------------|
| |
| |
CNC GET the | GET /VN |
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. VN Model Usage
4.1. Customer view of VN 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 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 [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 (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 customer to instantiate and view the VN as one entity, making it
skipping to change at page 12, line 26 skipping to change at page 13, line 17
destinations from which the optimal source-destination may be destinations from which the optimal source-destination may be
chosen. The following YANG module is shown for describing source chosen. The following YANG module is shown for describing source
container and destination container. The following YANG tree shows container and destination container. The following YANG tree shows
how to model multi-sources and multi-destinations. how to model multi-sources and multi-destinations.
+--rw vn +--rw vn
+--rw vn-list* [vn-id] +--rw vn-list* [vn-id]
+--rw vn-id uint32 +--rw vn-id uint32
+--rw vn-name? string +--rw vn-name? string
+--rw vn-topology-id? te-types:te-topology-id +--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-list* [vn-member-id]
&gt; /nw:networks/network/node/tet:te-node-id
| +--rw vn-member-id uint32 | +--rw vn-member-id uint32
| +--rw src | +--rw src
| | +--rw src? -> /ap/access-point-list/access-point-id | | +--rw src?
| | +--rw src-vn-ap-id? -> /ap/access-point-list/vn-ap/vn-ap-id -> /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 multi-src? boolean {multi-src-dest}?
&gt; /ap/access-point-list/vn-ap/vn-ap-id
| +--rw dest | +--rw dest
| | +--rw dest? -> /ap/access-point-list/access-point-id | | +--rw dest?
| | +--rw dest-vn-ap-id? -> /ap/access-point-list/vn-ap/vn-ap-id -> /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 multi-dest? boolean {multi-src-dest}?
&gt; /ap/access-point-list/vn-ap/vn-ap-id | +--rw connetivity-matrix-id?
| +--rw connetivity-matrix-id? -> /nw:networks/network/node/tet:te/te- -> /nw:networks/network/node/tet:te/te-node-attributes/connectivity-
node-attributes/connectivity-matrices/connectivity-matrix/id matrices/connectivity-matrix/id
| +--ro oper-status? identityref | +--ro oper-status? identityref
+--ro if-selected? boolean {multi-src-dest}? +--ro if-selected? boolean {multi-src-dest}?
+--rw admin-status? identityref +--rw admin-status? identityref
+--ro oper-status? identityref +--ro oper-status? identityref
4.3.3. Others 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 [TE-MAP]. VN to the Services such as L3SM and L2SM as described in [TE-MAP].
skipping to change at page 13, line 34 skipping to change at page 14, line 31
Members. Members.
No other details need to be set by customer, making for a No other details need to be set by customer, making for a
simplified operations for the customer. simplified operations for the customer.
* VN Type 2: Along with VN Members, the customer could also * VN Type 2: Along with VN Members, the customer could also
provide an abstract topology, this topology is provided by provide an abstract topology, this topology is provided by
the Abstract TE Topology Yang Model. the Abstract TE Topology Yang Model.
5. VN YANG Model (Tree Structure) 5. VN YANG Model (Tree Structure)
module: ietf-vn module: ietf-vn
+--rw ap +-rw ap
| +--rw access-point-list* [access-point-id] | +-rw access-point-list* [access-point-id]
| +--rw access-point-id uint32 | +-rw access-point-id uint32
| +--rw access-point-name? string | +-rw access-point-name? string
| +--rw max-bandwidth? te-types:te-bandwidth | +-rw max-bandwidth? te-types:te-bandwidth
| +--rw avl-bandwidth? te-types:te-bandwidth | +-rw avl-bandwidth? te-types:te-bandwidth
| +--rw vn-ap* [vn-ap-id] | +-rw vn-ap* [vn-ap-id]
| +--rw vn-ap-id uint32 | +-rw vn-ap-id uint32
| +--rw vn? -> /vn/vn-list/vn-id | +-rw vn?
| +--rw abstract-node? -> /nw:networks/network/node/tet:te-node-id -> /vn/vn-list/vn-id
| +--rw ltp? te-types:te-tp-id | +-rw abstract-node?
+--rw vn -> /nw:networks/network/node/tet:te-node-id
+--rw vn-list* [vn-id] | +-rw ltp?
+--rw vn-id uint32 -> /nw:networks/network/node/nt:termination-point/tet:te-tp-id
+--rw vn-name? string +-rw vn
+--rw vn-topology-id? te-types:te-topology-id +-rw vn-list* [vn-id]
+--rw abstract-node? -> /nw:networks/network/node/tet:te-node-id +-rw vn-id uint32
+--rw vn-member-list* [vn-member-id] +-rw vn-name? string
| +--rw vn-member-id uint32 +-rw vn-topology-id? te-types:te-topology-id
| +--rw src +-rw abstract-node?
| | +--rw src? -> /ap/access-point-list/access-point-id -> /nw:networks/network/node/tet:te-node-id
| | +--rw src-vn-ap-id? -> /ap/access-point-list/vn-ap/vn-ap-id +-rw vn-member-list* [vn-member-id]
| | +--rw multi-src? boolean {multi-src-dest}? | +-rw vn-member-id uint32
| +--rw dest | +-rw src
| | +--rw dest? -> /ap/access-point-list/access-point-id | | +-rw src?
| | +--rw dest-vn-ap-id? -> /ap/access-point-list/vn-ap/vn-ap-id -> /ap/access-point-list/access-point-id
| | +--rw multi-dest? boolean {multi-src-dest}? | | +-rw src-vn-ap-id?
| +--rw connetivity-matrix-id? -> /nw:networks/network/node/tet:te/te- -> /ap/access-point-list/vn-ap/vn-ap-id
node-attributes/connectivity-matrices/connectivity-matrix/id | | +-rw multi-src? boolean {multi-src-dest}?
| +--ro oper-status? identityref | +-rw dest
+--ro if-selected? boolean {multi-src-dest}? | | +-rw dest?
+--rw admin-status? identityref -> /ap/access-point-list/access-point-id
+--ro oper-status? identityref | | +-rw dest-vn-ap-id?
+--rw vn-level-diversity? vn-disjointness -> /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: rpcs:
+---x vn-compute +--x vn-compute
+---w input +--w input
| +---w abstract-node? -> /nw:networks/network/node/tet:te-node-id | +--w abstract-node?
| +---w vn-member-list* [vn-member-id] -> /nw:networks/network/node/tet:te-node-id
| | +---w vn-member-id uint32 | +--w vn-member-list* [vn-member-id]
| | +---w src | | +--w vn-member-id uint32
| | | +---w src? -> /ap/access-point-list/access-point-id | | +--w src
| | | +---w src-vn-ap-id? -> /ap/access-point-list/vn-ap/vn-ap-id | | | +--w src?
| | | +---w multi-src? boolean {multi-src-dest}? -> /ap/access-point-list/access-point-id
| | +---w dest | | | +--w src-vn-ap-id?
| | | +---w dest? -> /ap/access-point-list/access-point-id -> /ap/access-point-list/vn-ap/vn-ap-id
| | | +---w dest-vn-ap-id? -> /ap/access-point-list/vn-ap/vn-ap-id | | | +--w multi-src? boolean {multi-src-dest}?
| | | +---w multi-dest? boolean {multi-src-dest}? | | +--w dest
| | +---w connetivity-matrix-id? -> | | | +--w dest?
/nw:networks/network/node/tet:te/te-node-attributes/connectivity- -> /ap/access-point-list/access-point-id
matrices/connectivity-matrix/id | | | +--w dest-vn-ap-id?
| +---w vn-level-diversity? vn-disjointness -> /ap/access-point-list/vn-ap/vn-ap-id
+--ro output | | | +--w multi-dest? boolean {multi-src-dest}?
+--ro vn-member-list* [vn-member-id] | | +--w connectivity-matrix-id?
+--ro vn-member-id uint32 -> /nw:networks/network/node/tet:te/te-node-attributes
+--ro src /connectivity-matrices/connectivity-matrix/id
| +--ro src? -> /ap/access-point-list/access-point-id | +--w vn-level-diversity? vn-disjointness
| +--ro src-vn-ap-id? -> /ap/access-point-list/vn-ap/vn-ap-id +-ro output
| +--ro multi-src? boolean {multi-src-dest}? +-ro vn-member-list* [vn-member-id]
+--ro dest +-ro vn-member-id uint32
| +--ro dest? -> /ap/access-point-list/access-point-id +-ro src
| +--ro dest-vn-ap-id? -> /ap/access-point-list/vn-ap/vn-ap-id | +-ro src? ->
| +--ro multi-dest? boolean {multi-src-dest}? /ap/access-point-list/access-point-id
+--ro connetivity-matrix-id? -> | +-ro src-vn-ap-id? ->
/nw:networks/network/node/tet:te/te-node-attributes/connectivity- /ap/access-point-list/vn-ap/vn-ap-id
matrices/connectivity-matrix/id | +-ro multi-src? boolean {multi-src-dest}?
+--ro if-selected? boolean {multi-src-dest}? +-ro dest
+--ro compute-status? Identityref | +-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 6. VN YANG Code
The YANG code is as follows: The YANG code is as follows:
<CODE BEGINS> file "ietf-vn@2019-02-04.yang" <CODE BEGINS> file "ietf-vn@2019-06-20.yang"
module ietf-vn { module ietf-vn {
yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-vn"; namespace "urn:ietf:params:xml:ns:yang:ietf-vn";
prefix "vn"; prefix "vn";
/* Import network */ /* Import network */
import ietf-network { import ietf-network {
prefix "nw"; 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 TE generic types */
import ietf-te-types { import ietf-te-types {
prefix "te-types"; prefix "te-types";
reference
"I-D.ietf-teas-yang-te-types: Traffic Engineering
Common YANG Types";
} }
/* Import Abstract TE Topology */ /* Import Abstract TE Topology */
import ietf-te-topology { import ietf-te-topology {
prefix "tet"; prefix "tet";
reference
"I-D.ietf-teas-yang-te-topo: YANG Data Model for
Traffic Engineering (TE) Topologies";
} }
organization organization
"IETF Traffic Engineering Architecture and Signaling (TEAS) "IETF Traffic Engineering Architecture and Signaling (TEAS)
Working Group"; Working Group";
contact contact
"Editor: Young Lee <leeyoung@huawei.com> "Editor: Young Lee <younglee.tx@gmail.com>
: Dhruv Dhody <dhruv.ietf@gmail.com>"; : Dhruv Dhody <dhruv.ietf@gmail.com>";
description description
"This module contains a YANG module for the VN. It "This module contains a YANG module for the VN. It
describes a VN operation module that takes place in the describes a VN operation module that takes place in the
context of the CNC-MDSC Interface (CMI) of the ACTN context of the CNC-MDSC Interface (CMI) of the ACTN
architecture where the CNC is the actor of a VN architecture where the CNC is the actor of a VN
Instantiation/modification /deletion."; Instantiation/modification /deletion.";
revision 2019-02-04 { revision 2019-06-10 {
description description
"initial version."; "initial version.";
reference reference
"TBD"; "TBD";
} }
/* /*
* Features * Features
*/ */
feature multi-src-dest { feature multi-src-dest {
description description
skipping to change at page 18, line 33 skipping to change at page 20, line 19
"unique identifier for the referred "unique identifier for the referred
VNAP"; VNAP";
} }
leaf vn { leaf vn {
type leafref { type leafref {
path "/vn/vn-list/vn-id"; path "/vn/vn-list/vn-id";
} }
description description
"reference to the VN"; "reference to the VN";
} }
leaf abstract-node { leaf abstract-node {
type leafref { type leafref {
path "/nw:networks/nw:network/nw:node/" path "/nw:networks/nw:network/nw:node/"
+ "tet:te-node-id"; +"tet:te-node-id";
} }
description description
"a reference to the abstract node in TE "a reference to the abstract node in TE
Topology"; Topology";
} }
leaf ltp { 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 description
"Reference LTP in the TE-topology"; "Reference LTP in the TE-topology";
} }
} }
grouping access-point{ grouping access-point{
description description
"AP related information"; "AP related information";
leaf access-point-id { leaf access-point-id {
type uint32; type uint32;
description description
skipping to change at page 21, line 9 skipping to change at page 22, line 43
"reference to dest VNAP"; "reference to dest VNAP";
} }
leaf multi-dest { leaf multi-dest {
if-feature multi-src-dest; if-feature multi-src-dest;
type boolean; type boolean;
description description
"Is destination part of multi-destination, where "Is destination part of multi-destination, where
only one of the destination is enabled"; only one of the destination is enabled";
} }
} }
leaf connetivity-matrix-id{ leaf connectivity-matrix-id{
type leafref { type leafref {
path "/nw:networks/nw:network/nw:node/tet:te/" path "/nw:networks/nw:network/nw:node/tet:te/"
+ "tet:te-node-attributes/" + "tet:te-node-attributes/"
+ "tet:connectivity-matrices/" + "tet:connectivity-matrices/"
+ "tet:connectivity-matrix/tet:id"; + "tet:connectivity-matrix/tet:id";
} }
description description
"reference to connetivity-matrix"; "reference to connectivity-matrix";
} }
}//vn-member }//vn-member
/* /*
grouping policy { grouping policy {
description description
"policy related to vn-member-id"; "policy related to vn-member-id";
leaf local-reroute { leaf local-reroute {
type boolean; type boolean;
description description
"Policy to state if reroute "Policy to state if reroute
skipping to change at page 53, line 38 skipping to change at page 55, line 38
Nokia Nokia
Email: sergio.belotti@nokia.com Email: sergio.belotti@nokia.com
Takuya Miyasaka Takuya Miyasaka
KDDI KDDI
Email: ta-miyasaka@kddi.com Email: ta-miyasaka@kddi.com
Authors' Addresses Authors' Addresses
Young Lee (ed.) Young Lee (ed.)
Huawei Technologies Futurewei Technologies
Email: leeyoung@huawei.com Email: younglee.tx@gmail.com
Dhruv Dhody (ed.) Dhruv Dhody (ed.)
Huawei Technologies Huawei Technologies
Email: dhruv.ietf@gmail.com Email: dhruv.ietf@gmail.com
Daniele Ceccarelli Daniele Ceccarelli
Ericsson Ericsson
Torshamnsgatan,48 Torshamnsgatan,48
Stockholm, Sweden Stockholm, Sweden
Email: daniele.ceccarelli@ericsson.com Email: daniele.ceccarelli@ericsson.com
Igor Bryskin Igor Bryskin
Huawei Huawei
Email: Igor.Bryskin@huawei.com Email: ibryskin@futurewei.com
Bin Yeong Yoon Bin Yeong Yoon
ETRI ETRI
Email: byyun@etri.re.kr Email: byyun@etri.re.kr
Qin Wu Qin Wu
Huawei Technologies Huawei Technologies
Email: bill.wu@huawei.com Email: bill.wu@huawei.com
Peter Park Peter Park
 End of changes. 42 change blocks. 
211 lines changed or deleted 281 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/