Common BMP Route-Monitoring Messages for Routes Unchanged by Policy
draft-patki-grow-bmp-common-updates-00

GROW                                                            D. Patki
Internet-Draft                                              P. Narasimha
Intended status: Standards Track                     Cisco Systems, Inc.
Expires: 22 September 2024                                 21 March 2024

  Common BMP Route-Monitoring Messages for Routes Unchanged by Policy
                 draft-patki-grow-bmp-common-updates-00

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

   Copyright (c) 2024 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

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

   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.  Requirements Language . . . . . . . . . . . . . . . . . .   3
   2.  Common Update Flag in Peer Flags  . . . . . . . . . . . . . .   3
   3.  Common Update TLV . . . . . . . . . . . . . . . . . . . . . .   4
     3.1.  Examples of the Common Update TLV . . . . . . . . . . . .   4
   4.  BMP Messages  . . . . . . . . . . . . . . . . . . . . . . . .   5
     4.1.  Route Monitoring  . . . . . . . . . . . . . . . . . . . .   5
     4.2.  Statistics Report . . . . . . . . . . . . . . . . . . . .   6
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   7
     5.1.  Addition to BMP Peer Flags Registry . . . . . . . . . . .   7
     5.2.  Addition to BMP Route Monitoring TLVs . . . . . . . . . .   7
     5.3.  Additions to BMP Statistics Types Registry  . . . . . . .   7
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .   8
   7.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   8
   8.  Normative References  . . . . . . . . . . . . . . . . . . . .   8
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   8

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:

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

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

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

   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.

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

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

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

   *  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 22 September 2024               [Page 6]
Internet-Draft             Common BMP Messages                March 2024

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 1: 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 2: Additions to the "BMP Statistics Types" Registry

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

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-13, 23 October
              2023, <https://datatracker.ietf.org/doc/html/draft-ietf-
              grow-bmp-tlv-13>.

Authors' Addresses

   Dhananjay Patki
   Cisco Systems, Inc.
   Cessna Business Park SEZ, Kadubeesanahalli
   Bangalore 560103
   Karnataka
   India
   Email: dhpatki@cisco.com

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

   Prasad S. Narasimha
   Cisco Systems, Inc.
   Cessna Business Park SEZ, Kadubeesanahalli
   Bangalore 560103
   Karnataka
   India
   Email: snprasad@cisco.com

Patki & Narasimha       Expires 22 September 2024               [Page 9]