YANG Data Model for MPLS LDPCisco SystemsCanadaskraza@cisco.comCisco SystemsUnited States of Americarajiva@cisco.comIBM CorporationUnited States of Americaxufeng.liu.ietf@gmail.comJuniper NetworksUnited States of Americasantosh_easale@berkeley.eduHuawei TechnologiesChinajescia.chenxia@huawei.comCiena CorporationUnited States of Americahshah@ciena.com
Routing
MPLSMPLSLDPYANGThis document describes a YANG data model for the Multiprotocol Label Switching (MPLS)
Label Distribution Protocol (LDP). The model also serves as the base model
to define the Multipoint LDP (mLDP) model. The YANG modules in this document conform to the Network Management
Datastore Architecture (NMDA).
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
.
Copyright Notice
Copyright (c) 2022 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
() in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with
respect to this document. Code Components extracted from this
document must include Revised BSD License text as described in
Section 4.e of the Trust Legal Provisions and are provided without
warranty as described in the Revised BSD License.
Table of Contents
. Introduction
. Base and Extended
. Specification of Requirements
. Overview
. The Complete Tree
. Configuration
. Configuration Hierarchy
. Global Parameters
. Capabilities Parameters
. Per-Address-Family Parameters
. Hello Discovery Parameters
. Peer Parameters
. Forwarding Parameters
. Operational State
. Adjacency State
. Peer State
. Bindings State
. Capabilities State
. Notifications
. Action
. YANG Specification
. Base
. Extended
. Security Considerations
. YANG Data Model
. Writable Nodes
. Readable Nodes
. RPC Operations
. Notifications
. IANA Considerations
. Normative References
. Informative References
. Data Tree Example
Acknowledgments
Contributors
Authors' Addresses
IntroductionThe Network Configuration Protocol (NETCONF)
is one of the network management protocols that defines mechanisms to
manage network devices. YANG is a modular language that represents data structures
in an XML tree format and is used as a data modeling language for
NETCONF. This document introduces a YANG data model for the MPLS Label
Distribution Protocol (LDP) . This model also
covers LDP IPv6 and LDP capability specifications. The data model is defined for the following constructs that are used for managing the protocol:
Configuration
Operational State
Executables (Actions)
Notifications
This document is organized to define the data model for each of the above constructs
in the sequence as listed above. Base and Extended The configuration and state items are divided into the following two broad categories:
Base
Extended
The "base" category contains the basic and fundamental features that are
covered in LDP base specification and constitute the
minimum requirements for a typical base LDP deployment, whereas the "extended"
category contains other non-base features. All the items in a base category
are mandatory and, hence, no "if-feature" is allowed under the "base" category.
The base and extended categories are defined in their own modules as described
later. The examples of a base feature include the configuration of LDP lsr-id,
enabling LDP interfaces, setting passwords for LDP sessions, etc., whereas the
examples of an extended feature include inbound/outbound label policies, IGP
Sync , downstream on demand, etc. It is worth
highlighting that LDP IPv6 is also categorized as an
extended feature. While "base" model support will suffice for small deployments, it is expected that large deployments will require both "base" and "extended" model support from the vendors. Specification of Requirements In this document, the word "IP" is used to refer to both IPv4 and
IPv6 unless otherwise explicitly stated. For example, "IP address
family" should be read as "IPv4 and/or IPv6 address family". Overview This document defines two new modules for LDP YANG support:
"ietf-mpls-ldp"
A module that specifies the base LDP features and augments
/rt:routing/rt:control-plane-protocols/rt:control-plane-protocol defined in
. We define the new identity 'mpls-ldp' for LDP; the
model allows only a single instance of 'mpls-ldp'.
"ietf-mpls-ldp-extended"
A module that specifies the extended LDP features and augments the base
LDP module.
It is to be noted that the mLDP YANG data model augments LDP base and extended
modules to specify the mLDP-specific base and extended features.
There are four types of containers in our module(s):
Read-write parameters for configuration ()
Read-only parameters for operational state ()
Notifications for events ()
RPCs for executing commands to perform some action ()
The modules in this document conform to the Network Management
Datastore Architecture (NMDA) defined in .
The operational state data is combined with the associated
configuration data in the same hierarchy .
When protocol states are retrieved from the NMDA operational state
datastore, the returned states cover all "config true" (rw) and
"config false" (ro) nodes defined in the schema.
The following diagram depicts high-level LDP YANG tree organization and hierarchy: Before going into data model details, it is important to take
note of the following points:
This model aims to address only the core LDP parameters as
per RFC specification, as well as well-known and widely deployed
manageability controls (such as label filtering policies to apply
filtering rules on the assignment, advertisement, and acceptance
for label bindings). Any vendor-specific feature should be
defined in a vendor-specific augmentation of this model.
Multi-topology LDP is beyond the scope of this document.
This model does not cover any applications running on top of
LDP, nor does it cover any Operations, Administration, and
Maintenance (OAM) procedures for LDP.
This model is a VRF-centric model. It is important to note
that defines VPN Routing and Forwarding
(VRF) tables and default forwarding tables as different; however,
from a YANG modeling perspective, this introduces unnecessary
complications; hence, we are treating the default forwarding table
as just another VRF.
A "network-instance", as defined in ,
refers to a VRF instance (both default and non-default) within the
scope of this model.
This model supports two address families, namely, "ipv4" and "ipv6".
This model assumes platform-wide label space (i.e., label
space Id of zero). However, when upstream label assignment is in use, an upstream assigned label is looked
up in a Context-Specific Label Space as defined in .
The label and peer policies (including filters) are defined
using prefix-set and neighbor-set, respectively, as defined in the
routing-policy model .
This model uses the terms LDP "neighbor/adjacency",
"session", and "peer" with the following semantics:
Neighbor/Adjacency:
An LDP-enabled Label Switching Router (LSR) that is discovered through LDP
discovery mechanisms.
Session:
An LDP neighbor with whom a TCP connection has been established.
Peer:
An LDP session that has successfully progressed beyond its initialization
phase and is either already exchanging the bindings or is ready to do so.
It is to be noted that LDP Graceful Restart (GR) mechanisms
defined in allow keeping the exchanged
bindings for some time after a session goes down with a peer. We
refer to such a state as belonging to a "stale" peer, i.e., keeping peer
bindings from a peer with whom currently there is either no
connection established or connection is established but the GR session
is in recovery state.
When used in this document, the above terms will refer strictly to
the semantics and definitions defined for them.
A simplified graphical tree representation of base and extended LDP
YANG data models is presented in .
The meaning of the symbols in these tree diagrams is defined in
.
The actual YANG specification for base and extended modules is
captured in .
While presenting the YANG tree view and actual specification, this
document assumes readers are familiar with the concepts of YANG
modeling, its presentation, and its compilation.
The Complete TreeThe following is a complete tree representation of configuration,
state, notification, and RPC items under LDP base and extended
modules. Configuration This specification defines the configuration parameters for base
LDP as specified in and LDP IPv6 . Moreover, it incorporates provisions to enable LDP
Capabilities and defines some of the most
significant and commonly used capabilities such as Typed Wildcard
FEC , End-of-LIB
, and LDP Upstream
Label Assignment . This model augments
/rt:routing/rt:control-plane-protocols/rt:control-plane-protocol,
which is defined in and follows NMDA as
mentioned earlier.
The following is the high-level configuration organization for the
base LDP module: The following is the high-level configuration organization for the
extended LDP module: Given the configuration hierarchy, the model allows inheritance
such that an item in a child tree is able to derive value from a
similar or related item in one of the parents. For instance, Hello
holdtime can be configured per VRF or per VRF interface, thus allowing
inheritance as well flexibility to override with a different value at
any child level. Configuration HierarchyThe LDP module resides under a network-instance and the scope of
any LDP configuration defined under this tree is per network-instance
(per-VRF). This configuration is further divided into sub categories
as follows:
Global parameters
Per-address-family parameters
LDP Capabilities parameters
Hello Discovery parameters
interfaces
Global
Per-interface: Global
Per-interface: Per-address-family
targeted
Global
Per-address-family: Per-target
Peer parameters
Global
Per-peer: Global
Per-peer: Per-address-family
Forwarding parameters
The following subsections briefly explain these configuration areas. Global Parameters There are configuration items that are available directly
under a VRF instance and do not fall under any other subtree. An
example of such a parameter is an LDP LSR Id that is typically
configured per VRF. To keep legacy LDP features and applications
working in an LDP IPv4 network with this model, this document
recommends an operator to pick a routable IPv4 unicast address
(within a routing domain) as an LSR Id. Capabilities Parameters This container falls under the global tree and holds the LDP
capabilities that are to be enabled for certain features. By
default, an LDP capability is disabled unless explicitly
enabled. These capabilities are typically used to negotiate with
LDP peer(s) the support/non-support related to a feature and its
parameters. The scope of a capability enabled under this
container applies to all LDP peers in the given VRF
instance. There is also a peer-level capability container that
is provided to override a capability that is enabled/specified
at VRF level. Per-Address-Family Parameters Any LDP configuration parameter related to an IP address
family (AF) whose scope is VRF wide is configured under this
tree. The examples of per-AF parameters include enabling LDP for
an address family, prefix-list-based label policies, and LDP
transport address. Hello Discovery Parameters This container is used to hold LDP configuration related to
the Hello and discovery process for both basic (link) and extended
(targeted) discovery. The "interfaces" container is used to configure parameters
related to VRF interfaces. There are parameters that apply to
all interfaces (such as Hello timers) as well as parameters
that can be configured per interface. Hence, an interface list
is defined under the "interfaces" container. The model defines
parameters to configure per-interface non-AF-related items as
well as per-interface per-AF items. The example of the former is
interface Hello timers, and an example of the latter is enabling
hellos for a given AF under an interface. The "targeted" container under a VRF instance allows for the
configuration of parameters related to LDP targeted
discovery. Within this container, the "target" list provides a
means to configure multiple target addresses to perform extended
discovery to a specific destination target, as well as to
fine tune the per-target parameters. Peer Parameters
This container is used to hold LDP configuration related to LDP sessions and
peers under a VRF instance.
This container allows for the configuration of parameters that either apply to
all or a subset (peer-list) of peers in a given VRF.
The example of such parameters includes authentication
passwords, session KeepAlive (KA) timers, etc. Moreover, the
model also allows per-peer parameter tuning by specifying a
"peer" list under the "peers" container. A peer is uniquely
identified by its LSR Id. Like per-interface parameters, some per-peer parameters are
AF agnostic (i.e., either non-AF related or apply to both IP
address families), and some belong to an AF. The example of
the former is per-peer session password configuration, whereas
the example of the latter is prefix-lis-based label policies
(inbound and outbound) that apply to a given peer. Forwarding Parameters This container is used to hold configuration used to control LDP
forwarding behavior under a VRF instance.
One example of a configuration under this container is when a user wishes to
enable LDP neighbor discovery on an interface but wishes to disable use of the
same interface for forwarding MPLS packets.
This example configuration makes sense only when there are more
than one LDP-enabled interfaces towards a neighbor. Operational StateThe operational state of LDP can be queried and obtained from
read-only state containers that fall under the same tree
(/rt:routing/rt:control-plane-protocols/rt:control-plane-protocol) as
the configuration. The following are main areas for which LDP operational state is defined:
Neighbor Adjacencies
Peer
Bindings (FEC-Label and address)
Capabilities
Adjacency State Neighbor adjacencies are per-address-family Hello adjacencies
that are formed with neighbors as a result of LDP basic or
extended discovery. In terms of organization, there is a source of
discovery (e.g., interface or target address) along with its
associated parameters and one or more discovered neighbors along
with neighbor-discovery-related parameters. For the basic
discovery, there could be more than one discovered neighbor for a
given source (interface), whereas there is at most one discovered
neighbor for an extended discovery source (local-address and
target-address). It is also to be noted that the reason for a
targeted neighbor adjacency could be either an active source
(locally configured targeted) or passive source (to allow any
incoming extended/targeted hellos). A neighbor/adjacency record
also contains session state that helps highlight whether a given
adjacency has progressed to the subsequent session level or
eventual peer level. The following captures high-level tree hierarchy for neighbor
adjacency state. The tree is shown for ipv4 address-family only; a
similar tree exists for ipv6 address-family as well. Peer StatePeer-related state is presented under a peers tree. This is one
of the core states that provides info on the session-related
parameters (mode, authentication, KA timeout, etc.), TCP connection
info, Hello adjacencies for the peer, statistics related to
messages and bindings, and capabilities exchange info. The following captures high-level tree hierarchy for peer
state. The peer's Hello adjacencies tree is shown for ipv4
address-family only; a similar tree exists for ipv6 address-family
as well.Bindings State Bindings state provides information on LDP FEC-Label bindings
as well as address bindings for both inbound (received) as well as
outbound (advertised) direction. FEC-Label bindings are presented
in a FEC-centric view, and address bindings are presented in an
address-centric view: Note that all local addresses are advertised to all peers;
hence, there is no need to provide per-peer information for local address
advertisement. Furthermore, note that it is easy to derive a
peer-centric view for the bindings from the information already
provided in this model.
The following captures high-level tree hierarchy for bindings
state. The tree shown below is for ipv4 address-family only; a
similar tree exists for ipv6 address-family as well. Capabilities State LDP capabilities state comprises two types of information:
global information (such as timer, etc.) and per-peer
information. The following captures high-level tree hierarchy for LDP capabilities state. Notifications This model defines a list of notifications to inform the client of
important events detected during the protocol operation. These events
include events related to changes in the operational state of an LDP
peer, Hello adjacency, and FEC, etc. It is to be noted that an LDP FEC
is treated as operational (up) as long as it has at least one Next Hop
Label Forwarding Entry (NHLFE) with an outgoing label. A simplified graphical representation of the data model for LDP notifications is shown in . Action This model defines a list of rpcs that allow performing an action
or executing a command on the protocol. For example, it allows for the
clearing (resetting) of LDP peers, hello-adjacencies, and
statistics. The model makes an effort to provide a different level of
control so that a user is able to either clear all, clear all for a
given type, or clear a specific entity. A simplified graphical representation of the data model for LDP actions is shown in . YANG SpecificationThe following sections specify the actual YANG (module) specification
for LDP constructs defined earlier in the document. Base
This YANG module imports types defined in , , , , , , and .
Extended
This YANG module imports types defined in , , , , , and .
Security Considerations This specification inherits the security
considerations captured in and the LDP protocol specification documents, namely base LDP
, LDP IPv6 , LDP Capabilities
, Typed Wildcard FEC , LDP End-of-LIB
, and LDP Upstream Label Assignment
.
YANG Data Model The YANG modules specified in this document define 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. Writable Nodes There are a number of data nodes defined in these YANG modules 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. For LDP, the ability to modify MPLS LDP configuration may allow the entire MPLS LDP domain to be compromised including forming LDP adjacencies and/or peer sessions with unauthorized
routers to mount a massive Denial-of-Service (DoS) attack. In particular, the following are the subtrees and data nodes that are sensitive and vulnerable:
/mpls-ldp/discovery/interfaces/interface:
Adding LDP on any unprotected interface could allow an LDP Hello adjacency
to be formed with an unauthorized and malicious neighbor. Once a Hello
adjacency is formed, a peer session could progress with this neighbor.
/mpls-ldp/discovery/targeted/hello-accept:
Allowing acceptance of targeted-hellos could open LDP to DoS attacks
related to incoming targeted hellos from malicious sources.
/mpls-ldp/peers/authentication:
Allowing a peer session establishment is typically controlled via LDP
authentication where a proper and secure authentication password/key
management is warranted.
/mpls-ldp/peers/peer/authentication:
Same as above.
Readable Nodes Some of the readable data nodes in these YANG modules 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: The exposure of LDP databases (such as Hello adjacencies, peers, address bindings, and FEC-Label bindings) beyond the scope of the LDP admin domain may be undesirable. The relevant subtrees and data nodes are as follows:
The configuration for LDP peer authentication is supported via the
key-chain specification or via direct
specification of a key associated with a crypto algorithm (such as MD5).
The relevant subtrees and data nodes are as follows:
/mpls-ldp/peers/authentication
/mpls-ldp/peers/peer/authentication
The actual authentication key data (whether locally specified or part of a
key-chain) is sensitive and needs to be kept secret from unauthorized parties.
For key-chain-based authentication, this model inherits the security
considerations of (that includes the considerations
with respect to the local storage and handling of authentication keys). A
similar procedure for storage and access to direct keys is warranted.
RPC OperationsSome of the RPC operations in these YANG modules may be considered sensitive or vulnerable in some network environments. It is thus important to control access to these operations; otherwise, control plane flaps, network outages, and DoS attacks are possible. The RPC operations are:
mpls-ldp-clear-peer
mpls-ldp-clear-hello-adjacency
Notifications The model describes several notifications. The implementations must rate-limit the generation of these notifications to avoid creating
significant notification load and possible side effects on the system stability.
IANA ConsiderationsPer this document, the following URIs have been registered in the IETF "XML
Registry" :
Normative ReferencesGraceful Restart Mechanism for Label Distribution ProtocolThis document describes a mechanism that helps to minimize the negative effects on MPLS traffic caused by Label Switching Router's (LSR's) control plane restart, specifically by the restart of its Label Distribution Protocol (LDP) component, on LSRs that are capable of preserving the MPLS forwarding component across the restart. The mechanism described in this document is applicable to all LSRs, both those with the ability to preserve forwarding state during LDP restart and those without (although the latter needs to implement only a subset of the mechanism described in this document). Supporting (a subset of) the mechanism described here by the LSRs that can not preserve their MPLS forwarding state across the restart would not reduce the negative impact on MPLS traffic caused by their control plane restart, but it would minimize the impact if their neighbor(s) are capable of preserving the forwarding state across the restart of their control plane and implement the mechanism described here. The mechanism makes minimalistic assumptions on what has to be preserved across restart - the mechanism assumes that only the actual MPLS forwarding state has to be preserved; the mechanism does not require any of the LDP-related states to be preserved across the restart. The procedures described in this document apply to downstream unsolicited label distribution. Extending these procedures to downstream on demand label distribution is for further study. [STANDARDS-TRACK]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.LDP SpecificationThe architecture for Multiprotocol Label Switching (MPLS) is described in RFC 3031. A fundamental concept in MPLS is that two Label Switching Routers (LSRs) must agree on the meaning of the labels used to forward traffic between and through them. This common understanding is achieved by using a set of procedures, called a label distribution protocol, by which one LSR informs another of label bindings it has made. This document defines a set of such procedures called LDP (for Label Distribution Protocol) by which LSRs distribute labels to support MPLS forwarding along normally routed paths. [STANDARDS-TRACK]MPLS Upstream Label Assignment and Context-Specific Label SpaceRFC 3031 limits the MPLS architecture to downstream-assigned MPLS labels. This document introduces the notion of upstream-assigned MPLS labels. It describes the procedures for upstream MPLS label assignment and introduces the concept of a "Context-Specific Label Space". [STANDARDS-TRACK]LDP IGP SynchronizationIn certain networks, there is dependency on the edge-to-edge Label Switched Paths (LSPs) setup by the Label Distribution Protocol (LDP), e.g., networks that are used for Multiprotocol Label Switching (MPLS) Virtual Private Network (VPN) applications. For such applications, it is not possible to rely on Internet Protocol (IP) forwarding if the MPLS LSP is not operating appropriately. Blackholing of labeled traffic can occur in situations where the Interior Gateway Protocol (IGP) is operational on a link on which LDP is not. While the link could still be used for IP forwarding, it is not useful for MPLS forwarding, for example, MPLS VPN applications or Border Gateway Protocol (BGP) route-free cores. This document describes a mechanism to avoid traffic loss due to this condition without introducing any protocol changes. This memo provides information for the Internet community.LDP CapabilitiesA number of enhancements to the Label Distribution Protocol (LDP) have been proposed. Some have been implemented, and some are advancing toward standardization. It is likely that additional enhancements will be proposed in the future. This document defines a mechanism for advertising LDP enhancements at session initialization time, as well as a mechanism to enable and disable enhancements after LDP session establishment. [STANDARDS-TRACK]Label Distribution Protocol (LDP) 'Typed Wildcard' Forward Equivalence Class (FEC)The Label Distribution Protocol (LDP) specification for the Wildcard Forward Equivalence Class (FEC) element has several limitations. This document addresses those limitations by defining a Typed Wildcard FEC Element and associated procedures. In addition, it defines a new LDP capability to address backward compatibility. [STANDARDS-TRACK]Signaling LDP Label Advertisement CompletionThere are situations following Label Distribution Protocol (LDP) session establishment where it would be useful for an LDP speaker to know when its peer has advertised all of its labels. The LDP specification provides no mechanism for an LDP speaker to notify a peer when it has completed its initial label advertisements to that peer. This document specifies means for an LDP speaker to signal completion of its initial label advertisements following session establishment. [STANDARDS-TRACK]Security Framework for MPLS and GMPLS NetworksThis document provides a security framework for Multiprotocol Label Switching (MPLS) and Generalized Multiprotocol Label Switching (GMPLS) Networks. This document addresses the security aspects that are relevant in the context of MPLS and GMPLS. It describes the security threats, the related defensive techniques, and the mechanisms for detection and reporting. This document emphasizes RSVP-TE and LDP security considerations, as well as inter-AS and inter-provider security considerations for building and maintaining MPLS and GMPLS networks across different domains or different Service Providers. This document is not an Internet Standards Track specification; it is published for informational purposes.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]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]MPLS Upstream Label Assignment for LDPThis document describes procedures for distributing upstream-assigned labels for the Label Distribution Protocol (LDP). It also describes how these procedures can be used for avoiding branch Label Switching Router (LSR) traffic replication on a LAN for LDP point-to-multipoint (P2MP) Label Switched Paths (LSPs). [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.Updates to LDP for IPv6The Label Distribution Protocol (LDP) specification defines procedures to exchange label bindings over either IPv4 or IPv6 networks, or both. This document corrects and clarifies the LDP behavior when an IPv6 network is used (with or without IPv4). This document updates RFCs 5036 and 6720.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).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).YANG Data Model for Key ChainsThis document describes the key chain YANG data model. Key chains are commonly used for routing protocol authentication and other applications requiring symmetric keys. A key chain is a list containing one or more elements containing a Key ID, key string, send/accept lifetimes, and the associated authentication or encryption algorithm. By properly overlapping the send and accept lifetimes of multiple key chain elements, key strings and algorithms may be gracefully updated. By representing them in a YANG data model, key distribution can be automated.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.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.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.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.A YANG Data Model for IP ManagementThis document defines a YANG data model for management of IP implementations. The data model includes configuration and system state.The YANG data model in this document conforms to the Network Management Datastore Architecture defined in RFC 8342.This document obsoletes RFC 7277.A YANG Data Model for Routing Management (NMDA Version)This document specifies three YANG modules and one submodule. Together, they form the core routing data model that serves as a framework for configuring and managing a routing subsystem. It is expected that these modules will be augmented by additional YANG modules defining data models for control-plane protocols, route filters, and other functions. The core routing data model provides common building blocks for such extensions -- routes, Routing Information Bases (RIBs), and control-plane protocols.The YANG modules in this document conform to the Network Management Datastore Architecture (NMDA). This document obsoletes RFC 8022.Guidelines for Authors and Reviewers of Documents Containing YANG Data ModelsThis memo provides guidelines for authors and reviewers of specifications containing YANG modules. Recommendations and procedures are defined, which are intended to increase interoperability and usability of Network Configuration Protocol (NETCONF) and RESTCONF protocol implementations that utilize YANG modules. This document obsoletes RFC 6087.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.YANG Data Model for Network InstancesThis document defines a network instance module. This module can be used to manage the virtual resource partitioning that may be present on a network device. Examples of common industry terms for virtual resource partitioning are VPN Routing and Forwarding (VRF) instances and Virtual Switch Instances (VSIs).The YANG data model in this document conforms to the Network Management Datastore Architecture (NMDA) defined in RFC 8342.A YANG Data Model for Routing PolicyThis document defines a YANG data model for configuring and managing routing policies in a vendor-neutral way. The model provides a generic routing policy framework that can be extended for specific routing protocols using the YANG 'augment' mechanism.Informative ReferencesYANG Data Model for MPLS mLDPWork in ProgressBGP/MPLS IP Virtual Private Networks (VPNs)This document describes a method by which a Service Provider may use an IP backbone to provide IP Virtual Private Networks (VPNs) for its customers. This method uses a "peer model", in which the customers' edge routers (CE routers) send their routes to the Service Provider's edge routers (PE routers); there is no "overlay" visible to the customer's routing algorithm, and CE routers at different sites do not peer with each other. Data packets are tunneled through the backbone, so that the core routers do not need to know the VPN routes. [STANDARDS-TRACK]LDP Extensions for Multi-TopologyMulti-Topology (MT) routing is supported in IP networks with the use of MT-aware IGPs. In order to provide MT routing within Multiprotocol Label Switching (MPLS) Label Distribution Protocol (LDP) networks, new extensions are required.This document describes the LDP protocol extensions required to support MT routing in an MPLS environment.JSON Encoding of Data Modeled with YANGThis document defines encoding rules for representing configuration data, state data, parameters of Remote Procedure Call (RPC) operations or actions, and notifications defined using YANG as JavaScript Object Notation (JSON) text.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.Data Tree Example
This section contains an example of an instance data tree in the JSON
encoding , containing both configuration and
state data.
The configuration instance data tree for Router 203.0.113.1 in could be as follows:
The corresponding operational state data for Router 203.0.113.1
could be as follows:
AcknowledgmentsThe authors would like to acknowledge , , , and for their contribution to this
document. We also acknowledge ,
, , , and for their detailed review of the
model during WG and IESG processes.ContributorsCisco Systemsdajohari@cisco.comHuawei Technologiesloa@pi.nuApstrajefftant.ietf@gmail.comNokiamatthew.bocci@nokia.comreshad@yahoo.comCisco Systemsslitkows@cisco.comAuthors' AddressesCisco SystemsCanadaskraza@cisco.comCisco SystemsUnited States of Americarajiva@cisco.comIBM CorporationUnited States of Americaxufeng.liu.ietf@gmail.comJuniper NetworksUnited States of Americasantosh_easale@berkeley.eduHuawei TechnologiesChinajescia.chenxia@huawei.comCiena CorporationUnited States of Americahshah@ciena.com