A YANG Data Model for Traffic Engineering Tunnels, Label Switched Paths and InterfacesJuniper Networkstsaad@juniper.netCisco Systems Incrgandhi@cisco.comVolta Networksxufeng.liu.ietf@gmail.comJuniper Networksvbeeram@juniper.netIndividuali_bryskin@yahoo.comTelefonicaoscar.gonzalezdedios@telefonica.comTEAS Working GroupInternet-DraftThis document defines a YANG data model for the provisioning and management of
Traffic Engineering (TE) tunnels, Label Switched Paths (LSPs), and interfaces.
The model is divided into YANG modules that classify data into generic,
device-specific, technology agnostic, and technology-specific elements.This model covers data for configuration, operational state, remote procedural
calls, and event notifications.YANG and is a data modeling language that was
introduced to define the contents of a conceptual data store that allows
networked devices to be managed using NETCONF . YANG has proved
relevant beyond its initial confines, as bindings to other interfaces (e.g.
RESTCONF ) and encoding other than XML (e.g. JSON) are being defined.
Furthermore, YANG data models can be used as the basis of implementation for
other interfaces, such as CLI and programmatic APIs.This document describes YANG data model for Traffic Engineering (TE) tunnels,
Label Switched Paths (LSPs), and interfaces. The model covers data applicable
to generic or device-independent, device-specific, and Multiprotocol Label
Switching (MPLS) technology specific.The document describes a high-level relationship between the modules defined in
this document, as well as other external protocol YANG modules. The TE generic
YANG data model does not include any data specific to a signaling protocol. It
is expected other data plane technology model(s) will augment the TE generic
YANG data model.Also, it is expected other YANG module(s) that model TE signaling protocols,
such as RSVP-TE (, ), or Segment-Routing TE (SR-TE)
will augment the generic TE YANG module.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 when, and only when, they
appear in all capitals, as shown here.The following terms are defined in and are used in this specification:clientconfiguration datastate dataThis document also makes use of the following terminology introduced in the
YANG Data Modeling Language :augmentdata modeldata nodeIn 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 .PrefixYANG moduleReferenceyangietf-yang-typesinetietf-inet-typesrt-typesietf-routing-typeste-typesietf-te-typeste-packet-typesietf-te-packet-typesteietf-tethis documentte-devietf-te-devicethis documentThe tree diagrams extracted from the module(s) defined in this document are given in
subsequent sections as per the syntax defined in .This document describes a generic TE YANG data model that is independent of
any dataplane technology. One of the design objectives is to allow specific
data plane technology models to reuse the TE generic data model and possibly
augment it with technology specific data.The elements of the generic TE YANG data model, including TE Tunnels, LSPs, and
interfaces have leaf(s) that identify the technology layer where they reside.
For example, the LSP encoding type can identify the technology associated with a
TE Tunnel or LSP.Also, the generic TE YANG data model does not cover signaling protocol data.
The signaling protocol used to instantiate TE LSPs are outside the scope of this
document and expected to be covered by augmentations defined in other document(s).The following other design considerations are taken into account with respect data
organization:The generic TE YANG data model ‘ietf-te’ contains device independent data and
can be used to model data off a device (e.g. on a TE controller). The
device-specific TE data is defined in module ‘ietf-te-device’ as
shown in ,In general, minimal elements in the model are designated as “mandatory” to
allow freedom to vendors to adapt the data model to their specific product
implementation.Suitable defaults are specified for all configurable elements.The model declares a number of TE functions as features that can be
optionally supported.The Network Management Datastore Architecture (NMDA) addresses
modeling state data for ephemeral objects. This document adopts the NMDA model
for configuration and state data representation as per IETF guidelines for new
IETF YANG models.The data models defined in this document cover the core TE features that are
commonly supported by different vendor implementations. The support of extended
or vendor specific TE feature(s) is expected to be in either augmentations, or
deviations to the model defined in this document.The generic TE YANG data model that is defined in “ietf-te.yang” covers the
building blocks that are device independent and agnostic of any specific
technology or control plane instances. The TE device model defined in
“ietf-te-device.yang” augments the generic TE YANG data model and covers data
that is specific to a device – for example, attributes of TE interfaces, or
TE timers that are local to a TE node.The TE data model for specific instances of data plane technology exist in a
separate YANG module(s) that augment the generic TE YANG data model. For
example, the MPLS-TE module “ietf-te-mpls.yang” is defined in another document
and augments the TE generic model as shown in .The TE data model for specific instances of signaling protocol are outside the
scope of this document and are defined in other documents. For example, the
RSVP-TE YANG model augmentation of the TE model is covered in
.The generic TE YANG module (‘ietf-te’) is meant to manage and operate a TE network.
This includes creating, modifying and retrieving TE Tunnels, LSPs, and interfaces
and their associated attributes (e.g. Administrative-Groups, SRLGs, etc.).The detailed tree structure is provided in .The ‘ietf-te’ uses three main containers grouped under the main ‘te’ container
(see ). The ‘te’ container is the top level container in the
data model. The presence of the ‘te’ container enables TE function system wide.
Below provides further descriptions of containers that exist under the ‘te’ top
level container.globals:The ‘globals’ container maintains the set of global TE attributes that can be
applicable to TE Tunnel(s) and interface(s).tunnels:The ‘tunnels’ container includes the list of TE Tunnels that are instantiated. Refer to
for further details on the properties of a TE Tunnel.lsps:The ‘lsps’ container includes the list of TE LSP(s) that are instantiated for
TE Tunnels. Refer to for further details on the properties of a TE LSP.tunnels-path-compute:A Remote Procedure Call (RPC) to request path computation for a specific TE Tunnel.
The RPC allows requesting path computation using atomic and stateless operation.
A tunnel may also be configured in ‘compute-only’ mode to provide stateful path updates
- see for further details.tunnels-action:An RPC to request a specific action (e.g. reoptimize, or tear-and-setup) to be taken
on a specific tunnel or all tunnels.The ‘globals’ container covers properties that control TE features behavior
system-wide, and its respective state (see ).
The TE globals configuration include:named-admin-groups:A YANG container for the list of named (extended) administrative groups that may be applied
to TE links.named-srlgs:A YANG container for the list named Shared Risk Link Groups (SRLGs) that may be
applied to TE links.named-path-constraints:A YANG container for a list of named path constraints. Each named path constraint is
composed of a set of constraints that can be applied during path computation.
A named path constraint can be applied to multiple TE Tunnels. Path constraints may also
be specified directly under the TE Tunnel. The path constraint specified under
the TE Tunnel take precedence over the path constraints
derived from the referenced named path constraint. A named path constraint entry can be
formed up of the following path constraints:te-bandwidth: A YANG container that holds the technology agnostic TE bandwidth constraint.link-protection: A YANG leaf that holds the link protection type constraint required for the links to be included in the computed path.setup/hold priority: A YANG leaf that holds the LSP setup and hold admission priority as defined in .signaling-type: A YANG leaf that holds the LSP setup type, such as RSVP-TE or SR.path-metric-bounds: A YANG container that holds the set of metric bounds applicable on the
computed TE tunnel path.path-affinities-values: A YANG container that holds the set of affinity values and
mask to be used during path computation.path-affinity-names: A YANG container that holds the set of named affinity constraints and
corresponding inclusion or exclusions instruction for each to be used during path computation.path-srlgs-lists: A YANG container that holds the set of SRLG values and
corresponding inclusion or exclusions instruction to be used during path computation.path-srlgs-names: A YANG container that holds the set of named SRLG constraints and
corresponding inclusion or exclusions instruction for each to be used during path computation.disjointness: The level of resource disjointness constraint that the secondary path
of a TE tunnel has to adhere to.explicit-route-objects-always: A YANG container that contains two route objects lists: ‘route-object-exclude-always’: a list of route entries to always exclude from the path computation.‘route-object-include-exclude’: a list of route entries to include or exclude in the path computation.The ‘route-object-include-exclude’ is used to configure constraints on which route objects (e.g., nodes, links) are included or excluded in the path computation.The interpretation of an empty ‘route-object-include-exclude’ list depends on the TE Tunnel (end-to-end or Tunnel Segment) and on the specific path, according to the following rules:An empty ‘route-object-include-exclude’ list for the primary path of an end-to-end TE Tunnel indicates that there are no route objects to be included or excluded in the path computation.An empty ‘route-object-include-exclude’ list for the primary path of a TE Tunnel Segment indicates that no primary LSP is required for that TE Tunnel.An empty ‘route-object-include-exclude’ list for a reverse path means it always follows the forward path (i.e., the TE Tunnel is co-routed). When the ‘route-object-include-exclude’ list is not empty, the reverse path is routed independently of the forward path.An empty ‘route-object-include-exclude’ list for the secondary (forward) path indicates that the secondary path has the same endpoints as the primary path.The ‘tunnels’ container holds the list of TE Tunnels that are provisioned on
devices in the network (see ).A TE Tunnel in the list is uniquely identified by a name.
When the model is used to manage a specific device, the ‘tunnels’ list contains
the TE Tunnels originating from the specific device. When the model is used to
manage a TE controller, the ‘tunnels’ list contains all TE Tunnels and TE
tunnel segments originating from device(s) that the TE controller manages.The TE Tunnel model allows the configuration and management of the following TE
tunnel related objected:TE Tunnel:A YANG container of one or more LSPs established between the source and destination
TE Tunnel termination points. A TE Tunnel LSP is a connection-oriented service
provided by the network layer for the delivery of client data between a source and
the destination of the TE Tunnel termination points.TE Tunnel Segment:A part of a multi-domain TE Tunnel that is within a specific network domain.The TE Tunnel has a number of attributes that are set directly under the
tunnel (see ). The main attributes of a TE Tunnel are described below:operational-state:A YANG leaf that holds the operational state of the tunnel.name:A YANG leaf that holds the name of a TE Tunnel. The name of the
TE Tunnel uniquely identifies the tunnel within the TE tunnel list. The name
of the TE Tunnel can be formatted as a Uniform Resource Indicator (URI) by
including the namespace to ensure uniqueness of the name amongst all the TE
Tunnels present on devices and controllers.alias:A YANG leaf that holds an alternate name to the TE tunnel. Unlike the TE tunnel
name, the alias can be modified at any time during the lifetime of the TE tunnel.identifier:A YANG leaf that holds an identifier of the tunnel. This identifier is unique amongst tunnels
originated from the same ingress device.color:A YANG leaf that holds the color associated with the TE tunnel. The color is used
to map or steer services that carry matching color on to the TE tunnel as described in
.encoding/switching:The ‘encoding’ and ‘switching-type’ are YANG leafs that define the specific
technology in which the tunnel operates in as described in .reoptimize-timer:A YANG leaf to set the inteval period for tunnel reoptimization.source/destination:YANG leafs that define the tunnel source and destination node endpoints.src-tunnel-tp-id/dst-tunnel-tp-id:YANG leafs that hold the identifiers of source and destination TE Tunnel
Termination Points (TTPs) residing on the source and
destination nodes. The TTP identifiers are optional on nodes that have a
single TTP per node. For example, TTP identifiers are optional for packet
(IP/MPLS) routers.controller:A YANG container that holds tunnel data relevant to an optional external TE controller that
may initiate or control a tunnel. This target node may be augmented by external module(s), for example, to add data for PCEP initiated and/or
delegated tunnels.bidirectional:A YANG leaf that when present indicates the LSPs of a TE Tunnel are bidirectional and co-routed.association-objects:A YANG container that holds the set of associations of the TE Tunnel to other
TE Tunnels. Associations at the TE Tunnel level apply to all paths of the TE
Tunnel. The TE tunnel associations can be overridden by associations
configured directly under the TE Tunnel path.protection:A YANG container that holds the TE Tunnel protection properties.restoration:A YANG container that holds the TE Tunnel restoration properties.te-topology-identifier:A YANG container that holds the topology identifier associated with the topology where paths for the TE tunnel are computed.hierarchy:A YANG container that holds hierarchy related properties of the TE Tunnel (see . A TE LSP
can be set up in MPLS or Generalized MPLS (GMPLS) networks to be used as
a TE links to carry traffic in other (client) networks . In this
case, the model introduces the TE Tunnel hierarchical link endpoint parameters
to identify the specific link in the client layer that the underlying TE Tunnel is
associated with. The hierarchy container includes the following:dependency-tunnels: A set of hierarchical TE Tunnels provisioned or to be
provisioned in the immediate lower layer that this TE tunnel depends on for
multi-layer path computation. A dependency TE Tunnel is provisioned if and
only if it is used (selected by path computation) at least by one client
layer TE Tunnel. The TE link in the client layer network topology supported
by a dependent TE Tunnel is dynamically created only when the dependency TE
Tunnel is actually provisioned.hierarchical-link: A YANG container that holds the identity of the
hierarchical link (in the client layer) that is supported by this TE Tunnel.
The endpoints of the hierarchical link are defined by TE tunnel source and
destination node endpoints. The hierarchical link can be identified by its source
and destination link termination point identifiers.The TE Tunnel can be configured with a set of paths that define the tunnel
forward and reverse paths as described in . Moreover, a primary
path can be specified a set of candidate secondary paths that can be visited to
support path protection. The following describe further the list of paths associated with a
TE Tunnel.primary-paths:A YANG container that holds the list of primary paths.
A primary path is identified by ‘name’. A primary path is selected from the list
to instantiate a primary forwarding LSP for the tunnel. The list of primary
paths is visited by order of preference. A primary path has the following
attributes:primary-reverse-path: A YANG container that holds properties of the
primary reverse path. The reverse path is applicable to
bidirectional TE Tunnels.candidate-secondary-paths: A YANG container that holds a list of candidate
secondary paths which may be used for the primary path to support path
protection. The candidate secondary path(s) reference path(s) from the
tunnel secondary paths list. The preference of the secondary paths is
specified within the list and dictates the order of visiting the secondary
path from the list. The attributes of a secondary path can be defined
separately from the primary path. The attributes of a secondary path will be
inherited from the associated ‘active’ primary when not explicitly defined
for the secondary path.secondary-paths:A YANG container that holds the set of secondary paths. A secondary path is
identified by ‘name’. A secondary path can be referenced from the TE Tunnel’s
‘candidate-secondary-path’ list. A secondary path contains attributes similar to a primary path.secondary-reverse-paths:A YANG container that holds teh set of secondary reverse paths. A secondary reverse
path is identified by ‘name’. A secondary reverse path can be referenced from the
TE Tunnel’s ‘candidate-secondary-reverse-paths’ list. A secondary reverse path contains
attributes similar to a primary path.The following set common path attributes are shared for primary forward and reverse primary and secondary paths:compute-only:A path of TE Tunnel is, by default, provisioned so that it can is instantiated
in forwarding to carry traffic as soon as a valid path is computed. In some cases,
a TE path may be provisioned for the only purpose of computing a path
and reporting it without the need to instantiate the LSP or commit any
resources. In such a case, the path is configured in ‘compute-only’ mode to
distinguish it from the default behavior. A ‘compute-only’ path is configured
as a usual with the associated per path constraint(s) and properties on a
device or TE controller. The device or TE controller computes the feasible path(s) subject
to configured constraints. A client may query the
‘compute-only’ computed path properties ‘on-demand’, or alternatively, can subscribe
to be notified of computed path(s) and whenever the path properties change.use-path-computation:A YANG leaf that indicates whether or not path computation is to
be used for a specified path.lockdown:A YANG leaf that when set indicates the existing path should not be reoptimized
after a failure on any of its traversed links.te-topology-identifier:A YANG container that holds the topology identifier
associated with the tunnel.optimizations:a YANG container that holds the optimization objectives
that path computation will use to select a path.computed-paths-properties:
> A YANG container that holds properties for the list of computed paths.computed-path-error-infos:A YANG container that holds a list of errors related to the path.lsps:a YANG container that holds a list of LSPs that are instantiated for this specific path.The ‘lsps’ container includes the set of TE LSP(s) that are instantiated.
A TE LSP is identified by a 3-tuple (‘tunnel-name’, ‘node’, ‘lsp-id’).When the model is used to manage a specific device, the ‘lsps’ list contains all TE
LSP(s) that traverse the device (including ingressing, transiting and egressing the device).When the model is used to manage a TE controller, the ‘lsps’ list contains all
TE LSP(s) that traverse all network devices (including ingressing, transiting and
egressing the device) that the TE controller manages. shows the tree diagram of the generic TE YANG model defined in
modules ‘ietf-te.yang’.The generic TE YANG module ‘ietf-te’ imports the following modules:ietf-yang-types and ietf-inet-types defined in ietf-te-types defined in This module references the following documents:
, , , , ,
, , , , , and
.The device TE YANG module (‘ietf-te-device’) models data that is specific to
managing a TE device. This module augments the generic TE YANG module.This branch of the model manages TE interfaces that are present on a device.
Examples of TE interface properties are:Maximum reservable bandwidth, bandwidth constraints (BC)Flooding parameters
Flooding intervals and threshold valuesinterface attributes
(Extended) administrative groupsSRLG valuesTE metric valueFast reroute backup tunnel properties (such as static, auto-tunnel)The derived state associated with interfaces is grouped under the interface
“state” sub-container as shown in . This covers state data
such as:Bandwidth information: maximum bandwidth, available bandwidth at different
priorities and for each class-type (CT)List of admitted LSPs
Name, bandwidth value and pool, time, priorityStatistics: state counters, flooding counters, admission counters
(accepted/rejected), preemption countersAdjacency information
Neighbor addressMetric value shows the tree diagram of the device TE YANG model defined in
modules ‘ietf-te.yang’.The device TE YANG module ‘ietf-te-device’ imports the following module(s):ietf-yang-types and ietf-inet-types defined in ietf-interfaces defined in ietf-routing-types defined in ietf-te-types defined in ietf-te defined in this documentNotifications are a key component of any topology data model. and define a subscription mechanism and a push
mechanism for YANG datastores. These mechanisms currently allow the
user to:Subscribe to notifications on a per-client basis.Specify subtree filters or XML Path Language (XPath) filters so
that only contents of interest will be sent.Specify either periodic or on-demand notifications.This document registers the following URIs in the IETF XML registry
.
Following the format in , the following registrations are
requested to be made.This document registers two YANG modules in the YANG Module Names
registry .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
or RESTCONF . The lowest NETCONF layer is the secure
transport layer, and the mandatory-to-implement secure transport is Secure
Shell (SSH) . The lowest RESTCONF layer is HTTPS, and the
mandatory-to-implement secure transport is TLS .The Network Configuration Access Control Model (NACM) 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/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:“/te/globals”: This module specifies the global TE configurations on a device.
Unauthorized access to this container could cause the device to ignore packets
it should receive and process.“/te/tunnels”: This list specifies the configuration and state of TE Tunnels
present on the device or controller. Unauthorized access to this list could
cause the device to ignore packets it should receive and process. An attacker
may also use state to derive information about the network topology,
and subsequently orchestrate further attacks.“/te/interfaces”: This list specifies the configuration and state TE interfaces
on a device. Unauthorized access to this list could cause the device to ignore packets it
should receive and process.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:“/te/lsps”: this list contains information state about established LSPs in the network.
An attacker can use this information to derive information about the network topology,
and subsequently orchestrate further attacks.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:“/te/tunnels-actions”: using this RPC, an attacker can modify existing paths that
may be carrying live traffic, and hence result to interruption to services
carried over the network.“/te/tunnels-path-compute”: using this RPC, an attacker can retrieve secured
information about the network provider which can be used to orchestrate further
attacks.The security considerations spelled out in the YANG 1.1 specification
apply for this document as well.The authors would like to thank the members of the multi-vendor YANG design
team who are involved in the definition of this model.The authors would like to thank Tom Petch for reviewing and providing useful
feedback about the document. The authors would also like to thank Loa
Andersson, Lou Berger, Sergio Belotti, Italo Busi, Carlo Perocchio, Francesco
Lazzeri, Aihua Guo, Dhruv Dhody, and Raqib Jones for providing useful feedback on this
document.This section contains examples of use of the model with RESTCONF and JSON encoding.For the example we will use a 4 node MPLS network were RSVP-TE MPLS Tunnels can be setup. The
loopbacks of each router are shown. The network in will be used in the examples
described in the following sections.This example uses the TE Tunnel YANG data model defined in this document to create an
RSVP-TE signaled Tunnel of packet LSP encoding type. First, the TE Tunnel is created with no specific restrictions or constraints (e.g., protection or restoration).
The TE Tunnel ingresses on router A and egresses on router D.In this case, the TE Tunnel is created without specifying additional information about the primary paths.This example uses the YANG data model to create a ‘named path constraitnt’ that can be reference by TE Tunnels.
The path constraint, in this case, limits the TE Tunnel hops for the computed path.In this example, the previously created ‘named path constraint’ is applied to the TE Tunnel created in .In this example, the a per tunnel path constraint is explicitly indicated under the TE Tunnel created in to constrain the computed path for the tunnel.In this example, the ‘GET’ query is sent to return the state stored about the tunnel.The request, with status code 200 would include, for example, the following json:RSVP-TE: Extensions to RSVP for LSP TunnelsThis document describes the use of RSVP (Resource Reservation Protocol), including all the necessary extensions, to establish label-switched paths (LSPs) in MPLS (Multi-Protocol Label Switching). Since the flow along an LSP is completely identified by the label applied at the ingress node of the path, these paths may be treated as tunnels. A key application of LSP tunnels is traffic engineering with MPLS as specified in RFC 2702. [STANDARDS-TRACK]Key words for use in RFCs to Indicate Requirement LevelsIn many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)YANG is a data modeling language used to model configuration and state data manipulated by the Network Configuration Protocol (NETCONF), NETCONF remote procedure calls, and NETCONF notifications. [STANDARDS-TRACK]Network Configuration Protocol (NETCONF)The Network Configuration Protocol (NETCONF) defined in this document provides mechanisms to install, manipulate, and delete the configuration of network devices. It uses an Extensible Markup Language (XML)-based data encoding for the configuration data as well as the protocol messages. The NETCONF protocol operations are realized as remote procedure calls (RPCs). This document obsoletes RFC 4741. [STANDARDS-TRACK]Common YANG Data TypesThis document introduces a collection of common data types to be used with the YANG data modeling language. This document obsoletes RFC 6021.Procedures for Dynamically Signaled Hierarchical Label Switched PathsLabel Switched Paths (LSPs) set up in Multiprotocol Label Switching (MPLS) or Generalized MPLS (GMPLS) networks can be used to form links to carry traffic in those networks or in other (client) networks.Protocol mechanisms already exist to facilitate the establishment of such LSPs and to bundle traffic engineering (TE) links to reduce the load on routing protocols. This document defines extensions to those mechanisms to support identifying the use to which such LSPs are to be put and to enable the TE link endpoints to be assigned addresses or unnumbered identifiers during the signaling process. [STANDARDS-TRACK]RESTCONF ProtocolThis document describes an HTTP-based protocol that provides a programmatic interface for accessing data defined in YANG, using the datastore concepts defined in the Network Configuration Protocol (NETCONF).The YANG 1.1 Data Modeling LanguageYANG is a data modeling language used to model configuration data, state data, Remote Procedure Calls, and notifications for network management protocols. This document describes the syntax and semantics of version 1.1 of the YANG language. YANG version 1.1 is a maintenance release of the YANG language, addressing ambiguities and defects in the original specification. There are a small number of backward incompatibilities from YANG version 1. This document also specifies the YANG mappings to the Network Configuration Protocol (NETCONF).Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) ExtensionsThis document describes extensions to Multi-Protocol Label Switching (MPLS) Resource ReserVation Protocol - Traffic Engineering (RSVP-TE) signaling required to support Generalized MPLS. Generalized MPLS extends the MPLS control plane to encompass time-division (e.g., Synchronous Optical Network and Synchronous Digital Hierarchy, SONET/SDH), wavelength (optical lambdas) and spatial switching (e.g., incoming port or fiber to outgoing port or fiber). This document presents a RSVP-TE specific description of the extensions. A generic functional description can be found in separate documents. [STANDARDS-TRACK]Ambiguity of Uppercase vs Lowercase in RFC 2119 Key WordsRFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.Common YANG Data Types for the Routing AreaThis document defines a collection of common data types using the YANG data modeling language. These derived common types are designed to be imported by other modules defined in the routing area.Common YANG Data Types for Traffic EngineeringThis document defines a collection of common data types and groupings in YANG data modeling language. These derived common types and groupings are intended to be imported by modules that model Traffic Engineering (TE) configuration and state capabilities.YANG Tree DiagramsThis document captures the current syntax used in YANG module tree diagrams. The purpose of this document is to provide a single location for this definition. This syntax may be updated from time to time based on the evolution of the YANG language.Network Management Datastore Architecture (NMDA)Datastores are a fundamental concept binding the data models written in the YANG data modeling language to network management protocols such as the Network Configuration Protocol (NETCONF) and RESTCONF. This document defines an architectural framework for datastores based on the experience gained with the initial simpler model, addressing requirements that were not well supported in the initial model. This document updates RFC 7950.Generalized Multi-Protocol Label Switching (GMPLS) ArchitectureFuture data and transmission networks will consist of elements such as routers, switches, Dense Wavelength Division Multiplexing (DWDM) systems, Add-Drop Multiplexors (ADMs), photonic cross-connects (PXCs), optical cross-connects (OXCs), etc. that will use Generalized Multi-Protocol Label Switching (GMPLS) to dynamically provision resources and to provide network survivability using protection and restoration techniques. This document describes the architecture of GMPLS. GMPLS extends MPLS to encompass time-division (e.g., SONET/SDH, PDH, G.709), wavelength (lambdas), and spatial switching (e.g., incoming port or fiber to outgoing port or fiber). The focus of GMPLS is on the control plane of these various layers since each of them can use physically diverse data or forwarding planes. The intention is to cover both the signaling and the routing part of that control plane. [STANDARDS-TRACK]YANG Data Model for Traffic Engineering (TE) TopologiesThis 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-specific TE topology models can augment.Extensions to Resource Reservation Protocol - Traffic Engineering (RSVP-TE) for Point-to-Multipoint TE Label Switched Paths (LSPs)This document describes extensions to Resource Reservation Protocol - Traffic Engineering (RSVP-TE) for the set up of Traffic Engineered (TE) point-to-multipoint (P2MP) Label Switched Paths (LSPs) in Multi- Protocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks. The solution relies on RSVP-TE without requiring a multicast routing protocol in the Service Provider core. Protocol elements and procedures for this solution are described.There can be various applications for P2MP TE LSPs such as IP multicast. Specification of how such applications will use a P2MP TE LSP is outside the scope of this document. [STANDARDS-TRACK]RSVP-TE Extensions for Associated Bidirectional Label Switched Paths (LSPs)This document describes Resource Reservation Protocol (RSVP) extensions to bind two point-to-point unidirectional Label Switched Paths (LSPs) into an associated bidirectional LSP. The association is achieved by defining new Association Types for use in ASSOCIATION and in Extended ASSOCIATION Objects. One of these types enables independent provisioning of the associated bidirectional LSPs on both sides, while the other enables single-sided provisioning. The REVERSE_LSP Object is also defined to enable a single endpoint to trigger creation of the reverse LSP and to specify parameters of the reverse LSP in the single-sided provisioning case.Label Switched Paths (LSP) Hierarchy with Generalized Multi-Protocol Label Switching (GMPLS) Traffic Engineering (TE)To improve scalability of Generalized Multi-Protocol Label Switching (GMPLS) it may be useful to aggregate Label Switched Paths (LSPs) by creating a hierarchy of such LSPs. A way to create such a hierarchy is by (a) a Label Switching Router (LSR) creating a Traffic Engineering Label Switched Path (TE LSP), (b) the LSR forming a forwarding adjacency (FA) out of that LSP (by advertising this LSP as a Traffic Engineering (TE) link into the same instance of ISIS/OSPF as the one that was used to create the LSP), (c) allowing other LSRs to use FAs for their path computation, and (d) nesting of LSPs originated by other LSRs into that LSP (by using the label stack construct).This document describes the mechanisms to accomplish this. [PROPOSED STANDARD]RSVP-TE Extensions in Support of End-to-End Generalized Multi-Protocol Label Switching (GMPLS) RecoveryThis document describes protocol-specific procedures and extensions for Generalized Multi-Protocol Label Switching (GMPLS) Resource ReSerVation Protocol - Traffic Engineering (RSVP-TE) signaling to support end-to-end Label Switched Path (LSP) recovery that denotes protection and restoration. A generic functional description of GMPLS recovery can be found in a companion document, RFC 4426. [STANDARDS-TRACK]RSVP ASSOCIATION Object ExtensionsThe RSVP ASSOCIATION object was defined in the context of GMPLS-controlled Label Switched Paths (LSPs). In this context, the object is used to associate recovery LSPs with the LSP they are protecting. This object also has broader applicability as a mechanism to associate RSVP state. This document defines how the ASSOCIATION object can be more generally applied. This document also defines Extended ASSOCIATION objects that, in particular, can be used in the context of the MPLS Transport Profile (MPLS-TP). This document updates RFC 2205, RFC 3209, and RFC 3473. It also generalizes the definition of the Association ID field defined in RFC 4872. [STANDARDS-TRACK]Extended Administrative Groups in MPLS Traffic Engineering (MPLS-TE)MPLS Traffic Engineering (MPLS-TE) advertises 32 administrative groups (commonly referred to as "colors" or "link colors") using the Administrative Group sub-TLV. This is defined for OSPFv2 (RFC 3630), OSPFv3 (RFC 5329) and IS-IS (RFC 5305).This document adds a sub-TLV to the IGP TE extensions, "Extended Administrative Group". This sub-TLV provides for additional administrative groups (link colors) beyond the current limit of 32.A YANG Data Model for Interface ManagementThis document defines a YANG data model for the management of network interfaces. It is expected that interface-type-specific data models augment the generic interfaces data model defined in this document. The data model includes definitions for configuration and system state (status information and counters for the collection of statistics).The YANG data model in this document conforms to the Network Management Datastore Architecture (NMDA) defined in RFC 8342.This document obsoletes RFC 7223.Subscription to YANG NotificationsThis document defines a YANG data model and associated mechanisms enabling subscriber-specific subscriptions to a publisher's event streams. Applying these elements allows a subscriber to request and receive a continuous, customized feed of publisher-generated information.Subscription to YANG Notifications for Datastore UpdatesThis document describes a mechanism that allows subscriber applications to request a continuous and customized stream of updates from a YANG datastore. Providing such visibility into updates enables new capabilities based on the remote mirroring and monitoring of configuration and operational state.The IETF XML RegistryThis document describes an IANA maintained registry for IETF standards which use Extensible Markup Language (XML) related items such as Namespaces, Document Type Declarations (DTDs), Schemas, and Resource Description Framework (RDF) Schemas.Using the NETCONF Protocol over Secure Shell (SSH)This document describes a method for invoking and running the Network Configuration Protocol (NETCONF) within a Secure Shell (SSH) session as an SSH subsystem. This document obsoletes RFC 4742. [STANDARDS-TRACK]The Transport Layer Security (TLS) Protocol Version 1.3This document specifies version 1.3 of the Transport Layer Security (TLS) protocol. TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery.This document updates RFCs 5705 and 6066, and obsoletes RFCs 5077, 5246, and 6961. This document also specifies new requirements for TLS 1.2 implementations.Network Configuration Access Control ModelThe standardization of network configuration interfaces for use with the Network Configuration Protocol (NETCONF) or the RESTCONF protocol requires a structured and secure operating environment that promotes human usability and multi-vendor interoperability. There is a need for standard mechanisms to restrict NETCONF or RESTCONF protocol access for particular users to a preconfigured subset of all available NETCONF or RESTCONF protocol operations and content. This document defines such an access control model.This document obsoletes RFC 6536.Segment Routing Policy ArchitectureCisco SystemsCisco SystemsBell CanadaBritish TelecomMicrosoft Segment Routing (SR) allows a headend node to steer a packet flow
along any path. Intermediate per-path states are eliminated thanks
to source routing. The headend node steers a flow into an SR Policy.
The packets steered into an SR Policy carry an ordered list of
segments associated with that SR Policy. This document details the
concepts of SR Policy and steering into an SR Policy.
A YANG Data Model for Resource Reservation Protocol (RSVP)Juniper NetworksJuniper NetworksCisco Systems, Inc.Volta NetworksIndividual This document defines a YANG data model for the configuration and
management of the RSVP protocol. The YANG data model covers the
building blocks that may be augmented by other RSVP extension data
models such as RSVP Traffic-Engineering (RSVP-TE). It is divided
into two modules that cover the basic and extended RSVP features.
The BGP Tunnel Encapsulation AttributeThis document defines a BGP path attribute known as the "Tunnel Encapsulation attribute", which can be used with BGP UPDATEs of various Subsequent Address Family Identifiers (SAFIs) to provide information needed to create tunnels and their corresponding encapsulation headers. It provides encodings for a number of tunnel types, along with procedures for choosing between alternate tunnels and routing packets into tunnels.This document obsoletes RFC 5512, which provided an earlier definition of the Tunnel Encapsulation attribute. RFC 5512 was never deployed in production. Since RFC 5566 relies on RFC 5512, it is likewise obsoleted. This document updates RFC 5640 by indicating that the Load-Balancing Block sub-TLV may be included in any Tunnel Encapsulation attribute where load balancing is desired.Recovery (Protection and Restoration) Terminology for Generalized Multi-Protocol Label Switching (GMPLS)This document defines a common terminology for Generalized Multi-Protocol Label Switching (GMPLS)-based recovery mechanisms (i.e., protection and restoration). The terminology is independent of the underlying transport technologies covered by GMPLS. This memo provides information for the Internet community.Path Computation Element Communication Protocol (PCEP) Extension for Label Switched Path (LSP) Diversity Constraint SignalingThis document introduces a simple mechanism to associate a group of Label Switched Paths (LSPs) via an extension to the Path Computation Element Communication Protocol (PCEP) with the purpose of computing diverse (disjointed) paths for those LSPs. The proposed extension allows a Path Computation Client (PCC) to advertise to a Path Computation Element (PCE) that a particular LSP belongs to a particular Disjoint Association Group; thus, the PCE knows that the LSPs in the same group need to be disjoint from each other.