| Internet-Draft | VN YANG Model | June 2024 |
| Lee, et al. | Expires 8 December 2024 | [Page] |
A Virtual Network (VN) is a network provided by a service provider to a customer for the customer to use in any way it wants. This document provides a YANG data model generally applicable to any mode of VN operations. This includes VN operations as per the Abstraction and Control of TE Networks (ACTN) framework.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
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 8 December 2024.¶
Copyright (c) 2024 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 Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
Abstraction and Control of Traffic Engineered (TE) Networks (ACTN) describes a set of management and control functions used to operate one or more TE networks to construct a Virtual Network (VN). A VN is represented to customers and is built from the abstractions of the underlying TE networks [RFC8453]. This document provides a YANG [RFC7950] data model generally applicable to any mode of VN operation. ACTN is the primary example of the usage of the VN YANG model but not limited to it.¶
The VN model defined in this document is applicable in a 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 the Layer Three Virtual Private Network Service Model (L3SM) [RFC8299], the Layer Two Virtual Private Network Service Model (L2SM) [RFC8466] and the Layer One Connectivity Service Model (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:¶
An abstract TE topology is a topology that contains abstract topological elements (nodes, links) created and customised based on customer's preference [RFC8795]. The actual VN instantiation and computation is performed with Connectivity Matrices of the TE-Topology Model [RFC8795] which provides a TE network topology abstraction and management operation. As per [RFC8795], a TE node connectivity matrix is the TE node's switching limitations in the form of valid switching combinations of the TE node's LTPs and potential TE paths. The VN representation relies on a single abstract TE node with a connectivity matrix. The VN can be abstracted as a set of edge-to-edge links (a Type 1 VN). Each link is the VN member that is mapped to the connectivity matrix entry (Section 2.1). The VN can also be abstracted as a topology of virtual nodes and virtual links (a Type 2 VN). Alongside the mapping of VN members to connectivity matrix entry, an underlay path can also be specified (Section 2.2).¶
Once the TE-topology Model is used in triggering VN instantiation over the networks, the TE-tunnel [I-D.ietf-teas-yang-te] Model will inevitably interact with the TE-Topology model for setting up actual tunnels and LSPs under the tunnels.¶
Sections 2 and 3 provide a 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 (MDSC) interface (CMI).¶
The YANG model on the CMI is also known as the 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].¶
This document borrows the following terms from [RFC8453]:¶
This document borrows the following terms from [RFC8795]:¶
This document borrows the terminology in Section 1.1 of [RFC7926].¶
This document uses the term 'Service Model' as described in [RFC8309].¶
A simplified graphical representation of the data model is used in Section 5 of this document. The meaning of the symbols in these diagrams is defined in [RFC8340].¶
In this document, the 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] |
| yang | ietf-yang-types | [RFC6991] |
| nw | ietf-network | [RFC8345] |
| nt | ietf-network-topology | [RFC8345] |
| te-types | ietf-te-types | [RFC8776] |
| tet | ietf-te-topology | [RFC8795] |
Note: The RFC Editor will replace XXXX with the number assigned to the RFC once this draft becomes an RFC.¶
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 following ACTN context.¶
+-------+
| CNC |
+-------+
|
| VN YANG + TE-topology YANG
|
+-----------------------+
| MDSC |
+-----------------------+
Both ACTN VN YANG and TE-topology models are used over the CMI to establish a VN over TE networks as shown in Figure 1.¶
As defined in [RFC8453], a Virtual Network is a customer view of the TE network. To recapitulate VN types from [RFC8453], Type 1 VN is defined as follows:¶
The VN can be seen as a set of edge-to-edge abstract links (a Type 1 VN). Each abstract link is referred to as a VN member and is formed as an end-to-end tunnel across the underlying networks. Such tunnels may be constructed by recursive slicing or abstraction of paths in the underlying networks and can encompass edge points of the customer's network, access links, intra-domain paths, and inter-domain links.¶
VN-member 1 L1-L4
VN-member 2 L1-L7
VN-member 3 L2-L4
VN-member 4 L3-L8
¶
This VN can be modelled as one abstract node representation as follows in Figure 2:¶
+----------------------------------------------+
| |
L1----|..............................................|------L4
| . . |
| . AN1 . |
| . . |
| ..................................*.....|------L7
| . |
L2-----|....................................... |
| |
L3-----|..............................................|------L8
| |
+----------------------------------------------+
Modelling a VN as one abstract node is the easiest way for customers to express their end-to-end connectivity as shown in Figure 2.¶
For some VN members, the customers are allowed to configure the intended path. To achieve this, alongside the single node abstract topology, an underlay topology is also needed. The underlay topology could be native TE topology or an abstract TE topology. The intended path is set based on the nodes and links of the underlay topology. Type 1 VN can be seen as a higher abstraction of a Type 2 VN (which along with a single node abstract topology, an underlay topology and the intended path is specified). These topologies could be mutually agreed between CNC and MDSC prior to VN creation or it could be created as part of VN instantiation.¶
If a Type 2 VN is desired for some or all of the VN members of a Type 1 VN (see the example in Section 2.1), the TE-topology model can provide the following abstract topologies (a single node topology AN1 and an underlay topology (with nodes S1 to S11 and corresponding links)).¶
+----------------------------------------------+
| S1 S2 |
| O...............O |
| ......... ....... . |
| . . . |
|S3 . . S4 . S5 |
L1----|.O......................O.........O...........|------L4
| . . . |
| . . . |
| . S6 . S7 . S8 |
| O ................O.........O.......|------L7
| . . . . ..... |
|S9 . . .S10 . . |
L2-----|...O.....O.....................O..............|------L8
| . S11 |
L3-----|.. |
| AN1 |
+----------------------------------------------+
As shown in Figure 3, the abstract node is AN1 and an underlay topology is depicted with nodes and links (S1 to S11).¶
As an example, if VN-member 1 (L1-L4) is chosen to configure its own path over Type 2 topology, it can select, say, a path that consists of the explicit abstract path {S3,S4,S5} based on the underlay topology and its service requirement. This capability is enacted via TE-topology configuration by the customer.¶
If this VN is Type 1, the following diagram shows the message flow between CNC and MDSC to instantiate this VN using VN and TE-Topology Models.¶
+--------+ +--------+
| CNC | | MDSC |
+--------+ +--------+
| |
| |
CNC POST TE-topo | POST /nw:networks/nw:network/ |
model(with Conn. | nw:node/te-node-id/ |
Matrix on one | tet:connectivity-matrices/ |
Abstract node | tet:connectivity-matrix |
|-------------------------------->|
| HTTP 200 |
|<--------------------------------|
| |
CNC POST the | POST /virtual-network |
VN identifying |-------------------------------->| If there is
AP, VNAP and VN- | | multi-src/dest
Members and maps | | then MDSC
to the TE-topo | HTTP 200 | selects a
|<--------------------------------| src or dest
| | and updates
| | VN YANG
CNC GET the | GET /virtual-network |
VN YANG status |-------------------------------->|
| |
| HTTP 200 (VN with status: |
| selected VN-members |
| in case of multi s-d) |
|<--------------------------------|
| |
For some VN members, the customer may want to "configure" explicit path that connects its two end-points. Let us consider the following example.¶
There are two options depending on whether CNC or MDSC creates the single abstract node topology.¶
Case 1:¶
If CNC creates the single-abstract-node topology, the following diagram shows the message flow between CNC and MDSC to instantiate this VN using VN and TE-Topology Model.¶
+--------+ +--------+
| CNC | | MDSC |
+--------+ +--------+
| |
| |
CNC POST TE-topo | POST /nw:networks/nw:network/ |
model(with Conn. | nw:node/te-node-id/tet:connectivity- |
Matrix on one | matrices/tet:connectivity-matrix |
Abstract node and|---------------------------------------->|
Explicit paths in| |
the conn. matrix)| HTTP 200 |
|<----------------------------------------|
| |
CNC POST the | POST /virtual-network |
VN identifying |---------------------------------------->|
AP, VNAP and VN- | |
Members and maps | |
to the TE-topo | HTTP 200 |
|<----------------------------------------|
| |
| |
CNC GET the | GET /virtual-network |
VN YANG status |---------------------------------------->|
| |
| HTTP 200 (VN with status) |
|<----------------------------------------|
| |
Case 2:¶
On the other hand, if MDSC create the single-abstract-node topology based on VN YANG posted by the CNC, the following diagram shows the message flow between CNC and MDSC to instantiate this VN using VN and TE-Topology Models.¶
+--------+ +--------+
| CNC | | MDSC |
+--------+ +--------+
| |
| |
CNC POST VN | |
Identifying AP, | |
VNAP and VN- | POST /virtual-network | MDSC populates
Members |-------------------------------->| a single Abst.
| HTTP 200 | node topology
|<--------------------------------| by itself
| |
CNC GET VN & | GET /virtual-network & |
POST TE-Topo | POST /nw:networks/nw:network/ |
Models (with | nw:node/te-node-id/tet: |
Conn. Matrix | connectivity-matrices/ |
on the | tet:connectivity-matrix |
Abstract Node |-------------------------------->|
and explicit | |
paths in the | |
conn. matrix) | |
| HTTP 200 |
|<--------------------------------|
| |
| |
CNC GET the | GET /virtual-network |
VN YANG status |-------------------------------->|
| |
| HTTP 200 (VN with status) |
|<--------------------------------|
| |
Note that the underlay topology (which is referred to by the single-abstract-node topology) could be a Native/White topology or a Grey topology ([RFC8453]) that is further customised based on the requirements of the customer and configured at MDSC.¶
Appendix B 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.¶
The customer access information may be known at the time of VN creation. A shared logical AP identifier is used between the customer and the operator to identify the access link between Customer Edge (CE) and Provider Edge (PE). This is described in Section 6 of [RFC8453].¶
In some VN operations, the customer access may not be known at the initial VN creation. The VN operation allows the creation of a VN with only a PE identifier as well. The customer access information could be 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.¶
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 allows the grouping 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 offered by a separate YANG model for the customer services as described in [RFC8309], which states that service models do not make any assumption about how a service is actually engineered and delivered for a customer.¶
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 configured, but created automatically by the MDSC based on the customer service model and local policy, even in these cases, the VN YANG model can be used by the CNC to learn details of the underlying VN created to meet the requirements of the customer service model.¶
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 ([I-D.ietf-teas-yang-te]) does not provide the same functionality.¶
+--------+ +--------+
| CNC | | MDSC |
+--------+ +--------+
| |
| |
CNC POST TE-topo | POST /nw:networks/nw:network/ |
model(with Conn. | nw:node/te-node-id/tet:connectivity- |
Matrix on one | matrices/tet:connectivity-matrix |
Abstract node and|---------------------------------------->|
constraints in | |
the conn. matrix)| HTTP 200 |
|<----------------------------------------|
| |
| |
CNC calls RPC to | RPC /vn-compute |
compute the VN |---------------------------------------->|
as per the | |
refered TE-Topo | |
| |
| HTTP 200 (Computed VN) |
|<----------------------------------------|
| |
The VN compute RPC allows you to optionally include the constraints and the optimization criteria at the VN as well as at the individual VN-member level. Thus, the RPC can be used independently to get the computed VN result without creating an abstract topology first.¶
+--------+ +--------+
| CNC | | MDSC |
+--------+ +--------+
| |
| |
CNC calls RPC to | RPC /vn-compute |
compute the VN |---------------------------------------->|
as per the | |
constraints and | |
VN-members | |
| HTTP 200 (Computed VN) |
|<----------------------------------------|
| |
In either case the output includes a reference to the single node abstract topology with each VN-member including a reference to the connectivity-matrix-id where the path properties could be found.¶
To achieve this the VN-compute RPC reuses the following common groupings:¶
When MDSC receives this RPC it computes the VN based on the input provided in the RPC call. This computation does not create a VN or reserve any resources in the system, it simply computes the resulting VN based on information at the MDSC or in coordination with the CNC. A single-node-abstract topology is used to convey the result of each VN member as a reference to the connectivity-matrix-id. In case of an error, the error information is included.¶
rpcs:
+---x vn-compute
+---w input
| +---w te-topology-identifier
| | +---w provider-id? te-global-id
| | +---w client-id? te-global-id
| | +---w topology-id? te-topology-id
| +---w abstract-node?
| | -> /nw:networks/network/node/tet:te-node-id
| +---w path-constraints
| | +---w te-bandwidth
| | | +---w (technology)?
| | | ...
| | +---w link-protection? identityref
| | +---w setup-priority? uint8
| | +---w hold-priority? uint8
| | +---w signaling-type? identityref
| | +---w path-metric-bounds
| | | +---w path-metric-bound* [metric-type]
| | | ...
| | +---w path-affinities-values
| | | +---w path-affinities-value* [usage]
| | | ...
| | +---w path-affinity-names
| | | +---w path-affinity-name* [usage]
| | | ...
| | +---w path-srlgs-lists
| | | +---w path-srlgs-list* [usage]
| | | ...
| | +---w path-srlgs-names
| | | +---w path-srlgs-name* [usage]
| | | ...
| | +---w disjointness? te-path-disjointness
| +---w cos? te-types:te-ds-class
| +---w optimizations
| | +---w (algorithm)?
| | +--:(metric) {path-optimization-metric}?
| | | ...
| | +--:(objective-function)
| | {path-optimization-objective-function}?
| | ...
| +---w vn-member-list* [vnm-id]
| | +---w vnm-id vnm-id
| | +---w src
| | | +---w src? -> /access-point/ap/ap-id
| | | +---w src-vn-ap-id?
| | | | -> /access-point/ap/vn-ap/vn-ap-id
| | | +---w multi-src? boolean {multi-src-dest}?
| | +---w dest
| | | +---w dest? -> /access-point/ap/ap-id
| | | +---w dest-vn-ap-id?
| | | | -> /access-point/ap/vn-ap/vn-ap-id
| | | +---w multi-dest? boolean {multi-src-dest}?
| | +---w connectivity-matrix-id? leafref
| | +---w underlay
| | +---w path-constraints
| | | +---w te-bandwidth
| | | | ...
| | | +---w link-protection? identityref
| | | +---w setup-priority? uint8
| | | +---w hold-priority? uint8
| | | +---w signaling-type? identityref
| | | +---w path-metric-bounds
| | | | ...
| | | +---w path-affinities-values
| | | | ...
| | | +---w path-affinity-names
| | | | ...
| | | +---w path-srlgs-lists
| | | | ...
| | | +---w path-srlgs-names
| | | | ...
| | | +---w disjointness? te-path-disjointness
| | +---w cos? te-types:te-ds-class
| | +---w optimizations
| | +---w (algorithm)?
| | ...
| +---w vn-level-diversity?
| te-types:te-path-disjointness
+--ro output
+--ro te-topology-identifier
| +--ro provider-id? te-global-id
| +--ro client-id? te-global-id
| +--ro topology-id? te-topology-id
+--ro abstract-node?
| -> /nw:networks/network/node/tet:te-node-id
+--ro vn-member-list* [vnm-id]
+--ro vnm-id vnm-id
+--ro src
| +--ro src? -> /access-point/ap/ap-id
| +--ro src-vn-ap-id?
| | -> /access-point/ap/vn-ap/vn-ap-id
| +--ro multi-src? boolean {multi-src-dest}?
+--ro dest
| +--ro dest? -> /access-point/ap/ap-id
| +--ro dest-vn-ap-id?
| | -> /access-point/ap/vn-ap/vn-ap-id
| +--ro multi-dest? boolean {multi-src-dest}?
+--ro connectivity-matrix-id? leafref
+--ro underlay
+--ro if-selected? boolean
| {multi-src-dest}?
+--ro compute-status? vn-compute-status
+--ro error-info
+--ro error-description? string
+--ro error-timestamp? yang:date-and-time
+--ro error-reason? identityref
¶
In creating a virtual network, the list of sources or destinations or both may not be pre-determined by the customer. For instance, for a given source, there may be a list of multiple-destinations to which the optimal destination may be chosen depending on the network resource situations. Likewise, for a given destination, there may also be multiple-sources from which the optimal source may be chosen. In some cases, there may be a pool of multiple sources and destinations from which the optimal source-destination may be chosen. The following YANG tree shows how to model multi-sources and multi-destinations.¶
module: ietf-vn
+--rw virtual-network
+--rw vn* [vn-id]
+--rw vn-id vn-id
+--rw te-topology-identifier
| +--rw provider-id? te-global-id
| +--rw client-id? te-global-id
| +--rw topology-id? te-topology-id
+--rw abstract-node?
| -> /nw:networks/network/node/tet:te-node-id
+--rw vn-member* [vnm-id]
| +--rw vnm-id vnm-id
| +--rw src
| | +--rw src? -> /access-point/ap/ap-id
| | +--rw src-vn-ap-id?
| | | -> /access-point/ap/vn-ap/vn-ap-id
| | +--rw multi-src? boolean {multi-src-dest}?
| +--rw dest
| | +--rw dest? -> /access-point/ap/ap-id
| | +--rw dest-vn-ap-id?
| | | -> /access-point/ap/vn-ap/vn-ap-id
| | +--rw multi-dest? boolean {multi-src-dest}?
| +--rw connectivity-matrix-id? leafref
| +--rw underlay
| +--ro oper-status? te-types:te-oper-status
| +--ro if-selected? boolean {multi-src-dest}?
+--rw admin-status? te-types:te-admin-status
+--ro oper-status? te-types:te-oper-status
+--rw vn-level-diversity? te-types:te-path-disjointness
¶
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 monitoring and network autonomics as described in [I-D.ietf-teas-actn-pm-telemetry-autonomics].¶
Note that the YANG model is tightly coupled with the TE Topology model [RFC8795]. Any underlay technology not supported by [RFC8795] is also not supported by this model. The model does include an empty container called "underlay" that can be augmented. For example the Segment Routing (SR) Policy [RFC9256] information can be augmented for the SR underlay by a future model.¶
Apart from the te-types:generic-path-constraints and te-types:generic-path-optimization, an additional leaf cos for the class of service [RFC4124] is added to represent the Class-Type of traffic to be used as one of the path constraints.¶
This section summarizes the features of the VN YANG.¶
Ability to support various VN and VNS Types¶
module: ietf-vn
+--rw access-point
| +--rw ap* [ap-id]
| +--rw ap-id ap-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 ap-id
| +--rw vn? -> /virtual-network/vn/vn-id
| +--rw abstract-node?
| | -> /nw:networks/network/node/tet:te-node-id
| +--rw ltp? leafref
| +--ro max-bandwidth? te-types:te-bandwidth
+--rw virtual-network
+--rw vn* [vn-id]
+--rw vn-id vn-id
+--rw te-topology-identifier
| +--rw provider-id? te-global-id
| +--rw client-id? te-global-id
| +--rw topology-id? te-topology-id
+--rw abstract-node?
| -> /nw:networks/network/node/tet:te-node-id
+--rw vn-member* [vnm-id]
| +--rw vnm-id vnm-id
| +--rw src
| | +--rw src? -> /access-point/ap/ap-id
| | +--rw src-vn-ap-id? -> /access-point/ap/vn-ap/vn-ap-id
| | +--rw multi-src? boolean {multi-src-dest}?
| +--rw dest
| | +--rw dest? -> /access-point/ap/ap-id
| | +--rw dest-vn-ap-id? -> /access-point/ap/vn-ap/vn-ap-id
| | +--rw multi-dest? boolean {multi-src-dest}?
| +--rw connectivity-matrix-id? leafref
| +--rw underlay
| +--ro oper-status? te-types:te-oper-status
| +--ro if-selected? boolean {multi-src-dest}?
+--rw admin-status? te-types:te-admin-status
+--ro oper-status? te-types:te-oper-status
+--rw vn-level-diversity? te-types:te-path-disjointness
rpcs:
+---x vn-compute
+---w input
| +---w te-topology-identifier
| | +---w provider-id? te-global-id
| | +---w client-id? te-global-id
| | +---w topology-id? te-topology-id
| +---w abstract-node?
| | -> /nw:networks/network/node/tet:te-node-id
| +---w path-constraints
| | +---w te-bandwidth
| | | +---w (technology)?
| | | ...
| | +---w link-protection? identityref
| | +---w setup-priority? uint8
| | +---w hold-priority? uint8
| | +---w signaling-type? identityref
| | +---w path-metric-bounds
| | | +---w path-metric-bound* [metric-type]
| | | ...
| | +---w path-affinities-values
| | | +---w path-affinities-value* [usage]
| | | ...
| | +---w path-affinity-names
| | | +---w path-affinity-name* [usage]
| | | ...
| | +---w path-srlgs-lists
| | | +---w path-srlgs-list* [usage]
| | | ...
| | +---w path-srlgs-names
| | | +---w path-srlgs-name* [usage]
| | | ...
| | +---w disjointness? te-path-disjointness
| +---w cos? te-types:te-ds-class
| +---w optimizations
| | +---w (algorithm)?
| | +--:(metric) {path-optimization-metric}?
| | | ...
| | +--:(objective-function)
| | {path-optimization-objective-function}?
| | ...
| +---w vn-member-list* [vnm-id]
| | +---w vnm-id vnm-id
| | +---w src
| | | +---w src? -> /access-point/ap/ap-id
| | | +---w src-vn-ap-id? -> /access-point/ap/vn-ap/vn-ap-id
| | | +---w multi-src? boolean {multi-src-dest}?
| | +---w dest
| | | +---w dest? -> /access-point/ap/ap-id
| | | +---w dest-vn-ap-id?
| | | | -> /access-point/ap/vn-ap/vn-ap-id
| | | +---w multi-dest? boolean {multi-src-dest}?
| | +---w connectivity-matrix-id? leafref
| | +---w underlay
| | +---w path-constraints
| | | +---w te-bandwidth
| | | | ...
| | | +---w link-protection? identityref
| | | +---w setup-priority? uint8
| | | +---w hold-priority? uint8
| | | +---w signaling-type? identityref
| | | +---w path-metric-bounds
| | | | ...
| | | +---w path-affinities-values
| | | | ...
| | | +---w path-affinity-names
| | | | ...
| | | +---w path-srlgs-lists
| | | | ...
| | | +---w path-srlgs-names
| | | | ...
| | | +---w disjointness? te-path-disjointness
| | +---w cos? te-types:te-ds-class
| | +---w optimizations
| | +---w (algorithm)?
| | ...
| +---w vn-level-diversity? te-types:te-path-disjointness
+--ro output
+--ro te-topology-identifier
| +--ro provider-id? te-global-id
| +--ro client-id? te-global-id
| +--ro topology-id? te-topology-id
+--ro abstract-node?
| -> /nw:networks/network/node/tet:te-node-id
+--ro vn-member-list* [vnm-id]
+--ro vnm-id vnm-id
+--ro src
| +--ro src? -> /access-point/ap/ap-id
| +--ro src-vn-ap-id? -> /access-point/ap/vn-ap/vn-ap-id
| +--ro multi-src? boolean {multi-src-dest}?
+--ro dest
| +--ro dest? -> /access-point/ap/ap-id
| +--ro dest-vn-ap-id?
| | -> /access-point/ap/vn-ap/vn-ap-id
| +--ro multi-dest? boolean {multi-src-dest}?
+--ro connectivity-matrix-id? leafref
+--ro underlay
+--ro if-selected? boolean {multi-src-dest}?
+--ro compute-status? vn-compute-status
+--ro error-info
+--ro error-description? string
+--ro error-timestamp? yang:date-and-time
+--ro error-reason? identityref
¶
The YANG model is as follows:¶
<CODE BEGINS> file "ietf-vn@2024-06-07.yang"
module ietf-vn {
yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-vn";
prefix vn;
/* Import common YANG types */
import ietf-yang-types {
prefix yang;
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 */
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
"RFC 8776: Common YANG Data Types for Traffic Engineering";
}
/* Import TE Topology */
import ietf-te-topology {
prefix tet;
reference
"RFC 8795: YANG Data Model for Traffic Engineering (TE)
Topologies";
}
organization
"IETF Traffic Engineering Architecture and Signaling (TEAS)
Working Group";
contact
"WG Web: <https://datatracker.ietf.org/wg/teas/>
WG List: <mailto:teas@ietf.org>
Editor: Young Lee <younglee.tx@gmail.com>
: Dhruv Dhody <dhruv.ietf@gmail.com>";
description
"This module contains a YANG module for the Virtual Network
(VN). It describes a VN operation module that can take place
in the context of the Customer Network Controller (CNC)-
Multi-Domain Service Coordinator (MDSC) interface (CMI) of
the Abstraction and Control of Traffic Engineered (TE)
Networks (ACTN) architecture where the CNC is the actor of
a VN Instantiation/modification/deletion as per RFC 8453.
Copyright (c) 2024 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 Revised 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.";
revision 2024-06-07 {
description
"The initial version.";
reference
"RFC XXXX: A YANG Data Model for Virtual Network (VN)
Operations";
}
/* 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)";
}
/* Typedef */
typedef vn-id {
type string {
length "1..max";
}
description
"A type definition for Virtual Network (VN)
identifier.";
}
typedef ap-id {
type string {
length "1..max";
}
description
"A type definition for Access Point (AP) identifier.";
}
typedef vnm-id {
type string {
length "1..max";
}
description
"A type definition for VN member identifier.";
}
typedef vn-compute-status {
type te-types:te-common-status;
description
"A type definition for representing the VN compute status. Note
that all statuses apart from up and down are considered as
unknown.";
}
/* identities */
identity vn-computation-error-reason {
description
"Base identity for VN computation error reasons.";
}
identity vn-computation-error-not-ready {
base vn-computation-error-reason;
description
"VN computation has failed because the MDSC is not
ready";
}
identity vn-computation-error-no-cnc {
base vn-computation-error-reason;
description
"VN computation has failed because one or more dependent
CNC are unavailable.";
}
identity vn-computation-error-no-resource {
base vn-computation-error-reason;
description
"VN computation has failed because there is no
available resource in one or more domains.";
}
identity vn-computation-error-path-not-found {
base vn-computation-error-reason;
description
"VN computation failed as no path found.";
}
identity vn-computation-ap-unknown {
base vn-computation-error-reason;
description
"VN computation failed as the source or destination Access
Point (AP) not known.";
}
/* Groupings */
grouping vn-member {
description
"The vn-member is described by this grouping";
leaf vnm-id {
type vnm-id;
description
"A vn-member identifier";
}
container src {
description
"The source of VN Member";
leaf src {
type leafref {
path "/access-point/ap/ap-id";
}
description
"A reference to source AP";
}
leaf src-vn-ap-id {
type leafref {
path "/access-point/ap[ap-id=current()/../src]/vn-ap"
+ "/vn-ap-id";
}
description
"A reference to source VNAP";
}
leaf multi-src {
if-feature "multi-src-dest";
type boolean;
default "false";
description
"Is the source part of multi-source, where
only one of the sources is enabled";
}
}
container dest {
description
"the destination of VN Member";
leaf dest {
type leafref {
path "/access-point/ap/ap-id";
}
description
"A reference to destination AP";
}
leaf dest-vn-ap-id {
type leafref {
path "/access-point/ap[ap-id=current()/../dest]/"
+ "vn-ap/vn-ap-id";
}
description
"A reference to dest VNAP";
}
leaf multi-dest {
if-feature "multi-src-dest";
type boolean;
default "false";
description
"Is destination part of multi-destination, where only one
of the destinations 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
"A reference to connectivity-matrix";
reference
"RFC 8795: YANG Data Model for Traffic Engineering (TE)
Topologies";
}
container underlay {
description
"An empty container that can be augmented with underlay
technology information not supported by RFC 8795 (for
example - Segment Routing (SR). ";
}
reference
"RFC 8454: Information Model for Abstraction and Control of TE
Networks (ACTN)";
}
grouping vn-policy {
description
"policy for VN-level diversity";
leaf vn-level-diversity {
type te-types:te-path-disjointness;
description
"The type of disjointness on the VN level (i.e., across all
VN members)";
}
}
/* Configuration data nodes */
container access-point {
description
"AP configurations";
list ap {
key "ap-id";
description
"access-point identifier";
leaf ap-id {
type ap-id;
description
"An AP identifier unique within the scope of the entity
that controls the VN.";
}
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";
}
leaf max-bandwidth {
type te-types:te-bandwidth;
description
"The max bandwidth of the AP";
}
leaf avl-bandwidth {
type te-types:te-bandwidth;
description
"The available bandwidth of the AP";
}
list vn-ap {
key "vn-ap-id";
leaf vn-ap-id {
type ap-id;
description
"A unique identifier for the VNAP";
}
leaf vn {
type leafref {
path "/virtual-network/vn/vn-id";
}
description
"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
represent the VN";
}
leaf ltp {
type leafref {
path "/nw:networks/nw:network/nw:node/"
+ "nt:termination-point/tet:te-tp-id";
}
description
"A reference to Link Termination Point (LTP) in the
abstract-node.";
reference
"RFC 8795: 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";
}
description
"List of VNAP in this AP";
}
}
reference
"RFC 8453: Framework for Abstraction and Control of TE
Networks (ACTN), Section 6";
}
container virtual-network {
description
"VN configurations";
list vn {
key "vn-id";
description
"A virtual network is identified by a vn-id";
leaf vn-id {
type vn-id;
description
"An identifier unique within the scope of the entity
that controls the VN.";
}
uses te-types:te-topology-identifier;
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";
}
list vn-member {
key "vnm-id";
description
"List of vn-members in a VN";
uses vn-member;
leaf oper-status {
type te-types:te-oper-status;
config false;
description
"The vn-member operational state.";
}
leaf if-selected {
if-feature "multi-src-dest";
type boolean;
default "false";
config false;
description
"Is the vn-member selected among the multi-src/dest
options";
}
}
leaf admin-status {
type te-types:te-admin-status;
default "up";
description
"VN administrative state.";
}
leaf oper-status {
type te-types:te-oper-status;
config false;
description
"VN operational state.";
}
uses vn-policy;
}
reference
"RFC 8453: Framework for Abstraction and Control of TE
Networks (ACTN)";
}
/* RPC */
rpc vn-compute {
description
"The VN computation without actual instantiation. This is
used by the CNC to get the VN results without actually
creating it in the network.
The input could include a reference to the single-node
-abstract topology. It could optionally also include
constraints and optimization criteria. The computation
is done based on the list of VN-members.
The output includes a reference to the single-node
-abstract topology with each VN-member including a
reference to the connectivity-matrix-id where the
path properties could be found. Error information is
also included.";
input {
uses te-types:te-topology-identifier;
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";
}
uses te-types:generic-path-constraints;
leaf cos {
type te-types:te-ds-class;
description
"The class of service";
}
uses te-types:generic-path-optimization;
list vn-member-list {
key "vnm-id";
description
"List of VN-members in a VN";
uses vn-member;
uses te-types:generic-path-constraints;
leaf cos {
type te-types:te-ds-class;
description
"The class of service";
reference
"RFC 4124: Protocol Extensions for Support of
Diffserv-aware MPLS Traffic Engineering,
Section 4.3.1";
}
uses te-types:generic-path-optimization;
}
uses vn-policy;
}
output {
uses te-types:te-topology-identifier;
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";
}
list vn-member-list {
key "vnm-id";
description
"List of VN-members in a VN";
uses vn-member;
leaf if-selected {
if-feature "multi-src-dest";
type boolean;
default "false";
description
"Is the vn-member selected among the multi-src/dest
options";
reference
"RFC 8453: Framework for Abstraction and Control of TE
Networks (ACTN), Section 7";
}
leaf compute-status {
type vn-compute-status;
description
"The VN-member compute state.";
}
container error-info {
description
"Error information related to the VN member";
leaf error-description {
type string {
length "1..max";
}
description
"Textual representation of the error occurred during
VN compute.";
}
leaf error-timestamp {
type yang:date-and-time;
description
"Timestamp of the attempt.";
}
leaf error-reason {
type identityref {
base vn-computation-error-reason;
}
description
"Reason for the VN computation error.";
}
}
}
}
}
}
<CODE ENDS>¶
The YANG module specified in this document defines a schema for data that is designed to be accessed via network management protocols 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 or RESTCONF users to a preconfigured subset of all available NETCONF or RESTCONF protocol operations and content.¶
The model presented in this document is used in the interface between the CNC and MDSC, which is referred to as CNC-MDSC Interface (CMI). Security risks such as malicious attack and rogue elements attempting to connect to the various ACTN components are possible. Furthermore, some ACTN components (e.g., MDSC) represent a single point of failure and threat vector. Also, there is a need to manage policy conflicts and eavesdropping of communication between different ACTN components.¶
There are a number of data nodes defined in this YANG module that are writable/creatable/deletable (i.e., "config true", which is the default). These data nodes may be considered sensitive or vulnerable in some network environments. Write operations (e.g., edit-config) to these data nodes without proper protection can have a negative effect on network operations. These are the subtrees and data nodes and their sensitivity/vulnerability:¶
ap: this list includes a set of sensitive data that influences how the access points in the VN service are attached. By accessing the following data nodes, an attacker may be able to manipulate the VN.¶
vn-ap: this list includes a set of sensitive data that influences how the VN service is delivered. By accessing the following data nodes, an attacker may be able to manipulate the VN.¶
vn: this list includes a set of sensitive data that influences how the VN service is delivered. By accessing the following data nodes, an attacker may be able to manipulate the VN.¶
vn-member: this list includes a set of sensitive data that influences how the VN member in the VN service is delivered. By accessing the following data nodes, an attacker may be able to manipulate the VN member.¶
Some of the readable data nodes in this YANG module may be considered sensitive or vulnerable in some network environments. It is thus important to control read access (e.g., via get, get-config, or notification) to these data nodes. These are the subtrees and data nodes and their sensitivity/vulnerability:¶
Some of the RPC operations in this YANG module may be considered sensitive or vulnerable in some network environments. It is thus important to control access to these operations. These are the operations and their sensitivity/vulnerability:¶
IANA is requested to make the following allocation for the URIs in the "ns" subregistry within the "IETF XML Registry" [RFC3688]:¶
URI: urn:ietf:params:xml:ns:yang:ietf-vn Registrant Contact: The IESG. XML: N/A, the requested URI is an XML namespace.¶
IANA is requested to make the following allocation for the YANG module in the "YANG Module Names" registry [RFC6020]:¶
name: ietf-vn namespace: urn:ietf:params:xml:ns:yang:ietf-vn prefix: vn reference: RFC XXXX¶
The authors would like to thank Xufeng Liu, Adrian Farrel, Tom Petch, Mohamed Boucadair, Italo Busi, Bo Wu and Daniel King for their helpful comments and valuable suggestions.¶
Thanks to Andy Bierman for YANGDIR review. Thanks to Darren Dukes for RTGDIR review. Thanks to Behcet Sarikaya for GENART review Thanks to Bo Wu for OPSDIR review. Thanks to Shivan Sahib for SECDIR review.¶
Thanks to Deb Cooley, Francesca Palombini, and Mahesh Jethanandani for IESG review.¶
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 module relies on the TE-Topology Model [RFC8795] by using a reference to an abstract node to achieve this. Further, the connectivity-matrix structure is used to assign the constraints and optimization criteria including delay, jitter etc. [RFC8776] defines some of the metric-types already and future documents are meant to augment it.¶
Note that the VN compute allows the inclusion of the constraints and the optimization criteria directly in the RPC to allow it to be used independently.¶
This section provides JSON examples of how VN YANG model and TE topology model are used together to instantiate VN.¶
The example in this section includes the following VN¶
L1---104---L4 L1---105---L5 L1---106---L6(md)
L1---107---L7 Underlay Path: L1---107---L7(md)
L2---204---L4 (S4 and S7) L1---108---L8(ms)
L3---308---L8 L3---308---L8(ms)
L1---108---L8
--- --- ---
VN1 VN2 VN3
--- --- ---
¶
Note that the VN YANG model also includes the AP and VNAP which shows various VN using the same AP.¶
{
"ietf-vn:access-point": {
"ap": [
{
"ap-id": "101",
"vn-ap": [
{
"vn-ap-id": "10101",
"vn": "1",
"abstract-node": "192.0.2.1",
"ltp": "203.0.113.11"
},
{
"vn-ap-id": "10102",
"vn": "2",
"abstract-node": "192.0.2.2",
"ltp": "203.0.113.12"
},
{
"vn-ap-id": "10103",
"vn": "3",
"abstract-node": "192.0.2.3",
"ltp": "203.0.113.13"
}
]
},
{
"ap-id": "202",
"vn-ap": [
{
"vn-ap-id": "20201",
"vn": "1",
"abstract-node": "192.0.2.1",
"ltp": "203.0.113.21"
}
]
},
{
"ap-id": "303",
"vn-ap": [
{
"vn-ap-id": "30301",
"vn": "1",
"abstract-node": "192.0.2.1",
"ltp": "203.0.113.31"
},
{
"vn-ap-id": "30303",
"vn": "3",
"abstract-node": "192.0.2.3",
"ltp": "203.0.113.33"
}
]
},
{
"ap-id": "404",
"vn-ap": [
{
"vn-ap-id": "40401",
"vn": "1",
"abstract-node": "192.0.2.1",
"ltp": "203.0.113.41"
}
]
},
{
"ap-id": "505",
"vn-ap": [
{
"vn-ap-id": "50502",
"vn": "2",
"abstract-node": "192.0.2.2",
"ltp": "203.0.113.52"
}
]
},
{
"ap-id": "606",
"vn-ap": [
{
"vn-ap-id": "60603",
"vn": "3",
"abstract-node": "192.0.2.3",
"ltp": "203.0.113.63"
}
]
},
{
"ap-id": "707",
"vn-ap": [
{
"vn-ap-id": "70701",
"vn": "1",
"abstract-node": "192.0.2.1",
"ltp": "203.0.113.71"
},
{
"vn-ap-id": "70703",
"vn": "3",
"abstract-node": "192.0.2.3",
"ltp": "203.0.113.73"
}
]
},
{
"ap-id": "808",
"vn-ap": [
{
"vn-ap-id": "80801",
"vn": "1",
"abstract-node": "192.0.2.1",
"ltp": "203.0.113.81"
},
{
"vn-ap-id": "80803",
"vn": "3",
"abstract-node": "192.0.2.3",
"ltp": "203.0.113.83"
}
]
}
]
},
"ietf-vn:virtual-network": {
"vn": [
{
"vn-id": "1",
"te-topology-identifier": {
"topology-id": "abstract1"
},
"abstract-node": "192.0.2.1",
"vn-member": [
{
"vnm-id": "104",
"src": {
"src": "101",
"src-vn-ap-id": "10101"
},
"dest": {
"dest": "404",
"dest-vn-ap-id": "40401"
},
"connectivity-matrix-id": 10104
},
{
"vnm-id": "107",
"src": {
"src": "101",
"src-vn-ap-id": "10101"
},
"dest": {
"dest": "707",
"dest-vn-ap-id": "70701"
},
"connectivity-matrix-id": 10107
},
{
"vnm-id": "204",
"src": {
"src": "202",
"src-vn-ap-id": "20201"
},
"dest": {
"dest": "404",
"dest-vn-ap-id": "40401"
},
"connectivity-matrix-id": 10204
},
{
"vnm-id": "308",
"src": {
"src": "303",
"src-vn-ap-id": "30301"
},
"dest": {
"dest": "808",
"dest-vn-ap-id": "80801"
},
"connectivity-matrix-id": 10308
},
{
"vnm-id": "108",
"src": {
"src": "101",
"src-vn-ap-id": "10101"
},
"dest": {
"dest": "808",
"dest-vn-ap-id": "80801"
},
"connectivity-matrix-id": 10108
}
]
},
{
"vn-id": "2",
"te-topology-identifier": {
"topology-id": "abstract2"
},
"abstract-node": "192.0.2.2",
"vn-member": [
{
"vnm-id": "105",
"src": {
"src": "101",
"src-vn-ap-id": "10102"
},
"dest": {
"dest": "505",
"dest-vn-ap-id": "50502"
},
"connectivity-matrix-id": 20105
}
]
},
{
"vn-id": "3",
"te-topology-identifier": {
"topology-id": "abstract3"
},
"abstract-node": "192.0.2.3",
"vn-member": [
{
"vnm-id": "106",
"src": {
"src": "101",
"src-vn-ap-id": "10103"
},
"dest": {
"dest": "606",
"dest-vn-ap-id": "60603",
"multi-dest": true
},
"connectivity-matrix-id": 30106,
"if-selected": false
},
{
"vnm-id": "107",
"src": {
"src": "101",
"src-vn-ap-id": "10103"
},
"dest": {
"dest": "707",
"dest-vn-ap-id": "70703",
"multi-dest": true
},
"connectivity-matrix-id": 30107,
"if-selected": true
},
{
"vnm-id": "108",
"src": {
"src": "101",
"src-vn-ap-id": "10103",
"multi-src": true
},
"dest": {
"dest": "808",
"dest-vn-ap-id": "80803"
},
"connectivity-matrix-id": 30108,
"if-selected": false
},
{
"vnm-id": "308",
"src": {
"src": "303",
"src-vn-ap-id": "30303",
"multi-src": true
},
"dest": {
"dest": "808",
"dest-vn-ap-id": "80803"
},
"connectivity-matrix-id": 30308,
"if-selected": true
}
]
}
]
}
}
¶
This section provides JSON examples of the various TE topology instances.¶
The example in this section includes the following TE Topologies¶
{
"ietf-network:networks": {
"network": [
{
"network-types": {
"ietf-te-topology:te-topology": {}
},
"network-id": "example:abstract1",
"ietf-te-topology:te-topology-identifier": {
"provider-id": 0,
"client-id": 0,
"topology-id": "example:abstract1"
},
"node": [
{
"node-id": "example:192.0.2.1",
"ietf-network-topology:termination-point": [
{
"tp-id": "example:1-0-1",
"ietf-te-topology:te-tp-id": "203.0.113.11"
},
{
"tp-id": "example:1-0-2",
"ietf-te-topology:te-tp-id": "203.0.113.21"
},
{
"tp-id": "example:1-0-3",
"ietf-te-topology:te-tp-id": "203.0.113.31"
},
{
"tp-id": "example:1-0-4",
"ietf-te-topology:te-tp-id": "203.0.113.41"
},
{
"tp-id": "example:1-0-7",
"ietf-te-topology:te-tp-id": "203.0.113.71"
},
{
"tp-id": "example:1-0-8",
"ietf-te-topology:te-tp-id": "203.0.113.81"
}
],
"ietf-te-topology:te-node-id": "192.0.2.1",
"ietf-te-topology:te": {
"te-node-attributes": {
"domain-id": 1,
"is-abstract": [
null
],
"connectivity-matrices": {
"is-allowed": true,
"path-constraints": {
"te-bandwidth": {
"generic": "0x1p10"
},
"disjointness": "node link srlg"
},
"connectivity-matrix": [
{
"id": 10104,
"from": {
"tp-ref": "example:1-0-1"
},
"to": {
"tp-ref": "example:1-0-4"
}
},
{
"id": 10107,
"from": {
"tp-ref": "example:1-0-1"
},
"to": {
"tp-ref": "example:1-0-7"
}
},
{
"id": 10204,
"from": {
"tp-ref": "example:1-0-2"
},
"to": {
"tp-ref": "example:1-0-4"
}
},
{
"id": 10308,
"from": {
"tp-ref": "example:1-0-3"
},
"to": {
"tp-ref": "example:1-0-8"
}
},
{
"id": 10108,
"from": {
"tp-ref": "example:1-0-1"
},
"to": {
"tp-ref": "example:1-0-8"
}
}
]
}
}
}
}
]
},
{
"network-types": {
"ietf-te-topology:te-topology": {}
},
"network-id": "example:abstract2",
"ietf-te-topology:te-topology-identifier": {
"provider-id": 0,
"client-id": 0,
"topology-id": "example:abstract2"
},
"node": [
{
"node-id": "example:192.0.2.2",
"ietf-network-topology:termination-point": [
{
"tp-id": "example:2-0-1",
"ietf-te-topology:te-tp-id": "203.0.113.12"
},
{
"tp-id": "example:2-0-5",
"ietf-te-topology:te-tp-id": "203.0.113.52"
}
],
"ietf-te-topology:te-node-id": "192.0.2.2",
"ietf-te-topology:te": {
"te-node-attributes": {
"domain-id": 1,
"is-abstract": [
null
],
"connectivity-matrices": {
"is-allowed": true,
"underlay": {
"enabled": true
},
"path-constraints": {
"te-bandwidth": {
"generic": "0x1p10"
}
},
"optimizations": {
"objective-function": {
"objective-function-type":
"ietf-te-types:of-maximize-residual-bandwidth"
}
},
"ietf-te-topology:connectivity-matrix": [
{
"id": 20105,
"from": {
"tp-ref": "example:2-0-1"
},
"to": {
"tp-ref": "example:2-0-5"
},
"underlay": {
"enabled": true,
"primary-path": {
"network-ref": "example:underlay",
"path-element": [
{
"path-element-id": 1,
"numbered-node-hop": {
"node-id": "198.51.100.44",
"hop-type": "strict"
}
},
{
"path-element-id": 2,
"numbered-node-hop": {
"node-id": "198.51.100.77",
"hop-type": "strict"
}
}
]
}
}
}
]
}
}
}
}
]
},
{
"network-types": {
"ietf-te-topology:te-topology": {}
},
"network-id": "example:underlay",
"ietf-te-topology:te-topology-identifier": {
"provider-id": 0,
"client-id": 0,
"topology-id": "example:underlay"
},
"node": [
{
"node-id": "example:198.51.100.11",
"ietf-te-topology:te-node-id": "198.51.100.11"
},
{
"node-id": "example:198.51.100.22",
"ietf-te-topology:te-node-id": "198.51.100.22"
},
{
"node-id": "example:198.51.100.33",
"ietf-te-topology:te-node-id": "198.51.100.33"
},
{
"node-id": "example:198.51.100.44",
"ietf-te-topology:te-node-id": "198.51.100.44"
},
{
"node-id": "example:198.51.100.55",
"ietf-te-topology:te-node-id": "198.51.100.55"
},
{
"node-id": "example:198.51.100.66",
"ietf-te-topology:te-node-id": "198.51.100.66"
},
{
"node-id": "example:198.51.100.77",
"ietf-te-topology:te-node-id": "198.51.100.77"
},
{
"node-id": "example:198.51.100.88",
"ietf-te-topology:te-node-id": "198.51.100.88"
},
{
"node-id": "example:198.51.100.99",
"ietf-te-topology:te-node-id": "198.51.100.99"
}
]
},
{
"network-types": {
"ietf-te-topology:te-topology": {}
},
"network-id": "example:abstract3",
"ietf-te-topology:te-topology-identifier": {
"provider-id": 0,
"client-id": 0,
"topology-id": "example:abstract3"
},
"node": [
{
"node-id": "example:192.0.2.3",
"ietf-network-topology:termination-point": [
{
"tp-id": "example:3-0-1",
"ietf-te-topology:te-tp-id": "203.0.113.13"
},
{
"tp-id": "example:3-0-3",
"ietf-te-topology:te-tp-id": "203.0.113.33"
},
{
"tp-id": "example:3-0-6",
"ietf-te-topology:te-tp-id": "203.0.113.63"
},
{
"tp-id": "example:3-0-7",
"ietf-te-topology:te-tp-id": "203.0.113.73"
},
{
"tp-id": "example:3-0-8",
"ietf-te-topology:te-tp-id": "203.0.113.83"
}
],
"ietf-te-topology:te-node-id": "192.0.2.3",
"ietf-te-topology:te": {
"te-node-attributes": {
"domain-id": 3,
"is-abstract": [
null
],
"connectivity-matrices": {
"is-allowed": true,
"path-constraints": {
"te-bandwidth": {
"generic": "0x1p10"
}
},
"connectivity-matrix": [
{
"id": 30107,
"from": {
"tp-ref": "example:3-0-1"
},
"to": {
"tp-ref": "example:3-0-7"
}
},
{
"id": 30106,
"from": {
"tp-ref": "example:3-0-1"
},
"to": {
"tp-ref": "example:3-0-6"
}
},
{
"id": 30108,
"from": {
"tp-ref": "example:3-0-1"
},
"to": {
"tp-ref": "example:3-0-8"
}
},
{
"id": 30308,
"from": {
"tp-ref": "example:3-0-3"
},
"to": {
"tp-ref": "example:3-0-8"
}
}
]
}
}
}
}
]
}
]
}
}
¶
Qin Wu Huawei Technologies Email: bill.wu@huawei.com Peter Park KT Email: peter.park@kt.com Haomian Zheng Huawei Technologies Email: zhenghaomian@huawei.com Xian Zhang Huawei Technologies Email: zhang.xian@huawei.com Sergio Belotti Nokia Email: sergio.belotti@nokia.com Takuya Miyasaka KDDI Email: ta-miyasaka@kddi.com Kenichi Ogaki KDDI Email: ke-oogaki@kddi.com¶