BMP registry procedures: Revision to Registration Procedures for Multiple BMP Registries
Simplifies registration procedures for BGP Monitoring Protocol IANA registries.
Scudder, J., "Revision to Registration Procedures for Multiple BMP Registries", RFC 9515, DOI 10.17487/RFC9515, December 2023, <https://www.rfc-editor.org/info/rfc9515>.
@misc{rfc9515,
series = {Request for Comments},
number = 9515,
howpublished = {RFC 9515},
publisher = {RFC Editor},
doi = {10.17487/RFC9515},
url = {https://www.rfc-editor.org/info/rfc9515},
author = {J. Scudder},
title = {{Revision to Registration Procedures for Multiple BMP Registries}},
pagetotal = 3,
year = 2023,
month = dec,
} RFC text
Contents
Internet Engineering Task Force (IETF) J. Scudder
Request for Comments: 9515 Juniper Networks
Updates: 7854 December 2023
Category: Standards Track
ISSN: 2070-1721
Revision to Registration Procedures for Multiple BMP Registries
Abstract
This document updates RFC 7854, "BGP Monitoring Protocol (BMP)", by
changing the registration procedures for several registries.
Specifically, any BMP registry with a range of 32768-65530 designated
"Specification Required" has that range redesignated as "First Come
First Served".
Status of This Memo
This is an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc9515.
Copyright Notice
Copyright (c) 2023 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.
Table of Contents
1. Introduction
2. IANA Considerations
3. Security Considerations
4. Normative References
Acknowledgements
Author's Address
1. Introduction
[RFC7854] creates a number of IANA registries that include a range of
32768-65530 designated "Specification Required". Each such registry
also has a large range designated "Standards Action". Subsequent
experience has shown two things. First, there is less difference
between these two policies in practice than there is in theory
(consider that [RFC8126] explains that for Specification Required,
"Publication of an RFC is an ideal means of achieving this
requirement"). Second, it's desirable to have a very low bar to
registration, to avoid the risk of conflicts introduced by use of
unregistered code points (so-called "code point squatting").
Accordingly, this document revises the registration procedures, as
given in Section 2.
2. IANA Considerations
IANA has revised the following registries within the BMP group:
* BMP Statistics Types
* BMP Initiation and Peer Up Information TLVs
* BMP Termination Message TLVs
* BMP Termination Message Reason Codes
* BMP Route Mirroring TLVs
* BMP Route Mirroring Information Codes
For each of these registries, the ranges 32768-65530 whose
registration procedures were "Specification Required" are revised to
have the registration procedures "First Come First Served".
3. Security Considerations
This revision to registration procedures does not change the
underlying security issues inherent in [RFC7854].
4. Normative References
[RFC7854] Scudder, J., Ed., Fernando, R., and S. Stuart, "BGP
Monitoring Protocol (BMP)", RFC 7854,
DOI 10.17487/RFC7854, June 2016,
<https://www.rfc-editor.org/info/rfc7854>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>.
Acknowledgements
Thanks to Jeff Haas for review and encouragement, and to Tom Petch
for review.
Author's Address
John Scudder
Juniper Networks
1194 N. Mathilda Ave
Sunnyvale, CA 94089
United States of America
Email: jgs@juniper.net
AI ELI5
On this page
§1The Problem
RFC 7854 created the BGP Monitoring Protocol (BMP) and defined several IANA registries for code points. These registries included two ranges: one requiring Specification Required (strict approval) and another requiring Standards Action (full RFC process). In practice, the high-value range 32768-65530 with Specification Required was almost never used because the burden of getting a specification published was too high.
This created pressure for operators to use unregistered code points unofficially, risking collisions when multiple vendors independently chose the same values.
There was a waiting list to add new things, and the waiting process was so strict that nobody used it officially. People started using secret code points instead.
§2First Come First Served Registration
RFC 9515 changes six registries: BMP Statistics Types, Initiation and Peer Up TLVs, Termination Message TLVs, Termination Message Reason Codes, Route Mirroring TLVs, and Route Mirroring Information Codes. For each registry, the 32768-65530 range now uses First Come First Served instead of Specification Required.
First Come First Served is a registration policy defined in RFC 8126 that requires only basic checks (is the code point available? does the request make sense?) and does not require publication of an RFC or specification.
Instead of saying yes or no to formal applications, the registrar now just checks if the number is free and approves it. It takes minutes instead of months.
§3Impact on Network Monitoring
This change makes BMP more useful for proprietary and experimental extensions. Organizations can now quickly reserve code points for their own monitoring probes or for features still in development. The lower bar for registration is balanced by keeping the highest ranges (Standards Action) for features that must be widely interoperable.
Network teams can now try new monitoring ideas without waiting for approval committees. When an idea proves useful, it can still be formalized later.