| Internet-Draft | BMP Path Attribute Sets and Statistics | October 2026 |
| Wang, et al. | Expires 1 May 2027 | [Page] |
- Workgroup:
- GROW
- Internet-Draft:
- draft-wang-grow-bmp-attribute-sets-stats-00
- Published:
- Intended Status:
- Standards Track
- Expires:
BMP Extension for BGP Path Attribute Sets and Statistics
Abstract
The BGP Monitoring Protocol (BMP) specified in RFC 7854 requires a monitored router to send full BGP Path Attributes for every Route Monitoring message. In networks with a large number of prefixes sharing identical BGP Path Attributes, this requirement leads to substantial transmission redundancy and protocol overhead.¶
This document specifies a decoupled architecture for BMP monitoring that separates Path Attribute Set registration from NLRI volume statistics. Attribute updates are triggered immediately upon path attribute changes, while NLRI count updates can be configured for either event-driven (immediate) or periodic reporting modes, with mandatory instant notification when an attribute set's reference count drops to zero.¶
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.¶
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 1 May 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.¶
1. Introduction
The BGP Monitoring Protocol (BMP) [RFC7854] provides a mechanism to monitor BGP routing state and updates on a router. Currently, BMP encapsulates standard BGP UPDATE messages containing Network Layer Reachability Information (NLRI) and Path Attributes [RFC4271] inside BMP Route Monitoring (RM) messages.¶
In modern scale-out networks, hundreds of thousands of NLRIs often share identical BGP Path Attributes (e.g., AS_PATH, Local-Preference, Communities). Transmitting identical attribute structures repeatedly for each route update introduces significant redundancy.¶
To minimize export bandwidth while maintaining visibility, this draft decouples Attribute Sets from Prefix Counts:¶
2. Terminology
3. Protocol Extensions
3.1. BMP Attribute Set Declaration Message
The BMP Attribute Set Declaration Message is used to register a new unique BGP Path Attribute Set or explicitly unregister an existing one.¶
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Attribute Set ID (AS-ID) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Action| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Path Attributes Length (2 Octets) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Path Attributes (Variable Length) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+¶
Fields:¶
-
Attribute Set ID (AS-ID) (32 bits): A 32-bit unsigned integer assigned locally by the monitored router to uniquely identify a specific BGP Path Attribute Set during the active session lifecycle. The value MUST NOT be 0 (0x00000000 is reserved).¶
-
Action (4 bits): Specifies the operation to be performed on the target AS-ID:¶
-
0x1 (REGISTER): Indicates the declaration of a new unique Path Attribute Set. The receiver MUST associate the provided Path Attributes with this AS-ID.¶
-
0x2 (UNREGISTER): Indicates that the AS-ID is explicitly deleted. The receiver MUST purge or mark inactive the Path Attribute Set associated with this AS-ID.¶
-
Values 0x0 and 0x3-0xF are reserved for future use and MUST be ignored on receipt.¶
-
-
Reserved (28 bits): Reserved for future extension. MUST be set to 0 by the sender on transmission and MUST be ignored by the receiver upon receipt.¶
-
Path Attributes Length (16 bits): A 16-bit unsigned integer specifying the total length, in octets, of the Path Attributes field.¶
-
Path Attributes (Variable Length): Contains zero or more BGP Path Attributes formatted as specified in Section 5 of [RFC4271]. This field is evaluated only when Action = 0x1 (REGISTER).¶
3.2. BMP Attribute Count Update Message
The BMP Attribute Count Update Message is used to convey prefix volume statistics bound to a previously registered AS-ID.¶
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Attribute Set ID (AS-ID) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Op | Mode | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | NLRI Count / Delta | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+¶
Fields:¶
-
Attribute Set ID (AS-ID) (32 bits): A 32-bit unsigned integer referencing a valid AS-ID previously announced via a BMP Attribute Set Declaration Message (Action = REGISTER).¶
-
Op (Operation Type) (4 bits): Defines how the receiver interprets the value in the NLRI Count / Delta field:¶
-
0x1 (ABSOLUTE_COUNT): The value represents the exact total number of prefixes (NLRIs) currently bound to this AS-ID.¶
-
0x2 (DELTA_ADD): The value represents an incremental addition (+N) to the current prefix count associated with this AS-ID.¶
-
0x3 (DELTA_DEL): The value represents an incremental subtraction (-N) from the current prefix count associated with this AS-ID.¶
-
0x4 (ZERO_REF): Indicates that the prefix count bound to this AS-ID has dropped to 0. The NLRI Count / Delta field MUST be set to 0.¶
-
-
Mode (4 bits): Indicates the operational context under which this report was generated:¶
-
Reserved (24 bits): Reserved for future extension. MUST be set to 0 on transmission and ignored on receipt.¶
-
NLRI Count / Delta (32 bits): A 32-bit unsigned integer representing either the total prefix volume or the change delta, interpreted according to the Op field.¶
3.3. BMP Message Type Allocations
This document defines two new BMP message types to be registered by IANA under the "BMP Message Types" registry:¶
4. Operational Procedures
4.1. Attribute Set Declaration Logic (Immediate Trigger)
4.2. Attribute Count Update Modes
An implementation SHOULD allow the operator to configure one of the following export modes for Attribute Count Update messages:¶
Option 1: Event-Driven Mode (Immediate Reporting)¶
-
Whenever prefixes associated with an AS-ID are added or withdrawn, the router immediately transmits a Count Update Message using either DELTA or ABSOLUTE values.¶
Option 2: Periodic Reporting Mode (Interval Polling + Zero Threshold)¶
-
The router suppresses real-time per-route update messages and instead transmits ABSOLUTE count reports for all active AS-IDs at a configured interval (e.g., every 30 seconds).¶
-
EXCEPTION: If the prefix count for any AS-ID drops to 0 prior to the next periodic timer expiration, the router MUST immediately emit a Count Update Message (Op = ZERO_REF, NLRI Count = 0).¶
-
Upon emitting or receiving Op = ZERO_REF, the router and server MAY initiate unregistration/garbage collection for that AS-ID.¶
4.3. Session Re-establishment and State Synchronization
When a BMP session between the Monitored Router and the Monitoring Station is established or re-established after a failure:¶
-
The Monitored Router MUST re-advertise all currently active Path Attribute Sets present in its RIB using Attribute Set Declaration Messages (Action = REGISTER) with their corresponding valid AS-IDs.¶
-
Following the attribute declarations, the router SHOULD transmit initial Attribute Count Update Messages (Op = ABSOLUTE_COUNT, Mode = EVENT_DRIVEN) to synchronize current prefix volumes for each AS-ID, ensuring the BMP Monitoring Station rapidly achieves state convergence without waiting for the next periodic polling interval.¶
5. Security Considerations
This extension introduces no new security vulnerabilities beyond those described in [RFC7854].¶
6. IANA Considerations
This document requests IANA to allocate two new message types in the "BMP Message Types" registry defined in [RFC7854]:¶
+-------+----------------------------------+---------------+ | Value | Description | Reference | +-------+----------------------------------+---------------+ | TBD1 | Attribute Set Declaration Message| This document | | TBD2 | Attribute Count Update Message | This document | +-------+----------------------------------+---------------+¶
7. Acknowledgements
TBD¶
8. References
8.1. Normative References
- [RFC2119]
- Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <https://www.rfc-editor.org/info/rfc2119>.
- [RFC4271]
- Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, DOI 10.17487/RFC4271, , <https://www.rfc-editor.org/info/rfc4271>.
- [RFC7854]
- Scudder, J., Ed., Fernando, R., and S. Stuart, "BGP Monitoring Protocol (BMP)", RFC 7854, DOI 10.17487/RFC7854, , <https://www.rfc-editor.org/info/rfc7854>.
- [RFC8174]
- Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, , <https://www.rfc-editor.org/info/rfc8174>.