| Internet-Draft | BMP Sync Mechanism | March 2025 |
| Geng & Zhuang | Expires 4 September 2025 | [Page] |
This document proposes methods to facilitate correction of BGP Routing Information Base inconsistencies in a non-disruptive manner from the BMP Sender to the BMP Collector.¶
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 4 September 2025.¶
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.¶
The generation of BGP Adj-RIB-In, Loc-RIB and Adj-RIB-Out comes from BGP route exchange and route policy processing. BGP Monitoring Protocol (BMP) provides the monitoring of BGP Adj-RIB-In [RFC7854], BGP Loc-RIB [RFC9069] and BGP Adj-RIB-Out [RFC8671]. The RIB view inconsistency may occur between the BMP sender and BMP collector due to message loss, network flapping, instability, and faults. In this document, we define methods to facilitate correction of BGP Routing Information Base (RIB) inconsistencies in a non-disruptive manner from the BMP Sender to the BMP Collector.¶
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.¶
This document defines a new BMP Route-Refresh message type (TBD1) that is used to synchronize the RIB view from the BMP sender to the BMP collector. Following the common BMP header and per-peer header is a Route-Refresh PDU. The Route-Refresh PDU is a ROUTE-REFRESH message defined in [RFC2918] and updated by [RFC7313], and its format is as follows:¶
Type: 5 - ROUTE-REFRESH¶
Message Format: One <AFI, Sub-Type, SAFI> tuple encoded as:¶
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AFI | Sub-Type | SAFI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The meaning, usage, and encoding of this <AFI, Sub-Type, SAFI> tuple are defined in [RFC2918] and updated by [RFC7313] as follows:¶
AFI - Address Family Identifier (2 octets)¶
Sub-Type - Message Subtype (1 octet):¶
SAFI - Subsequent Address Family Identifier (1 octet).¶
The sequences of BMP messages transmissions shown as follows:¶
BMP Sender BMP Collector
~ ~
| ------- BMP BoRR ---------> | Sender notifies BoRR operation
| |
| | Collector marks the routes of
| | the specific RIB view as
| | stale/historical or purges
| | them directly
| |
| ------- BMP RM Msg.-------> | Sender sends zero or more
| --------........----------> | Route Monitoring Messages for
| ------- BMP RM Msg.-------> | the specific RIB view
| | Collector uses the new routes
| | to update the stale/historical
| | routes
| ------- BMP EoRR ---------> | Sender notifies EoRR operation
| |
| | Collector purges the routes
| | remaining the stale/historical
| | state
| |
~ ~
This document defines a new Monitoring Options (MO) message type (TBD2) that is used to synchronize the monitoring options from the BMP sender to BMP collector. Following the common BMP header and per-peer header is a BMP Monitoring Options PDU. The BMP Monitoring Options PDU is defined as follows:¶
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | SubType | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flags | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI1 | Res. | SAFI1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI2 | Res. | SAFI2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ...... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFIn | Res. | SAFIn | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Where:¶
Type - 2 octets, It indicates as follows:¶
SubType - 2 octets, It indicates as follows:¶
Flags - 2 octets, the least significant bit of Flags Indicates whether the options are enabled or disabled, and other bits are reserved.¶
Length - 2 octets¶
The list of (AFI, SAFI) follows the Length field.¶
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flags | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Stat Type 1 | Stat Type 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ...... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Stat Type n-1 | Stat Type n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Where:¶
Type - 2 octets, It indicates as follows:¶
4 - Stats¶
Flags - 2 octets, the least significant bit of Flags Indicates whether the options are enabled or disabled, and other bits are reserved.¶
Length - 2 octets¶
The list of Stat Types follows the Length field.¶
In the following scenario, a BGP session is established between Router1 and Router2, and IPv4 unicast, IPv4 multicast, and IPv4 labeled unicast address families are enabled on both the BGP speakers. The two BGP speakers exchange IPv4 unicast, IPv4 multicast, and IPv4 labeled unicast address family routes. Router1 as the BMP Sender sends BMP messages to the BMP Collector.¶
BMP Collector
|
|
| BGP Session
Router1(BMP Sender)----------------Router2
Sender initiates the BMP protocol with the Collector:¶
BMP Sender BMP Collector ~ ~ |------ Initial Export -------> | Sender Sends Route Monitoring | | messages for IPv4 unicast, | | IPv4 multicast and IPv4 | | labeled unicast address | | families | | Collector stores the RIB info | | for the Sender
Sender disabled the monitoring on IPv4 multicast address family:¶
BMP Sender BMP Collector |-MO with(AFI 1/SAFI 2) disable-| Sender sends an MO message | | to Collector | | Collector purges the IPv4 | | multicast RIB view of the | | specific BGP peer
Sender disabled the monitoring on IPv4 labeled unicast address family:¶
BMP Sender BMP Collector |-MO with(AFI 1/SAFI 4) disable-| Sender sends an MO message | | to Collector | | Collector purges the IPv4 | | labeled unicast RIB view | | of the specific BGP peer | |
Sender enabled the monitoring on IPv4 multicast address family:¶
BMP Sender BMP Collector |-MO with(AFI 1/SAFI 2) enabled-| Sender sends an MO message | | to Collector |-------BMP RM(AFI 1/SAFI 2)--> | Sender sends zero or more | | Route Monitoring Messages | | for theIPv4 multicast | | address family of the | | specific BGP peer | | Collector stores the RIB | | info for IPv4 multicast | | address family of the | | specific BGP peer
The same considerations as in Section 11 of [RFC7854] apply to this document. Implementations of this protocol SHOULD require that sessions only be established with authorized and trusted monitoring devices. It is also believed that this document does not introduce any additional security considerations.¶
The following people made significant contributions to this document:¶
To be added.¶
The authors would like to acknowledge the review and inputs from xxx.¶