GROW D. Patki
Internet-Draft P. Narasimha
Intended status: Standards Track Cisco Systems, Inc.
Expires: 28 August 2025 24 February 2025
Common BMP Route-Monitoring Messages for Routes Unchanged by Policy
draft-patki-grow-bmp-common-updates-01
Abstract
A route unmodified by the inbound policy on a monitored router 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.
This document defines methods to avoid duplicate inclusion of routes
unmodified by policy either in Adj-RIB-In or Adj-RIB-Out.
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 28 August 2025.
Copyright Notice
Copyright (c) 2025 IETF Trust and the persons identified as the
document authors. All rights reserved.
Patki & Narasimha Expires 28 August 2025 [Page 1]
Internet-Draft Common BMP Messages February 2025
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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. BMP Convergence . . . . . . . . . . . . . . . . . . . . . 3
1.2. Solution . . . . . . . . . . . . . . . . . . . . . . . . 4
1.3. Requirements Language . . . . . . . . . . . . . . . . . . 4
2. Common Update Flag in Peer Flags . . . . . . . . . . . . . . 4
3. Common Update TLV . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Examples of the Common Update TLV . . . . . . . . . . . . 6
4. BMP Messages . . . . . . . . . . . . . . . . . . . . . . . . 6
4.1. Route Monitoring . . . . . . . . . . . . . . . . . . . . 6
4.2. Statistics Report . . . . . . . . . . . . . . . . . . . . 7
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
5.1. Addition to BMP Peer Flags Registry . . . . . . . . . . . 8
5.2. Addition to BMP Route Monitoring TLVs . . . . . . . . . . 8
5.3. Additions to BMP Statistics Types Registry . . . . . . . 8
6. Security Considerations . . . . . . . . . . . . . . . . . . . 9
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9
8. Normative References . . . . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9
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 improve the BMP
convergence as described in the section below.
Patki & Narasimha Expires 28 August 2025 [Page 2]
Internet-Draft Common BMP Messages February 2025
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.
+==========+==========+===========+========+===========+===========+
| Prefixes |Pre-Policy|Post-Policy| Common | Total |Total Bytes|
| modified | Messages | Messages |Messages| Messages |Transmitted|
|by inbound| | | |Transmitted| |
| policy | | | | | |
+==========+==========+===========+========+===========+===========+
|100% = | 100,000 | 100,000 | 0 | 200,000 | 40 MB |
|1,000,000 | | | | | |
+----------+----------+-----------+--------+-----------+-----------+
|50% = | 50,000 | 50,000 | 50,000 | 150,000 | 30 MB |
|500,000 | | | | | |
+----------+----------+-----------+--------+-----------+-----------+
|10% = | 10,000 | 10,000 | 90,000 | 110,000 | 22 MB |
|100,000 | | | | | |
+----------+----------+-----------+--------+-----------+-----------+
|None | 0 | 0 |100,000 | 100,000 | 20 MB |
+----------+----------+-----------+--------+-----------+-----------+
Table 1: Route-Monitoring messages generated for inbound policy
variations
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.
Patki & Narasimha Expires 28 August 2025 [Page 3]
Internet-Draft Common BMP Messages February 2025
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.
1.3. 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.
Patki & Narasimha Expires 28 August 2025 [Page 4]
Internet-Draft Common BMP Messages February 2025
* 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.
Patki & Narasimha Expires 28 August 2025 [Page 5]
Internet-Draft Common BMP Messages February 2025
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.
Patki & Narasimha Expires 28 August 2025 [Page 6]
Internet-Draft Common BMP Messages February 2025
* 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.
Patki & Narasimha Expires 28 August 2025 [Page 7]
Internet-Draft Common BMP Messages February 2025
5. IANA Considerations
IANA needs to assign the following new parameters to the "BGP
Monitoring Protocol (BMP) Parameters" registry
(https://www.iana.org/assignments/bmp-parameters/).
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:
+======+=============+
| Flag | Description |
+======+=============+
| TBD1 | C flag |
+------+-------------+
Table 2: Addition to
the "BMP Peer Flags"
Registry
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:
+===========+==============================================+
| 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. |
+-----------+----------------------------------------------+
Table 3: Additions to the "BMP Statistics Types" Registry
Patki & Narasimha Expires 28 August 2025 [Page 8]
Internet-Draft Common BMP Messages February 2025
6. Security Considerations
This document does not add any additional security considerations.
The considerations in Section 11 of [RFC7854] apply to this document.
7. Acknowledgements
TBD
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-15, 17 January
2025, <https://datatracker.ietf.org/doc/html/draft-ietf-
grow-bmp-tlv-15>.
Authors' Addresses
Dhananjay Patki
Cisco Systems, Inc.
Cessna Business Park SEZ, Kadubeesanahalli
Bangalore 560103
Karnataka
India
Email: dhpatki@cisco.com
Patki & Narasimha Expires 28 August 2025 [Page 9]
Internet-Draft Common BMP Messages February 2025
Prasad S. Narasimha
Cisco Systems, Inc.
Cessna Business Park SEZ, Kadubeesanahalli
Bangalore 560103
Karnataka
India
Email: snprasad@cisco.com
Patki & Narasimha Expires 28 August 2025 [Page 10]