MPLS Working Group K. Raza
Internet-Draft R. Asati
Intended status: Standards Track Cisco Systems, Inc.
Expires: April 25, 2019
X. Liu
Volta Networks
S. Esale
Juniper Networks
X. Chen
Huawei Technologies
H. Shah
Ciena Corporation
October 22, 2018
YANG Data Model for MPLS LDPdraft-ietf-mpls-ldp-yang-05
Abstract
This document describes a YANG data model for Multi-Protocol Label
Switching (MPLS) Label Distribution Protocol (LDP). The model also
serves as the base model to define Multipoint LDP (mLDP) model.
The YANG modules in this document conform to the Network Management
Datastore Architecture (NMDA).
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
Raza, et al. Expires April 25, 2019 [Page 1]

Internet-Draft YANG Data Model for MPLS LDP October 2018
The example of base feature includes the configuration of LDP lsr-id,
enabling LDP interfaces, setting password for LDP session etc.,
whereas the examples of extended feature include inbound/outbound
label policies, igp sync, downstream-on-demand etc. This is worth
higlighting that LDP IPv6 [RFC7552] is also categorized as an
extended feature.
While "base" model support will suffice for small deployments, it is
expected that large deployments will require not only the "base"
module support from the vendors but also the support for "extended"
model for some extended feature(s) of interest.
2. Specification of Requirements
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD 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.
In this document, the word "IP" is used to refer to both IPv4 and
IPv6, unless otherwise explicitly stated. For example, "IP address
family" means and be read as "IPv4 and/or IPv6 address family"
3. Overview
This document defines two new modules for LDP YANG support:
o "ietf-mpls-ldp" module that models the base LDP features and
augments /rt:routing/rt:control-plane-protocols defined in
[RFC8349]
o extended "ietf-mpls-ldp-extended" module that models the extended
LDP features and augments the base LDP
It is to be noted that mLDP data model [I-D.ietf-mpls-mldp-yang]
augments LDP base and extended models to model the base and extended
mLDP features respectively.
There are four main containers in our module(s):
o Read-Write parameters for configuration (Discussed in Section 5)
o Read-only parameters for operational state (Discussed in
Section 6)
o Notifications for events (Discussed in Section 7)
Raza, et al. Expires April 25, 2019 [Page 4]

Internet-Draft YANG Data Model for MPLS LDP October 2018
Before going into data model details, it is important to take note of
the following points:
o This module aims to address only the core LDP parameters as per
RFC specification, as well as some widely deployed non-RFC
features (such as label policies, session authentication etc).
Any vendor specific feature should be defined in a vendor-specific
augmentation of this model.
o Multi-topology LDP [RFC7307] is beyond the scope of this document.
o This module does not cover any applications running on top of LDP,
nor does it cover any OAM procedures for LDP.
o This model is a VPN Forwarding and Routing (VRF)-centric model.
It is important to note that [RFC4364] defines VRF tables and
default forwarding tables as different, however from a yang
modelling perspective this introduces unnecessary complications,
hence we are treating the default forwarding table as just another
VRF.
o A "network-instance", as defined in [I-D.ietf-rtgwg-ni-model],
refers to a VRF instance (both default and non-default) within the
scope of this model.
o This model supports two address-families, namely "ipv4" and
"ipv6".
o This model assumes platform-wide label space (i.e. label space Id
of zero). However, when Upstream Label assignment [RFC6389] is in
use, an upstream assigned label is looked up in a Context-Specific
label space as defined in [RFC5331].
o The label and peer policies (including filters) are defined using
a prefix-list. When used for a peer policy, the prefix refers to
the LSR Id of the peer. The prefix-list is referenced from
routing-policy model as defined in [I-D.ietf-rtgwg-policy-model].
o This model uses the terms LDP "neighbor"/"adjacency", "session",
and "peer" with the following semantics:
* Neighbor/Adjacency: An LDP enabled LSR that is discovered
through LDP discovery mechanisms.
* Session: An LDP neighbor with whom a TCP connection has been
established.
Raza, et al. Expires April 25, 2019 [Page 6]

Internet-Draft YANG Data Model for MPLS LDP October 2018
* Peer: An LDP session which 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 mechanisms defined in
[RFC3478] allow keeping the exchanged bindings for some time after
a session goes down with a peer. We call such a state 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 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 full LDP YANG data
model is presented in Figure 2, whereas LDP configuration (base and
extended), state (base and extended), notification, and rpc are
grapically represented in Figure 5, Figure 6, Figure 8, Figure 9,
Figure 15, and Figure 16 respectively. The meaning of the symbols in
these tree diagrams is defined in [RFC8340].
The actual base and extended model definition in YANG is captured in
Section 9.
While presenting the YANG tree view and actual .yang specification,
this document assumes readers' familiarity with the concepts of YANG
modeling, its presentation and its compilation.
4. Consolidated Tree
Following is a consolidated tree representation of configuration,
state, notification, and rpc items under LDP base and extended.
module: ietf-mpls-ldp
augment /rt:routing/rt:control-plane-protocols:
+--rw mpls-ldp!
+--rw global
| +--rw capability
| | +--rw ldp-ext:end-of-lib {capability-end-of-lib}?
| | | +--rw ldp-ext:enable? boolean
| | +--rw ldp-ext:typed-wildcard-fec
| | | {capability-typed-wildcard-fec}?
| | | +--rw ldp-ext:enable? boolean
| | +--rw ldp-ext:upstream-label-assignment
| | {capability-upstream-label-assignment}?
| | +--rw ldp-ext:enable? boolean
| +--rw graceful-restart
| | +--rw enable? boolean
Raza, et al. Expires April 25, 2019 [Page 7]

Internet-Draft YANG Data Model for MPLS LDP October 20185.2.1.1. Per-VRF global parameters
There are configuration items that are available directly under a VRF
instance and do not fall under any other sub tree. Example of such a
parameter is LDP LSR id that is typically configured per VRF. To
keep legacy LDP features and applications working in an LDP IPv4
networks with this model, this document recommends an operator to
pick a routable IPv4 unicast address as an LSR Id.
5.2.1.2. Per-VRF Capabilities parameters
This container falls under 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.
5.2.1.3. Per-VRF Per-Address-Family parameters
Any LDP configuration parameter related to 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.
5.2.1.4. Per-VRF Hello Discovery parameters
This container is used to hold LDP configuration related to Hello and
discovery process for both basic (link) and extended (targeted)
discovery.
The "interfaces" is a container 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
"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 former is interface hello timers, and example
of latter is enabling hellos for a given AF under an interface.
The "targeted" container under a VRF instance allows to configure LDP
targeted discovery related parameters. Within this container, the
"target" list provides a mean to configure multiple target addresses
to perform extended discovery to a specific destination target, as
well as to fine-tune the per-target parameters.
Raza, et al. Expires April 25, 2019 [Page 24]

Internet-Draft YANG Data Model for MPLS LDP October 20185.2.1.5. Per-VRF Peer parameters
This container is used to hold LDP configuration related to LDP
sessions and peers under a VRF instance. This container allows to
configure parameters that either apply on VRF's all peers or a subset
(peer-list) of VRF peers. The example of such parameters include
authentication password, session 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 using its
LSR Id and hence LSR Id is the key for peer list
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 that belong to an AF. The example of former is
per-peer session password configuration, whereas the example of
latter is prefix-list based label policies (inbound and outbound)
that apply to a given peer.
5.2.1.6. Per-VRF 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
neighbor discovery on an interface but wishes to disable use of the
same interface as forwarding nexthop. This example configuration
makes sense only when there are more than one LDP enabled interfaces
towards the neighbor.
6. Operational State
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/) as the configuration.
6.1. Operational Tree6.1.1. Base
Following is a simplified graphical representation of the base data
model for LDP operational state.
module: ietf-mpls-ldp
augment /rt:routing/rt:control-plane-protocols:
+--rw mpls-ldp!
+--rw global
| +--rw address-families
| +--rw ipv4!
Raza, et al. Expires April 25, 2019 [Page 25]

Internet-Draft YANG Data Model for MPLS LDP October 2018
| +--ro ldp-ext:hello-dropped? yang:counter64
+--ro ldp-ext:interface? if:interface-ref
Figure 9
6.2. States
Following are main areas for which LDP operational state is defined:
Neighbor Adjacencies
Peer
Bindings (FEC-label and address)
Capabilities
6.2.1. Adjacency state
Neighbor adjacencies are per address-family hello adjacencies that
are formed with neighbors as 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). This 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 subsequent session level
or to eventual peer level.
Following captures high level tree hierarchy for neighbor adjacency
state.
Raza, et al. Expires April 25, 2019 [Page 31]

Internet-Draft YANG Data Model for MPLS LDP October 2018
leaf discontinuity-time {
type yang:date-and-time;
mandatory true;
description
"The time on the most recent occasion at which any one or
more of this interface's counters suffered a
discontinuity. If no such discontinuities have occurred
since the last re-initialization of the local management
subsystem, then this node contains the time the local
management subsystem re-initialized itself.";
}
leaf hello-received {
type yang:counter64;
description
"The number of Hello messages received.";
}
leaf hello-dropped {
type yang:counter64;
description
"The number of Hello messages dropped.";
}
} // statistics
} // adjacency-state-attributes
grouping basic-discovery-timers {
description
"The timer attributes for basic discovery, used in the
per-interface setting and in the all-interface setting.";
leaf hello-holdtime {
type uint16 {
range 15..3600;
}
units seconds;
default 15;
description
"The time interval for which a LDP link Hello adjacency
is maintained in the absence of link Hello messages from
the LDP neighbor";
}
leaf hello-interval {
type uint16 {
range 5..1200;
}
units seconds;
default 5;
description
Raza, et al. Expires April 25, 2019 [Page 43]

Internet-Draft YANG Data Model for MPLS LDP October 2018
description
"Enable the target.";
}
leaf local-address {
type inet:ipv4-address;
description
"The local address used as the source address to
send targeted Hello messages.
If the value is not specified, the
transport-address is used as the source
address.";
}
} // target
} // ipv4
} // address-families
} // targeted
} // discovery
container peers {
description
"Peers configuration attributes.";
uses peer-authentication;
uses peer-attributes;
list peer {
key "lsr-id label-space-id";
description
"List of peers.";
leaf lsr-id {
type rt-types:router-id;
description
"The LSR ID of the peer, to identify the globally
unique LSR. This is the first four octets of the LDP
ID. This leaf is used together with the leaf
'label-space-id' to form the LDP ID.";
reference
"RFC5036. Sec 2.2.2.";
}
leaf label-space-id {
type uint16;
description
"The Label Space ID of the peer, to identify a specific
label space within the LSR. This is the last two
octets of the LDP ID. This leaf is used together with
the leaf 'lsr-id' to form the LDP ID.";
reference
Raza, et al. Expires April 25, 2019 [Page 60]

Internet-Draft YANG Data Model for MPLS LDP October 2018
feature per-peer-graceful-restart-config {
description
"This feature indicates that the system allows to configure
graceful restart at the per-peer level.";
}
feature per-peer-session-attributes-config {
description
"This feature indicates that the system allows to configure
session attributes at the per-peer level.";
}
feature policy-label-assignment-config {
description
"This feature indicates that the system allows to configure
policies to assign labels according to certain prefixes.";
}
feature policy-ordered-label-config {
description
"This feature indicates that the system allows to configure
ordered label policies.";
}
feature policy-targeted-discovery-config {
description
"This feature indicates that the system allows to configure
policies to control the acceptance of targeted neighbor
discovery hello messages.";
}
feature session-downstream-on-demand-config {
description
"This feature indicates that the system allows to configure
session downstream-on-demand";
}
/*
* Typedefs
*/
typedef neighbor-list-ref {
type string;
description
"A type for a reference to a neighbor address list.
The string value is the name identifier for uniquely
identifying the referenced address list, which contains a list
of addresses that a routing policy can applied. The definition
of such an address list is outside the scope of this
Raza, et al. Expires April 25, 2019 [Page 69]

Internet-Draft YANG Data Model for MPLS LDP October 2018
document.";
}
typedef prefix-list-ref {
type string;
description
"A type for a reference to a prefix list.
The string value is the name identifier for uniquely
identifying the referenced prefix set, which contains a list
of prefixes that a routing policy can applied. The definition
of such a prefix set is outside the scope of this document.";
}
typedef peer-list-ref {
type string;
description
"A type for a reference to a peer address list.
The string value is the name identifier for uniquely
identifying the referenced address list, which contains a list
of addresses that a routing policy can applied. The definition
of such an address list is outside the scope of this
document.";
}
/*
* Identities
*/
/*
* Groupings
*/
grouping address-family-ipv4-augment {
description "Augmentation to address family IPv4.";
uses policy-container;
leaf transport-address {
type inet:ipv4-address;
description
"The transport address advertised in LDP Hello messages.
If this value is not specified, the LDP LSR ID is used as
the transport address.";
reference
"RFC5036. Sec. 3.5.2.";
}
} // address-family-ipv4-augment
Raza, et al. Expires April 25, 2019 [Page 70]

Internet-Draft YANG Data Model for MPLS LDP October 2018
"Peer list entry IPv6 augmentation.";
uses peer-af-policy-container;
}
}
<CODE ENDS>
Figure 18
10. Security Considerations
The YANG module specified in this document defines a schema for data
that is designed to be accessed via network management protocols such
as NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF layer
is the secure transport layer, and the mandatory-to-implement secure
transport is Secure Shell (SSH) [RFC6242]. The lowest RESTCONF layer
is HTTPS, and the mandatory-to-implement secure transport is TLS
[RFC8446].
The Network Configuration Access Control Model (NACM) [RFC8341]
provides the means to restrict access for particular NETCONF or
RESTCONF users to a preconfigured subset of all available NETCONF or
RESTCONF protocol operations and content.
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.
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.
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.
It goes without saying that this specification also inherits the
security considerations captured in the actual protocol specification
documents, namely base LDP [RFC5036], LDP IPv6 [RFC7552], LDP
Capabilities [RFC5561], Typed Wildcard FEC [RFC5918], LDP End-of-LIB
[RFC5919], and LDP Upstream Label Assignment [RFC6389].
Raza, et al. Expires April 25, 2019 [Page 86]