A YANG Data Model for the Routing Information Protocol (RIP)
Extracted elements (24)
Several capabilities are modeled as optional YANG features (bfd, explicit-neighbors, global-statistics, interface-statistics) to allow vendors to selectively implement them. The document explicitly states it is each vendor's responsibility to decide whether to support a given feature.
The data model conforms to NMDA (RFC 8342) by combining operational state data with associated configuration data in the same schema hierarchy, rather than separating them. When queried from the operational state datastore, both 'config true' (rw) and 'config false' (ro) nodes are returned.
The model does not define RIP-specific notifications; instead it relies on the generic YANG notification subscription mechanisms defined in RFC 8639 and RFC 8641, which support per-client subscriptions, subtree/XPath filters, and periodic or on-demand delivery.
The 'ietf-rip' module imports and depends on ietf-routing (RFC 8349), ietf-interfaces (RFC 8343), ietf-ip (RFC 8344), ietf-key-chain (RFC 8177), ietf-bfd-types, ietf-ospf, and ietf-isis. Implementations must support these modules to use the RIP YANG model.
OSPFv2 redistribution into RIP is only applicable when the RIP instance type is 'ripv2', and OSPFv3 redistribution is only applicable when the type is 'ripng'. This is enforced with YANG 'when' statements on the respective lists.
RIPv2 interfaces must have an IPv4 address configured, and RIPng interfaces must have an IPv6 address configured. This is enforced by a YANG 'must' statement on the interface leaf that checks the corresponding ip:ipv4 or ip:ipv6 presence.
The timers container enforces that invalid-interval must be at least three times the value of update-interval, and flush-interval must be larger than invalid-interval. These constraints are encoded as YANG 'must' statements and will cause an error if violated.
Explicit neighbor configuration (feature 'explicit-neighbors') is supported per interface, allowing specification of RIP neighbor IP addresses for use on non-broadcast multiple access (NBMA) networks where multicast neighbor discovery is not available.
Global statistics (feature 'global-statistics') track discontinuity-time, requests-rcvd, requests-sent, responses-rcvd, and responses-sent as yang:counter32 values. Per-interface statistics (feature 'interface-statistics') track discontinuity-time, bad-packets-rcvd, bad-routes-rcvd, and updates-sent.
Interface authentication is applicable only to RIPv2 (not RIPng) and supports two modes: key-chain reference (using ietf-key-chain) or explicit key string with a crypto-algorithm identity. This is modeled as a YANG choice within the authentication container.
Operational state data for IPv4 (RIPv2) includes per-neighbor information (IPv4 address, last-update timestamp, bad-packets-rcvd counter, bad-routes-rcvd counter) and per-route information (IPv4 prefix, next-hop, interface, redistributed flag, route-type, metric, expire-time, deleted, holddown, need-triggered-update, inactive, flush-expire-before-holddown flags).
Operational state data for IPv6 (RIPng) mirrors the IPv4 structure with neighbor and route containers keyed by ipv6-address and ipv6-prefix respectively, including the same set of route-state flags (deleted, holddown, need-triggered-update, inactive, flush-expire-before-holddown).
Per-interface configuration includes authentication (key-chain or explicit key+crypto-algorithm, RIPv2 only), BFD parameters (feature-gated), cost (uint8, range 1..16, default 1), explicit neighbors (feature-gated, for NBMA networks), passive mode, no-listen mode, split-horizon (disabled/simple/poison-reverse, default simple), summary-address, and per-interface timers.
RIP timers are defined as a container with four leaves: update-interval (default 30s), invalid-interval (default 180s), holddown-interval (default 180s), and flush-interval (default 240s). YANG 'must' constraints enforce that invalid-interval >= update-interval*3 and flush-interval > invalid-interval.
Split-horizon is configurable per interface with three enumerated values: 'disabled' (no split-horizon), 'simple' (routes not advertised back toward the source interface), and 'poison-reverse' (routes advertised with infinite metric back toward source). The default is 'simple'.
The 'clear-rip-route' RPC clears RIP routes from the IP routing table and redistributed routes for a specified RIP instance or all instances. Its input is an optional leafref to a control-plane-protocol name; if omitted, all RIP instances are cleared.
The distribute-list container allows filtering of incoming or outgoing routing updates by associating prefix-set references with a direction (in/out) and optionally an interface. Multiple distribute-lists can be configured, keyed by prefix-set-name and direction.
The 'ietf-rip' YANG module augments the core 'ietf-routing' module under /rt:routing/rt:control-plane-protocols/rt:control-plane-protocol to add a 'rip' container that instantiates a RIP entity supporting RIPv2 or RIPng. The augmentation is conditioned on the routing protocol type being derived from the 'rip:rip' identity.
The redistribute container supports importing routes from BGP (by ASN), CG-NAT, connected, IPsec, IS-IS (by instance and level), NAT, OSPFv2 (RIPv2 only, by instance and route-type), OSPFv3 (RIPng only, by instance and route-type), RIPv2-to-RIPv2, RIPng-to-RIPng, and static routes. Each redistribution entry supports optional metric (0..16) and route-policy.
The 'rip' container provides per-instance configuration including originate-default-route, default-metric (uint8, range 0..16, default 1), distance (uint8, range 1..255, default 120), triggered-update-threshold (uint8, range 1..30 seconds, default 5), maximum-paths (uint8, range 1..16, default 8), output-delay (uint8, range 1..50 milliseconds), distribute-list, redistribute, timers, and interfaces.
This document registers namespace URI 'urn:ietf:params:xml:ns:yang:ietf-rip' in the IETF XML Registry (RFC 3688) and registers module 'ietf-rip' (prefix 'rip', namespace 'urn:ietf:params:xml:ns:yang:ietf-rip') in the YANG Module Names registry (RFC 6020).
Readable data nodes under the rip:rip subtree are also sensitive; unauthorized read access can disclose the operational state of RIP on the device. The 'clear-rip-route' RPC is additionally sensitive as unauthorized invocation can disrupt routing on the local device and the network.
The mandatory-to-implement secure transport for NETCONF access is SSH (RFC 6242), and for RESTCONF access is TLS (RFC 8446). Access control is provided by NACM (RFC 8341), which restricts NETCONF/RESTCONF users to preconfigured subsets of operations and content.
Writable data nodes under /rt:routing/rt:control-plane-protocols/rt:control-plane-protocol/rip:rip are sensitive; unauthorized write access via NETCONF/RESTCONF can adversely affect the routing subsystem, potentially causing network malfunctions and delivery of packets to inappropriate destinations.