A YANG Data Model for Routing Management (NMDA Version)
obsoletes
- rfc-8022 — A YANG Data Model for Routing Management
Extracted elements (27)
New control-plane protocol modules are RECOMMENDED to encapsulate protocol-specific data in a presence container; a presence container may contain mandatory nodes that are otherwise forbidden at the top level of a YANG augment, allowing richer protocol-specific schemas.
The model distinguishes 'system-controlled entries' (created by the server in operational state regardless of configuration) from 'user-controlled entries' (created as a direct result of configuration). Deleting a system-controlled entry from the intended configuration removes only its supplemental configuration, not the operational state entry itself.
The 'router-id' leaf is placed behind a feature flag because not all routing protocols require an explicit 32-bit router ID; servers without the feature assign a router ID algorithmically (typically an IPv4 address) in an implementation-specific manner.
The 'routing-state' container and its subtree are retained in the YANG module with 'status obsolete' rather than removed outright, because NMDA (RFC 8342) supersedes the pre-NMDA pattern of separate config and state containers; the unified '/routing' container serves both roles via NMDA datastores.
The 'valid-lifetime' and 'preferred-lifetime' RA prefix parameters are specified as constant configured values rather than decrementing counters. Decrementing behavior would be reset on configuration reload, no implementation is known to use it, and RFC 4861 explicitly permits constant values.
The 'ietf-routing', 'ietf-ipv4-unicast-routing', and 'ietf-ipv6-unicast-routing' modules require NMDA-compatible versions of 'ietf-interfaces' (RFC 8343) and 'ietf-ip' (RFC 8344); importing pre-NMDA versions is incompatible with this revision.
This document obsoletes RFC 8022. The 'routing-state' subtree from RFC 8022 is retained in the module with 'status obsolete' to smooth migration; implementations conforming to RFC 8349 must use the NMDA '/routing' container and NMDA datastores instead.
Configuration of an IP address on an enabled interface MUST result in the immediate creation of the corresponding direct route; the destination prefix is derived from the configured IP address and network prefix/mask, and the interface is set as the outgoing interface.
Every implementation of the core routing data model MUST provide exactly one instance of the 'direct' pseudo-protocol type; it is the source of direct routes for all configured address families.
For every supported address family, exactly one RIB MUST be marked as the default RIB, in which control-plane protocols place their routes by default.
If ip:forwarding is set to 'false' for an interface, the forwarding of IPv4 or IPv6 datagrams through that interface MUST be disabled, though the interface MAY still participate in routing protocols such as OSPF.
If the /if:interfaces/if:interface/if:enabled leaf is set to 'false' for a network-layer interface, all routing and forwarding functions MUST be disabled on that interface.
The 'default-lifetime' leaf for IPv6 Router Advertisements MUST be either zero or between max-rtr-adv-interval and 9000 seconds; a value of zero indicates the router is not to be used as a default router.
The 'min-rtr-adv-interval' MUST NOT be greater than 75% of 'max-rtr-adv-interval', enforced by a YANG 'must' constraint in the submodule.
When defining a new control-plane protocol, a new identity MUST be defined with its base set to 'rt:control-plane-protocol' or a derived identity; protocol-specific data nodes SHOULD be conditional via a 'when' statement testing 'rt:type' or 'rt:source-protocol'.
A route entry in a RIB carries: 'destination-prefix' (mandatory, address-family-specific, added by augmenting modules), 'route-preference' (uint32 administrative distance, lower is preferred), and a 'next-hop' container using the next-hop-state-content grouping.
The 'active-route' action on the RIB list takes a destination address (augmented by address-family modules) and returns the active route for that destination; if no route exists, no output is returned.
The control-plane-protocol list is keyed by [type name], where 'type' is an identityref derived from 'rt:control-plane-protocol' and 'name' is an arbitrary string instance label. The core model defines identities for 'direct' and 'static' pseudo-protocols.
The 'ietf-ipv6-router-advertisements' submodule augments /if:interfaces/if:interface/ip:ipv6 with an 'ipv6-router-advertisements' container holding RFC 4861 AdvSendAdvertisements, MaxRtrAdvInterval (4-65535 s, default 600), MinRtrAdvInterval, managed-flag, other-config-flag, link-mtu, reachable-time, retrans-timer, cur-hop-limit, default-lifetime, and a prefix-list.
The 'ietf-routing' module defines the core routing framework under a '/routing' container holding: an optional router-id (yang:dotted-quad, feature-guarded), a read-only 'interfaces' leaf-list, a 'control-plane-protocols' list, and a 'ribs' list.
The 'multiple-ribs' feature flag signals server support for user-defined RIBs beyond system-controlled defaults, enabling policy routing with multiple RIBs per address family. Servers not advertising this feature SHOULD provide exactly one system-controlled RIB per address family.
The 'next-hop-content' grouping presents a mandatory choice among three cases: 'simple-next-hop' (outgoing-interface plus augmented next-hop address), 'special-next-hop', and 'next-hop-list' (container with a keyed list of next hops for ECMP). Address-family modules MUST augment simple-next-hop and next-hop-list with address-family-specific next-hop-address leaves.
The RIB list (/routing/ribs/rib) is keyed by 'name' (string) and carries 'address-family' (identityref, mandatory), 'default-rib' (boolean, read-only, guarded by multiple-ribs feature), a read-only 'routes' container, and an 'active-route' action.
The 'route-metadata' grouping defines three common attributes: 'source-protocol' (mandatory identityref to the originating routing protocol), 'active' (empty leaf whose presence marks the preferred route for a given prefix), and 'last-updated' (yang:date-and-time).
The 'special-next-hop' grouping enumerates four special next-hop actions: 'blackhole' (silently discard), 'unreachable' (discard with host-unreachable error), 'prohibit' (discard with administratively-prohibited error), and 'receive' (deliver to local system).
IANA registered three YANG modules in the 'IANA XML Registry' and 'IANA-maintained YANG Module Names' registry: 'ietf-routing' (namespace urn:ietf:params:xml:ns:yang:ietf-routing), 'ietf-ipv4-unicast-routing' (urn:ietf:params:xml:ns:yang:ietf-ipv4-unicast-routing), and 'ietf-ipv6-unicast-routing' (urn:ietf:params:xml:ns:yang:ietf-ipv6-unicast-routing), all referencing RFC 8349.
The writable data nodes in the 'ietf-routing', 'ietf-ipv4-unicast-routing', and 'ietf-ipv6-unicast-routing' modules (including static routes and control-plane protocol configuration) are security-sensitive because unauthorized modification could redirect or black-hole traffic; access MUST be restricted to authorized principals via appropriate NETCONF access control.