Support for BMP RIB Purge Notification

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.¶

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

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.¶

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.¶

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:¶

 0 1 2 3 4 5 6 7
 +-+-+-+-+-+-+-+-+
 |V|L|A|O|P|Resv |
 +-+-+-+-+-+-+-+-+

• 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/).¶

   +------+-------------+---------------+
   | Flag | Description | Reference     |
   +======+=============+===============+
   | 4    | P flag      | this document |
   +------+-------------+---------------+

    Table 1: Addition to the "BMP Peer Flags" Registry

Authors' Addresses