BMP YANG Model for Network Telemetry Messages

BMP YANG Modules The 'ietf-bmp-telemetry-message' YANG module defines the top-level BMP message structure. It carries a mandatory version leaf from the BMP Common Header, an optional session-metadata presence container derived from the BMP Initiation message, and a message-type choice covering all seven BMP message types: route-monitoring, statistics-report, peer-down-notification, peer-up-notification, initiation-message, termination-message, and route-mirroring-message. The 'ietf-bgp-rib-entry' module provides the rib-entry grouping used by route-monitoring and route-mirroring messages. It selects between five RIB table types — loc-rib, adj-rib-in-pre, adj-rib-in-post, adj-rib-out-pre, and adj-rib-out-post — via a nested rib-type choice. Each route entry contains the prefix, optional path-id for ADD-PATH, BGP path attributes, and community attributes. The 'ietf-bgp-open' module provides the bgp-open grouping, which carries the BGP OPEN message fields: protocol version, Autonomous System number, hold time, BGP identifier, and the negotiated capability list. It is used in peer-up-notification for both the sent and received OPEN messages. The 'ietf-bmp-tlv' module provides TLV groupings modeling the decoded content of BMP TLV Value fields. The common grouping — carrying sequence number, typed timestamps, and extended peer-header flags — is used across all seven BMP message types. Additional groupings are message-type-specific: information for initiation and peer-up messages, termination for termination messages, peer-down for Loc-RIB peer-down with reason code 6, and route-monitoring for path status and VRF/Table Name in route-monitoring messages. A BMP Initiation message is sent once per BMP session when the TCP connection is established and provides router identity information such as sys-name, sys-descr, and optional free-form strings. Because subsequent per-peer messages (Route Monitoring, Statistics Report, Peer Up, Peer Down) carry no equivalent identity information, a Network Telemetry collector acting as a YANG Message Broker Producer SHOULD cache the Initiation message content for each BMP session and populate session-metadata in every downstream message it emits. This makes each Message Broker message self-contained for consumers that did not observe or store the Initiation message directly. The session-metadata container is absent when the collector has not yet received or cached the Initiation message for that session.

BMP Telemetry Message YANG Module

Paolo Lucente Leonardo Rodoni "; description "Adds BMP specific subscription metadata to the data collection protocol provenance of the ietf-telemetry-message envelope. The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this document are to be interpreted as described in BCP 14 (RFC 2119) (RFC 8174) when, and only when, they appear in all capitals, as shown here. Copyright (c) 2026 IETF Trust and the persons identified as authors of the code. All rights reserved. Redistribution and use in source and binary forms, with or without modification, is permitted pursuant to, and subject to the license terms contained in, the Revised BSD License set forth in Section 4.c of the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info). This version of this YANG module is part of RFC XXXX; see the RFC itself for full legal notices."; revision 2026-06-30 { description "Initial revision."; reference "RFC XXXX"; } typedef peer-type { type enumeration { enum global-instance-peer { value 0; description "Global Instance Peer"; reference "RFC 7854: BGP Monitoring Protocol (BMP), Section 4.2."; } enum rd-instance-peer { value 1; description "RD Instance Peer"; reference "RFC 7854: BGP Monitoring Protocol (BMP), Section 4.2."; } enum local-instance-peer { value 2; description "Local Instance Peer"; reference "RFC 7854: BGP Monitoring Protocol (BMP), Section 4.2."; } enum loc-rib-instance-peer { value 3; description "Loc-RIB Instance Peer"; reference "RFC 9069: Support for Local RIB in the BGP Monitoring Protocol (BMP)"; } } description "BMP Peer Type."; reference "RFC 7854: BGP Monitoring Protocol (BMP), Section 4.2."; } grouping per-peer { description "BMP per-peer header."; reference "RFC 7854: BGP Monitoring Protocol (BMP), Section 4.2."; leaf peer-type { type peer-type; mandatory true; description "BMP peer type from per-peer header."; reference "RFC 7854: BGP Monitoring Protocol (BMP), Section 4.2."; } container peer-flags { when "not(../extended-flags)" { description "Present only when the Extended Flags TLV is absent. When extended-flags is present it is authoritative and peer-flags MUST NOT be emitted."; } description "BMP Per-Peer Header Flags decoded from the Per-Peer Header Flags field."; reference "RFC 7854: BGP Monitoring Protocol (BMP), Section 4.2."; uses btlv:peer-header-flags; } leaf peer-distinguisher { type rt-types:route-distinguisher; mandatory true; description "BMP peer distinguisher from per-peer header. The routing instance on which the encapsulated PDU was received."; reference "RFC 7854: BGP Monitoring Protocol (BMP), Section 4.2."; } leaf peer-address { type inet:ip-address; mandatory true; description "BMP peer IP address from per-peer header."; reference "RFC 7854: BGP Monitoring Protocol (BMP), Section 4.2. The remote IP address associated with the TCP session over which the encapsulated PDU was received."; } leaf peer-as { type uint32; mandatory true; description "BMP peer autonomous system number from per-peer header. The Autonomous System number of the peer from which the encapsulated PDU was received."; reference "RFC 7854: BGP Monitoring Protocol (BMP), Section 4.2."; } leaf peer-bgp-id { type inet:ipv4-address; mandatory true; description "BMP Peer BGP ID from per-peer header. The BGP Identifier of the peer from which the encapsulated PDU was received."; reference "RFC 7854: BGP Monitoring Protocol (BMP), Section 4.2."; } leaf timestamp { type yang:date-and-time; description "BMP timestamp from the Per-Peer Header (RFC 7854 Section 4.2). Represents the time the encapsulated routes were received or installed in the Adj-RIB-In. Absent when the value was zero (unavailable) in the wire header. // TODO: check with bmp-tlv regarding authoritative timestamp The Timestamp TLV (message-timestamp in btlv:common) MAY also be present and carries a typed timestamp. When message-timestamp with type 'adj-rib-in-time' is present, it is the authoritative value for this same event; the other Timestamp TLV types (trigger-time, message-export-time, local-rib-time, adj-rib-out-time) carry additional timing information with no Per-Peer Header equivalent."; reference "RFC 7854: BGP Monitoring Protocol (BMP), Section 4.2.; draft-ietf-grow-bmp-tlv: Section 5.6.1."; } } typedef peer-down-reason-code { type enumeration { enum local-system-closed-notification { value 1; description "The local system closed the session. A BGP PDU containing a BGP NOTIFICATION message that would have been sent to the peer follows the reason code."; reference "RFC 7854: BGP Monitoring Protocol (BMP), Section 4.9."; } enum local-system-closed-fsm-event { value 2; description "The local system closed the session. No NOTIFICATION message was sent. A 2-byte field containing the FSM Event code follows the reason code."; reference "RFC 7854: BGP Monitoring Protocol (BMP), Section 4.9."; } enum remote-system-closed-notification { value 3; description "The remote system closed the session with a NOTIFICATION message. The BGP PDU containing the NOTIFICATION follows the reason code."; reference "RFC 7854: BGP Monitoring Protocol (BMP), Section 4.9."; } enum remote-system-closed-no-data { value 4; description "The remote system closed the session without a NOTIFICATION message. Includes any unexpected termination of the transport session."; reference "RFC 7854: BGP Monitoring Protocol (BMP), Section 4.9."; } enum peer-de-configured { value 5; description "Information for this peer will no longer be sent to the monitoring station for configuration reasons."; reference "RFC 7854: BGP Monitoring Protocol (BMP), Section 4.9."; } enum local-system-closed-tlv-data-follows { value 6; description "The local system closed the Loc-RIB instance peer session. TLV data follows (see btlv:peer-down), including the VRF/Table Name TLV if it was present in the Peer Up."; reference "RFC 9069: Support for Local RIB in BMP, Section 5.3."; } } description "BMP Peer Down reason codes."; reference "RFC 7854: Section 4.9; RFC 9069: Section 5.3."; } grouping mirroring { description "BMP Route Mirroring Information TLV content (type 1 in the Route Mirroring TLVs registry). Conveys a 2-byte information code about the mirrored message or message stream."; reference "RFC 7854: BGP Monitoring Protocol (BMP), Section 4.7."; leaf information { type enumeration { enum error-pdu { value 0; description "Errored PDU. The contained message was found to have an error causing it to be treated-as-withdraw (RFC 7606). A BGP Message TLV MUST also be present."; } enum message-lost { value 1; description "Messages Lost. One or more messages may have been lost, e.g., due to buffer exhaustion."; } } description "Route Mirroring Information code."; } } // TODO: design better grouping for statistics grouping statistics { description "BMP Statistics."; reference "RFC 7854: BGP Monitoring Protocol (BMP), Section 4.8."; leaf statistics-type { type string { } description "BMP statistics type. Defines the type of the statistic carried in the Stat Data field."; } leaf statistics-data { type uint64; description "BMP statistics data. Defines the value of the statistic."; } } grouping peer-up { description "BMP Peer Up Notification fields."; reference "RFC 7854: BGP Monitoring Protocol (BMP), Section 4.10."; leaf local-address { type inet:ip-address; description "Local address from the Peer Up Notification. Set to '0::' for Loc-RIB Instance Peers."; reference "RFC 7854: BGP Monitoring Protocol (BMP), Section 4.10."; } leaf local-port { type inet:port-number; description "Local port from the Peer Up Notification. Set to 0 for Loc-RIB Instance Peers."; reference "RFC 7854: BGP Monitoring Protocol (BMP), Section 4.10."; } leaf remote-port { type inet:port-number; description "Remote port from the Peer Up Notification. Set to 0 for Loc-RIB Instance Peers."; reference "RFC 7854: BGP Monitoring Protocol (BMP), Section 4.10."; } container sent-open { description "BGP OPEN message sent by the local router to its peer."; reference "RFC 4271: A Border Gateway Protocol 4 (BGP-4), Section 4.2. RFC 7854: BGP Monitoring Protocol (BMP), Section 4.10."; uses bgo:bgp-open; } container received-open { description "BGP OPEN message received from the peer."; reference "RFC 4271: A Border Gateway Protocol 4 (BGP-4), Section 4.2. RFC 7854: BGP Monitoring Protocol (BMP), Section 4.10."; uses bgo:bgp-open; } } sx:structure message { description "Augments telemetry-message-metadata with BMP specific subscription metadata"; leaf version { type uint8; mandatory true; description "BMP version from common header."; reference "RFC 7854: BGP Monitoring Protocol (BMP), Section 4.1."; } container session-metadata { presence "BMP Initiation message information cached by a collector to enrich this message with router identity context."; description "Optional metadata derived from the BMP Initiation message for this BMP session. A collector MAY populate sys-name, sys-descr or a free-form string leaf-list to make this message self-contained for consumers that did not process or store the Initiation message directly."; uses btlv:information; } choice message-type { description "BMP message type from common header."; reference "RFC 7854: BGP Monitoring Protocol (BMP), Section 4.1."; case route-monitoring { container route-monitoring { description "BMP Route Monitoring message. Used for initial synchronization of Adj-RIBs-In and for ongoing incremental route monitoring."; uses per-peer; uses bre:rib-entry; uses btlv:route-monitoring; uses btlv:common; } } case statistics-report { container statistics-report { description "BMP Statistics Report message. Carries one or more counters reflecting activity on the monitored router."; uses per-peer; uses statistics; uses btlv:common; } } case peer-down-notification { container peer-down-notification { description "BMP Peer Down Notification message. Indicates that a peering session was terminated."; uses per-peer; leaf reason { type peer-down-reason-code; mandatory true; description "Reason why the peering session was closed."; reference "RFC 7854: BGP Monitoring Protocol (BMP), Section 4.9; RFC 9069: Support for Local RIB in BMP, Section 5.3."; } container peer-down { when "../reason = 'local-system-closed-tlv-data-follows'" { description "TLV data is present only when reason code 6 is used (Loc-RIB instance peer session closed)."; } description "Peer Down TLV data following reason code 6. Contains the VRF/Table Name TLV if it was present in the corresponding Peer Up notification."; uses btlv:peer-down; } uses btlv:common; } } case peer-up-notification { container peer-up-notification { description "BMP Peer Up Notification message. Indicates that a peering session has come up."; uses per-peer; uses peer-up; container information { presence "Information TLVs are present in this Peer Up notification"; description "Optional Information TLVs at the end of the Peer Up message. For standard peers only the string type (type 0) is defined; for Loc-RIB Instance Peers the VRF/Table Name TLV (type 3, RFC 9069) MUST be included when a name is configured."; reference "RFC 7854: Section 4.10; RFC 9069: Section 5.2.1."; uses btlv:information; } uses btlv:common; } } case initiation-message { container initiation-message { description "BMP Initiation Message. Provides information about the monitored router. MUST be the first message sent after the TCP session comes up. The sysDescr and sysName TLVs MUST be present."; uses btlv:information; uses btlv:common; } } case termination-message { container termination-message { description "BMP Termination Message. Provides a reason why the monitored router is closing the BMP session."; uses btlv:termination; uses btlv:common; } } case route-mirroring-message { container route-mirroring-message { description "BMP Route Mirroring Message. Used for verbatim duplication of messages as received, e.g., for full-fidelity monitoring or error reporting."; uses per-peer; uses bre:rib-entry; uses mirroring; uses btlv:common; } } } } } ]]>

BGP Open Message YANG Module

Paolo Lucente Leonardo Rodoni "; description "Defines a grouping for representing a BGP OPEN message as defined in RFC 4271. The BGP OPEN message is the first message sent by each side after a TCP connection is established and carries session parameters including the BGP version, the sender's AS number, the Hold Time, the BGP Identifier, and the list of optional capabilities. This module complements the ietf-bgp model by exposing the OPEN message fields in a standalone reusable grouping, intended for use by BMP and other BGP monitoring or telemetry protocols. Copyright (c) 2026 IETF Trust and the persons identified as authors of the code. All rights reserved. Redistribution and use in source and binary forms, with or without modification, is permitted pursuant to, and subject to the license terms contained in, the Revised BSD License set forth in Section 4.c of the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info). This version of this YANG module is part of RFC XXXX; see the RFC itself for full legal notices. The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this document are to be interpreted as described in BCP 14 (RFC 2119) (RFC 8174) when, and only when, they appear in all capitals, as shown here."; revision 2026-06-30 { description "Initial revision."; reference "RFC XXXX"; } grouping bgp-open { description "Fields from a BGP OPEN message."; reference "RFC 4271: A Border Gateway Protocol 4 (BGP-4), Section 4.2."; leaf version { type uint8; mandatory true; description "BGP protocol version number carried in the OPEN message. The current BGP version number is 4."; reference "RFC 4271: A Border Gateway Protocol 4 (BGP-4), Section 4.2."; } leaf my-as { type uint32; mandatory true; description "Autonomous System number of the BGP OPEN message sender."; reference "RFC 4271: A Border Gateway Protocol 4 (BGP-4), Section 4.2. RFC 6793: BGP Support for Four-Octet Autonomous System (AS) Number Space."; } leaf hold-time { type uint16; units "seconds"; mandatory true; description "Hold Time proposed by the sender in the BGP OPEN message. The Hold Time MUST be either zero or at least three seconds."; reference "RFC 4271: A Border Gateway Protocol 4 (BGP-4), Section 4.2."; } leaf bgp-identifier { type inet:ipv4-address; mandatory true; description "BGP Identifier of the sender, set to an IP address assigned to that BGP speaker. The value is determined upon startup and is the same for every local interface and BGP peer."; reference "RFC 4271: A Border Gateway Protocol 4 (BGP-4), Section 4.2."; } // TODO: check if we can ignore/need the index? list capabilities { key "code index"; description "List of BGP capabilities carried in the BGP OPEN message, identified by the Capability Code and an index. The index covers the case where the same BGP Capability may be advertised more than once."; reference "RFC 5492: Capabilities Advertisement with BGP-4, Section 4."; uses bgp:bgp-capabilities-common; } } } ]]>

BGP RIB Entry YANG Module

Paolo Lucente Leonardo Rodoni "; description "Defines a module for representing a single entry from a BGP Routing Information Base (RIB). The submodule supports entries from 5 logical RIB types per address family: loc-rib: An entry from the main BGP routing table for the local routing instance, containing best-path selections for each prefix. The key for the loc-rib entry corresponds either to a route in the adj-rib-in-post table or a route redistributed from another protocol. adj-rib-in-pre: An entry from the per-neighbor table containing the BGP routes received from the neighbor before any local input policy rules have been applied. This can be considered the 'raw' routes from a given neighbor. adj-rib-in-post: An entry from the per-neighbor table containing the routes received from the neighbor that are eligible for best-path selection after local input policy rules have been applied. The 'best-path' leaf is attached to the route selected by the BGP Decision Process (RFC 4271, Section 9.1). Such routes may be present in the loc-rib, described above, when local configuration determines that the BGP best-path will be used for that destination. adj-rib-out-pre: An entry from the per-neighbor table containing routes eligible for sending (advertising) to the neighbor before output policy rules have been applied. adj-rib-out-post: An entry from the per-neighbor table containing routes eligible for sending (advertising) to the neighbor after output policy rules have been applied. Copyright (c) 2026 IETF Trust and the persons identified as authors of the code. All rights reserved. Redistribution and use in source and binary forms, with or without modification, is permitted pursuant to, and subject to the license terms contained in, the Revised BSD License set forth in Section 4.c of the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info). This version of this YANG module is part of RFC XXXX (https://www.rfc-editor.org/info/rfcXXXX); see the RFC itself for full legal notices. The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this document are to be interpreted as described in BCP 14 (RFC 2119) (RFC 8174) when, and only when, they appear in all capitals, as shown here."; revision 2026-06-30 { description "Initial Version"; reference "RFC XXXX"; } grouping bgp-common-route-attributes { description "BGP path attributes and communities."; uses bgp-path-attributes; uses bgp:bgp-community-attr-state; uses bgp:ext-community-attributes; uses bgp:ipv6-ext-community-attributes; uses bgp:large-community-attributes; } grouping bgp-path-attributes { description "BGP path attributes."; container attributes { description "BGP path attribute parameters."; leaf origin { type bt:bgp-origin-attr-type; mandatory true; description "BGP attribute defining the origin of the path information."; reference "RFC 4271: A Border Gateway Protocol 4 (BGP-4), Section 5.1.1."; } container as-path { description "Enclosing container for the list of AS path segments."; reference "RFC 4271: A Border Gateway Protocol 4 (BGP-4), Section 5.1.2. RFC 6793: BGP Support for Four-Octet Autonomous System (AS) Number Space. RFC 5065: Autonomous System Confederations for BGP."; list segment { uses bgp:bgp-as-path-segment; description "List of AS PATH segments."; } } leaf next-hop { type inet:ip-address; description "BGP next hop attribute."; reference "RFC 4271: A Border Gateway Protocol 4 (BGP-4), Section 5.1.3."; } leaf link-local-next-hop { type inet:ipv6-address; description "Link-local next-hop when using RFC 2545 procedures."; reference "RFC 2545: Use of BGP-4 Multiprotocol Extensions for IPv6 Inter-Domain Routing."; } leaf med { type uint32; description "BGP multi-exit discriminator attribute."; reference "RFC 4271: A Border Gateway Protocol 4 (BGP-4), Section 5.1.4."; } leaf local-pref { type uint32; description "BGP local preference attribute."; reference "RFC 4271: A Border Gateway Protocol 4 (BGP-4), Section 5.1.5."; } container as4-path { description "AS4_PATH attribute for 4-octet AS numbers in Adj-RIB-In/Out. Not populated in Loc-RIB."; reference "RFC 6793: BGP Support for Four-octet AS Number Space."; list segment { uses bgp:bgp-as-path-segment; description "List of AS PATH segments."; } } container aggregator { description "BGP AGGREGATOR attribute."; reference "RFC 4271: A Border Gateway Protocol 4 (BGP-4), Section 5.1.7. RFC 6793: BGP Support for Four-octet AS Number Space."; leaf as { type inet:as-number; description "AS number of the aggregating router."; reference "RFC 4271: A Border Gateway Protocol 4 (BGP-4), Section 5.1.7."; } leaf identifier { type yang:dotted-quad; description "BGP Identifier of the aggregating router."; reference "RFC 4271: A Border Gateway Protocol 4 (BGP-4), Section 5.1.7."; } } container aggregator4 { description "AS4_AGGREGATOR attribute. Not populated in Loc-RIB."; reference "RFC 6793: BGP Support for Four-Octet Autonomous System (AS) Number Space."; leaf as4 { type inet:as-number; description "4-octet AS number of the aggregating router."; reference "RFC 6793: BGP Support for Four-Octet Autonomous System (AS) Number Space, Section 3."; } leaf identifier { type yang:dotted-quad; description "BGP Identifier of the aggregating router."; reference "RFC 6793: BGP Support for Four-Octet Autonomous System (AS) Number Space, Section 3."; } } leaf atomic-aggregate { type boolean; description "BGP ATOMIC_AGGREGATE attribute."; reference "RFC 4271: A Border Gateway Protocol 4 (BGP-4), Section 5.1.6."; } leaf originator-id { type yang:dotted-quad; description "BGP ORIGINATOR_ID attribute for route reflection."; reference "RFC 4456: BGP Route Reflection, Section 8."; } leaf-list cluster-list { type yang:dotted-quad; description "BGP CLUSTER_LIST attribute for route reflection."; reference "RFC 4456: BGP Route Reflection, Section 8."; } leaf aigp-metric { type uint64; description "BGP AIGP attribute."; reference "RFC 7311: The Accumulated IGP Metric Attribute for BGP."; } } } grouping ipv4-loc-rib-common { description "IPv4 Loc-RIB route entry."; container route { description "A single IPv4 Loc-RIB route entry."; leaf prefix { type inet:ipv4-prefix; mandatory true; description "The IPv4 prefix."; } uses bgp:bgp-loc-rib-common-keys; uses bgp-common-route-attributes; uses bgp:bgp-common-route-annotations-state; uses bgp:bgp-unknown-attr-top; uses bgp:rib-ext-route-annotations; } } grouping ipv6-loc-rib-common { description "IPv6 Loc-RIB route entry."; container route { description "A single IPv6 Loc-RIB route entry."; leaf prefix { type inet:ipv6-prefix; mandatory true; description "The IPv6 prefix."; } uses bgp:bgp-loc-rib-common-keys; uses bgp-common-route-attributes; uses bgp:bgp-common-route-annotations-state; uses bgp:bgp-unknown-attr-top; uses bgp:rib-ext-route-annotations; } } grouping ipv4-adj-rib-common { description "IPv4 Adj-RIB route entry (In-Pre, Out-Pre, Out-Post)."; container route { description "A single IPv4 Adj-RIB route entry."; leaf prefix { type inet:ipv4-prefix; mandatory true; description "The IPv4 prefix."; } uses bgp:bgp-adj-rib-attr-state; uses bgp-common-route-attributes; uses bgp:bgp-common-route-annotations-state; uses bgp:bgp-unknown-attr-top; uses bgp:rib-ext-route-annotations; } } grouping ipv4-adj-rib-in-post { description "IPv4 Adj-RIB-In post-policy route entry."; container route { description "A single IPv4 Adj-RIB-In post-policy route entry."; leaf prefix { type inet:ipv4-prefix; mandatory true; description "The IPv4 prefix."; } uses bgp:bgp-adj-rib-attr-state; uses bgp-common-route-attributes; uses bgp:bgp-common-route-annotations-state; uses bgp:bgp-adj-rib-in-post-route-annotations-state; uses bgp:bgp-unknown-attr-top; uses bgp:rib-ext-route-annotations; } } grouping ipv6-adj-rib-common { description "IPv6 Adj-RIB route entry (In-Pre, Out-Pre, Out-Post)."; container route { description "A single IPv6 Adj-RIB route entry."; leaf prefix { type inet:ipv6-prefix; mandatory true; description "The IPv6 prefix."; } uses bgp:bgp-adj-rib-attr-state; uses bgp-common-route-attributes; uses bgp:bgp-common-route-annotations-state; uses bgp:bgp-unknown-attr-top; uses bgp:rib-ext-route-annotations; } } grouping ipv6-adj-rib-in-post { description "IPv6 Adj-RIB-In post-policy route entry."; container route { description "A single IPv6 Adj-RIB-In post-policy route entry."; leaf prefix { type inet:ipv6-prefix; mandatory true; description "The IPv6 prefix."; } uses bgp:bgp-adj-rib-attr-state; uses bgp-common-route-attributes; uses bgp:bgp-common-route-annotations-state; uses bgp:bgp-adj-rib-in-post-route-annotations-state; uses bgp:bgp-unknown-attr-top; uses bgp:rib-ext-route-annotations; } } grouping rib-entry { description "Grouping for a BGP RIB entry organized by AFI-SAFI."; leaf afi-safi-type { type identityref { base bt:afi-safi-type; } mandatory true; description "AFI,SAFI name."; } container rib-entry { description "Encapsulates the route entry for a specific AFI-SAFI."; choice afi-safi { mandatory true; description "Choice of AFI-SAFI content, enforced by the afi-safi-type leaf."; case ipv4-unicast { when "derived-from-or-self(../afi-safi-type, 'bt:ipv4-unicast')"; container ipv4-unicast { description "Routing tables for IPv4 unicast."; choice rib-type { mandatory true; description "The specific RIB table type from which the route originates."; case loc-rib { container loc-rib { description "Route from the main BGP routing table for the local routing instance, containing best-path selections for each prefix."; uses ipv4-loc-rib-common; } } case adj-rib-in-pre { container adj-rib-in-pre { description "Route received from the neighbor before any local input policy rules or filters have been applied."; uses ipv4-adj-rib-common; } } case adj-rib-in-post { container adj-rib-in-post { description "Route received from the neighbor after local input policy rules have been applied."; uses ipv4-adj-rib-in-post; } } case adj-rib-out-pre { container adj-rib-out-pre { description "Route eligible to be sent to the neighbor before output policy rules have been applied."; uses ipv4-adj-rib-common; } } case adj-rib-out-post { container adj-rib-out-post { description "Route eligible to be sent to the neighbor after output policy rules have been applied."; uses ipv4-adj-rib-common; } } } } } case ipv6-unicast { when "derived-from-or-self(../afi-safi-type, 'bt:ipv6-unicast')"; container ipv6-unicast { description "Routing tables for IPv6 unicast."; choice rib-type { mandatory true; description "Choice between Local RIB and Neighbor-specific Adj-RIBs."; case loc-rib { container loc-rib { description "Route from the main BGP routing table for the local routing instance, containing best-path selections for each prefix."; uses ipv6-loc-rib-common; } } case adj-rib-in-pre { container adj-rib-in-pre { description "Route received from the neighbor before local input policy rules have been applied."; uses ipv6-adj-rib-common; } } case adj-rib-in-post { container adj-rib-in-post { description "Route received from the neighbor after local input policy rules have been applied."; uses ipv6-adj-rib-in-post; } } case adj-rib-out-pre { container adj-rib-out-pre { description "Route eligible to be sent to the neighbor before output policy rules have been applied."; uses ipv6-adj-rib-common; } } case adj-rib-out-post { container adj-rib-out-post { description "Route eligible to be sent to the neighbor after output policy rules have been applied."; uses ipv6-adj-rib-common; } } } } } } } } ]]>

BMP TLV YANG Module

Paolo Lucente Leonardo Rodoni "; description "Defines TLV groupings for BMP (BGP Monitoring Protocol) messages. The groupings in this module correspond to TLV types defined across the core BMP specifications and extensions: - RFC 7854 (BMP base): Information TLVs, Termination TLVs, Route Mirroring TLVs. - RFC 9069 (Loc-RIB): VRF/Table Name TLV (type 3), Peer Down reason code 6. - draft-ietf-grow-bmp-tlv (BMP v4): Cross-cutting TLVs applicable to all message types: Sequence Number (type 1), Extended Flags (type 2), Timestamp (type 3). Also Route Monitoring-specific TLVs: Group (4), VRF/Table Name (5), Stateless Parsing (6), BGP Message (7). - draft-ietf-grow-bmp-path-marking-tlv: Path Status TLV for Route Monitoring messages. This module models the decoded content of TLVs (i.e., what is carried in each TLV's Value field), not the wire-format TLV headers. The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this document are to be interpreted as described in BCP 14 (RFC 2119) (RFC 8174) when, and only when, they appear in all capitals, as shown here. Copyright (c) 2026 IETF Trust and the persons identified as authors of the code. All rights reserved. Redistribution and use in source and binary forms, with or without modification, is permitted pursuant to, and subject to the license terms contained in, the Revised BSD License set forth in Section 4.c of the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info). This version of this YANG module is part of RFC XXXX; see the RFC itself for full legal notices."; revision 2026-06-30 { description "Initial revision."; reference "RFC XXXX"; } // --------------------------------------------------------------- // Typedefs // --------------------------------------------------------------- typedef timestamp-type { type enumeration { enum trigger-time { value 0; description "Timestamp of the event which triggered BMP to report, e.g., a received message or a BGP/BMP session state transition."; reference "draft-ietf-grow-bmp-tlv: Section 5.6.1.1.1."; } enum message-export-time { value 1; description "Time at which the BMP message was generated for export."; reference "draft-ietf-grow-bmp-tlv: Section 5.6.1.1.2."; } enum adj-rib-in-time { value 2; description "Time at which the route was installed in the Adj-RIB-In, as per RFC 7854."; reference "draft-ietf-grow-bmp-tlv: Section 5.6.1.1.3."; } enum local-rib-time { value 3; description "Time at which the route was installed in the Loc-RIB, as per RFC 9069."; reference "draft-ietf-grow-bmp-tlv: Section 5.6.1.1.4."; } enum adj-rib-out-time { value 4; description "Time at which the route was installed in the Adj-RIB-Out, as per RFC 8671."; reference "draft-ietf-grow-bmp-tlv: Section 5.6.1.1.5."; } } description "BMP Timestamp types for the Timestamp TLV (type 3). Indicates which event the accompanying timestamp value refers to."; reference "draft-ietf-grow-bmp-tlv: Section 5.6.1."; } grouping path-status-flags { description "Boolean flags encoding path roles and states for a BGP route. Multiple flags may be true when multiple statuses apply. All flags absent or false indicates a path with no marking."; reference "draft-ietf-grow-bmp-path-marking-tlv: Section 3.1."; leaf invalid { type boolean; default false; description "Route does not enter the BGP decision process as indicated in Section 9.1.2 of RFC 4271."; } leaf best { type boolean; default false; description "Best route as defined in Section 9.1 of RFC 4271."; } leaf nonselected { type boolean; default false; description "Route not selected in the BGP decision process. Backup routes are considered nonselected, while best and primary routes are not."; } leaf primary { type boolean; default false; description "Path used for traffic forwarding. A prefix can have more than one primary path when multipath is configured. The best path is also a primary path."; } leaf backup { type boolean; default false; description "Path installed in the RIB but not used until some or all primary paths become unreachable. Used for fast convergence."; } leaf non-installed { type boolean; default false; description "Route not installed into the IP routing table."; } leaf best-external { type boolean; default false; description "Best external path."; } leaf add-path { type boolean; default false; description "Advertisement includes multiple paths for the same address prefix without the new paths implicitly replacing any previous ones, as per RFC 7911."; } leaf filtered-inbound-policy { type boolean; default false; description "Route filtered in the Adj-RIB-In policy."; } leaf filtered-outbound-policy { type boolean; default false; description "Route filtered in the Adj-RIB-Out policy."; } leaf stale { type boolean; default false; description "Path declared stale by the BGP Graceful Restart mechanism as described in Section 4.1 of RFC 4724."; } leaf suppressed { type boolean; default false; description "Path declared suppressed by the BGP Route Flap Damping mechanism as described in Section 2.2 of RFC 2439."; } } typedef path-status-reason-code { type enumeration { enum invalid-as-loop { value 1; description "Invalid due to AS loop as defined in Section 9.1.2 of RFC 4271."; } enum invalid-unresolvable-nexthop { value 2; description "Invalid due to unresolvable nexthop as defined in Section 9.1.2 of RFC 4271."; } enum not-preferred-local-preference { value 3; description "Not preferred because of local preference as described in Section 9.1.2.2 of RFC 4271."; } enum not-preferred-as-path-length { value 4; description "Not preferred because of AS Path Length as described in Section 9.1.2.2 of RFC 4271."; } enum not-preferred-origin { value 5; description "Not preferred because of origin as described in Section 9.1.2.2 of RFC 4271."; } enum not-preferred-med { value 6; description "Not preferred because of MED as described in Section 9.1.2.2 of RFC 4271."; } enum not-preferred-peer-type { value 7; description "Not preferred because of peer type (eBGP vs iBGP) as described in Section 9.1.2.2 of RFC 4271."; } enum not-preferred-igp-cost { value 8; description "Not preferred because of IGP cost as described in Section 9.1.2.2 of RFC 4271."; } enum not-preferred-router-id { value 9; description "Not preferred because of router ID as described in Section 9.1.2.2 of RFC 4271."; } enum not-preferred-peer-address { value 10; description "Not preferred because of peer address as described in Section 9.1.2.2 of RFC 4271."; } enum not-preferred-aigp { value 11; description "Not preferred because of AIGP as described in RFC 7311."; } } description "Reason codes for the BMP Path Status TLV. Indicates the reason a path has the indicated path status."; reference "draft-ietf-grow-bmp-path-marking-tlv: Section 3.2."; } // TODO: move to a separate module? // --------------------------------------------------------------- // Per-Peer Header Flags (shared by per-peer header and // Extended Flags TLV) // RFC 7854 Section 4.2 / draft-ietf-grow-bmp-tlv Section 5.6.3 // --------------------------------------------------------------- grouping peer-header-flags { description "Flags from the BMP Per-Peer Header (RFC 7854 Section 4.2)."; reference "RFC 7854: Section 4.2"; leaf ipv6-peer { type boolean; default false; description "V flag: Peer address is an IPv6 address."; reference "RFC 7854: Section 4.2."; } leaf post-policy { type boolean; default false; description "L flag: true indicates post-policy Adj-RIB-In; false indicates pre-policy Adj-RIB-In."; reference "RFC 7854: Section 4.2."; } leaf legacy-as-path { type boolean; default false; description "A flag: Message is formatted using the legacy 2-byte AS_PATH format."; reference "RFC 7854: Section 4.2."; } leaf adj-rib-out { type boolean; default false; description "O flag: Message reflects Adj-RIB-Out."; reference "RFC 8671: Support for Adj-RIB-Out in BMP, Section 4."; } leaf filtered { type boolean; default false; description "F flag: Loc-RIB is filtered. Set when a filter is applied to Loc-RIB routes sent to the BMP collector."; reference "RFC 9069: Section 4.2."; } } // --------------------------------------------------------------- // Cross-cutting TLVs (applicable to all BMP message types) // draft-ietf-grow-bmp-tlv Section 5.6 // --------------------------------------------------------------- grouping common { description "TLVs applicable to all BMP message types as defined in draft-ietf-grow-bmp-tlv Section 5.6. These TLVs carry per-message metadata and are allocated the same code point value in every TLV code point registry."; reference "draft-ietf-grow-bmp-tlv: Section 5.6."; leaf sequence-number { type uint64; description "Sequence Number TLV (type 1). Carries the per-BMP-session sequence number of this message starting at 0. If the sequence number would overflow, the BMP session MUST be reset."; reference "draft-ietf-grow-bmp-tlv: Section 5.6.2."; } list timestamps { key "timestamp-type"; description "Timestamp TLV (type 3). Carries a typed timestamp for this BMP message. Multiple instances MAY be present, one per timestamp type. A timestamp MUST NOT be included if it is not available."; reference "draft-ietf-grow-bmp-tlv: Section 5.6.1."; leaf timestamp-type { type timestamp-type; description "Type of the timestamp, indicating which event the timestamp value refers to."; } leaf timestamp { type yang:date-and-time; mandatory true; description "Timestamp value expressed as a date and time."; } } container extended-flags { presence "Extended Flags TLV (type 2) is present in this message. When this container is present, the X Flag in the Per-Peer Header Flags is set to 1."; description "Extended Flags TLV (type 2). Carries an extended set of per-peer flags, extending the Flags field of the Per-Peer Header to a variable-length sequence of bytes. The first byte carries the flags defined prior to this document (V, L, A, O, F); subsequent bytes carry newly allocated flags. When this TLV is present, the X Flag in the Per-Peer Header Flags MUST be set to 1 to signal that the authoritative flags are carried here. Collectors that do not understand the X Flag continue to use the Per-Peer Header flags directly."; reference "draft-ietf-grow-bmp-tlv: Section 5.6.3."; // TODO: discuss extensibility of this extended-flags container... // Extension point for future flag bits (RFC 8791 sx:augment-structure). // The augment path starts from the sx:structure root of the module // that instantiates btlv:common, e.g. for ietf-bmp-telemetry-message: // // sx:augment-structure // "/bmptm:message/bmptm:route-monitoring/btlv:extended-flags" { // leaf { type boolean; default false; ... } // } // uses peer-header-flags; } } // --------------------------------------------------------------- // Initiation and Peer Up Information TLVs // RFC 7854 Section 4.4 + RFC 9069 Section 5.2.1 // --------------------------------------------------------------- grouping information { description "BMP Information TLVs used in Initiation messages and Peer Up notifications. RFC 9069 renamed the registry to 'BMP Initiation and Peer Up Information TLVs', confirming both message types share these TLV type codes. For Initiation messages, sysDescr (type 1) and sysName (type 2) MUST be present; string (type 0) MAY appear multiple times; vrf-table-name is not applicable. For Peer Up notifications, only string (type 0) is defined in RFC 7854 (and may be repeated); RFC 9069 adds vrf-table-name (type 3) for Loc-RIB Instance Peers. If vrf-table-name is included in Peer Up it MUST also be included in the corresponding Peer Down notification."; reference "RFC 7854: Section 4.4; RFC 9069: Section 5.2.1."; leaf-list string { type string { length "1..65535"; } ordered-by user; description "String TLV (type 0). Free-form UTF-8 string. Multiple instances are permitted; their ordering MUST be preserved when reported."; reference "RFC 7854: Section 4.4."; } leaf sys-descr { type string { length "1..65535"; } description "sysDescr TLV (type 1). ASCII string whose value MUST be equal to the value of the sysDescr MIB-II (RFC 1213) object. MUST be present in Initiation messages."; reference "RFC 7854: Section 4.4."; } leaf sys-name { type string { length "1..65535"; } description "sysName TLV (type 2). ASCII string whose value MUST be equal to the value of the sysName MIB-II (RFC 1213) object. MUST be present in Initiation messages."; reference "RFC 7854: Section 4.4."; } leaf vrf-table-name { type string { length "1..255"; } description "VRF/Table Name TLV (type 3). UTF-8 string equal to the value of the VRF or table name (e.g., RD instance name) being conveyed. The default value 'global' MUST be used for the default Loc-RIB instance with a zero-filled distinguisher. If included in a Peer Up notification, it MUST also be included in the corresponding Peer Down notification."; reference "RFC 9069: Section 5.2.1."; } } // --------------------------------------------------------------- // Termination Message TLVs // RFC 7854 Section 4.5 // --------------------------------------------------------------- grouping termination { description "BMP Termination Message TLVs."; reference "RFC 7854: Section 4.5."; leaf-list string { type string { length "1..65535"; } ordered-by user; description "String TLV (type 0). Free-form UTF-8 string. Inclusion is optional. Multiple instances are permitted."; reference "RFC 7854: Section 4.5."; } leaf reason { type enumeration { enum administratively-closed { value 0; description "Session administratively closed. The session might be re-initiated."; } enum unspecified { value 1; description "Unspecified reason."; } enum out-of-resources { value 2; description "Out of resources. The router has exhausted resources available for the BMP session."; } enum redundant-connection { value 3; description "Redundant connection. The router has determined that this connection is redundant with another one."; } enum permanently-administratively-closed { value 4; description "Session permanently administratively closed and will not be re-initiated. Monitoring station should reduce (potentially to 0) the rate at which it attempts reconnection."; } } mandatory true; description "Reason TLV (type 1). Indicates why the session was terminated. Inclusion is REQUIRED."; reference "RFC 7854: Section 4.5."; } } // --------------------------------------------------------------- // Peer Down TLVs // RFC 9069 Section 5.3 (reason code 6 / TLV data follows) // --------------------------------------------------------------- grouping peer-down { description "BMP Peer Down TLVs. Present when the Peer Down reason code is 6 ('local-system-closed-tlv-data-follows'), as defined in RFC 9069 for Loc-RIB Instance Peers."; reference "RFC 9069: Section 5.3."; leaf vrf-table-name { type string { length "1..255"; } description "VRF/Table Name TLV (type 3). UTF-8 string equal to the VRF or table name. MUST be included if it was present in the corresponding Peer Up notification."; reference "RFC 9069: Section 5.3."; } } // --------------------------------------------------------------- // Route Monitoring TLVs // draft-ietf-grow-bmp-tlv Section 5.2 // draft-ietf-grow-bmp-path-marking-tlv // --------------------------------------------------------------- grouping path-status-info { description "BMP Path Status TLV for Route Monitoring messages. Conveys the status of a BGP path after processing by the BGP decision process. Carried as an indexed TLV in Route Monitoring messages; the index identifies the specific NLRI within the BGP Update PDU to which the status applies (index 0 applies to all NLRIs)."; reference "draft-ietf-grow-bmp-path-marking-tlv: Section 2."; uses path-status-flags; leaf reason-code { type path-status-reason-code; description "Optional reason code indicating why the path has the indicated status. Absent when no reason code is carried."; } } grouping route-monitoring { description "TLVs specific to BMP Route Monitoring messages. These appear in addition to the common metadata that applies to all BMP message types."; reference "draft-ietf-grow-bmp-tlv: Section 5.2; draft-ietf-grow-bmp-path-marking-tlv."; container path-status { presence "Path Status TLV is present for this route"; description "Path Status TLV. Conveys the BGP decision-process status of the route. As a per-NLRI indexed TLV this container represents the status applicable to the route entry in rib-entry."; uses path-status-info; } leaf vrf-table-name { type string { length "1..255"; } description "VRF/Table Name TLV (type 5 in Route Monitoring TLVs). UTF-8 string equal to the VRF or table name (i.e., RD instance name) being conveyed, consistent with RFC 9069 Section 5.2.1."; reference "draft-ietf-grow-bmp-tlv: Section 5.2.2."; } } } ]]>