A YANG Data Model for RIB Extensions
Extracted elements (16)
A per-next-hop 'preference' attribute is provided for static routes to enable selection among multiple configured static routes to the same destination, supporting both primary/backup and ECMP scenarios without requiring separate administrative distance configuration.
The 'metric' and 'tag' augmentations for RIB routes include a YANG 'when' condition that excludes OSPF and IS-IS source protocols, because the YANG data models for OSPF (RFC 9129) and IS-IS (RFC 9130) already define their own 'metric' and 'tag' augmentations for RIB routes, avoiding duplication.
The repair-path metric is included even though IPFRR repair rerouting is local and the metric is not advertised externally, because it is useful for troubleshooting purposes.
The 'metric' and 'tag' augmentations to RIB routes are excluded via a YANG 'when' constraint for routes whose source-protocol is derived from 'ospf:ospf' or 'isis:isis', ensuring compatibility with the existing OSPF (RFC 9129) and IS-IS (RFC 9130) YANG modules that already augment these fields.
This module conforms to the Network Management Datastore Architecture (NMDA) as described in RFC 8342, and augments only the NMDA version of the ietf-routing YANG module from RFC 8349.
The mandatory-to-implement secure transport for NETCONF access to this YANG module is Secure Shell (SSH) per RFC 6242; for RESTCONF access it is TLS per RFC 8446.
The 'application-tag' leaf (type uint32) is added to RIB routes as an additional opaque tag for application-specific semantics or policy different from the standard 'tag'. Unlike 'tag', it is not automatically advertised in OSPF AS-External LSAs.
The ietf-rib-extension YANG module augments the ietf-routing, ietf-ipv4-unicast-routing, and ietf-ipv6-unicast-routing modules from RFC 8349 to add multiple next hops, route metrics, administrative tags, and IP Fast Reroute repair paths to the RIB data model.
The 'metric' leaf (type uint32) is added to RIB routes to indicate the routing protocol cost. It is conditionally excluded for routes sourced from OSPF or IS-IS, which already define their own metric augmentations.
The 'preference' leaf (type uint32, default 1) is added to static route next hops for both IPv4 and IPv6. Routes with a lower preference value are preferred; equal-preference routes result in ECMP static routes.
The 'repair-path' container (grouping) is added to each RIB route next hop for IP Fast Reroute (IPFRR). It contains 'outgoing-interface' (interface-state-ref), 'next-hop-address' (ip-address-no-zone), and 'metric' (uint32) for the alternate repair path.
The 'rib-statistics' grouping adds a read-only 'statistics' container to each RIB, providing 'total-routes' (uint32), 'total-active-routes' (uint32), 'total-route-memory' (uint64, bytes), and per-protocol breakdowns in a 'protocol-statistics' list.
The 'tag' leaf (type uint32, default 0) is added at both the static route next-hop level and the RIB route level. It is a 32-bit opaque value used for policy decisions such as route advertisement and filtering.
This document registers the URI 'urn:ietf:params:xml:ns:yang:ietf-rib-extension' in the IETF XML Registry (RFC 3688), and registers the YANG module 'ietf-rib-extension' with prefix 'rib-ext' in the YANG Module Names registry (RFC 6020).
Read access to RIB statistics, route metrics, tags, application-tags, and repair paths must be controlled, as exposing the RIB reveals the routing topology of the network, which may facilitate other attacks and which operators may consider confidential.
Writable data nodes for static route preferences and tags (e.g., rib-ext:preference, rib-ext:tag on IPv4/IPv6 next hops) are sensitive: unauthorized write access could cause traffic misrouting. These must be protected via NACM (RFC 8341) and accessed only over secure transports (SSH for NETCONF, TLS for RESTCONF).