YANG Data Model for Traffic Engineering (TE) Topologies
Extracted elements (26)
Attributes directly under the 'connectivity-matrices' container serve as defaults for all connectivity matrix entries when per-entry attributes are not specified; per-entry attributes override container-level defaults. The same rule applies to 'local-link-connectivities'. This reduces redundant configuration for topologies with mostly uniform attributes.
Overlay/underlay topology relationships are captured via optional 'underlay-topology' (node) and 'underlay' (link) fields tagged as the 'te-topology-hierarchy' feature, allowing traversal from the topmost to bottommost supporting topology in hierarchical multi-layer networks.
The model uses inter-domain plug IDs (rather than remote node ID/link ID) as the preferred option for identifying neighboring domains and resolving inter-domain TE links. This is more flexible because providers may not know the respective remote node IDs/link IDs, and it allows clients to mix and match multiple topologies from the same providers.
The TE topology is protocol independent: information about topological elements may be learned via link-state protocols, but the topology can exist without depending on any particular protocol. This decouples the TE topology model from routing topology and specific IGP protocols.
The TE topology model is intentionally technology agnostic, providing common building blocks that technology-specific models (e.g., WSON, OTN, L3) can augment. Writers of technology-specific models are encouraged to augment the base model's containers rather than defining new containers.
RFC 8639 and RFC 8641 define subscription and push mechanisms for YANG datastores that can be used with this topology model, allowing per-client subscriptions, subtree/XPath filtering, and periodic or on-demand notifications.
The TE topology model augments and uses the 'ietf-network-topology' module defined in RFC 8345. Technology-specific TE topology models are expected to further augment the base TE topology model defined in this document.
When merging TE topologies from multiple providers, the client must rename TE node IDs, link IDs, and SRLG IDs to IDs from a separate namespace, because independent topologies may have overlapping/clashing IDs.
An authorized client MAY receive a TE topology with the client ID field matching some other client, but the client can customize only TE topologies with the client ID field either set to 0 or matching the ID of the client in question.
Each TTP MAY be supported by one or more supporting TTPs. If the TE node hosting the TTP refers to a supporting TE node, the supporting TTPs are hosted by that supporting TE node; if it refers to an underlay TE topology, the supporting TTPs are hosted by one or more specified TE nodes of the underlay topology.
Implementations MAY restrict access for particular clients to particular data fields; the Network Configuration Access Control Model (NACM) [RFC8341] provides such a mechanism.
The provider, by setting its own ID in the client ID field of the topology ID, MAY tell the client that a given TE topology cannot be renegotiated.
A TE inter-layer lock describes adaptation relationships between client and server layers, associating M client-layer LTPs and N server-layer TTPs within which data arriving at any client-layer LTP can be adapted onto any server-layer TTP. It is identified by a unique inter-layer lock ID across all TE topologies from the same provider.
A TE Link Termination Point (LTP) is a conceptual point of connection of a TE node to one of the TE links terminated by the TE node. Cardinality between an LTP and the associated TE link is 1:0..1.
A TE node connectivity matrix describes the TE node's switching limitations as valid switching combinations of the node's LTPs. It identifies permissible outbound LTPs from which a TE path can leave the node for any given inbound LTP.
A TE node is an element of a TE topology representing one or several nodes or a fraction of a node. It is assigned a unique ID within the TE topology scope and includes data-plane attributes (connectivity matrix) and configuration data (TE node name).
A TE Tunnel Termination Point (TTP) is an element of a TE topology representing one or several potential transport service termination points. A TTP is associated with exactly one TE node and assigned a unique ID within the TE node scope.
A transitional TE link represents the layer transition function inside a node decomposed into multiple logical TE nodes, connecting a client-layer node with a server-layer node. Transitional TE links only exist while not in use (representing potential connectivity) and disappear when a server-layer trail is established.
A TTP Local Link Connectivity List (LLCL) is a list of TE links terminated by the TE node hosting a TTP to which the TTP could be connected, providing valid TE links a path must start or stop on for a connection to be terminated on the TTP.
Generic TE link attributes include bandwidth (max-link-bandwidth, max-resv-link-bandwidth, unreserved-bandwidth by priority), administrative groups, SRLGs, switching capabilities, TE metric extensions, link protection type, and link index.
TED information sources for each topological element include OSPF-TE, ISIS-TE, BGP-LS, user-configured, system-processed, or other. Each information source is associated with a credibility preference (uint16) to indicate precedence when multiple sources exist.
Templates allow defining reusable node-template and link-template configurations. Multiple templates can apply to a single element; when conflicts occur, the template with the highest priority (lower numeric value, range 0–65535) wins. The 'reference-change-policy' parameter controls behavior when a referenced template changes.
The overlay/underlay relationship for TE links is modeled via the 'underlay' container, which captures primary-path, backup-path (indexed list), protection-type, tunnel-termination-points (source and destination), and tunnels. This functionality is gated behind the 'te-topology-hierarchy' feature.
The TE topology is uniquely identified by a three-part key: 'topology-id', 'provider-id', and 'client-id'. The combination of 'provider-id' and 'topology-id' uniquely identifies a Native TE topology on a given provider; 'client-id' value of '0' is used for Native TE topologies.
This document registers the YANG module 'ietf-te-topology' in the 'IANA-maintained YANG Module Names' registry with namespace 'urn:ietf:params:xml:ns:yang:ietf-te-topology' and prefix 'tet'.
The YANG module defined in this document can be accessed via the NETCONF or RESTCONF protocol. Several data nodes are writable and could be used by a malicious user to disrupt TE topology services; implementations should restrict access using NACM (RFC 8341) to ensure only authorized users can modify sensitive topology data.