A YANG Augmentation for Carrying BMP Telemetry in the Network Telemetry Message Envelope
draft-dikshit-nmop-bmp-telemetry-message-00
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Authors | Saumya Dikshit , Mukul Kumar Srivastava , Changwang Lin | ||
| Last updated | 2026-07-28 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Yang Validation | 2 errors, 2 warnings | ||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-dikshit-nmop-bmp-telemetry-message-00
Network Working Group S. Dikshit
Internet-Draft Aruba Networks, HPE
Intended status: Standards Track M. Srivastava
Expires: 25 January 2027 Hewlett Packard Enterprise
C. Lin
New H3C Technologies
28 July 2026
A YANG Augmentation for Carrying BMP Telemetry in the
Network Telemetry Message Envelope
draft-dikshit-nmop-bmp-telemetry-message-00
Abstract
[I-D.ietf-nmop-message-broker-telemetry-message] defines an
extensible YANG envelope, "ietf-telemetry-message", for publishing
collected Network Telemetry data to a Message Broker as part of a
Data Mesh, together with a companion augmentation module,
"ietf-yang-push-telemetry-message", that adds YANG-Push-specific
subscription metadata to that envelope. The base document's prose
explicitly anticipates the BGP Monitoring Protocol (BMP) [RFC7854]
as a source of collected data flowing through this envelope (see
the description of the "node-export-timestamp" leaf), but defines
no "session-protocol" identity, and no companion augmentation
module, for BMP.
This document closes that gap. It defines a new YANG module,
"ietf-bmp-telemetry-message", that (a) adds an "identity bmp" under
the base module's "session-protocol" identity, and (b) augments
"telemetry-message-metadata" with BMP-specific provenance: the
monitoring station identifier, BMP per-peer header fields, BMP
message type, and route-monitoring scope (network instance, RIB
type, address family, and Route Distinguisher). It also documents
how this module interoperates with the BMP YANG configuration and
monitoring model [I-D.ietf-grow-bmp-yang] and with several BMP
Statistics Report extensions ([RFC9972],
[I-D.ietf-grow-bmp-stats-informational-tlv],
[I-D.saum-grow-bmp-afi-safi-evpn],
[I-D.smc-grow-bmp-route-change-stats], and
[I-D.dikshit-grow-bmp-rd-scoped-rib-stats]) when their messages are
republished to a Message Broker.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current
Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other
documents at any time. It is inappropriate to use Internet-Drafts
as reference material or to cite them other than as "work in
progress."
This Internet-Draft will expire on 25 January 2027.
Copyright Notice
Copyright (c) 2026 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this
document. Please review these documents carefully, as they
describe your rights and restrictions with respect to this
document. Code Components extracted from this document must
include Revised BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Revised BSD License.
Dikshit, et al. Expires 25 January 2027 [Page 1]
Internet-Draft BMP Telemetry Message July 2026
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. The Gap in draft-ietf-nmop-message-broker-telemetry-message . 3
4. Relationship to Existing and In-Progress Documents . . . . . 4
5. BMP Telemetry Message Provenance . . . . . . . . . . . . . . 5
5.1. session-protocol Identity . . . . . . . . . . . . . . . . 5
5.2. BMP Session Provenance . . . . . . . . . . . . . . . . . 5
5.3. BMP Per-Peer-Header Fields . . . . . . . . . . . . . . . 6
5.4. Route Monitoring Scope . . . . . . . . . . . . . . . . . 6
5.5. Statistics Extension Marker . . . . . . . . . . . . . . . 7
6. YANG Module . . . . . . . . . . . . . . . . . . . . . . . . . 7
7. Use Case: Data-Product SLOs for BMP Statistics Pipelines . . 11
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
9. Security Considerations . . . . . . . . . . . . . . . . . . 12
10. Contributors and Acknowledgements . . . . . . . . . . . . . . 12
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
11.1. Normative References . . . . . . . . . . . . . . . . . . 13
11.2. Informative References . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14
1. Introduction
[I-D.ietf-nmop-message-broker-telemetry-message] defines the
"ietf-telemetry-message" YANG module: an extensible envelope used
at data collection to transform Network Telemetry
[RFC9232] messages into a form suitable for publication to a
Message Broker (e.g. Apache Kafka, Apache Pulsar) as part of an
organization's Data Mesh. The envelope carries a Network Node
Manifest, Network Telemetry protocol metadata (session-protocol,
export/collection addresses and timestamps, sequence number), a
Data Collection Manifest, network-operator labels, and the
collected payload itself. A second module in the same document,
"ietf-yang-push-telemetry-message", augments the envelope with
YANG-Push [RFC8641] specific subscription metadata (subscription
id, filter, transport, encoding, update trigger).
The base module's "session-protocol" identity currently has three
concrete identities: "yang-push", "netconf", and "restconf".
However, the description of the "node-export-timestamp" leaf in
that same module explicitly reads (emphasis added):
"Timestamp when the Network Telemetry data has been exported
from network element. This can be obtained in YANG-Push from
event-time defined in draft-ietf-netconf-notif-envelope or in
IPFIX from the export time in the message header as defined in
RFC 7011 **or in BMP from the timestamp in the per-peer header
as defined in RFC 7854**."
In other words, the document's own text anticipates the BGP
Monitoring Protocol (BMP) [RFC7854] as a legitimate source of
Network Telemetry data flowing through this envelope, but no
"identity bmp" exists to say so in the data, and no augmentation
module exists to carry BMP-specific provenance the way
"ietf-yang-push-telemetry-message" carries YANG-Push-specific
provenance.
This matters operationally because BMP is widely deployed
specifically to export BGP RIB/session telemetry to collectors
that frequently sit in front of the same Message Broker / Data Mesh
infrastructure this envelope targets, and because a growing set of
GROW working group documents extend BMP's Statistics Report
message with additional per-AFI/SAFI, per-EVI, and per-policy-
change-event counters (see Section 4) that would benefit from the
same manifest/provenance discipline this envelope already provides
for YANG-Push notifications: knowing which monitoring station
collected the data, which BMP peer and RIB it concerns, and when
it was collected versus exported, without having to parse
opaque payload bytes to answer those questions.
This document defines "ietf-bmp-telemetry-message", a companion
augmentation module that closes this gap using exactly the same
extension pattern the base document already uses for YANG-Push
(an "sx:augment-structure" of "telemetry-message-metadata", plus a
new identity based on "tm:session-protocol"). No change to the
base module is required.
1.1. Requirements Language
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 [RFC2119] [RFC8174] when, and only when, they appear in
all capitals, as shown here.
2. Terminology
This document uses the terms "Message Broker", "Publisher", and
"Receiver" as defined in
[I-D.ietf-nmop-yang-message-broker-integration], and "Network
Telemetry" as defined in [RFC9232]. It uses "Route Monitoring",
"Statistics Report", "Peer Up/Down Notification", "Initiation
Message", "Termination Message", and "Route Mirroring Message" as
defined in [RFC7854]. It uses "monitoring station" as defined in
[I-D.ietf-grow-bmp-yang].
3. The Gap in draft-ietf-nmop-message-broker-telemetry-message
See Section 1. In short: the base document's YANG model supports
exactly one collection protocol family (YANG-Push, with NETCONF
and RESTCONF <GET> also identified as identities but without a
dedicated augmentation module of their own) even though its prose
references BMP and IPFIX [RFC7011] as valid sources. This document
addresses the BMP half of that gap; IPFIX is out of scope here but
the same extension pattern applies and is noted as a companion
opportunity in Section 4.
4. Relationship to Existing and In-Progress Documents
This document builds directly on, and is intended to interoperate
with, the following:
* [RFC7854] defines BMP itself, including the per-peer header
fields (Peer Type, Peer Flags, Peer Distinguisher, Peer Address,
Peer AS, Peer BGP ID, Timestamp) reused in Section 5.3, and the
message types reused in Section 5.2.
* [I-D.ietf-grow-bmp-yang] defines the "ietf-bmp" YANG module for
configuring and monitoring BMP sessions on the monitored router,
including the "monitoring-station" identifier and the
network-instance / RIB-type / address-family / peer hierarchy
for route monitoring. This document's "monitoring-station-id"
(Section 5.2) is intended to match the "id" key of that module's
"monitoring-station" list when the monitored router and the
collector are both administered by the same operator; see
Security Considerations (Section 9) for the case where they are
not.
* [RFC9972] (published from
[I-D.ietf-grow-bmp-bgp-rib-stats]) defines advanced, per-AFI/
SAFI BGP RIB statistics carried in BMP Statistics Report
messages.
* [I-D.ietf-grow-bmp-stats-informational-tlv] adds min/max/avg/
median informational TLVs to BMP gauge-type statistics.
* [I-D.saum-grow-bmp-afi-safi-evpn] defines per-EVI EVPN BMP RIB
statistics keyed by Route Distinguisher.
* [I-D.smc-grow-bmp-route-change-stats] defines generic per-peer
BMP statistics for route attribute changes caused by routing
policy.
* [I-D.dikshit-grow-bmp-rd-scoped-rib-stats] generalizes the
per-EVI pattern above into an address-family-agnostic
"RD-Scoped Statistics" container applicable to L3VPN, EVPN, and
MVPN alike.
When any of the above Statistics Report extensions are collected
by a BMP monitoring station and republished to a Message Broker
using the base envelope, this document's "route-monitoring-scope"
container (Section 5.4) lets a consumer filter or route messages
by Route Distinguisher, address family, and RIB type without
parsing the (anydata) Stat Data payload, mirroring the filtering
convenience "ietf-yang-push-telemetry-message" already provides
for YANG-Push xpath/subtree filters.
* [I-D.ietf-nmop-message-broker-telemetry-message] and
[I-D.ietf-nmop-yang-message-broker-integration] are the base
envelope and its architecture document, described in Section 1.
A companion module for IPFIX [RFC7011], analogous in spirit to
this document, is a natural next contribution for whichever author
wishes to pick it up; this document does not attempt it so as to
keep BMP and IPFIX concerns independently reviewable.
5. BMP Telemetry Message Provenance
5.1. session-protocol Identity
This document defines:
identity bmp {
base tm:session-protocol;
description
"BGP Monitoring Protocol (BMP) as defined in RFC 7854.";
reference
"RFC 7854: BGP Monitoring Protocol (BMP).";
}
A Publisher populating "ietf-telemetry-message:message" for data
collected via BMP sets "telemetry-message-metadata/session-
protocol" to this identity.
5.2. BMP Session Provenance
"monitoring-station-id" identifies the BMP monitoring station
configuration (Section 3.1 of [I-D.ietf-grow-bmp-yang]) under which
the monitored router's connection to the collector was
established. It is carried as an opaque string (matching the
"monitoring-station/id" leaf type) rather than a leafref, because
the collector's telemetry-message datastore and the monitored
router's configuration datastore are, in general, different
management contexts; see the discussion of collector identity
versus BMP session identity in Section 4.
5.3. BMP Per-Peer-Header Fields
Route Monitoring, Statistics Report, and Peer Up/Down messages in
BMP all carry a Per-Peer Header (Section 4.2 of [RFC7854]). This
document exposes the fields of that header that are useful for
routing/filtering telemetry messages without payload inspection:
peer type, peer distinguisher (Route Distinguisher, when the peer
type indicates an L3VPN peer), peer address, peer AS, and peer BGP
ID. The per-peer-header Timestamp field is intentionally NOT
re-exposed here, since the base envelope's own
"node-export-timestamp" already serves that purpose (see Section
1) once "session-protocol" is set to "bmp".
5.4. Route Monitoring Scope
For Route Monitoring and Statistics Report messages, this document
carries the network-instance, RIB type (adj-rib-in-pre/post,
local-rib, adj-rib-out-pre/post, reusing the identities from
[I-D.ietf-grow-bmp-yang]), and address family (reusing "afi-safi-
type" from the same module) that the message concerns, plus an
OPTIONAL Route Distinguisher for messages scoped to a specific VRF/
EVI/MVPN instance (as produced by
[I-D.saum-grow-bmp-afi-safi-evpn] or
[I-D.dikshit-grow-bmp-rd-scoped-rib-stats]).
5.5. Statistics Extension Marker
An OPTIONAL "stat-extension" identityref names which registry a
Statistics Report message's Stat Type belongs to (base [RFC7854],
[RFC9972], the informational-tlv extension, the EVPN extension, the
route-change-stats extension, or the RD-scoped-stats extension).
This lets a Message Broker consumer route or dashboard messages by
extension family without decoding the Stat Type/Stat Data payload
itself, analogous to how "ietf-yang-push-telemetry-message"'s
"module" list lets a consumer identify which YANG modules/revisions
a push-update payload uses without parsing the payload.
6. YANG Module
The following tree diagram summarizes the augmentation defined by
this document (module: ietf-bmp-telemetry-message):
augment-structure /tm:message/tm:telemetry-message-metadata:
+-- bmp-session
+-- monitoring-station-id? string
+-- message-type identityref
+-- peer-header
| +-- peer-type? identityref
| +-- peer-distinguisher? rt-types:route-distinguisher
| +-- peer-address? inet:ip-address
| +-- peer-as? inet:as-number
| +-- peer-bgp-id? yang:dotted-quad
+-- route-monitoring-scope
| +-- network-instance? string
| +-- rib-type? identityref
| +-- address-family? identityref
| +-- route-distinguisher? rt-types:route-distinguisher
+-- stat-extension? identityref
<CODE BEGINS> file "ietf-bmp-telemetry-message@2026-07-25.yang"
module ietf-bmp-telemetry-message {
yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-bmp-telemetry-message";
prefix bmp-tm;
import ietf-telemetry-message {
prefix tm;
reference
"I-D.ietf-nmop-message-broker-telemetry-message: Extensible
YANG Model for Network Telemetry Messages";
}
import ietf-bmp {
prefix bmp;
reference
"I-D.ietf-grow-bmp-yang: A YANG Data Model for BMP";
}
import ietf-inet-types {
prefix inet;
reference "RFC 6991: Common YANG Data Types";
}
import ietf-yang-types {
prefix yang;
reference "RFC 6991: Common YANG Data Types";
}
import ietf-routing-types {
prefix rt-types;
reference "RFC 8294: Common YANG Data Types for the Routing
Area";
}
import ietf-yang-structure-ext {
prefix sx;
reference "RFC 8791: YANG Data Structure Extensions";
}
organization "IETF NMOP Working Group (proposed)";
contact
"Author: Saumya Dikshit
<mailto:saumya.dikshit@hpe.com>
Author: Mukul Srivastava
<mailto:mukul.srivastava@hpe.com>
Author: Changwang Lin
<mailto:linchangwang@h3c.com>";
description
"This module augments the 'ietf-telemetry-message' envelope
defined in I-D.ietf-nmop-message-broker-telemetry-message
with provenance metadata specific to data collected via the
BGP Monitoring Protocol (BMP), RFC 7854.
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).";
revision 2026-07-25 {
description
"Initial revision.";
reference
"RFC XXXX";
}
identity bmp {
base tm:session-protocol;
description
"BGP Monitoring Protocol (BMP) as defined in RFC 7854.";
reference
"RFC 7854: BGP Monitoring Protocol (BMP).";
}
identity bmp-message-type {
description
"Base identity for BMP message types, RFC 7854 Section 4.";
}
identity route-monitoring {
base bmp-message-type;
description "Route Monitoring message.";
}
identity statistics-report {
base bmp-message-type;
description "Statistics Report message.";
}
identity peer-down {
base bmp-message-type;
description "Peer Down Notification.";
}
identity peer-up {
base bmp-message-type;
description "Peer Up Notification.";
}
identity initiation {
base bmp-message-type;
description "Initiation Message.";
}
identity termination {
base bmp-message-type;
description "Termination Message.";
}
identity route-mirroring {
base bmp-message-type;
description "Route Mirroring Message.";
}
identity bmp-stat-extension {
description
"Base identity for BMP Statistics Report Stat Type
registries/extensions.";
}
identity base-rfc7854 {
base bmp-stat-extension;
description "Base Stat Types defined in RFC 7854 Section 4.8.";
}
identity rfc9972-bgp-rib-stats {
base bmp-stat-extension;
description "Per-AFI/SAFI BGP RIB statistics, RFC 9972.";
}
identity informational-tlv {
base bmp-stat-extension;
description
"Min/max/avg/median informational TLV extension,
I-D.ietf-grow-bmp-stats-informational-tlv.";
}
identity afi-safi-evpn {
base bmp-stat-extension;
description
"Per-EVI EVPN BMP RIB statistics,
I-D.saum-grow-bmp-afi-safi-evpn.";
}
identity route-change-stats {
base bmp-stat-extension;
description
"Per-peer route-attribute-change statistics,
I-D.smc-grow-bmp-route-change-stats.";
}
identity rd-scoped-rib-stats {
base bmp-stat-extension;
description
"Address-family-agnostic RD-scoped statistics container,
I-D.dikshit-grow-bmp-rd-scoped-rib-stats.";
}
sx:augment-structure "/tm:message/tm:telemetry-message-metadata" {
description
"Augments telemetry-message-metadata with BMP-specific
provenance metadata.";
container bmp-session {
when "../session-protocol = 'bmp-tm:bmp'";
description
"BMP-specific provenance for this telemetry message.";
leaf monitoring-station-id {
type string;
description
"Identifier of the BMP monitoring station configuration
(RFC 7854 Section 3.1; see also the 'monitoring-station'
list in I-D.ietf-grow-bmp-yang) under which this message
was collected.";
}
leaf message-type {
type identityref {
base bmp-message-type;
}
mandatory true;
description
"BMP message type of the payload carried in this
telemetry message.";
reference "RFC 7854 Section 4.";
}
container peer-header {
description
"Fields from the BMP Per-Peer Header, RFC 7854
Section 4.2, relevant to routing/filtering telemetry
messages without payload inspection.";
leaf peer-type {
type identityref {
base bmp:peer-type;
}
description "BMP peer type.";
}
leaf peer-distinguisher {
type rt-types:route-distinguisher;
description
"Route Distinguisher, present when the peer type
indicates an L3VPN peer.";
}
leaf peer-address {
type inet:ip-address;
description "BMP peer IP address.";
}
leaf peer-as {
type inet:as-number;
description "BMP peer Autonomous System number.";
}
leaf peer-bgp-id {
type yang:dotted-quad;
description "BMP peer BGP Identifier.";
}
}
container route-monitoring-scope {
description
"Scope of a Route Monitoring or Statistics Report
message, mirroring the network-instance / RIB-type /
address-family hierarchy of I-D.ietf-grow-bmp-yang.";
leaf network-instance {
type string;
description "Network instance name.";
}
leaf rib-type {
type identityref {
base bmp:afi-safi-type;
}
description
"Address family of the RIB this message concerns.";
}
leaf route-distinguisher {
type rt-types:route-distinguisher;
description
"Route Distinguisher, when this message is scoped to
a specific VRF/EVI/MVPN instance (see
I-D.saum-grow-bmp-afi-safi-evpn and
I-D.dikshit-grow-bmp-rd-scoped-rib-stats).";
}
}
leaf stat-extension {
type identityref {
base bmp-stat-extension;
}
description
"For Statistics Report messages, identifies which Stat
Type registry/extension the payload's Stat Data belongs
to, without requiring payload inspection.";
}
}
}
}
<CODE ENDS>
Note to WG: the tree diagram and module above use a placeholder
reference to "bmp:peer-type" and "bmp:afi-safi-type" identities
that would need to be confirmed/exported from
[I-D.ietf-grow-bmp-yang] (that module currently defines
"afi-safi-type" but the base BMP peer-type enumeration lives in
RFC 7854 prose, not yet as a YANG identity; this document assumes
the WG will expose it as one, and is happy to coordinate the exact
identity names with the grow-bmp-yang authors, several of whom
overlap with this document's authors and with
draft-ietf-nmop-message-broker-telemetry-message's authors).
7. Use Case: Data-Product SLOs for BMP Statistics Pipelines
Mirroring Section 4.2 ("Data Product Service Level Objective") of
[I-D.ietf-nmop-message-broker-telemetry-message]: once BMP
Statistics Report messages carrying RFC 9972 / route-change-stats /
rd-scoped-rib-stats extensions are published through this envelope,
a data consumer can compute end-to-end loss and delay for a given
monitoring-station/peer/RD/AFI-SAFI combination using
"node-export-timestamp" (from the BMP per-peer header, per Section
1), "collection-timestamp", and the time the message arrived at
the consumer -- exactly as the base document already describes for
YANG-Push -- without needing any BMP-specific parsing beyond this
module's provenance fields. This also lets an operator build a
single dashboard/alerting pipeline that treats YANG-Push and BMP
derived telemetry uniformly at the transport/provenance layer,
differing only in the "session-protocol" value and its associated
augmentation.
8. IANA Considerations
This document registers the following namespace URI in the IETF
XML Registry [RFC3688]:
URI: urn:ietf:params:xml:ns:yang:ietf-bmp-telemetry-message
Registrant Contact: The IESG.
XML: N/A; the requested URI is an XML namespace.
This document registers the following YANG module in the YANG
Module Names registry:
Name: ietf-bmp-telemetry-message
Namespace: urn:ietf:params:xml:ns:yang:ietf-bmp-telemetry-message
Prefix: bmp-tm
Reference: RFC XXXX
9. Security Considerations
This module inherits the security considerations of
[I-D.ietf-nmop-message-broker-telemetry-message] Section 6 and of
[I-D.ietf-grow-bmp-yang] Section 7.1. In addition:
Correlating "monitoring-station-id" (Section 5.2) with an actual
BMP session configuration requires that the collector and the
monitored router be administered under a shared trust domain, or
that the identifier be treated as an opaque, non-authoritative
label when they are not. Implementations MUST NOT assume that a
"monitoring-station-id" value is globally unique across
administrative domains, and consumers processing telemetry from
multiple organizations SHOULD additionally key on the Network Node
Manifest (Section 3 of the base document) to disambiguate.
The "peer-header" and "route-monitoring-scope" fields defined here
expose BGP peering relationships, AS numbers, and VPN Route
Distinguishers to any Message Broker consumer with access to the
relevant topic. This is the same class of information already
exposed by RFC 7854 BMP sessions themselves, but publishing it to a
Data Mesh broadens its reach beyond direct BMP monitoring station
connections; operators SHOULD apply Message Broker access controls
(see Section 6 of the base document) commensurate with the
sensitivity of routing topology and customer VPN identifiers.
10. Contributors and Acknowledgements
Thanks to Ahmed Elhassany, Thomas Graf, and Paolo Lucente for
[I-D.ietf-nmop-message-broker-telemetry-message], and to Camilo
Cardona, Paolo Lucente, Thomas Graf, Benoit Claise, Dhananjay
Patki, and Prasad S. Narasimha for [I-D.ietf-grow-bmp-yang], both
of which this document builds directly on.
11. References
11.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC7854] Scudder, J., Ed., Fernando, R., and S. Stuart, "BGP
Monitoring Protocol (BMP)", RFC 7854, June 2016.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, May 2017.
[RFC8294] Liu, X., Qu, Y., Lindem, A., Hopps, C., and L. Berger,
"Common YANG Data Types for the Routing Area", RFC 8294,
December 2017.
[RFC8791] Bierman, A., Bjorklund, M., and K. Watsen, "YANG Data
Structure Extensions", RFC 8791, June 2020.
[I-D.ietf-nmop-message-broker-telemetry-message]
Elhassany, A., Graf, T., and P. Lucente, "Extensible
YANG Model for Network Telemetry Messages", Work in
Progress, draft-ietf-nmop-message-broker-telemetry-
message-05, 19 July 2026.
[I-D.ietf-grow-bmp-yang]
Cardona, C., Lucente, P., Graf, T., Claise, B., Patki,
D., and P. Narasimha, "A YANG Data Model for BMP", Work
in Progress, draft-ietf-grow-bmp-yang-09, 15 June 2026.
11.2. Informative References
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
January 2004.
[RFC7011] Claise, B., Ed., Trammell, B., Ed., and P. Aitken,
"Specification of the IP Flow Information Export
(IPFIX) Protocol...", STD 77, RFC 7011, September 2013.
[RFC8641] Clemm, A. and E. Voit, "Subscription to YANG
Notifications for Datastore Updates", RFC 8641,
September 2019.
[RFC9232] Song, H., Ed., Qin, F., Martinez-Julia, P., Ciavaglia,
L., and A. Wang, "Network Telemetry Framework", RFC
9232, June 2022.
[RFC9972] (Published from I-D.ietf-grow-bmp-bgp-rib-stats),
"Advanced BMP Statistics", RFC 9972, 2026.
[I-D.ietf-nmop-yang-message-broker-integration]
Graf, T. and A. Elhassany, "An Architecture for
YANG-Push to Message Broker Integration", Work in
Progress, draft-ietf-nmop-yang-message-broker-
integration-13, 2 July 2026.
[I-D.ietf-grow-bmp-stats-informational-tlv]
Srivastava, M., Kolenchery, S., and C. Lin, "BMP
Statistics Informational TLV", Work in Progress,
draft-ietf-grow-bmp-stats-informational-tlv-00.
[I-D.saum-grow-bmp-afi-safi-evpn]
Dikshit, S., et al., "BMP RIB Statistics for EVPN", Work
in Progress, draft-saum-grow-bmp-afi-safi-evpn-06.
[I-D.smc-grow-bmp-route-change-stats]
Srivastava, M., et al., "Generic Per-Peer BMP Route
Change Statistics", Work in Progress,
draft-smc-grow-bmp-route-change-stats-02.
[I-D.dikshit-grow-bmp-rd-scoped-rib-stats]
Dikshit, S., Srivastava, M., and C. Lin,
"Route-Distinguisher-Scoped BMP RIB Statistics", Work in
Progress, draft-dikshit-grow-bmp-rd-scoped-rib-stats-00.
Authors' Addresses
Saumya Dikshit
Aruba Networks, Hewlett Packard Enterprise
Email: saumya.dikshit@hpe.com
Mukul Srivastava
Hewlett Packard Enterprise
Email: mukul.srivastava@hpe.com
Changwang Lin
New H3C Technologies
Email: linchangwang.04414@h3c.com