Support for Adj-RIB-Out in the BGP Monitoring Protocol (BMP)
RFC 8671

Document Type RFC - Proposed Standard (November 2019; No errata)
Updates RFC 7854
Authors Tim Evens  , Serpil Bayraktar  , Paolo Lucente  , Kevin Mi , Shunwan Zhuang 
Last updated 2019-11-05
Replaces draft-evens-grow-bmp-adj-rib-out
Stream Internet Engineering Task Force (IETF)
Formats plain text html xml pdf htmlized (tools) htmlized bibtex
Stream WG state Submitted to IESG for Publication
Document shepherd Chris Morrow
Shepherd write-up Show (last changed 2019-05-30)
IESG IESG state RFC 8671 (Proposed Standard)
Action Holders
Consensus Boilerplate Yes
Telechat date
Responsible AD Warren Kumari
Send notices to Chris Morrow <>
IANA IANA review state Version Changed - Review Needed
IANA action state RFC-Ed-Ack

Internet Engineering Task Force (IETF)                          T. Evens
Request for Comments: 8671                                  S. Bayraktar
Updates: 7854                                              Cisco Systems
Category: Standards Track                                     P. Lucente
ISSN: 2070-1721                                       NTT Communications
                                                                   P. Mi
                                                               S. Zhuang
                                                           November 2019

      Support for Adj-RIB-Out in the BGP Monitoring Protocol (BMP)


   The BGP Monitoring Protocol (BMP) only defines access to the Adj-RIB-
   In Routing Information Bases (RIBs).  This document updates BMP (RFC
   7854) by adding access to the Adj-RIB-Out RIBs.  It also adds a new
   flag to the peer header to distinguish between Adj-RIB-In and Adj-

Status of This Memo

   This is an Internet Standards Track document.

   This document is a product of the Internet Engineering Task Force
   (IETF).  It represents the consensus of the IETF community.  It has
   received public review and has been approved for publication by the
   Internet Engineering Steering Group (IESG).  Further information on
   Internet Standards is available in Section 2 of RFC 7841.

   Information about the current status of this document, any errata,
   and how to provide feedback on it may be obtained at

Copyright Notice

   Copyright (c) 2019 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
   ( 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 Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction
   2.  Terminology
   3.  Definitions
   4.  Per-Peer Header
   5.  Adj-RIB-Out
     5.1.  Post-policy
     5.2.  Pre-policy
   6.  BMP Messages
     6.1.  Route Monitoring and Route Mirroring
     6.2.  Statistics Report
     6.3.  Peer Up and Down Notifications
       6.3.1.  Peer Up Information
   7.  Other Considerations
     7.1.  Peer and Update Groups
     7.2.  Changes to Existing BMP Session
   8.  Security Considerations
   9.  IANA Considerations
     9.1.  Addition to BMP Peer Flags Registry
     9.2.  Additions to BMP Statistics Types Registry
     9.3.  Addition to BMP Initiation Message TLVs Registry
   10. Normative References
   Authors' Addresses

1.  Introduction

   The BGP Monitoring Protocol (BMP) defines monitoring of the received
   (e.g., Adj-RIB-In) Routing Information Bases (RIBs) per peer.  The
   pre-policy Adj-RIB-In conveys to a BMP receiver all RIB data before
   any policy has been applied.  The post-policy Adj-RIB-In conveys to a
   BMP receiver all RIB data after policy filters and/or modifications
   have been applied.  An example of pre-policy versus post-policy is
   when an inbound policy applies attribute modification or filters.
   Pre-policy would contain information prior to the inbound policy
   changes or filters of data.  Post-policy would convey the changed
   data or would not contain the filtered data.

   Monitoring the received updates that the router received before any
   policy has been applied is the primary level of monitoring for most
   use cases.  Inbound policy validation and auditing are the primary
   use cases for enabling post-policy monitoring.

   In order for a BMP receiver to receive any BGP data, the BMP sender
   (e.g., router) needs to have an established BGP peering session and
   actively be receiving updates for an Adj-RIB-In.

   Being able to only monitor the Adj-RIB-In puts a restriction on what
   data is available to BMP receivers via BMP senders (e.g., routers).
   This is an issue when the receiving end of the BGP peer is not
   enabled for BMP or when it is not accessible for administrative
   reasons.  For example, a service provider advertises prefixes to a
   customer, but the service provider cannot see what it advertises via
   BMP.  Asking the customer to enable BMP and monitoring of the Adj-
   RIB-In are not feasible.

   BMP [RFC7854] only defines Adj-RIB-In being sent to BMP receivers.
   This document updates the per-peer header defined in Section 4.2 of
   [RFC7854] by adding a new flag to distinguish between Adj-RIB-In and
Show full document text