A YANG Data Model for the Routing Information Base (RIB)
Extracted elements (28)
A rib-name nexthop case enables chained RIB lookups: a route's nexthop points to another RIB by name, causing the lookup to continue in the specified RIB rather than terminating. This supports policy-based routing and VPN use cases without requiring separate protocol machinery.
Nexthop lifecycle is managed separately from route lifecycle via dedicated nh-add/nh-delete RPCs that return a server-allocated nexthop-id. This enables nexthop sharing (sharing-flag=true) across multiple routes, reducing FIB memory when many routes share the same forwarding action.
RIB capability negotiation uses YANG feature and if-feature statements rather than a separate capability exchange protocol. This is necessary because not all hardware supports all nexthop types (chain, protection, replicate, load-balance, tunnel variants) or arbitrary levels of recursive lookup; advertisment at model-load time avoids runtime negotiation complexity.
The nexthop is modeled as a multilevel recursive structure to support combinations of use cases—load-balancing, protection switching, multicast replication—that cannot be expressed with a flat single-nexthop model. Nexthop chain allows multiple header operations on a packet before forwarding, enabling tunneling stacked with other actions.
The ietf-i2rs-rib YANG module is designed to align with the I2RS RIB information model defined in RFC 8430; implementations must satisfy the RIB use cases from [I2RS-REQS]. The YANG model is a concrete data representation of the abstract RFC 8430 information model.
A route MUST be associated with the following status attributes in responses to RIB write/read operations: Active (at least one fully resolved nexthop, eligible for FIB installation), Installed (route got installed in FIB), and Reason (specific failure cause, e.g., 'Not authorized').
A route MUST contain the ROUTE_PREFERENCE attribute (also known as administrative distance), a uint32 value used to compare routes from different protocols; lower values indicate higher preference.
An implementation MUST support sending route-change notifications whenever a route transitions between: active↔inactive and installed↔uninstalled states. A single notification MAY be used when transitioning between the combined inactive/uninstalled and active/installed states.
An implementation of this RIB data model MUST support sending two kinds of asynchronous notifications: route-change notifications (covering installed/active/reason state changes) and nexthop-resolution-status-change notifications (resolved/unresolved).
Before calling the route-add RPC, it is required to call the nh-add RPC to create the nexthop and obtain a nexthop identifier; an exception applies when the nexthop already exists and its nexthop-id is already known.
For nexthop-load-balance, each list member SHOULD be assigned a weight (uint8, 1..99). The weight 0 is reserved for equal load-balancing (ECMP) and, if applied, MUST be applied to all member nexthops; mixing weight 0 with non-zero weights is not permitted.
For the 'receive' special nexthop (locally destined traffic such as protocol or OAM packets), all locally destined traffic SHOULD be throttled to avoid a denial-of-service attack on the router's control plane; an optional rate-limiter can be specified.
A route consists of a route-index (uint64), a match condition (choice of IPv4, IPv6, MPLS label, MAC address, or interface), a nexthop container, a route-status container (route-state, route-installed-state, route-reason), and optional route-attributes and route-vendor-attributes containers.
Each RIB in rib-list is identified by a name and has an address-family (IPv4, IPv6, MPLS, or IEEE MAC), an optional ip-rpf-check boolean, a route-list keyed by route-index (uint64), and a nexthop-list keyed by nexthop-member-id (uint32). Multiple RIBs per routing instance are supported.
Route match types support five route kinds: IPv4 (destination, source, or destination+source prefix), IPv6 (destination, source, or destination+source prefix), MPLS (label uint32), MAC (mac-address yang:mac-address), and Interface (interface-identifier interface-ref). Each is a separate case in a YANG choice.
The ietf-i2rs-rib YANG module defines a routing-instance container as the top-level node, containing a name, interface-list, optional router-id (dotted-quad), optional lookup-limit (uint8), and a rib-list keyed by name. Each routing instance provides a logical slice of the router with its own set of RIBs, interfaces, and routing protocol parameters.
The module defines seven RPC operations: rib-add and rib-delete (manage RIBs within a routing instance), route-add, route-delete, and route-update (manage routes with bulk operation support and optional failure detail), and nh-add and nh-delete (manage shared nexthops with server-allocated identifiers). All RPCs return success/failure result codes.
The nexthop-base type supports eleven subtypes: special (discard, discard-with-error, receive, cos-value), egress-interface, IPv4 address, IPv6 address, egress-interface+IPv4, egress-interface+IPv6, egress-interface+MAC, tunnel-encapsulation, tunnel-decapsulation, logical-tunnel, rib-name (chained lookup), and nexthop-ref (indirection reference).
The nexthop is modeled as a multilevel structure supporting five types via a YANG choice: nexthop-base (foundational), nexthop-chain (multiple sequential header operations), nexthop-replicate (multiple destinations), nexthop-protection (primary/standby with preference), and nexthop-load-balance (weighted ECMP). All except nexthop-base are gated by YANG features.
The nexthop-protection type uses a nexthop-list-p grouping where each member has a nexthop-preference value (uint8, range 1..99, lower preferred). To download N nexthops to the FIB, the N members with lowest preference values are selected; tie-breaking among equal-preference nexthops is implementation-defined.
The route-change notification carries: rib-name, address-family, route-index, the full match condition, route-installed-state, route-state, and a list of route-change-reasons. Defined reasons include lower-route-preference, higher-route-preference, resolved-nexthop, and unresolved-nexthop.
The sharing-flag boolean on a nexthop indicates whether it is sharable (true: can be shared across multiple routes) or non-sharable (false: exclusive to one route). The nexthop-id (uint32) is a server-allocated identifier returned by nh-add that other routes reference for shared nexthop use.
Tunnel encapsulation nexthops support six tunnel types, each gated by a YANG feature: IPv4 tunnel (src/dest address, protocol, TTL, DSCP), IPv6 tunnel (src/dest, next-header, traffic-class, flow-label, hop-limit), MPLS (label push/swap operations), GRE (RFC 2784), NVGRE (RFC 7637), and VXLAN (RFC 7348).
IANA registered the 'ietf-i2rs-rib' YANG module in the 'IETF XML Registry' (namespace 'urn:ietf:params:xml:ns:yang:ietf-i2rs-rib') and in the 'YANG Module Names' registry with prefix 'iir' and reference to RFC 8431.
The 'receive' special nexthop and route-add RPC can be used to direct arbitrary traffic to a device's control plane, creating potential for DoS attacks on the router; the YANG model includes a rate-limiter option on the 'receive' special nexthop specifically to mitigate this risk.
The YANG module defines writable nodes (route-list, rib-list, nexthop-list and all RPC operations) that directly manipulate the routing information base; unauthorized write access could disrupt network routing, create black holes, or enable traffic interception. Access to this module must be controlled using standard NETCONF/RESTCONF access control mechanisms.
Nexthops have two states: resolved (has sufficient information to forward on an interface to a directly connected neighbor) and unresolved (requires the RIB manager to determine the final resolved nexthop, e.g., by IP lookup or MPLS tunnel). Unresolved nexthops are NOT eligible for FIB installation. State changes trigger nexthop-resolution-status-change notifications.
Routes have two orthogonal state dimensions: route-state (active/inactive, triggered by nexthop resolution—active requires at least one fully resolved nexthop) and route-installed-state (installed/uninstalled, triggered by FIB installation eligibility and policy). Transitions in either dimension generate route-change notifications.