draft-ietf-teas-actn-vn-yang-01.txt   draft-ietf-teas-actn-vn-yang-02.txt 
TEAS Working Group Y. Lee (Editor) TEAS Working Group Y. Lee (Editor)
Internet Draft Dhruv Dhody Internet Draft Dhruv Dhody (Editor)
Intended Status: Standard Track Huawei Intended Status: Standard Track Huawei
Expires: December 19, 2018 D. Ceccarelli Expires: March 19, 2019 D. Ceccarelli
Ericsson Ericsson
Igor Bryskin Igor Bryskin
Huawei Huawei
Bin Yeong Yoon Bin Yeong Yoon
ETRI ETRI
Qin Wu Qin Wu
Huawei Huawei
Peter Park Peter Park
KT KT
June 19, 2018 September 19, 2018
A Yang Data Model for ACTN VN Operation A Yang Data Model for ACTN VN Operation
draft-ietf-teas-actn-vn-yang-01 draft-ietf-teas-actn-vn-yang-02
Abstract Abstract
This document provides a YANG data model for the Abstraction and This document provides a YANG data model for the Abstraction and
Control of Traffic Engineered (TE) networks (ACTN) Virtual Network Control of Traffic Engineered (TE) networks (ACTN) Virtual Network
Service (VNS) operation. Service (VNS) 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
skipping to change at page 2, line 4 skipping to change at page 2, line 4
Internet-Drafts are draft documents valid for a maximum of six Internet-Drafts are draft documents valid for a maximum of six
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 December 19, 2018. This Internet-Draft will expire on March 19, 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
carefully, as they describe your rights and restrictions with carefully, as they describe your rights and restrictions with
respect to this document. Code Components extracted from this respect to this document. Code Components extracted from this
document must include Simplified BSD License text as described in document must include Simplified BSD License text as described in
Section 4.e of the Trust Legal Provisions and are provided without Section 4.e of the Trust Legal Provisions and are provided without
warranty as described in the Simplified BSD License. warranty as described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction...................................................3 1. Introduction...................................................3
1.1. Terminology...............................................4 1.1. Terminology...............................................4
2. ACTN CMI context...............................................4 1.2. Tree diagram..............................................4
2.1. Type 1 VN.................................................4 1.3. Prefixes in Data Node Names...............................4
2.2. Type 2 VN.................................................5 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. 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....................................8
4. Justification of the ACTN VN Model on the CMI.................10 4. Justification of the ACTN VN Model on the CMI.................11
4.1. Customer view of VN......................................10 4.1. Customer view of VN......................................11
4.2. Innovative Services......................................11 4.2. Innovative Services......................................11
4.2.1. VN Compute..........................................11 4.2.1. VN Compute..........................................11
4.2.2. Multi-sources and Multi-destinations................11 4.2.2. Multi-sources and Multi-destinations................12
4.2.3. Others..............................................12 4.2.3. Others..............................................13
4.3. Summary..................................................12 4.3. Summary..................................................13
5. ACTN VN YANG Model (Tree Structure)...........................13 5. ACTN VN YANG Model (Tree Structure)...........................13
6. ACTN-VN YANG Code.............................................15 6. ACTN-VN YANG Code.............................................15
7. JSON Example..................................................27 7. JSON Example..................................................27
7.1. ACTN VN JSON.............................................28 7.1. ACTN VN JSON.............................................28
7.2. TE-topology JSON.........................................34 7.2. TE-topology JSON.........................................33
8. Security Considerations.......................................50 8. Security Considerations.......................................49
9. IANA Considerations...........................................50 9. IANA Considerations...........................................51
10. Acknowledgments..............................................50 10. Acknowledgments..............................................51
11. References...................................................51 11. References...................................................52
11.1. Normative References....................................51 11.1. Normative References....................................52
11.2. Informative References..................................51 11.2. Informative References..................................52
12. Contributors.................................................52 12. Contributors.................................................53
Authors' Addresses...............................................52 Authors' Addresses...............................................53
1. Introduction 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 This document provides a YANG data model for the Abstraction and
Control of Traffic Engineered (TE) networks (ACTN) Virtual Network Control of Traffic Engineered (TE) networks (ACTN) Virtual Network
Service (VNS) operation that is going to be implemented for the Service (VNS) operation that is going to be implemented for the
Customer Network Controller (CNC)- Multi-Domain Service Coordinator Customer Network Controller (CNC)- Multi-Domain Service Coordinator
(MSDC) interface (CMI). (MSDC) interface (CMI).
The YANG model on the CMI is also known as customer service model in 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 [RFC8309]. The YANG model discussed in this document is used to
operate customer-driven VNs during the VN instantiation, VN operate customer-driven VNs during the VN instantiation, VN
computation, and its life-cycle service management and operations. computation, and its life-cycle service management and operations.
skipping to change at page 4, line 7 skipping to change at page 4, line 15
The actual VN instantiation and computation is performed with The actual VN instantiation and computation is performed with
Connectivity Matrices sub-module of TE-Topology Model [TE-Topo] Connectivity Matrices sub-module of TE-Topology Model [TE-Topo]
which provides TE network topology abstraction and management which provides TE network topology abstraction and management
operation. Once TE-topology Model is used in triggering VN operation. Once TE-topology Model is used in triggering VN
instantiation over the networks, TE-tunnel [TE-tunnel] Model will instantiation over the networks, TE-tunnel [TE-tunnel] Model will
inevitably interact with TE-Topology model for setting up actual inevitably interact with TE-Topology model for setting up actual
tunnels and LSPs under the tunnels. tunnels and LSPs under the tunnels.
The ACTN VN operational state is included in the same tree as the The ACTN VN operational state is included in the same tree as the
configuration consistent with Network Management Datastore configuration consistent with Network Management Datastore
Architecture (NMDA) [NMDA]. The origin of the data is indicated as Architecture (NMDA) [RFC8342]. The origin of the data is indicated
per the origin metadata annotation. as per the origin metadata annotation.
1.1. Terminology 1.1. Terminology
Refer to [ACTN-Frame], [RFC7926], and [RFC8309] for the key terms Refer to [RFC8453], [RFC7926], and [RFC8309] for the key terms used
used in this document. 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 2. ACTN CMI context
The model presented in this document has the following ACTN context. The model presented in this document has the following ACTN context.
+-------+ +-------+
| CNC | | CNC |
+-------+ +-------+
| |
| VN YANG + TE-topology YANG | VN YANG + TE-topology YANG
skipping to change at page 4, line 36 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.
2.1. Type 1 VN 2.1. Type 1 VN
As defined in [ACTN-FW], 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 [ACTN-FW], 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
the underlying networks and can encompass edge points of the the underlying networks and can encompass edge points of the
customer's network, access links, intra-domain paths, and inter- customer's network, access links, intra-domain paths, and inter-
domain links. domain links.
skipping to change at page 10, line 25 skipping to change at page 11, line 4
|<----------------------------------------| by itself |<----------------------------------------| by itself
| | | |
CNC POST the ACTN| POST /ACTN VN | CNC POST the ACTN| POST /ACTN VN |
VN identifying |---------------------------------------->| VN identifying |---------------------------------------->|
AP, VNAP and VN- | | AP, VNAP and VN- | |
Members and maps | | Members and maps | |
to the TE-topo | HTTP 200 | to the TE-topo | HTTP 200 |
|<----------------------------------------| |<----------------------------------------|
| | | |
| | | |
CNC GET the ACTN | GET /ACTN VN | CNC GET the ACTN | GET /ACTN VN |
VN YANG status |---------------------------------------->| VN YANG status |---------------------------------------->|
| | | |
| HTTP 200 (ACTN VN with 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 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
easier for some customers to work on VN without worrying about the easier for some customers to work on VN without worrying about the
details of the provider based YANG models. details of the provider based YANG models.
This is similar to the benefits of having a separate YANG model for This is similar to the benefits of having a separate YANG model for
the customer services as described in [SERVICE-YANG], which states the customer services as described in [RFC8309], which states that
that service models do not make any assumption of how a service is service models do not make any assumption of how a service is
actually engineered and delivered for a customer. 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 ACTN VN supports VN compute (pre-instantiation mode) to view the
full VN as a single entity before instantiation. Achieving this via full VN as a single entity before instantiation. Achieving this via
path computation or "compute only" tunnel setup does not provide the path computation or "compute only" tunnel setup does not provide the
same functionality. 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 In creating a virtual network, the list of sources or destinations
or both may not be pre-determined by the customer. For instance, for 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 a given source, there may be a list of multiple-destinations to
which the optimal destination may be chosen depending on the network which the optimal destination may be chosen depending on the network
resource situations. Likewise, for a given destination, there may resource situations. Likewise, for a given destination, there may
also be multiple-sources from which the optimal source may be also be multiple-sources from which the optimal source may be
chosen. In some cases, there may be a pool of multiple sources and chosen. In some cases, there may be a pool of multiple sources and
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
skipping to change at page 12, line 11 skipping to change at page 13, line 5
id id
| | +--rw dest-vn-ap-id? -> /actn/ap/access-point-list/vn-ap/vn-ap-id | | +--rw dest-vn-ap-id? -> /actn/ap/access-point-list/vn-ap/vn-ap-id
| | +--rw multi-dest? boolean {multi-src-dest}? | | +--rw multi-dest? boolean {multi-src-dest}?
| +--rw connetivity-matrix-id? -> /nw:networks/network/node/tet:te/te- | +--rw connetivity-matrix-id? -> /nw:networks/network/node/tet:te/te-
node-attributes/connectivity-matrices/connectivity-matrix/id node-attributes/connectivity-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.2.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].
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 [ACTN-PM]. 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 This section summarizes the innovative service features of the ACTN
VN Yang. VN Yang.
o Maintenance of AP and VNAP along with VN. o Maintenance of AP and VNAP along with VN.
o VN construct to group of edge-to-edge links o VN construct to group of edge-to-edge links
o VN Compute (pre-instantiate) o VN Compute (pre-instantiate)
skipping to change at page 13, line 18 skipping to change at page 14, line 6
+--rw actn +--rw actn
+--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? -> /actn/vn/vn-list/vn-id | +--rw vn? -> /actn/vn/vn-list/vn-id
| +--rw abstract-node? -> | +--rw abstract-node? -> /nw:networks/network/node/tet:te-node-id
/nw:networks/network/node/tet:te-node-id
| +--rw ltp? te-types:te-tp-id | +--rw ltp? te-types:te-tp-id
+--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? -> +--rw abstract-node? -> /nw:networks/network/node/tet:te-node-id
/nw:networks/network/node/tet:te-node-id
+--rw vn-member-list* [vn-member-id] +--rw vn-member-list* [vn-member-id]
| +--rw vn-member-id uint32 | +--rw vn-member-id uint32
| +--rw src | +--rw src
| | +--rw src? -> /actn/ap/access-point- | | +--rw src? -> /actn/ap/access-point-list/access-point-id
list/access-point-id | | +--rw src-vn-ap-id? -> /actn/ap/access-point-list/vn-ap/vn-ap-id
| | +--rw src-vn-ap-id? -> /actn/ap/access-point-
list/vn-ap/vn-ap-id
| | +--rw multi-src? boolean {multi-src-dest}? | | +--rw multi-src? boolean {multi-src-dest}?
| +--rw dest | +--rw dest
| | +--rw dest? -> /actn/ap/access-point- | | +--rw dest? -> /actn/ap/access-point-list/access-point-id
list/access-point-id | | +--rw dest-vn-ap-id? -> /actn/ap/access-point-list/vn-ap/vn-ap-id
| | +--rw dest-vn-ap-id? -> /actn/ap/access-point-
list/vn-ap/vn-ap-id
| | +--rw multi-dest? boolean {multi-src-dest}? | | +--rw multi-dest? boolean {multi-src-dest}?
| +--rw connetivity-matrix-id? -> | +--rw connetivity-matrix-id? -> /nw:networks/network/node/tet:te/te-node-
/nw:networks/network/node/tet:te/te-node-attributes/connectivity- 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
+--rw vn-level-diversity? vn-disjointness +--rw vn-level-diversity? vn-disjointness
rpcs: rpcs:
+---x vn-compute +---x vn-compute
+---w input +---w input
| +---w abstract-node? -> | +---w abstract-node? -> /nw:networks/network/node/tet:te-node-id
/nw:networks/network/node/tet:te-node-id
| +---w vn-member-list* [vn-member-id] | +---w vn-member-list* [vn-member-id]
| | +---w vn-member-id uint32 | | +---w vn-member-id uint32
| | +---w src | | +---w src
| | | +---w src? -> /actn/ap/access-point- | | | +---w src? -> /actn/ap/access-point-list/access-point-id
list/access-point-id | | | +---w src-vn-ap-id? -> /actn/ap/access-point-list/vn-ap/vn-ap-id
| | | +---w src-vn-ap-id? -> /actn/ap/access-point-
list/vn-ap/vn-ap-id
| | | +---w multi-src? boolean {multi-src-dest}? | | | +---w multi-src? boolean {multi-src-dest}?
| | +---w dest | | +---w dest
| | | +---w dest? -> /actn/ap/access-point- | | | +---w dest? -> /actn/ap/access-point-list/access-point-id
list/access-point-id | | | +---w dest-vn-ap-id? -> /actn/ap/access-point-list/vn-ap/vn-ap-id
| | | +---w dest-vn-ap-id? -> /actn/ap/access-point-
list/vn-ap/vn-ap-id
| | | +---w multi-dest? boolean {multi-src-dest}? | | | +---w multi-dest? boolean {multi-src-dest}?
| | +---w connetivity-matrix-id? -> | | +---w connetivity-matrix-id? -> /nw:networks/network/node/tet:te/te-node-
/nw:networks/network/node/tet:te/te-node-attributes/connectivity- attributes/connectivity-matrices/connectivity-matrix/id
matrices/connectivity-matrix/id
| +---w vn-level-diversity? vn-disjointness | +---w vn-level-diversity? vn-disjointness
+--ro output +--ro output
+--ro vn-member-list* [vn-member-id] +--ro vn-member-list* [vn-member-id]
+--ro vn-member-id uint32 +--ro vn-member-id uint32
+--ro src +--ro src
| +--ro src? -> /actn/ap/access-point- | +--ro src? -> /actn/ap/access-point-list/access-point-id
list/access-point-id | +--ro src-vn-ap-id? -> /actn/ap/access-point-list/vn-ap/vn-ap-id
| +--ro src-vn-ap-id? -> /actn/ap/access-point-
list/vn-ap/vn-ap-id
| +--ro multi-src? boolean {multi-src-dest}? | +--ro multi-src? boolean {multi-src-dest}?
+--ro dest +--ro dest
| +--ro dest? -> /actn/ap/access-point- | +--ro dest? -> /actn/ap/access-point-list/access-point-id
list/access-point-id | +--ro dest-vn-ap-id? -> /actn/ap/access-point-list/vn-ap/vn-ap-id
| +--ro dest-vn-ap-id? -> /actn/ap/access-point-
list/vn-ap/vn-ap-id
| +--ro multi-dest? boolean {multi-src-dest}? | +--ro multi-dest? boolean {multi-src-dest}?
+--ro connetivity-matrix-id? -> +--ro connetivity-matrix-id? -> /nw:networks/network/node/tet:te/te-node-
/nw:networks/network/node/tet:te/te-node-attributes/connectivity- attributes/connectivity-matrices/connectivity-matrix/id
matrices/connectivity-matrix/id +--ro if-selected? boolean {multi-src-dest}?
+--ro if-selected? boolean {multi-src-
dest}?
+--ro compute-status? identityref +--ro compute-status? identityref
6. ACTN-VN YANG Code 6. ACTN-VN YANG Code
The YANG code is as follows: The YANG code is as follows:
<CODE BEGINS> file "ietf-actn-vn@2018-02-27.yang" <CODE BEGINS> file "ietf-actn-vn@2018-02-27.yang"
module ietf-actn-vn { module ietf-actn-vn {
namespace "urn:ietf:params:xml:ns:yang:ietf-actn-vn"; namespace "urn:ietf:params:xml:ns:yang:ietf-actn-vn";
skipping to change at page 50, line 7 skipping to change at page 49, line 45
] ]
} }
] ]
}, },
] ]
} }
} }
8. Security Considerations 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 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 10. Acknowledgments
The authors would like to thank Xufeng Liu for his helpful comments The authors would like to thank Xufeng Liu for his helpful comments
and valuable suggestions. and valuable suggestions.
11. References 11. References
11.1. Normative References 11.1. Normative References
skipping to change at page 51, line 22 skipping to change at page 52, line 22
[TE-tunnel] T. Saad, et al., "A YANG Data Model for Traffic [TE-tunnel] T. Saad, et al., "A YANG Data Model for Traffic
Engineering Tunnels and Interfaces", work in progress: Engineering Tunnels and Interfaces", work in progress:
draft-ietf-teas-yang-te. draft-ietf-teas-yang-te.
11.2. Informative References 11.2. Informative References
[RFC7926] A. Farrel (Ed.), "Problem Statement and Architecture for [RFC7926] A. Farrel (Ed.), "Problem Statement and Architecture for
Information Exchange between Interconnected Traffic- Information Exchange between Interconnected Traffic-
Engineered Networks", RFC 7926, July 2016. Engineered Networks", RFC 7926, July 2016.
[ACTN-REQ] Lee, et al., "Requirements for Abstraction and Control of [RFC8453] D. Ceccarelli and Y. Lee (Editors), "Framework for
TE Networks", draft-ietf-teas-actn-requirements, work in
progress.
[ACTN-FWK] D. Ceccarelli, Y. Lee [Editors], "Framework for
Abstraction and Control of Traffic Engineered Networks", 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 [TE-MAP] Y. Lee, D. Dhody, and D. Ceccarelli, "Traffic Engineering
and Service Mapping Yang Model", draft-lee-teas-te- and Service Mapping Yang Model", draft-lee-teas-te-
service-mapping-yang, work in progress. 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 [ACTN-PM] Y. Lee, et al., "YANG models for ACTN TE Performance
Monitoring Telemetry and Network Autonomics", draft-lee- Monitoring Telemetry and Network Autonomics", draft-lee-
teas-actn-pm-telemetry-autonomics, work in progress. 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 [L1CSM] G. Fioccola, Ed. & Y. Lee, Ed., "A Yang Data Model for L1
Connectivity Service Model (L1CSM)", draft-ietf-ccamp- Connectivity Service Model (L1CSM)", draft-ietf-ccamp-
l1csm-yang, work in progress. l1csm-yang, work in progress.
[L2SM] G. Fioccola, Ed., "A YANG Data Model for L2VPN Service [L2SM] G. Fioccola, Ed., "A YANG Data Model for L2VPN Service
Delivery", draft-ietf-l2sm-l2vpn-service-model, work in Delivery", draft-ietf-l2sm-l2vpn-service-model, work in
progress. progress.
[RFC8299] Q. Wu, Ed., S. Litkowski, L. Tomotaki, and K. Ogaki, "YANG [RFC8299] Q. Wu, Ed., S. Litkowski, L. Tomotaki, and K. Ogaki, "YANG
Data Model for L3VPN Service Delivery", RFC 8299, January Data Model for L3VPN Service Delivery", RFC 8299, January
2018. 2018.
[RFC8309] Q. Wu, W. Cheng, and A. Farrel. "Service Models [RFC8309] Q. Wu, W. Cheng, and A. Farrel. "Service Models
Explained", RFC 8309, January 2018. Explained", RFC 8309, January 2018.
skipping to change at page 52, line 16 skipping to change at page 53, line 5
Delivery", draft-ietf-l2sm-l2vpn-service-model, work in Delivery", draft-ietf-l2sm-l2vpn-service-model, work in
progress. progress.
[RFC8299] Q. Wu, Ed., S. Litkowski, L. Tomotaki, and K. Ogaki, "YANG [RFC8299] Q. Wu, Ed., S. Litkowski, L. Tomotaki, and K. Ogaki, "YANG
Data Model for L3VPN Service Delivery", RFC 8299, January Data Model for L3VPN Service Delivery", RFC 8299, January
2018. 2018.
[RFC8309] Q. Wu, W. Cheng, and A. Farrel. "Service Models [RFC8309] Q. Wu, W. Cheng, and A. Farrel. "Service Models
Explained", RFC 8309, January 2018. 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 12. Contributors
Contributor's Addresses Contributor's Addresses
Haomian Zheng Haomian Zheng
Huawei Technologies Huawei Technologies
Email: zhenghaomian@huawei.com Email: zhenghaomian@huawei.com
Xian Zhang Xian Zhang
Huawei Technologies Huawei Technologies
skipping to change at page 52, line 42 skipping to change at page 53, line 41
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 Huawei Technologies
Email: leeyoung@huawei.com Email: leeyoung@huawei.com
Dhruv Dhody 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: Igor.Bryskin@huawei.com
 End of changes. 43 change blocks. 
95 lines changed or deleted 186 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/