]> Cisco Systems, Inc.

tsaad@cisco.com

Cisco Systems, Inc.

snprasad@cisco.com

Network Working Group Internet-Draft 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.

Introduction The BGP Monitoring Protocol (BMP) defines means to access and monitor multiple Routing Information Base (RIB) views on per peer of a router. and define mechanisms to export the pre and post policy views of the (Adj-RIB-In and Adj-RIB-Out), while 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.

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 when, and only when, they appear in all capitals, as shown here. The terminology for describing YANG data models is found in .

Per-Peer Header The per-peer header was initially defined . It includes a set of flags that are defined in and . 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:

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.

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 with no withdrawn routes similar to the End-of-RIB marker in Section 2 of . For other BMP messages that contain the per-peer header, the P flag MUST be set to 0.

Security Considerations The considerations in Section 11 of 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.

IANA Considerations IANA has assigned the following new parameters to the "BGP Monitoring Protocol (BMP) Parameters" registry (https://www.iana.org/assignments/bmp-parameters/).

Addition to BMP Peer Flags Registry IANA is requested to assign a new flag to the "Per-Peer Header Flags" registry as follow:

This document defines the BGP Monitoring Protocol (BMP), which can be used to monitor BGP sessions. BMP is intended to provide a convenient interface for obtaining route views. Prior to the introduction of BMP, screen scraping was the most commonly used approach to obtaining such views. The design goals are to keep BMP simple, useful, easily implemented, and minimally service affecting. BMP is not suitable for use as a routing protocol. The BGP Monitoring Protocol (BMP) only defines access to the Adj-RIB-In Routing Information Bases (RIBs). This document updates BMP (RFC 7854) by adding access to the Adj-RIB-Out RIBs. It also adds a new flag to the peer header to distinguish between Adj-RIB-In and Adj-RIB-Out. The BGP Monitoring Protocol (BMP) defines access to local Routing Information Bases (RIBs). This document updates BMP (RFC 7854) by adding access to the Local Routing Information Base (Loc-RIB), as defined in RFC 4271. The Loc-RIB contains the routes that have been selected by the local BGP speaker's Decision Process. In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. YANG is a data modeling language used to model configuration data, state data, Remote Procedure Calls, and notifications for network management protocols. This document describes the syntax and semantics of version 1.1 of the YANG language. YANG version 1.1 is a maintenance release of the YANG language, addressing ambiguities and defects in the original specification. There are a small number of backward incompatibilities from YANG version 1. This document also specifies the YANG mappings to the Network Configuration Protocol (NETCONF). This document defines extensions to BGP-4 to enable it to carry routing information for multiple Network Layer protocols (e.g., IPv6, IPX, etc...). [STANDARDS-TRACK] This document describes a mechanism for BGP that would help minimize the negative effects on routing caused by BGP restart. An End-of-RIB marker is specified and can be used to convey routing convergence information. A new BGP capability, termed "Graceful Restart Capability", is defined that would allow a BGP speaker to express its ability to preserve forwarding state during BGP restart. Finally, procedures are outlined for temporarily retaining routing information across a TCP session termination/re-establishment. The mechanisms described in this document are applicable to all routers, both those with the ability to preserve forwarding state during BGP restart and those without (although the latter need to implement only a subset of the mechanisms described in this document). [STANDARDS-TRACK]