Common BMP Route-Monitoring Messages for Routes Unchanged by Policy

Internet-Draft	Common BMP Messages	March 2024
Patki & Narasimha	Expires 22 September 2024	[Page]

Abstract

[RFC7854] and [RFC8671] define Pre-Policy Adj-RIB-In, Post-Policy Adj-RIB-In, Pre-Policy Adj-RIB-Out and Post-Policy Adj-RIB-Out Route-Monitoring messages. A route unmodified by the inbound policy is included both in Pre-Policy Adj-RIB-In as well as Post-Policy Adj-RIB-In Route-Monitoring messages when both the Pre-Policy and Post-Policy Route-Monitoring modes are enabled. Similarly, a route unmodified by the outbound policy is included in Pre-Policy Adj-RIB-Out as well as Post-Policy Adj-RIB-Out Route-Monitoring messages. To avoid duplicate inclusion of routes unmodified by policy either in Adj-RIB-In or Adj-RIB-Out this document defines two methods.¶

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 22 September 2024.¶

Copyright Notice

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

1. Introduction

[RFC7854] defined Pre-Policy and Post-Policy Adj-RIB-In Route-Monitoring messages, whereas [RFC8671] 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 reduce the number of Route-Monitoring messages sent up to 2 times in the best case when policy does not modify any of the routes. The exact reduction in number of messages depends on the policy being used. The higher number of Route-monitoring messages impacts the performance/convergence of BMP and increases the load on the transport layers and the network connecting to the BMP server. Reducing this will aid in improving the BGP, BMP and network performance and scalability.¶

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

1.1. Requirements Language

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 [RFC2119].¶

2. Common Update Flag in Peer Flags

The per-peer header has the same structure and flags as defined in Section 4 of [RFC8671] with the addition of the C flag in the Peer Flags in the Per-Peer Header as shown here.¶

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

The C flag, when set to 0, indicates that the BGP Update PDU that follows the common BMP header and per-peer header in the Route-Monitoring message reflects either the Pre-Policy or the Post-Policy view as indicated by the L flag.¶
The C flag, when set to 1, indicates that the BGP Update PDU that follows the common BMP header and per-peer header in the Route-Monitoring message is the same for Pre-Policy and Post-Policy views. The C flag and the L flag are mutually exclusive. When the C flag is set to 1, the L flag has no significance and MUST be transmitted as 0 and its value MUST be ignored on receipt.¶
If the C flag is set to 1 and the O flag is set to 0, then it indicates that the BGP Update PDU reflects the Adj-RIB-In route which is the same for both Pre-Policy and Post-Policy views.¶
If the C flag is set to 1 and the O flag is set to 1, then it indicates that the BGP Update PDU reflects the Adj-RIB-Out route which is the same for both Pre-Policy and Post-Policy views.¶

Note that the C flag can be used only if the BGP Update PDU is common between Pre-Policy and Post-Policy Adj-RIB-In or Pre-Policy and Post-Policy Adj-RIB-Out. It does not allow for indicating a BGP Update PDU that is common between Adj-RIB-In and Adj-RIB-Out.¶

3. Common Update TLV

Here we define a new TLV named Common Update TLV using the TLV construct defined in Section 4.2 of [I-D.ietf-grow-bmp-tlv] as an alternative to C flag method proposed above. 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 like the Common Update Flag method, this method is extensible in allowing sharing across Adj-RIB-In and Adj-R-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 TLC defines flags that are described below.¶

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

Figure 1: Common Update TLV

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

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. BMP Messages

Since the C flag is used in the context of BGP Update PDU, it 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 C flag has no significance. In all messages except the Route-Monitoring message, the C flag MUST be set to 0 in the per-peer header during transmission and MUST be ignored on reception.¶

Similarly, the Common Update TLV MUST not be included in the above listed BMP messages during transmission and MUST be ignored if found on reception.¶

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 |
          +-+-+-+-+-+-+-+-+

Figure 2: Bitmap of Route-Monitoring views

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. IANA Considerations

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

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

Table 1: Addition to the "BMP Peer Flags" Registry
Flag	Description
TBD1	C flag

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

Table 2: Additions to the "BMP Statistics Types" Registry
Stat Type	Description
TBD3	Number of routes common across a combination of Route-Monitoring views.
TBD4	Number of routes common across a combination of Route-Monitoring views per-AFI/SAFI.

8. Normative References

[RFC2119]: Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC7854]: Scudder, J., Ed., Fernando, R., and S. Stuart, "BGP Monitoring Protocol (BMP)", RFC 7854, DOI 10.17487/RFC7854, June 2016, <https://www.rfc-editor.org/info/rfc7854>.
[RFC8671]: Evens, T., Bayraktar, S., Lucente, P., Mi, P., and S. Zhuang, "Support for Adj-RIB-Out in the BGP Monitoring Protocol (BMP)", RFC 8671, DOI 10.17487/RFC8671, November 2019, <https://www.rfc-editor.org/info/rfc8671>.
[I-D.ietf-grow-bmp-tlv]: Lucente, P. and Y. Gu, "BMP v4: TLV support for BMP Route Monitoring and Peer Down Messages", Work in Progress, Internet-Draft, draft-ietf-grow-bmp-tlv-13, 23 October 2023, <https://datatracker.ietf.org/doc/html/draft-ietf-grow-bmp-tlv-13>.