YANG Data Model for MPLS LDP
Extracted elements (30)
Label and peer policies (including filters) are defined using prefix-set and neighbor-set from the routing-policy model (RFC 9067), rather than defining a new policy framework within the LDP module.
The model assumes platform-wide label space (label space ID of zero). When upstream label assignment (RFC 6389) is in use, an upstream-assigned label is looked up in a Context-Specific Label Space per RFC 5331, which is outside the scope of this base model.
The model is split into 'base' (ietf-mpls-ldp) and 'extended' (ietf-mpls-ldp-extended) categories. Base covers fundamental RFC 5036 features with no 'if-feature' allowed; extended covers non-base features such as LDP IPv6, label policies, and IGP sync. This separation allows small deployments to use only the base module.
The model is VRF-centric, treating the default forwarding table as just another VRF (network-instance). Although RFC 4364 distinguishes VRF tables from default forwarding tables, the YANG model collapses them to avoid unnecessary modeling complexity.
The model recommends that the LDP LSR Id be a routable IPv4 unicast address within the routing domain (rather than an arbitrary value) to maintain compatibility with legacy LDP IPv4 applications that depend on reachability of the LSR Id.
LDP IPv6 (RFC 7552) is categorized as an extended feature and is modeled entirely within 'ietf-mpls-ldp-extended'. The base module 'ietf-mpls-ldp' covers only IPv4.
Multi-topology LDP (RFC 7307), LDP OAM procedures, and applications running on top of LDP are explicitly out of scope for this model. Vendor-specific features should be defined via vendor-specific augmentations.
The mLDP YANG data model (a separate document) augments both 'ietf-mpls-ldp' and 'ietf-mpls-ldp-extended' to add mLDP-specific base and extended features. RFC 9070 explicitly serves as the base model for mLDP YANG.
All items in the base category are mandatory; no 'if-feature' statement is allowed under the base module. Extended features may use 'if-feature' to indicate optional capability support.
An LDP capability is disabled by default unless explicitly enabled. The scope of a capability enabled under the global container applies to all LDP peers in the given VRF instance; a per-peer capability container overrides the VRF-level setting.
The model enforces exactly one LDP instance per control-plane-protocol node via a YANG 'must' constraint: 'Only one LDP instance is allowed.' Multiple simultaneous LDP instances under the same routing context are prohibited.
The YANG modules conform to the Network Management Datastore Architecture (NMDA) defined in RFC 8342. Operational state data is combined with associated configuration data in the same hierarchy per RFC 8407.
FEC-Label bindings state is presented in a FEC-centric view under 'global/address-families/ipv4(or ipv6)/bindings/fec-label'. Each FEC entry holds a list of peers with advertisement-type (advertised/received), the label value, and a 'used-in-forwarding' boolean.
Module 'ietf-mpls-ldp' augments /rt:routing/rt:control-plane-protocols/rt:control-plane-protocol (RFC 8349) with a 'mpls-ldp' container holding four sub-containers: global (capabilities, graceful-restart, lsr-id, address-families), discovery (interfaces and targeted), peers, and operational state read-only nodes.
Module 'ietf-mpls-ldp-extended' augments the base LDP module to add IPv6 address family support, label policies (advertise/accept/assign with prefix-list references), forwarding nexthop control, IGP synchronization delay, downstream-on-demand, dual-stack transport preference, and per-peer/per-interface overrides.
Per-peer message statistics track sent and received counts for: total-octets, total-messages, address, address-withdraw, initialization, keepalive, label-abort-request, label-mapping, label-release, label-request, label-withdraw, and notification — all as yang:counter64.
Per-peer operational state includes: label-advertisement-mode (local/peer/negotiated, values downstream-unsolicited or downstream-on-demand), session-holdtime (peer/negotiated/remaining), tcp-connection (local/remote address+port), up-time (timeticks64 since OPERATIONAL state), and received-peer-state (GR and capability info from peer).
The 'adjacency-flag' identity hierarchy distinguishes actively configured adjacencies (adjacency-flag-active) from passively accepted ones (adjacency-flag-passive). A hello-adjacency may carry both flags simultaneously, visible in the 'flag' leaf-list of adjacency state.
The 'discovery/interfaces' container configures LDP basic (link) discovery. Global hello-holdtime defaults to 15 s (range 15–3600) and hello-interval defaults to 5 s (range 5–1200); these may be overridden per interface and per address family.
The 'discovery/targeted' container configures LDP extended (targeted) discovery, including a 'hello-accept' leaf (boolean) to passively accept incoming targeted hellos, and a 'target' list keyed by adjacent-address for configuring specific remote targets.
The 'global/graceful-restart' container configures LDP Graceful Restart (RFC 3478) with leaves: enabled (boolean, default false), reconnect-time (10–1800 s, default 120), recovery-time (30–3600 s, default 120), and forwarding-holdtime (30–3600 s, default 180).
The 'peers' container holds session KeepAlive parameters (session-ka-holdtime: 45–3600 s; session-ka-interval: 15–1200 s) and an authentication choice between a plain-text key+crypto-algorithm (password) or an RFC 8177 key-chain reference.
Three notifications are defined: 'mpls-ldp-peer-event' (peer operational status up/down with peer LDP ID), 'mpls-ldp-hello-adjacency-event' (adjacency up/down for link or targeted type), and 'mpls-ldp-fec-event' (FEC operational status with inet:ip-prefix).
Three RPC actions are defined: 'mpls-ldp-clear-peer' (reset LDP peer by lsr-id/label-space-id), 'mpls-ldp-clear-hello-adjacency' (clear link or targeted adjacency), and 'mpls-ldp-clear-peer-statistics' (reset per-peer counters). All are identified by protocol-name leafref.
IANA registers two new YANG modules: 'ietf-mpls-ldp' (namespace 'urn:ietf:params:xml:ns:yang:ietf-mpls-ldp') and 'ietf-mpls-ldp-extended' (namespace 'urn:ietf:params:xml:ns:yang:ietf-mpls-ldp-extended') in the 'IETF XML Registry' and 'YANG Module Names' registry.
Notifications (peer-event, hello-adjacency-event, fec-event) can expose topology change information to subscribers. Notification subscriptions should be restricted to authorized management clients to prevent information leakage.
Readable state nodes expose network topology information (neighbor adjacencies, FEC-label bindings, TCP connection endpoints, peer LSR IDs). Unauthorized read access could reveal topology details useful for network reconnaissance or traffic interception attacks.
RPC operations (clear-peer, clear-hello-adjacency, clear-peer-statistics) can cause service disruption if invoked by unauthorized parties. Access to these RPCs must be controlled via NETCONF access control mechanisms (e.g., NACM per RFC 8341).
Writable nodes in the model (e.g., authentication keys, hello/session timers, label policies, graceful-restart parameters) are sensitive. Unauthorized write access could disrupt LDP sessions, corrupt label bindings, or allow introduction of rogue peers.
The 'session-state' leaf (under peers/peer) models the LDP session finite state machine with five states: non-existent (transport disconnected), initialized, openrec, opensent, and operational. This maps directly to RFC 5036 Section 2.5.4.