A YANG Data Model for Routing Policy
Extracted elements (25)
A simple condition-action approach was chosen because it maps readily to several existing vendor implementations and gives operators a familiar way to express policy. Other policy expression methods (e.g., rule-based or declarative approaches) were not considered as a result.
Policy subroutines cannot explicitly accept or reject a route—they return only Boolean true/false to the caller. This design ensures that route acceptance or rejection is solely determined by the top-level policy, avoiding ambiguity from nested dispositions.
The model is intentionally a subset of available policy configuration—only widely-used constructs are included. Items available from a single vendor implementation are omitted, with the expectation they will be provided via vendor-specific YANG augmentations.
The set-application-tag action was introduced because the standard tag is automatically advertised in OSPF AS-External LSAs, whereas an application-specific tag allows applications requiring different semantics or policy to use a tag that is not implicitly advertised.
The model is designed for extensibility via YANG 'augment': routing protocol models (e.g., BGP) can add protocol-specific defined sets, conditions, and actions. Appendix A provides a non-normative example of BGP augmentation using draft-ietf-idr-bgp-model.
The nesting depth for policy subroutines is not prescribed by the model and varies among implementations. An implementation may only support a single level of subroutine recursion; creating policies nested beyond two to three levels is discouraged.
All members of a prefix-set MUST be of the same address family as the prefix-set mode. The device MUST validate all prefixes and reject the configuration if there is a discrepancy.
Implementations MUST perform validation to ensure that there is no recursion among nested routing policies. The call-policy MUST NOT have been previously called without returning (i.e., recursion is not allowed).
The called policy SHOULD contain an explicit or a default route disposition that returns an effective true (accept-route) or false (reject-route); otherwise, the behavior may be ambiguous.
The mask-length-lower leaf MUST NOT be less than the prefix length defined in ip-prefix. The mask-length-upper MUST NOT be less than mask-length-lower (enforced by a YANG 'must' constraint with error message).
A prefix-set entry is keyed by (name, mode) where mode is an enumeration of 'ipv4' or 'ipv6', and individual prefixes are identified by (ip-prefix, mask-length-lower, mask-length-upper). The mode enforces address family homogeneity within a set.
Defined sets include prefix-sets (IP prefixes with mask-length-lower and mask-length-upper range), neighbor-sets (IP addresses of neighboring nodes), and tag-sets (generic tag values). These sets are referenced by name in policy match conditions.
Policy actions include policy-result (accept-route or reject-route), set-metric (with metric-modification: set/add/subtract), set-metric-type, set-route-level, set-route-preference (administrative distance, uint16), set-tag, and set-application-tag.
Policy conditions include call-policy (subroutine invocation), source-protocol (route origin), match-interface, match-prefix-set, match-neighbor-set, match-tag-set, and match-route-type. Match behavior is modified by match-set-options (any/all/invert); prefix and neighbor sets restrict options to any/invert only.
Policy subroutines are implemented via the call-policy condition, which invokes another policy definition and returns a Boolean result (accept-route = true, reject-route = false) to the calling statement. Route accept/reject is determined solely by the top-level policy, not by subroutines.
The apply-policy grouping defines import-policy and export-policy as ordered leaf-lists of policy definition names, plus default-import-policy and default-export-policy (both defaulting to reject-route). This grouping is intended for reuse by other routing protocol models.
The ietf-routing-policy YANG module defines a generic routing policy framework with three main components: defined sets for matching (prefix-sets, neighbor-sets, tag-sets), policy definitions consisting of condition-action statements, and an apply-policy grouping for attaching import/export policy chains to routing contexts.
The match-modified-attributes operational leaf (read-only boolean) controls whether policy condition matching uses original route attributes or attributes as modified by preceding policy actions in the same evaluation pass. Its value is implementation-specific.
IANA registered the URI 'urn:ietf:params:xml:ns:yang:ietf-routing-policy' in the 'ns' subregistry of the IETF XML Registry (RFC 3688), and registered the YANG module 'ietf-routing-policy' with prefix 'rt-pol' in the 'YANG Module Names' subregistry of the YANG Parameters registry.
Modification of policy conditions and actions can redirect or drop traffic and alter route attributes in ways that are difficult to detect. Policy definitions should be considered proprietary—disclosure can reveal business relationships and represent loss of intellectual property.
The YANG module must be accessed via NETCONF over SSH (mandatory secure transport per RFC 6242) or RESTCONF over HTTPS/TLS 1.3 (RFC 8446). Access control should be enforced using the Network Configuration Access Control Model (NACM, RFC 8341).
Unauthorized modification of prefix-sets, neighbor-sets, or tag-sets can enable DoS attacks by redirecting or dropping traffic, or by leaking large numbers of routes into a routing protocol domain (e.g., BGP). Read access to these sets also reveals which prefixes and neighbors are susceptible to attack.
Policy evaluation proceeds sequentially through statements in order. When all conditions in a statement are satisfied, its actions execute; if actions include accept-route or reject-route, evaluation stops. If no conditions are satisfied in any statement, the chain's default route disposition (reject-route unless overridden) is applied.
The metric-modification-type enumeration governs set-metric behavior: 'set-metric' replaces the metric, 'add-metric' adds (clamping at 0xffffffff on overflow), and 'subtract-metric' subtracts (clamping at 0 on underflow). The metric value is uint32.
The tag-type typedef is a union of uint32 (decimal) and yang:hex-string (hexadecimal), used for IS-IS and OSPF administrative tags. It appears in tag-set members, set-tag, and set-application-tag action leaves.