Common BMP Route-Monitoring Messages for Routes Unchanged by Policy

1.1. BMP Convergence

The monitored routers may have policies that modify none, some or several attributes of prefixes learnt from a few to many BGP peers. For example, a Route Reflector Inbound policy may modify very few of the received attributes. Whereas, a Provider Edge router Inbound policy may modify more attributes in the prefixes learnt across several peers. Consider a monitored router that learns 1,000,000 prefixes from various peers and, in different cases, 100%, 50%, 10% and none of the prefixes are modified by the policies. For the sake of simplicity, consider that 10 prefixes are packed in a single Route-Monitoring message and the average size of Route-Monitoring messages is 200 bytes. The following illustration shows the number of Route-Monitoring messages sent in each of these cases.¶

While there can be multidimentional variations that determine the number of messages sent, the above simplified cases broadly illustrates that the number or Route-Monitoring messages can be reduced by a factor of two in the best case. This can therefore reduce the transmission processing, number of transmit buffers required for sending the BMP updates and internal queuing delays in the monitored router and load on the network connecting to the monitoring station; thereby improving the overall BMP convergence. This can also reduce the number of messages processed by the monitoring station.¶

1.2. Solution

To avoid sending duplicate unmodified routes in the Post-Policy Route-Monitoring messages, we introduce in this document two alternate methods based on:¶

• Common Update Flag, or C flag, in the Per-Peer header¶
• Common Update TLV based on [I-D.ietf-grow-bmp-tlv]¶

When the Monitored Router does not have TLV support as defined by [I-D.ietf-grow-bmp-tlv], the method using the Common Update Flag MAY be used. When the Monitored Router does support TLV, either of the two methods MAY be used. However, it is to be noted that the two methods are mutually exclusive.¶

3.1. Examples of the Common Update TLV

• When I=1, J=1, O=0, P=0 it indicates that the BGP Update PDU is the same for Pre-Policy and Post-Policy Adj-RIB-In views.¶
• When I=0, J=0, O=1, P=1 it indicates that the BGP Update PDU is the same for Pre-Policy and Post-Policy Adj-RIB-Out views.¶

The following examples demonstrate sharing across Adj-RIB-In and Adj-RIB-Out views as well, but we anticipate this not to be used¶

• When I=0, J=1, O=1, P=0 it indicates that the BGP Update PDU is the same for Post-Policy Adj-RIB-In and Pre-Policy Adj-RIB-Out views.¶
• When I=0, J=1, O=1, P=1 it indicates that the BGP Update PDU is the same for Post-Policy Adj-RIB-In, and Pre-Policy and Post-Policy Adj-RIB-Out views.¶

4.1. Route Monitoring

The C flag as well as the Common Update TLV are of relevance only in Adj-RIB-In and Adj-RIB-Out Route-Monitoring messages. They are of no relevance in Loc-RIB Route-Monitoring messages.¶

The C flag and the Common Update TLV are mutually exclusive. If a Route-Monitoring message has C flag set to 1 and includes the Common Update TLV:¶

• If an implementation supports C flag and Common Update TLV, the C flag value SHOULD be ignored and the value of Common Update TLV SHOULD be considered.¶
• If an implementation only supports C flag but not the Common Update TLV, the Common Update TLV value SHOULD be ignored, and the C flag value MUST be considered.¶
• If an implementation only supports Common Update TLV and not the C flag, C flag value SHOULD be ignored and Common Update TLV value MUST be considered.¶

4.2. Statistics Report

This document defines new statistics types that use the following bitmap which is used to indicate a combination of Route-Monitoring views for which routes are the same, i.e. unmodified by policy.¶

          +-+-+-+-+-+-+-+-+
          |I|J|O|P|  Resv |
          +-+-+-+-+-+-+-+-+

• I bit - Pre-Policy Adj-RIB-In¶
• J bit - Post-Policy Adj-RIB-In¶
• O bit - Pre-Policy Adj-RIB-Out¶
• P bit - Post-Policy Adj-RIB-Out¶
• The remaining bits are reserved for future use. They MUST be transmitted as 0 and their values MUST be ignored on receipt.¶

The following new statistics types are defined.¶

• Stat Type = TBD3: Number of routes common across a combination of Route-Monitoring views. The value is structured as follows: Bitmap of Route-Monitoring views, Number of routes (64-bit Gauge) common between the views indicated by the bitmap. Multiple instances of this statistics type MAY be included in the same Statistics Report message, each for a unique value of the bitmap.¶
• Stat Type = TBD4: Number of routes common across a combination of Route-Monitoring views per-AFI/SAFI. The value is structured as follows: 2-byte Address Family Identifier (AFI), 1-byte Subsequent Address Family Identifier (SAFI), Bitmap of Route-Monitoring views, Number of routes (64-bit Gauge) common between the views indicated by the bitmap. Multiple instances of this statistics type MAY be included in the same Statistics Report message, each for a unique value of AFI/SAFI and the bitmap.¶

5.1. Addition to BMP Peer Flags Registry

IANA needs to make the following assignment for the per-peer header flag defined in Section 2 of this document:¶

5.2. Addition to BMP Route Monitoring TLVs

IANA needs to make the following assignment for the "Common Update TLV" in the "BMP Route Monitoring TLVs" registry.¶

Type = TBD2 (15 Bits): Common Update TLV¶

5.3. Additions to BMP Statistics Types Registry

IANA needs to make the following assignment for the statistics types defined in Section 4.2 of this document:¶