Common BMP Route-Monitoring Messages for Routes Unchanged by Policy

defined Pre-Policy and Post-Policy Adj-RIB-In Route-Monitoring messages, whereas defined Pre-Policy and Post-Policy Adj-RIB-Out Route-Monitoring messages. If both Pre-Policy and Post-Policy Route-Monitoring modes are enabled on a device for a RIB (Adj-RIB-In or Adj-RIB-Out), the routes are included in both Pre-Policy and Post-Policy Route-Monitoring messages, even if the routes remains unmodified as a result of the application of policy. The optimization proposed in this document will help improve the BMP convergence as described in the section below.

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. Route-Monitoring messages generated for inbound policy variations

Prefixes modified by inbound policy	Pre-Policy Messages	Post-Policy Messages	Common Messages	Total Messages Transmitted	Total Bytes Transmitted
100% = 1,000,000	100,000	100,000	0	200,000	40 MB
50% = 500,000	50,000	50,000	50,000	150,000	30 MB
10% = 100,000	10,000	10,000	90,000	110,000	22 MB
None	0	0	100,000	100,000	20 MB

While there can be multi-dimensional 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.

To avoid sending duplicate unmodified routes in the Post-Policy Route-Monitoring messages, we introduce in this document a method based on Common Update TLV as defined in .

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in .

Here we define a new TLV named Common Update TLV using the TLV construct defined in . In addition to allowing sharing a common BGP Update PDU between Pre-Policy and Post-Policy modes of Adj-RIB-In and the same for Adj-RIB-Out, this method is extensible in allowing sharing across Adj-RIB-In and Adj-RIB-Out views, though we see it being used rarely. The TLV has Index zero (0) which specifies that a TLV applies to all NLRIs contained in the BGP Update PDU. The value of the TLV defines flags that are described below.

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type=TBD1 | Length = 3 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Index=0 |I|J|O|P| Resv | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

When I flag is set, it indicates that the BGP Update PDU reflects the Pre-Policy Adj-RIB-In view of all contained NLRIs
When J flag is set, it indicates that the BGP Update PDU reflects the Post-Policy Adj-RIB-In view of all contained NLRIs
When O flag is set, it indicates that the BGP Update PDU reflects the Pre-Policy Adj-RIB-Out view of all contained NLRIs
When P flag is set, it indicates that the BGP Update PDU reflects the Post-Policy Adj-RIB-Out view of all contained NLRIs
The remaining bits are reserved for future use. They MUST be transmitted as 0 and their values MUST be ignored on receipt.

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.

The Common Update TLV is used in the context of BGP Update PDU, and has no significance for Peer-Up, Peer-Down, Initiation, Termination and Statistics Report messages. Though the Route Mirroring message contains a BGP Update PDU, as there is no policy execution involved in its transmission, the Common Update TLV has no significance. In all messages except the Route-Monitoring message, the Common Update TLV MUST NOT be included during transmission and MUST be ignored if found on reception.

The Common Update TLV is of relevance only in the Adj-RIB-In and Adj-RIB-Out Route-Monitoring messages and not in the Loc-RIB Route-Monitoring messages. A Route-Monitoring Update message containing the Common Update TLV MAY also include Adj-In Time and Adj-Out Time Timestamp TLVs defined in . The Adj-In Timestamp TLV MUST NOT be included if the Common Update TLV does not have I flag or J flag set, and, the Adj-Out Timestamp TLV MUST NOT be included if the Common Update TLV does not have O flag or P flag set. If included, the same must be ignored by the receiver.

The Common Update TLV can also be used in the Aggregated BMP Route-Monitoring Message defined in . This TLV is of relevance only in the Adj-RIB-In and Adj-RIB-Out Aggregated Route-Monitoring messages and not in the Loc-RIB Aggregated Route-Monitoring messages. An Aggregated Route-Monitoring Update message containing the Common Update TLV MAY also include Adj-In Time and Adj-Out Time Timestamp TLVs defined in . The Adj-In Timestamp TLV MUST NOT be included if the Common Update TLV does not have I flag or J flag set, and, the Adj-Out Timestamp TLV MUST NOT be included if the Common Update TLV does not have O flag or P flag set. If included, the same must be ignored by the receiver.

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 = TBD2: 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 = TBD3: 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.

IANA needs to assign the following new parameters to the "BGP Monitoring Protocol (BMP) Parameters" registry.

IANA needs to make the following assignment for the "Common Update TLV" in the "BMP Route Monitoring TLVs" registry. Type = TBD1 (15 Bits): Common Update TLV

IANA needs to make the following assignment for the statistics types defined in of this document: Additions to the "BMP Statistics Types" Registry

Stat Type	Description
TBD2	Number of routes common across a combination of Route-Monitoring views.
TBD3	Number of routes common across a combination of Route-Monitoring views per-AFI/SAFI.

This document does not add any additional security considerations. The considerations in apply to this document.

TBD