file "ietf-vn@2025-03-27.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: WG List: Editor: Young Lee Editor: Dhruv Dhody "; description "This 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 TE Networks (ACTN) architecture where the CNC is the actor of a VN instantiation/modification/deletion as per RFC 8453. Copyright (c) 2025 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 9731; see the RFC itself for full legal notices."; revision 2025-03-27 { description "The initial version."; reference "RFC 9731: A YANG Data Model for Virtual Network (VN) Operations"; } /* Features */ feature multi-src-dest { description "Support for selection of one source 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 a VN identifier."; } typedef ap-id { type string { length "1..max"; } description "A type definition for an Access Point (AP) identifier."; } typedef vnm-id { type string { length "1..max"; } description "A type definition for a 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 to be 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 CNCs 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 id { type vnm-id; description "A vn-member identifier."; } container src { description "The source of VN member."; leaf ap { type leafref { path "/access-point/ap/id"; } description "A reference to the source AP."; } leaf vn-ap-id { type leafref { path "/access-point/ap[id=current()/../ap]/vn-ap" + "/id"; } description "A reference to the source VNAP."; } leaf multi-src { if-feature "multi-src-dest"; type boolean; default "false"; description "Is the source part of a multi-source, where only one of the sources is enabled?"; } } container dest { description "The destination of the VN member."; leaf ap { type leafref { path "/access-point/ap/id"; } description "A reference to the destination AP."; } leaf vn-ap-id { type leafref { path "/access-point/ap[id=current()/../ap]/" + "vn-ap/id"; } description "A reference to the destination VNAP."; } leaf multi-dest { if-feature "multi-src-dest"; type boolean; default "false"; description "Is the destination part of a 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 the 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) RFC 8795: YANG Data Model for Traffic Engineering (TE) Topologies"; } 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 "id"; description "The access-point identifier."; leaf 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 "id"; leaf id { type ap-id; description "A unique identifier for the VNAP."; } leaf vn { type leafref { path "/virtual-network/vn/id"; } description "A reference to the VN."; } leaf abstract-node { type leafref { path "/nw:networks/nw:network/nw:node/nw:node-id"; } must '/nw:networks/nw:network/nw:node[nw:node-id=' + 'current()/../abstract-node]/tet:te-node-id' { description "The associated network for the abstract-node must be TE enabled."; } description "A reference to the abstract node that represents the VN."; } leaf ltp { type leafref { path "/nw:networks/nw:network/nw:node[nw:node-id=" + "current()/../abstract-node]/nt:termination-point/" + "tet:te-tp-id"; } description "A reference to the Link Termination Point (LTP) in the abstract-node, i.e., the LTP should be in the abstract layer and not the underlying layer."; 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 VNAPs 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 "id"; description "A VN is identified by a vn-id."; leaf 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 "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-source or multi-destination 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 (COS)."; } uses te-types:generic-path-optimization; list vn-member-list { key "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 "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-source or multi-destination 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 that 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."; } } } } } } 7. Security Considerations 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 Network Configuration Access Control Model (NACM) [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 on 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 APs in the VN service are attached. By accessing the following data nodes, an attacker may be able to manipulate the VN. - id - pe - max-bandwidth - avl-bandwidth * 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. - id - vn - abstract-node - ltp - max-bandwidth * 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. - id - te-topology-identifier - abstract-node * 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. - id - src/ap - src/vn-ap-id - dest/ap - dest/vn-ap-id - connectivity-matrix-id 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: * oper-status: This leaf can reveal the current operational state of the VN. * if-selected: This leaf can reveal which vn-member is selected among the various multi-source / multi-destination options. 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: * vn-compute: This RPC triggers the VN computation at the MDSC, which can reveal the VN information. 8. IANA Considerations IANA has made the following allocation for a URI in the "ns" registry within the "IETF XML Registry" registry group [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 has made the following allocation for the VN YANG data model (see Section 5 in the "YANG Module Names" registry [RFC6020]: name: ietf-vn namespace: urn:ietf:params:xml:ns:yang:ietf-vn prefix: vn reference: RFC 9731 9. References 9.1. Normative References [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, DOI 10.17487/RFC3688, January 2004, . [RFC4124] Le Faucheur, F., Ed., "Protocol Extensions for Support of Diffserv-aware MPLS Traffic Engineering", RFC 4124, DOI 10.17487/RFC4124, June 2005, . [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)", RFC 6020, DOI 10.17487/RFC6020, October 2010, . [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., and A. Bierman, Ed., "Network Configuration Protocol (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, . [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, . [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", RFC 6991, DOI 10.17487/RFC6991, July 2013, . [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", RFC 7950, DOI 10.17487/RFC7950, August 2016, . [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, . [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, . [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration Access Control Model", STD 91, RFC 8341, DOI 10.17487/RFC8341, March 2018, . [RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., and R. Wilton, "Network Management Datastore Architecture (NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018, . [RFC8345] Clemm, A., Medved, J., Varga, R., Bahadur, N., Ananthakrishnan, H., and X. Liu, "A YANG Data Model for Network Topologies", RFC 8345, DOI 10.17487/RFC8345, March 2018, . [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, . [RFC8776] Saad, T., Gandhi, R., Liu, X., Beeram, V., and I. Bryskin, "Common YANG Data Types for Traffic Engineering", RFC 8776, DOI 10.17487/RFC8776, June 2020, . [RFC8795] Liu, X., Bryskin, I., Beeram, V., Saad, T., Shah, H., and O. Gonzalez de Dios, "YANG Data Model for Traffic Engineering (TE) Topologies", RFC 8795, DOI 10.17487/RFC8795, August 2020, . 9.2. Informative References [L1CSM-YANG] Lee, Y., Lee, K., Zheng, H., Gonzalez de Dios, O., and D. Ceccarelli, "A YANG Data Model for L1 Connectivity Service Model (L1CSM)", Work in Progress, Internet-Draft, draft- ietf-ccamp-l1csm-yang-26, 11 April 2024, . [RFC7926] Farrel, A., Ed., Drake, J., Bitar, N., Swallow, G., Ceccarelli, D., and X. Zhang, "Problem Statement and Architecture for Information Exchange between Interconnected Traffic-Engineered Networks", BCP 206, RFC 7926, DOI 10.17487/RFC7926, July 2016, . [RFC8299] Wu, Q., Ed., Litkowski, S., Tomotaki, L., and K. Ogaki, "YANG Data Model for L3VPN Service Delivery", RFC 8299, DOI 10.17487/RFC8299, January 2018, . [RFC8309] Wu, Q., Liu, W., and A. Farrel, "Service Models Explained", RFC 8309, DOI 10.17487/RFC8309, January 2018, . [RFC8453] Ceccarelli, D., Ed. and Y. Lee, Ed., "Framework for Abstraction and Control of TE Networks (ACTN)", RFC 8453, DOI 10.17487/RFC8453, August 2018, . [RFC8454] Lee, Y., Belotti, S., Dhody, D., Ceccarelli, D., and B. Yoon, "Information Model for Abstraction and Control of TE Networks (ACTN)", RFC 8454, DOI 10.17487/RFC8454, September 2018, . [RFC8466] Wen, B., Fioccola, G., Ed., Xie, C., and L. Jalil, "A YANG Data Model for Layer 2 Virtual Private Network (L2VPN) Service Delivery", RFC 8466, DOI 10.17487/RFC8466, October 2018, . [RFC8792] Watsen, K., Auerswald, E., Farrel, A., and Q. Wu, "Handling Long Lines in Content of Internet-Drafts and RFCs", RFC 8792, DOI 10.17487/RFC8792, June 2020, . [RFC9256] Filsfils, C., Talaulikar, K., Ed., Voyer, D., Bogdanov, A., and P. Mattes, "Segment Routing Policy Architecture", RFC 9256, DOI 10.17487/RFC9256, July 2022, . [TE-SERVICE-MAPPING] Lee, Y., Dhody, D., Fioccola, G., Wu, Q., Ceccarelli, D., and J. Tantsura, "Traffic Engineering (TE) and Service Mapping YANG Data Model", Work in Progress, Internet- Draft, draft-ietf-teas-te-service-mapping-yang-17, 29 January 2025, . [TEAS-ACTN-PM] Lee, Y., Dhody, D., Vilalta, R., King, D., and D. Ceccarelli, "YANG models for Virtual Network (VN)/TE Performance Monitoring Telemetry and Scaling Intent Autonomics", Work in Progress, Internet-Draft, draft-ietf- teas-actn-pm-telemetry-autonomics-14, 19 October 2024, . [YANG-TE] Saad, T., Gandhi, R., Liu, X., Beeram, V. P., and I. Bryskin, "A YANG Data Model for Traffic Engineering Tunnels, Label Switched Paths and Interfaces", Work in Progress, Internet-Draft, draft-ietf-teas-yang-te-37, 9 October 2024, . Appendix A. Performance Constraints At the creation of a VN, it is natural to provide VN-level constraints and optimization criteria. It should be noted that the VN YANG data model described in this document relies on the TE Topology model in [RFC8795] by using a reference to an abstract node to provide VN-level constraints and optimization criteria. 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; 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. Appendix B. JSON Example B.1. VN JSON This section provides JSON examples of how the VN YANG data model and TE Topology YANG data model are used together to instantiate a VN. The example in this section includes the following VNs: * VN1 (Type 1): This VN maps to the single node topology abstract1 and consists of VN members 104 (L1 to L4), 107 (L1 to L7), 204 (L2 to L4), 308 (L3 to L8), and 108 (L1 to L8). * VN2 (Type 2): This VN maps to the single node topology abstract2; this topology has an underlay topology (called underlay). This VN has a single VN member 105 (L1 to L5) and an underlay path (S4 and S7) has been set in the connectivity matrix of the abstract2 topology; * VN3 (Type 1): This VN has a multi-source and multi-destination feature enabled. VN member 106 (L1 to L6) and 107 (L1 to L7) showcase multi-dest and VN member 108 (L1 to L8) and 308 (L3 to L8) showcase the multi-src feature. The selected VN member is known via the field "if-selected" and the corresponding connectivity-matrix-id. 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 --- --- --- Figure 11: Example Note that the VN YANG data model also includes the AP and VNAP, which shows various VNs using the same AP. { "ietf-vn:access-point": { "ap": [ { "id": "101", "vn-ap": [ { "id": "10101", "vn": "1", "abstract-node": "192.0.2.1", "ltp": "203.0.113.11" }, { "id": "10102", "vn": "2", "abstract-node": "192.0.2.2", "ltp": "203.0.113.12" }, { "id": "10103", "vn": "3", "abstract-node": "192.0.2.3", "ltp": "203.0.113.13" } ] }, { "id": "202", "vn-ap": [ { "id": "20201", "vn": "1", "abstract-node": "192.0.2.1", "ltp": "203.0.113.21" } ] }, { "id": "303", "vn-ap": [ { "id": "30301", "vn": "1", "abstract-node": "192.0.2.1", "ltp": "203.0.113.31" }, { "id": "30303", "vn": "3", "abstract-node": "192.0.2.3", "ltp": "203.0.113.33" } ] }, { "id": "404", "vn-ap": [ { "id": "40401", "vn": "1", "abstract-node": "192.0.2.1", "ltp": "203.0.113.41" } ] }, { "id": "505", "vn-ap": [ { "id": "50502", "vn": "2", "abstract-node": "192.0.2.2", "ltp": "203.0.113.52" } ] }, { "id": "606", "vn-ap": [ { "id": "60603", "vn": "3", "abstract-node": "192.0.2.3", "ltp": "203.0.113.63" } ] }, { "id": "707", "vn-ap": [ { "id": "70701", "vn": "1", "abstract-node": "192.0.2.1", "ltp": "203.0.113.71" }, { "id": "70703", "vn": "3", "abstract-node": "192.0.2.3", "ltp": "203.0.113.73" } ] }, { "id": "808", "vn-ap": [ { "id": "80801", "vn": "1", "abstract-node": "192.0.2.1", "ltp": "203.0.113.81" }, { "id": "80803", "vn": "3", "abstract-node": "192.0.2.3", "ltp": "203.0.113.83" } ] } ] }, "ietf-vn:virtual-network": { "vn": [ { "id": "1", "te-topology-identifier": { "topology-id": "abstract1" }, "abstract-node": "192.0.2.1", "vn-member": [ { "id": "104", "src": { "ap": "101", "vn-ap-id": "10101" }, "dest": { "ap": "404", "vn-ap-id": "40401" }, "connectivity-matrix-id": 10104 }, { "id": "107", "src": { "ap": "101", "vn-ap-id": "10101" }, "dest": { "ap": "707", "vn-ap-id": "70701" }, "connectivity-matrix-id": 10107 }, { "id": "204", "src": { "ap": "202", "vn-ap-id": "20201" }, "dest": { "ap": "404", "vn-ap-id": "40401" }, "connectivity-matrix-id": 10204 }, { "id": "308", "src": { "ap": "303", "vn-ap-id": "30301" }, "dest": { "ap": "808", "vn-ap-id": "80801" }, "connectivity-matrix-id": 10308 }, { "id": "108", "src": { "ap": "101", "vn-ap-id": "10101" }, "dest": { "ap": "808", "vn-ap-id": "80801" }, "connectivity-matrix-id": 10108 } ] }, { "id": "2", "te-topology-identifier": { "topology-id": "abstract2" }, "abstract-node": "192.0.2.2", "vn-member": [ { "id": "105", "src": { "ap": "101", "vn-ap-id": "10102" }, "dest": { "ap": "505", "vn-ap-id": "50502" }, "connectivity-matrix-id": 20105 } ] }, { "id": "3", "te-topology-identifier": { "topology-id": "abstract3" }, "abstract-node": "192.0.2.3", "vn-member": [ { "id": "106", "src": { "ap": "101", "vn-ap-id": "10103" }, "dest": { "ap": "606", "vn-ap-id": "60603", "multi-dest": true }, "connectivity-matrix-id": 30106, "if-selected": false }, { "id": "107", "src": { "ap": "101", "vn-ap-id": "10103" }, "dest": { "ap": "707", "vn-ap-id": "70703", "multi-dest": true }, "connectivity-matrix-id": 30107, "if-selected": true }, { "id": "108", "src": { "ap": "101", "vn-ap-id": "10103", "multi-src": true }, "dest": { "ap": "808", "vn-ap-id": "80803", }, "connectivity-matrix-id": 30108, "if-selected": false }, { "id": "308", "src": { "ap": "303", "vn-ap-id": "30303", "multi-src": true }, "dest": { "ap": "808", "vn-ap-id": "80803" }, "connectivity-matrix-id": 30308, "if-selected": true } ] } ] } } B.2. TE Topology JSON This section provides JSON examples of the various TE topology instances. The example in this section includes the following TE Topologies: * abstract1: a single node TE topology referenced by VN1. We also show how disjointness (node, link, Shared Risk Link Group (SRLG)) is supported in the example on the connectivity matrices. * abstract2: a single node TE topology referenced by VN2 with an underlay path. * underlay: the topology with multiple nodes (in the underlay path of abstract2). For brevity, the example includes only the node: other parameters are not included. * abstract3: a single node TE topology referenced by VN3. { "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" } } ] } } } } ] } ] } } Acknowledgments 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 the YANGDIR review. * Darren Dukes and Susan Hares for the RTGDIR review. * Behcet Sarikaya for the GENART review. * Bo Wu for the OPSDIR review. * Shivan Sahib for the SECDIR review. * Deb Cooley, Francesca Palombini, Gunter Van de Velde, and Mahesh Jethanandani for the IESG review. Contributors 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 Authors' Addresses Young Lee (editor) Samsung Electronics Email: younglee.tx@gmail.com Dhruv Dhody (editor) Huawei India Email: dhruv.ietf@gmail.com Daniele Ceccarelli Cisco Email: daniele.ietf@gmail.com Igor Bryskin Individual Email: i_bryskin@yahoo.com Bin Yeong Yoon ETRI Email: byyun@etri.re.kr
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4