RFC 8795: YANG Data Model for Traffic Engineering (TE) Topologies
- X. Liu,
- I. Bryskin,
- V. Beeram,
- T. Saad,
- H. Shah,
- O. Gonzalez de Dios
Abstract
This document defines a YANG data model for representing, retrieving,
and manipulating Traffic Engineering (TE) Topologies. The model
serves as a base model that other technology
Status of This Memo
This is an Internet Standards Track document.¶
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.¶
Information about the current status of this document, any
errata, and how to provide feedback on it may be obtained at
https://
Copyright Notice
Copyright (c) 2020 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://
1. Introduction
The Traffic Engineering Database (TED) is an essential component of Traffic Engineered (TE) systems that are based on MPLS-TE [RFC2702] and GMPLS [RFC3945]. The TED is a collection of all TE information about all TE nodes and TE links in the network. The TE topology is a schematic arrangement of TE nodes and TE links present in a given TED. There could be one or more TE topologies present in a given TE system. A TE topology is the topology on which path computational algorithms are run to compute TE paths.¶
This document defines a YANG data model [RFC7950] for representing, retrieving,
and manipulating TE topologies. This model contains technology
1.1. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
We assume that the reader is familiar with the general body of work captured in currently available RFCs related to Traffic Engineering. [RFC7926] serves as a good starting point for those who may be less familiar with RFCs related to Traffic Engineering.¶
Some of the key terms used in this document are as follows:¶
- TED:
- The Traffic Engineering Database (TED) is a collection of all TE information about all TE nodes and TE links in a given network.¶
- TE topology:
- The TE topology is a schematic arrangement of TE nodes and TE links in a given TED. It forms the basis for a graph suitable for TE path computations.¶
- Native TE topology:
- A Native TE topology is a topology that is
native to a given provider network. A Native TE topology could be discovered
via various routing protocols and/or subscribe
/publish techniques. This is the topology on which path computational algorithms are run to compute TE paths.¶ - Customized TE topology:
- A Customized TE topology is a custom topology that is produced by a provider for a given client. This topology typically makes abstractions on the provider's Native TE topology and is provided to the client. The client receives the Customized TE topology and merges it into the client's Native TE topology. The client's path computational algorithms aren't typically run on the Customized TE topology; they are run on the client's Native TE topology after the merge.¶
1.2. Tree Structure
A simplified graphical representation of the data model is presented in Appendix A of this document. The tree format defined in [RFC8340] is used for the YANG data model tree representation.¶
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.¶
2. Characterizing TE Topologies
The data model defined by this document takes the following characteristics of TE topologies into account:¶
3. Modeling Abstractions and Transformations
3.1. TE Topology
A TE topology is a Traffic Engineering representation of one or more layers of network topologies. A TE topology is comprised of TE nodes (TE graph vertices) interconnected via TE links (TE graph edges). A TE topology is mapped to a TE graph.¶
3.2. TE Node
A TE node is an element of a TE topology, presented as a vertex on a TE graph. A TE node represents one or several nodes, or a fraction of a node, which can be a switch or router that is physical or virtual. A TE node belongs to and is fully defined in exactly one TE topology. A TE node is assigned a unique ID within the TE topology scope. TE node attributes include information related to the data‑plane aspects of the associated node(s) (e.g., connectivity matrix), as well as configuration data (such as the TE node name). A given TE node can be reached on the TE graph over one of the TE links terminated by the TE node.¶
Multi-layer TE nodes providing switching functions at multiple network layers are an example where a physical node can be decomposed into multiple logical TE nodes, which are fractions of the physical node. Some of these (logical) TE nodes may reside in the client-layer TE topology, while the remaining TE nodes belong to the server-layer TE topology.¶
3.3. TE Link
A TE link is an element of a TE topology, presented as an edge on a TE graph. The arrows on an edge indicate one or both directions of the TE link. When there are a pair of parallel links of opposite directions, an edge without arrows is also used. A TE link represents one or several (physical) links or a fraction of a link. A TE link belongs to and is fully defined in exactly one TE topology. A TE link is assigned a unique ID within the TE topology scope. TE link attributes include parameters related to the data-plane aspects of the associated link(s) (unreserved bandwidth, resource maps / resource pools, etc.), as well as the configuration data (remote node IDs / link IDs, Shared Risk Link Groups (SRLGs), administrative colors, etc.). A TE link is connected to a TE node, terminating the TE link via exactly one TE Link Termination Point (LTP).¶
3.4. Transitional TE Link for Multi-layer Topologies
Networks are typically composed of multiple network layers where one or multiple signals in the client-layer network can be multiplexed and encapsulated into a server-layer signal [RFC5212] [G.805]. The server-layer signal can be carried in the server-layer network across multiple nodes until the server-layer signal is terminated and the client-layer signals reappear in the node that terminates the server-layer signal. Examples of multi-layer networks include (1) IP over MPLS over Ethernet and (2) low-order Optical Data Unit-k (ODUk) signals multiplexed into a high-order ODUl (l>k) carried over an Optical Channel (OCh) signal in an Optical Transport Network (OTN) as defined in [G.872] and [G.709].¶
TE links as defined in Section 3.3 can be used to represent links within a network layer. In the case of a multi-layer network, TE nodes and TE links only allow the representation of each network layer as a separate TE topology. Each of these single-layer TE topologies would be isolated from their client and their server-layer TE topology, if present. The highest network layer and the lowest network layer in the hierarchy only have a single adjacent layer below or above, respectively. Multiplexing client-layer signals and encapsulating them into a server-layer signal require a function that is provided inside a node (typically realized in hardware). This function is also called "layer transition".¶
One of the key requirements for path computation is to be able to calculate a path between two endpoints across a multi-layer network based on the TE topology representing this multi-layer network. This means that an additional TE construct is needed that represents potential layer transitions in the multi-layer TE topology that connects the TE topologies representing each separate network layer. The so-called transitional TE link is such a construct, and it represents the layer transition function residing inside a node that is decomposed into multiple logical nodes that are represented as TE nodes (also see [G.8080] for the definition of a transitional link for the OTN). Hence, a transitional TE link connects a client-layer node with a server-layer node. A TE link as defined in Section 3.3 has LTPs of exactly the same kind on each link end, whereas the transitional TE link has client-layer LTPs on the client side of the transitional link and, in most cases, a single server-layer LTP on the server side. It should be noted that transitional links are a helper construct in the multi-layer TE topology and they only exist as long as they are not in use, as they represent potential connectivity. When the server-layer trail has been established between the server-layer LTP of two transitional links in the server-layer network, the resulting client-layer link in the data plane will be represented as a normal TE link in the client-layer topology. The transitional TE links will reappear when the server-layer trail has been torn down.¶
3.5. TE Link Termination Point (LTP)
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.¶
3.6. TE Tunnel Termination Point (TTP)
A TE Tunnel Termination Point (TTP) is an element of a TE topology representing one or several potential transport service termination points (i.e., service client adaptation points, such as a WDM/OCh transponder). ("WDM" stands for "Wavelength Division Multiplexing".) A TTP is associated with (hosted by) exactly one TE node. A TTP is assigned a unique ID within the TE node scope. Depending on the TE node's internal constraints, a given TTP hosted by the TE node could be accessed via one, several, or all TE links terminated by the TE node.¶
3.7. TE Node Connectivity Matrix
A TE node connectivity matrix is a TE node's attribute describing the TE node's switching limitations in the form of valid switching combinations of the TE node's LTPs (see below). From the point of view of a potential TE path arriving at the TE node at a given inbound LTP, the node's connectivity matrix describes valid (permissible) outbound LTPs from which the TE path can leave the TE node.¶
In Figure 1, the connectivity matrix on Node-2 is as follows:¶
{<LTP-6, LTP-1>, <LTP-5, LTP-2>, <LTP-5, LTP-4>, <LTP-4, LTP-1>, <LTP-3, LTP-2>}¶
3.8. TTP Local Link Connectivity List (LLCL)
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. From the point of view of the potential TE path of a connection, an LLCL provides a list of valid TE links the TE path needs to start/stop on for the connection to be successfully terminated on a TTP.¶
In Figure 1, the LLCL on Node-1 is as follows:¶
{<TTP-1, LTP-5>, <TTP-1, LTP-2>, <TTP-2, LTP-3>, <TTP-2, LTP-4>}¶
3.9. TE Path
A TE path is an ordered list of TE links and/or TE nodes on the TE topology graph; this path interconnects a pair of TTPs to be used by a potential connection. For example, TE paths could be a product of successful path computation performed for a given transport service.¶
In Figure 1, the TE path for TE-Tunnel-1 is as follows:¶
{Node-1:TTP-1, Link-12, Node-2, Link-23, Node-3:TTP-1}¶
3.10. TE Inter-layer Lock
A TE inter-layer lock is a modeling concept describing adaptation relationships between the client layer and the server layer and hence is important for multi-layer Traffic Engineering. It is an association of M client-layer LTPs and N server-layer TTPs, within which data arriving at any of the client-layer LTPs could be adopted onto any of the server-layer TTPs. A TE inter-layer lock is identified by an inter-layer lock ID, which is unique across all TE topologies provided by the same provider. The client-layer LTPs and the server-layer TTPs associated within a given TE inter-layer lock are annotated with the same inter-layer lock ID attribute.¶
In Figure 3, a TE inter-layer lock with an ID of IL-1 associates six client-layer LTPs (C-LTP-1 through C-LTP-6) with two server-layer TTPs (S-TTP-1 and S-TTP-2). They all have the same attribute -- TE inter-layer lock ID IL-1, which is the only thing that indicates the association. A given LTP may have zero, one, or more inter-layer lock IDs. In the latter case, this means that the data arriving at the LTP may be adopted onto any of the TTPs associated with all specified inter-layer locks. For example, C-LTP-1 could have two inter-layer lock IDs -- IL-1 and IL-2. This would mean that C-LTP-1 for adaptation purposes could use not just the TTPs associated with inter-layer lock IL-1 (i.e., S-TTP-1 and S-TTP-2 in the figure) but any of the TTPs associated with inter-layer lock IL-2 as well. Likewise, a given TTP may have one or more inter-layer lock IDs, meaning that it can offer the adaptation service to any of the client-layer LTPs with an inter-layer lock ID matching one of its own. Additionally, each TTP has an unreserved adaptation bandwidth attribute, which announces its remaining adaptation resources that are sharable between all potential client-layer LTPs.¶
LTPs and TTPs associated within the same TE inter-layer lock may be hosted by the same (hybrid, multi-layer) TE node or multiple TE nodes located in the same or separate TE topologies. The latter case is especially important, since TE topologies of different layer networks could be modeled by separate augmentations of the basic (common to all layers) TE topology model.¶
3.11. Underlay TE Topology
An underlay TE topology is a TE topology that serves as a base for the construction of overlay TE topologies.¶
3.12. Overlay TE Topology
An overlay TE topology is a TE topology that is constructed based on one or more underlay TE topologies. Each TE node of the overlay TE topology represents an arbitrary segment of an underlay TE topology; each TE link of the overlay TE topology represents an arbitrary TE path in one of the underlay TE topologies. The overlay TE topology and the supporting underlay TE topologies may represent distinct layer networks (e.g., OTN/ODUk and WDM/OCh, respectively) or the same layer network.¶
3.13. Abstract TE Topology
An abstract TE topology is a topology that contains abstract topological
elements (nodes, links, TTPs). An abstract TE
topology is an overlay TE topology created by a topology provider and
customized for a topology provider's client based on one or more of
the provider's Native TE topologies (underlay TE topologies), the
provider's policies, and the client's preferences. For example, a
first-level topology provider (such as a domain controller) can create
an abstract TE topology for its client (e.g., a multi-domain service
coordinator) based on one or more of the provider's Native TE
topologies, local policies
4. Model Applicability
4.1. Native TE Topologies
The model discussed in this document can be used to represent and retrieve Native TE topologies on a given TE system.¶
Consider the network topology depicted in Figure 5. R1 .. R9 are nodes representing routers. An implementation MAY choose to construct a Native TE topology using all nodes and links present in the given TED as depicted in Figure 6. The data model defined in this document can be used to represent and retrieve this TE topology.¶
Consider the case where the topology is split in a way that some nodes participate in OSPF-TE while others participate in ISIS-TE (Figure 7). An implementation MAY choose to construct separate TE topologies based on the information source. The Native TE topologies constructed using only nodes and links that were learned via a specific information source are depicted in Figure 8. The data model defined in this document can be used to represent and retrieve these TE topologies.¶
Similarly, the data model can be used to represent and retrieve a TE topology that is constructed using only nodes and links that belong to a particular technology layer. The data model is flexible enough to represent and retrieve many such Native TE topologies.¶
4.2. Customized TE Topologies
A Customized TE topology is a topology that was modified by the provider to honor a particular client's requirements or preferences. The model discussed in this document can be used to represent, retrieve, and manipulate Customized TE topologies. The model allows the provider to present the network in abstract TE terms on a per‑client basis. These customized topologies contain sufficient information for the client to compute and select paths according to its policies.¶
Consider the network topology depicted in Figure 9. This is a typical packet optical transport deployment scenario where the WDM-layer network domain serves as a server network domain providing transport connectivity to the packet-layer network domain (client network domain). Nodes R1, R2, R3, and R4 are IP routers that are connected to an optical WDM transport network. A, B, C, D, E, and F are WDM nodes that constitute the server network domain.¶
The goal here is to augment the client's TE topology with a Customized TE topology provided by the WDM network. Given the availability of the paths A-E, B-F, and B-E (Figure 10), a Customized TE topology as depicted in Figure 11 is provided to the client. This Customized TE topology is merged with the client's Native TE topology, and the resulting topology is depicted in Figure 12.¶
The data model defined in this document can be used to represent, retrieve, and manipulate the Customized TE topology depicted in Figure 11.¶
A Customized TE topology is not necessarily an abstract TE topology.
The provider may produce, for example, an abstract TE topology of a
certain type (a single
The client ID field in the TE topology identifier (Section 5.4) indicates which client the TE topology is customized for. Although an authorized client MAY receive a TE topology with the client ID field matching some other client, 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. If the client starts the reconfiguration of a topology, its client ID will be automatically set in the topology ID field for all future configurations and updates with regard to the topology in question.¶
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.¶
Even though this data model allows the access of TE topology information across clients, implementations MAY restrict access for particular clients to particular data fields. The Network Configuration Access Control Model (NACM) [RFC8341] provides such a mechanism.¶
4.3. Merging TE Topologies Provided by Multiple Providers
A client may receive TE topologies provided by multiple providers, each of which manages a separate domain of a multi-domain network. In order to make use of said topologies, the client is expected to merge the provided TE topologies into one or more of its own Native TE topologies, each of which homogeneously represents the multi-domain network. This makes it possible for the client to select end-to-end TE paths for its services traversing multiple domains.¶
In particular, the process of merging TE topologies includes:¶
Figure 13 illustrates the process whereby the client merges the TE topologies furnished by its providers.¶
In Figure 13, each of the two providers caters to the client (abstract or Native) TE topology, describing the network domain under the respective provider's control. The client, by consulting such attributes of the inter-domain TE links as inter-domain plug IDs or remote TE node IDs / link IDs (as defined by the TE topology model), is able to determine that:¶
Therefore, the client interconnects the open-ended TE links, as shown on the upper part of the figure.¶
As mentioned previously, one way to interconnect the open-ended inter-domain TE links of neighboring domains is to mandate that the providers specify a remote node ID / link ID attribute in the provided inter-domain TE links. However, this may prove not to be flexible. For example, the providers may not know the respective remote node IDs / link IDs. More importantly, this option does not allow the client to mix and match multiple topologies (more than one topology) catered by the same providers (see below). Another option (which is more flexible) for resolving the open-ended inter-domain TE links is to annotate them with the inter-domain plug ID attribute. The inter-domain plug ID is a network-wide unique number that identifies on the network a connection that supports a given inter-domain TE link. Instead of specifying a remote node ID / link ID, an inter-domain TE link may provide a non-zero inter-domain plug ID. It is expected that two neighboring domain TE topologies (provided by separate providers) will each have at least one open-ended inter-domain TE link with an inter-domain plug ID matching an ID provided by its neighbor. For example, the inter-domain TE link originating from node S15 of the Domain 1 TE topology (Figure 13) and the inter-domain TE link coming from node S23 of the Domain 2 TE topology may specify a matching inter-domain plug ID (e.g., 175344). This allows the client to identify adjacent nodes in the separate neighboring TE topologies and resolve the inter-domain TE links connecting them, regardless of their respective node IDs / link IDs (which, as mentioned previously, could be allocated from independent namespaces). Inter-domain plug IDs may be assigned and managed by a central network authority. Alternatively, inter-domain plug IDs could be dynamically autodiscovered (e.g., via the Link Management Protocol (LMP)).¶
Furthermore, the client renames the TE nodes, links, and SRLGs offered
in the abstract TE topologies by assigning to them IDs allocated from
a separate namespace managed by the client. Such renaming is
necessary, because the two abstract TE topologies may have their own
namespaces, generally speaking, independent one from another; hence,
ID overlaps
Once the merging process is complete, the client can use the merged TE topology for path computations across both domains -- for example, to compute a TE path connecting C11 to C23.¶
4.4. Dealing with Multiple Abstract TE Topologies Provided by the Same Provider
Based on local configuration, templates, and/or policies pushed by the
client, a given provider may expose more than one abstract TE
topology to the client. For example, one abstract TE topology could
be optimized based on a lowest-cost criterion, while another one
could be based on best possible delay metrics, while yet another one
could be based on maximum bandwidth availability for the client
services. Furthermore, the client may request all or some providers
to expose additional abstract TE topologies, possibly of a different
type and/or optimized differently, as compared to already
It should be up to the client (based on the client's local configuration and/or policies conveyed to the client by the client's clients) to decide how to mix and match multiple abstract TE topologies provided by each or some of the providers, as well as how to merge them into the client's Native TE topologies. The client also decides how many such merged TE topologies it needs to produce and maintain. For example, in addition to the merged TE topology depicted in the upper part of Figure 13, the client may merge the abstract TE topologies received from the two providers, as shown in Figure 14, into the client's additional Native TE topologies, as shown in Figure 15.¶
Note that allowing the client to mix and match multiple TE topologies assumes that inter-domain plug IDs (rather than a remote node ID / link ID) are used as the option for identifying neighboring domains and inter-domain TE link resolution.¶
It is important to note that each of the three Native (merged) TE
topologies could be used by the client for computing TE paths for any
of the multi-domain services. The choice of which topology to use
for a given service depends on the service parameters
5. Modeling Considerations
5.1. Network Topology Building Blocks
The network topology building blocks are discussed in [RFC8345]. The
TE topology model defined in this document augments and uses the
"ietf
5.2. Technology-Agnostic TE Topology Model
The TE topology model defined in this document is meant to be
network technology agnostic. Other technology
5.3. Model Structure
The high-level model structure defined by this document is as shown below:¶
5.4. Topology Identifiers
The TE topology is uniquely identified by a key that has three constituents -- "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" is used only when Customized TE topologies come into play; a "client-id" value of "0" is used for Native TE topologies.¶
5.5. Generic TE Link Attributes
The model covers the definitions for generic TE link attributes -- bandwidth, administrative groups, SRLGs, switching capabilities, TE metric extensions, etc.¶
5.6. Generic TE Node Attributes
The model covers the definitions for generic TE node attributes.¶
The definition of a generic connectivity matrix is shown below:¶
The definition of a TTP Local Link Connectivity List is shown below:¶
The attributes directly under container "connectivity
Each TTP MAY be supported by one or more supporting TTPs. If the TE node hosting the TTP in question refers to a supporting TE node, then the supporting TTPs are hosted by the supporting TE node. If the TE node refers to an underlay TE topology, the supporting TTPs are hosted by one or more specified TE nodes of the underlay TE topology.¶
5.7. TED Information Sources
The model allows each TE topological element to have multiple TE
information sources (OSPF-TE, ISIS-TE, Border Gateway Protocol - Link State
(BGP-LS), user
5.8. Overlay/Underlay Relationship
The model captures the overlay and underlay relationship for TE nodes/links. For example, in networks where multiple TE topologies are built hierarchically, this model allows the user to start from a specific topological element in the topmost topology and traverse all the way down to the supporting topological elements in the bottommost topology.¶
This relationship is captured via the "underlay
5.9. Templates
The data model provides users with the ability to define templates and apply them to link and node configurations. The use of the "template" configuration is optional, and this functionality is tagged as a "feature" ("template").¶
Multiple templates can be specified for a configuration element. When
two or more templates specify values for the same configuration
field, the value from the template with the highest priority is used.
The range of the priority is from 0 to 65535, with a lower number
indicating a higher priority. The "reference
5.10. Scheduling Parameters
The model allows time-scheduling parameters to be specified for each topological element or for the topology as a whole. These parameters allow the provider to present different topological views to the client at different time slots. The use of time-scheduling parameters is optional.¶
The YANG data model for configuration scheduling is defined in [YANG-CFG-SCHED], which allows specifying configuration schedules without altering this data model.¶
6. Guidance for Writing Technology-Specific TE Topology Augmentations
The TE topology model defined in this document is technology agnostic,
as it defines concepts, abstractions, and attributes that are common
across multiple network technologies. It is envisioned that this base
model will be widely used when defining technology
Consider the following technology
The technology
The technology
The example YANG module that implements the above example topology is provided in Appendix C.¶
7. TE Topology YANG Module
This module references [RFC1195], [RFC3209], [RFC3272], [RFC3471], [RFC3630], [RFC3785], [RFC4201], [RFC4202], [RFC4203], [RFC4206], [RFC4872], [RFC5152], [RFC5212], [RFC5305], [RFC5316], [RFC5392], [RFC6001], [RFC6241], [RFC6991], [RFC7308], [RFC7471], [RFC7579], [RFC7752], [RFC8345], and [RFC8776].¶
8. 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
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.¶
There are a number of data nodes defined in this YANG module that are
writable
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
9. IANA Considerations
IANA has registered the following URIs in the "ns" subregistry within the "IETF XML Registry" [RFC3688].¶
- URI:
- urn
:ietf :params :xml :ns :yang :ietf -te -topology¶ - Registrant Contact:
- The IESG.¶
- XML:
- N/A; the requested URI is an XML namespace.¶
- URI:
- urn
:ietf :params :xml :ns :yang :ietf -te -topology -state¶ - Registrant Contact:
- The IESG.¶
- XML:
- N/A; the requested URI is an XML namespace.¶
IANA has registered the following YANG modules in the "YANG Module Names" subregistry [RFC6020] within the "YANG Parameters" registry.¶
10. References
10.1. Normative References
- [RFC2119]
-
Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10
.17487 , , <https:///RFC2119 www >..rfc -editor .org /info /rfc2119 - [RFC3688]
-
Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, DOI 10
.17487 , , <https:///RFC3688 www >..rfc -editor .org /info /rfc3688 - [RFC3945]
-
Mannie, E., Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Architecture", RFC 3945, DOI 10
.17487 , , <https:///RFC3945 www >..rfc -editor .org /info /rfc3945 - [RFC6020]
-
Bjorklund, M., Ed., "YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)", RFC 6020, DOI 10
.17487 , , <https:///RFC6020 www >..rfc -editor .org /info /rfc6020 - [RFC6241]
-
Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., and A. Bierman, Ed., "Network Configuration Protocol (NETCONF)", RFC 6241, DOI 10
.17487 , , <https:///RFC6241 www >..rfc -editor .org /info /rfc6241 - [RFC6242]
-
Wasserman, M., "Using the NETCONF Protocol over Secure Shell (SSH)", RFC 6242, DOI 10
.17487 , , <https:///RFC6242 www >..rfc -editor .org /info /rfc6242 - [RFC6991]
-
Schoenwaelder, J., Ed., "Common YANG Data Types", RFC 6991, DOI 10
.17487 , , <https:///RFC6991 www >..rfc -editor .org /info /rfc6991 - [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 , , <https:///RFC7926 www >..rfc -editor .org /info /rfc7926 - [RFC7950]
-
Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", RFC 7950, DOI 10
.17487 , , <https:///RFC7950 www >..rfc -editor .org /info /rfc7950 - [RFC8040]
-
Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF Protocol", RFC 8040, DOI 10
.17487 , , <https:///RFC8040 www >..rfc -editor .org /info /rfc8040 - [RFC8174]
-
Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10
.17487 , , <https:///RFC8174 www >..rfc -editor .org /info /rfc8174 - [RFC8341]
-
Bierman, A. and M. Bjorklund, "Network Configuration Access Control Model", STD 91, RFC 8341, DOI 10
.17487 , , <https:///RFC8341 www >..rfc -editor .org /info /rfc8341 - [RFC8342]
-
Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., and R. Wilton, "Network Management Datastore Architecture (NMDA)", RFC 8342, DOI 10
.17487 , , <https:///RFC8342 www >..rfc -editor .org /info /rfc8342 - [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 , , <https:///RFC8345 www >..rfc -editor .org /info /rfc8345 - [RFC8446]
-
Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10
.17487 , , <https:///RFC8446 www >..rfc -editor .org /info /rfc8446 - [RFC8776]
-
Saad, T., Gandhi, R., Liu, X., Beeram, V., and I. Bryskin, "Common YANG Data Types for Traffic Engineering", RFC 8776, DOI 10
.17487 , , <https:///RFC8776 www >..rfc -editor .org /info /rfc8776
10.2. Informative References
- [G.709]
-
ITU-T, "Interfaces for the optical transport network", ITU-T Recommendation G.709, , <https://
www >..itu .int /rec /T -REC -G .709 / - [G.805]
-
ITU-T, "Generic functional architecture of transport networks", ITU-T Recommendation G.805, , <https://
www >..itu .int /rec /T -REC -G .805 /en - [G.8080]
-
ITU-T, "Architecture for the automatically switched optical network", ITU-T Recommendation G.8080, , <https://
www >..itu .int /rec /T -REC -G .8080 /en - [G.872]
-
ITU-T, "Architecture of optical transport networks", ITU-T Recommendation G.872, , <https://
www >..itu .int /rec /T -REC -G .872 /en - [RFC1195]
-
Callon, R., "Use of OSI IS-IS for routing in TCP/IP and dual environments", RFC 1195, DOI 10
.17487 , , <https:///RFC1195 www >..rfc -editor .org /info /rfc1195 - [RFC2702]
-
Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M., and J. McManus, "Requirements for Traffic Engineering Over MPLS", RFC 2702, DOI 10
.17487 , , <https:///RFC2702 www >..rfc -editor .org /info /rfc2702 - [RFC3209]
-
Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, DOI 10
.17487 , , <https:///RFC3209 www >..rfc -editor .org /info /rfc3209 - [RFC3272]
-
Awduche, D., Chiu, A., Elwalid, A., Widjaja, I., and X. Xiao, "Overview and Principles of Internet Traffic Engineering", RFC 3272, DOI 10
.17487 , , <https:///RFC3272 www >..rfc -editor .org /info /rfc3272 - [RFC3471]
-
Berger, L., Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description", RFC 3471, DOI 10
.17487 , , <https:///RFC3471 www >..rfc -editor .org /info /rfc3471 - [RFC3630]
-
Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering (TE) Extensions to OSPF Version 2", RFC 3630, DOI 10
.17487 , , <https:///RFC3630 www >..rfc -editor .org /info /rfc3630 - [RFC3785]
-
Le Faucheur, F., Uppili, R., Vedrenne, A., Merckx, P., and T. Telkamp, "Use of Interior Gateway Protocol (IGP) Metric as a second MPLS Traffic Engineering (TE) Metric", BCP 87, RFC 3785, DOI 10
.17487 , , <https:///RFC3785 www >..rfc -editor .org /info /rfc3785 - [RFC4201]
-
Kompella, K., Rekhter, Y., and L. Berger, "Link Bundling in MPLS Traffic Engineering (TE)", RFC 4201, DOI 10
.17487 , , <https:///RFC4201 www >..rfc -editor .org /info /rfc4201 - [RFC4202]
-
Kompella, K., Ed. and Y. Rekhter, Ed., "Routing Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)", RFC 4202, DOI 10
.17487 , , <https:///RFC4202 www >..rfc -editor .org /info /rfc4202 - [RFC4203]
-
Kompella, K., Ed. and Y. Rekhter, Ed., "OSPF Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)", RFC 4203, DOI 10
.17487 , , <https:///RFC4203 www >..rfc -editor .org /info /rfc4203 - [RFC4206]
-
Kompella, K. and Y. Rekhter, "Label Switched Paths (LSP) Hierarchy with Generalized Multi-Protocol Label Switching (GMPLS) Traffic Engineering (TE)", RFC 4206, DOI 10
.17487 , , <https:///RFC4206 www >..rfc -editor .org /info /rfc4206 - [RFC4872]
-
Lang, J.P., Ed., Rekhter, Y., Ed., and D. Papadimitriou, Ed., "RSVP-TE Extensions in Support of End-to-End Generalized Multi-Protocol Label Switching (GMPLS) Recovery", RFC 4872, DOI 10
.17487 , , <https:///RFC4872 www >..rfc -editor .org /info /rfc4872 - [RFC5152]
-
Vasseur, JP., Ed., Ayyangar, A., Ed., and R. Zhang, "A Per-Domain Path Computation Method for Establishing Inter-Domain Traffic Engineering (TE) Label Switched Paths (LSPs)", RFC 5152, DOI 10
.17487 , , <https:///RFC5152 www >..rfc -editor .org /info /rfc5152 - [RFC5212]
-
Shiomoto, K., Papadimitriou, D., Le Roux, JL., Vigoureux, M., and D. Brungard, "Requirements for GMPLS-Based Multi-Region and Multi-Layer Networks (MRN/MLN)", RFC 5212, DOI 10
.17487 , , <https:///RFC5212 www >..rfc -editor .org /info /rfc5212 - [RFC5305]
-
Li, T. and H. Smit, "IS-IS Extensions for Traffic Engineering", RFC 5305, DOI 10
.17487 , , <https:///RFC5305 www >..rfc -editor .org /info /rfc5305 - [RFC5316]
-
Chen, M., Zhang, R., and X. Duan, "ISIS Extensions in Support of Inter
-Autonomous System (AS) MPLS and GMPLS Traffic Engineering" , RFC 5316, DOI 10.17487 , , <https:///RFC5316 www >..rfc -editor .org /info /rfc5316 - [RFC5392]
-
Chen, M., Zhang, R., and X. Duan, "OSPF Extensions in Support of Inter
-Autonomous System (AS) MPLS and GMPLS Traffic Engineering" , RFC 5392, DOI 10.17487 , , <https:///RFC5392 www >..rfc -editor .org /info /rfc5392 - [RFC6001]
-
Papadimitriou, D., Vigoureux, M., Shiomoto, K., Brungard, D., and JL. Le Roux, "Generalized MPLS (GMPLS) Protocol Extensions for Multi-Layer and Multi-Region Networks (MLN/MRN)", RFC 6001, DOI 10
.17487 , , <https:///RFC6001 www >..rfc -editor .org /info /rfc6001 - [RFC7308]
-
Osborne, E., "Extended Administrative Groups in MPLS Traffic Engineering (MPLS-TE)", RFC 7308, DOI 10
.17487 , , <https:///RFC7308 www >..rfc -editor .org /info /rfc7308 - [RFC7471]
-
Giacalone, S., Ward, D., Drake, J., Atlas, A., and S. Previdi, "OSPF Traffic Engineering (TE) Metric Extensions", RFC 7471, DOI 10
.17487 , , <https:///RFC7471 www >..rfc -editor .org /info /rfc7471 - [RFC7579]
-
Bernstein, G., Ed., Lee, Y., Ed., Li, D., Imajuku, W., and J. Han, "General Network Element Constraint Encoding for GMPLS
-Controlled Networks" , RFC 7579, DOI 10.17487 , , <https:///RFC7579 www >..rfc -editor .org /info /rfc7579 - [RFC7752]
-
Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and S. Ray, "North-Bound Distribution of Link-State and Traffic Engineering (TE) Information Using BGP", RFC 7752, DOI 10
.17487 , , <https:///RFC7752 www >..rfc -editor .org /info /rfc7752 - [RFC8340]
-
Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", BCP 215, RFC 8340, DOI 10
.17487 , , <https:///RFC8340 www >..rfc -editor .org /info /rfc8340 - [RFC8639]
-
Voit, E., Clemm, A., Gonzalez Prieto, A., Nilsen-Nygaard, E., and A. Tripathy, "Subscription to YANG Notifications", RFC 8639, DOI 10
.17487 , , <https:///RFC8639 www >..rfc -editor .org /info /rfc8639 - [RFC8641]
-
Clemm, A. and E. Voit, "Subscription to YANG Notifications for Datastore Updates", RFC 8641, DOI 10
.17487 , , <https:///RFC8641 www >..rfc -editor .org /info /rfc8641 - [TEAS-TOPO]
-
Bryskin, I., Beeram, V., Saad, T., and X. Liu, "TE Topology and Tunnel Modeling for Transport Networks", Work in Progress, Internet-Draft, draft
-ietf , , <https://-teas -te -topo -and -tunnel -modeling -06 tools >..ietf .org /html /draft -ietf -teas -te -topo -and -tunnel -modeling -06 - [YANG-CFG-SCHED]
-
Liu, X., Bryskin, I., Beeram, V., Saad, T., Shah, H., and O. Gonzalez de Dios, "A YANG Data Model for Configuration Scheduling", Work in Progress, Internet-Draft, draft
-liu , , <https://-netmod -yang -schedule -05 tools >..ietf .org /html /draft -liu -netmod -yang -schedule -05 - [YANG-L3]
-
Liu, X., Bryskin, I., Beeram, V., Saad, T., Shah, H., and O. Gonzalez de Dios, "YANG Data Model for Layer 3 TE Topologies", Work in Progress, Internet-Draft, draft
-ietf , , <https://-teas -yang -l3 -te -topo -08 tools >..ietf .org /html /draft -ietf -teas -yang -l3 -te -topo -08 - [YANG-OTN]
-
Zheng, H., Busi, I., Liu, X., Belotti, S., and O. Gonzalez de Dios, "A YANG Data Model for Optical Transport Network Topology", Work in Progress, Internet-Draft, draft
-ietf , , <https://-ccamp -otn -topo -yang -10 tools >..ietf .org /html /draft -ietf -ccamp -otn -topo -yang -10 - [YANG-WSON]
-
Zheng, H., Lee, Y., Guo, A., Lopez, V., and D. King, "A YANG Data Model for WSON (Wavelength Switched Optical Networks)", Work in Progress, Internet-Draft, draft
-ietf , , <https://-ccamp -wson -yang -25 tools >..ietf .org /html /draft -ietf -ccamp -wson -yang -25
Appendix B. Companion YANG Data Model for Non-NMDA-Compliant Implementations
The YANG module "ietf
This companion module is redundant and SHOULD NOT be supported by implementations that support NMDA; therefore, we define it below rather than in the main body of this document.¶
As the structure of the module "ietf
Appendix C. Example: YANG Data Model for Technology-Specific Augmentations
This appendix provides an example YANG module that defines a
technology
Acknowledgments
The authors would like to thank Lou Berger, Sue Hares, Mazen Khaddam, Cyril Margaria, and Zafar Ali for participating in design discussions and providing valuable insights.¶