Common YANG Data Types for the Routing Area
Extracted elements (25)
The iana-routing-types module is separated from ietf-routing-types to distinguish types that directly map to IANA registries (and must be updated when those registries change) from types that do not. This allows IANA to maintain the former independently.
Address Families and Subsequent Address Families MUST NOT be directly added to the iana-routing-types YANG module. They must instead be added to the 'Address Family Numbers' and 'Subsequent Address Family Identifiers (SAFI) Parameters' IANA registries respectively.
When an Address Family or SAFI is added to its respective IANA registry, a new 'enum' statement MUST be added to the iana-routing-types YANG module. The enum name must be a valid lowercase YANG identifier with hyphens, and must include value, optional status, optional description, and optional reference substatements.
When the iana-routing-types YANG module is updated, a new 'revision' statement MUST be added in front of the existing revision statements.
MPLS label types include: mpls-label-special-purpose (identityref based on mpls-label-special-purpose-value identity), mpls-label-general-use (uint32 range 16..1048575 excluding special-purpose values), and mpls-label (union of both). The generalized-label type is a binary type for GMPLS labels whose type is known from context.
MPLS special-purpose label identities defined include: ipv4-explicit-null-label (value 0), router-alert-label (value 1), ipv6-explicit-null-label (value 2), implicit-null-label (value 3), entropy-label-indicator, gal-label, oam-alert-label, and extension-label — all derived from the base identity mpls-label-special-purpose-value.
Multicast address types include ipv4-multicast-group-address (224.0.0.0–239.255.255.255), ipv6-multicast-group-address (ff00::/8), and the version-neutral ip-multicast-group-address union type. Source address types (ipv4-multicast-source-address, ipv6-multicast-source-address) additionally allow the wildcard value '*'.
The address-family enumeration in iana-routing-types covers all IANA-defined address families including ipv4 (1), ipv6 (2), l2vpn (25), bgp-ls (16388), and many others through trill-nickname (16396), mirroring the IANA Address Family Numbers registry.
The bandwidth-ieee-float32 type represents bandwidth in IEEE 754 floating-point 32-bit binary format with units of octets per second. The encoding is restricted to normalized, non-negative, non-fraction hexadecimal-significant character sequences (e.g., 0x1p10, 0x1.abcde2p+20).
The bgp-safi enumeration covers all IANA-defined BGP Subsequent Address Family Identifiers including unicast (1), multicast (2), labeled-unicast (4), evpn (70), labeled-vpn (128), route-target (132), and sr-te (73), mirroring the IANA SAFI Parameters registry.
The iana-routing-types YANG module defines IANA-derived common routing types, specifically address-family and bgp-safi enumerations. Its namespace is urn:ietf:params:xml:ns:yang:iana-routing-types and it is intended to be IANA-maintained to mirror IANA registries.
The ietf-routing-types YANG module defines common routing data types for use across routing area YANG models. It imports only ietf-yang-types and ietf-inet-types from RFC 6991, and its namespace is urn:ietf:params:xml:ns:yang:ietf-routing-types.
The ipv6-route-target type is a 20-octet BGP IPv6 Address Specific Extended Community in the format <ipv6-address:2-octet-number>, allowing only an IPv6 address as the global administrator (RFC 5701).
The link-access-type enumeration identifies IGP link types with four values: broadcast, non-broadcast-multiaccess (NBMA), point-to-multipoint, and point-to-point.
The mpls-label-stack grouping defines a reusable MPLS label stack as a list of entries keyed by a uint8 id indicating relative ordering (lowest id = top of stack). Each entry contains label, ttl (uint8), and traffic-class (uint8, range 0..7) fields.
The route-distinguisher type is an 8-octet string value used to distinguish routes from different BGP VPNs. It shares the same encoding pattern as route-target: types 0, 1, 2, and 6 as defined in RFC 4360, RFC 5668, and RFC 7432.
The route-origin type is an 8-octet BGP extended community identifying the set of sites where a BGP route originated. It uses the same encoding format as route-target and route-distinguisher.
The route-target-type enumeration defines three values — import (0), export (1), and both (2) — indicating the role a Route Target plays in route filtering as described in RFC 4364 Section 4.3.1.
The route-target type is an 8-octet BGP extended community string identifying a set of sites in a BGP VPN. It supports four encoding formats: 0:2-octet-asn:4-octet-number, 1:4-octet-ipv4addr:2-octet-number, 2:4-octet-asn:2-octet-number, and 6:6-octet-mac-address, plus a generic hex pattern for future types.
The router-id type is a 32-bit number in dotted-quad format assigned to each router, uniquely identifying the router within an Autonomous System. It is derived from yang:dotted-quad.
The timeticks64 type extends RFC 6991's timeticks to 64-bit width, representing time modulo 2^64 in hundredths of a second between two epochs. The uint24 type defines a 24-bit unsigned integer as a uint32 with range 0..16777215.
The vpn-route-targets grouping defines a reusable list of Route Target import-export rules used in BGP-enabled VPNs (RFC 4364, RFC 4664). Each list entry contains a route-target leaf and a mandatory route-target-type leaf.
Three timer value types are defined: timer-value-seconds16 (uint16, seconds), timer-value-seconds32 (uint32, seconds), and timer-value-milliseconds (uint32, milliseconds). All three support special enumeration values 'infinity' and 'not-set' in addition to numeric ranges.
This document registers two YANG module namespace URIs in the IETF XML Registry: urn:ietf:params:xml:ns:yang:ietf-routing-types and urn:ietf:params:xml:ns:yang:iana-routing-types. It also registers both modules in the YANG Module Names registry.
The YANG typedef definitions themselves have no security or privacy impact on the Internet. However, the usage of these types in concrete YANG modules might have security implications, and the security considerations of YANG 1.1 (RFC 7950) apply to this document.