Network Working Group T. Saad
Internet-Draft P. Narasimha
Intended status: Standards Track Cisco Systems, Inc.
Expires: 30 August 2025 26 February 2025
Support for BMP RIB Purge Notification
draft-spd-grow-bmp-purge-00
Abstract
This document describes a mechanism to notify a BMP collector of the
need to purge the state associated with a RIB view of a specific
peer. This is useful, for example, when the BMP sender decides to
stop exporting a specific RIB view after providing an initial export.
The BMP collector can use the per-peer Purge message to take
appropriate action to remove the stale state and avoid holding on to
irrelevant network data.
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 30 August 2025.
Copyright Notice
Copyright (c) 2025 IETF Trust and the persons identified as the
document authors. All rights reserved.
Saad & Narasimha Expires 30 August 2025 [Page 1]
Internet-Draft BMP RIB Purge Notification February 2025
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
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
2. Per-Peer Header . . . . . . . . . . . . . . . . . . . . . . . 3
3. BMP Messages . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Security Considerations . . . . . . . . . . . . . . . . . . . 4
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4
5.1. Addition to BMP Peer Flags Registry . . . . . . . . . . . 4
6. Normative References . . . . . . . . . . . . . . . . . . . . 5
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6
1. Introduction
The BGP Monitoring Protocol (BMP) defines means to access and monitor
multiple Routing Information Base (RIB) views on per peer of a
router. [RFC7854] and [RFC8671] define mechanisms to export the pre
and post policy views of the (Adj-RIB-In and Adj-RIB-Out), while
[RFC9069] defines the mechanisms to access the Loc-RIB view.
The BMP sender (e.g. router) uses the flags present in the Per-Peer
Header of the BMP message to distinguish whether the BMP updates are
for the pre-policy or post-policy of the Adj-RIB-In, or Adj-RIB-Out
views. For the Loc-RIB updates, the BMP sender uses the Peer Type
field in the BMP Peer Header to indicate updates are for the Loc-RIB
view.
Saad & Narasimha Expires 30 August 2025 [Page 2]
Internet-Draft BMP RIB Purge Notification February 2025
A BMP sender can stop exporting a RIB view to a BMP collector at any
time after the initial export. For example, the BMP sender might
decide to halt the export of the Adj-RIB-Out view of a specific peer
to the BMP collector due to a policy or configuration change.
Currently, the BMP collector is not informed about these changes in
the RIB view export policy and continues to maintain the stale state,
which may no longer be relevant to the current network situation. To
address this, the BMP sender can terminate and restart the BMP
session, prompting the BMP collector to rebuild the BMP RIB views
based on the new policies. However, doing so each time such changes
occur may be undesirable or impractical, especially in high-scale
environments, where rebuilding the BMP views after a session restart
could take several minutes.
This document defines a new flag from the per peer header flags that
is used in a BMP message to notify the BMP collector to purge any
previously exported state for a specific RIB view of a peer. The BMP
sender can use the per peer Purge notification at anytime after the
BMP session is established to purge any previously stored state for
the specific peer and RIB view.
This document introduces a new flag within the per-peer header flags
to be used in a BMP message to notify the BMP collector to purge any
previously exported state for a RIB view of a peer. The BMP sender
can utilize the per-peer Purge notification message at any time after
the BMP session is established to remove the previously stored state
for the specific peer and RIB view on the BMP collector.
1.1. Terminology
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.
The terminology for describing YANG data models is found in
[RFC7950].
2. Per-Peer Header
The per-peer header was initially defined [RFC7854]. It includes a
set of flags that are defined in [RFC7854] and [RFC8671].
This document extends the per-peer header to include a new flag, the
P flag, to indicate that the BMP sender is requesting the BMP
collector to purge the state associated with the specific RIB view of
the peer. The P flag is defined as follows:
Saad & Narasimha Expires 30 August 2025 [Page 3]
Internet-Draft BMP RIB Purge Notification February 2025
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|V|L|A|O|P|Resv |
+-+-+-+-+-+-+-+-+
Figure 1: The BMP per-peer header flags.
* The P flag, when set, indicates that a purge is requested for the
specific RIB view of the peer. In combination with the O and L
flags, the BMP collector can determine which RIB view is being
purged.
The remaining bits are reserved for future use and MUST be set to 0
by the BMP sender and ignored by the BMP collector.
3. BMP Messages
The per-peer header follows the common header for most BMP messages.
A Purge BMP message is a BMP Route Monitoring or Route Mirroring
message that has the P flag set in the per-peer header. The Purge
message MUST only contain the MP_UNREACH_NLRI attribute [RFC2858]
with no withdrawn routes similar to the End-of-RIB marker in
Section 2 of [RFC4724].
For other BMP messages that contain the per-peer header, the P flag
MUST be set to 0.
4. Security Considerations
The considerations in Section 11 of [RFC7854] apply to this document.
Implementations of this protocol SHOULD require establishing sessions
with authorized and trusted monitoring devices. It is also believed
that this document does not add any additional security
considerations.
5. IANA Considerations
IANA has assigned the following new parameters to the "BGP Monitoring
Protocol (BMP) Parameters" registry
(https://www.iana.org/assignments/bmp-parameters/).
5.1. Addition to BMP Peer Flags Registry
IANA is requested to assign a new flag to the "Per-Peer Header Flags"
registry as follow:
Saad & Narasimha Expires 30 August 2025 [Page 4]
Internet-Draft BMP RIB Purge Notification February 2025
+------+-------------+---------------+
| Flag | Description | Reference |
+======+=============+===============+
| 4 | P flag | this document |
+------+-------------+---------------+
Table 1: Addition to the "BMP Peer Flags" Registry
6. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC2858] Bates, T., Rekhter, Y., Chandra, R., and D. Katz,
"Multiprotocol Extensions for BGP-4", RFC 2858,
DOI 10.17487/RFC2858, June 2000,
<https://www.rfc-editor.org/info/rfc2858>.
[RFC4724] Sangli, S., Chen, E., Fernando, R., Scudder, J., and Y.
Rekhter, "Graceful Restart Mechanism for BGP", RFC 4724,
DOI 10.17487/RFC4724, January 2007,
<https://www.rfc-editor.org/info/rfc4724>.
[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>.
[RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language",
RFC 7950, DOI 10.17487/RFC7950, August 2016,
<https://www.rfc-editor.org/info/rfc7950>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8671] Evens, T., Bayraktar, S., Lucente, P., Mi, P., and S.
Zhuang, "Support for Adj-RIB-Out in the BGP Monitoring
Protocol (BMP)", RFC 8671, DOI 10.17487/RFC8671, November
2019, <https://www.rfc-editor.org/info/rfc8671>.
[RFC9069] Evens, T., Bayraktar, S., Bhardwaj, M., and P. Lucente,
"Support for Local RIB in the BGP Monitoring Protocol
(BMP)", RFC 9069, DOI 10.17487/RFC9069, February 2022,
<https://www.rfc-editor.org/info/rfc9069>.
Saad & Narasimha Expires 30 August 2025 [Page 5]
Internet-Draft BMP RIB Purge Notification February 2025
Authors' Addresses
Tarek Saad
Cisco Systems, Inc.
Email: tsaad@cisco.com
Prasad S. Narasimha
Cisco Systems, Inc.
Email: snprasad@cisco.com
Saad & Narasimha Expires 30 August 2025 [Page 6]