Logging of routing events in BGP Monitoring Protocol (BMP)
draft-ietf-grow-bmp-rel-01

Global Routing Operations                                     P. Lucente
Internet-Draft                                                C. Cardona
Updates: 7854 (if approved)                                          NTT
Intended status: Standards Track                           18 March 2024
Expires: 19 September 2024

       Logging of routing events in BGP Monitoring Protocol (BMP)
                       draft-ietf-grow-bmp-rel-01

Abstract

   The BGP Monitoring Protocol (BMP) does provision for BGP session
   event logging (Peer Up, Peer Down), state synchronization (Route
   Monitoring), debugging (Route Mirroring) and Statistics messages,
   among the others.  This document defines a new Route Event Logging
   (REL) message type for BMP with the aim of covering use-cases with
   affinity to alerting, reporting and on-change analysis.

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 19 September 2024.

Copyright Notice

   Copyright (c) 2024 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

Lucente & Cardona       Expires 19 September 2024               [Page 1]
Internet-Draft                   BMP REL                      March 2024

   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
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Route Event Logging (REL) message . . . . . . . . . . . . . .   3
     3.1.  Per-Peer Header . . . . . . . . . . . . . . . . . . . . .   4
     3.2.  BGP Update PDU  . . . . . . . . . . . . . . . . . . . . .   4
     3.3.  Informational TLVs  . . . . . . . . . . . . . . . . . . .   4
       3.3.1.  Event Reason TLV  . . . . . . . . . . . . . . . . . .   5
       3.3.2.  Policy Discard TLV  . . . . . . . . . . . . . . . . .   5
     3.4.  Group TLV . . . . . . . . . . . . . . . . . . . . . . . .   5
     3.5.  Stateless Parsing TLV . . . . . . . . . . . . . . . . . .   6
   4.  Operational Considerations  . . . . . . . . . . . . . . . . .   6
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .   6
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   6
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   6
   Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .   8
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   8

1.  Introduction

   As NLRIs are advertised and distributed, policies are applied and, as
   a result, actions are performed on them.  Currently, in order to
   infer the outcome of an evaluation process, a comparative analysis
   needs to be performed between Route Monitoring data for two distinct
   observation points of interest, for example Adj-Rib-In pre-policy and
   post-policy.  It would be instead more useful if a monitored router
   could export event-driven data with the relevant information.

   The envisioned use-cases are the most diverse and range from logging
   route filtering to reporting the outcome of validation processes
   taking place on the monitored router, to isolating certain subsets of
   data to be validated offline, to report malformed BGP packets, to
   broader closed-loop operations.

   Since no other existing BMP message type does fit the described
   purpose, this document defines a new Route Event Logging (REL)
   message type that is suitable to carry event-driven data and is
   extensible in nature.  While the message format is similar to the

Lucente & Cardona       Expires 19 September 2024               [Page 2]
Internet-Draft                   BMP REL                      March 2024

   Route Mirroring message type defined in RFC 7854 [RFC7854] and to the
   Route Monitoring message type as defined in TLV support for BMP Route
   Monitoring and Peer Down Messages [I-D.ietf-grow-bmp-tlv], the
   semantics are different.

2.  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in BCP
   14 RFC 2119 [RFC2119] RFC 8174 [RFC8174] when, and only when, they
   appear in all capitals, as shown here.

3.  Route Event Logging (REL) message

   In basic terms a REL message does carry Events.  Each Event is
   logically composed by one Event Subject and one or more Event
   Attributes.

   The structure of the Route Event Logging message is the same as the
   Route Monitoring message defined in TLV support for BMP Route
   Monitoring and Peer Down Messages [I-D.ietf-grow-bmp-tlv] where the
   Per-Peer Header is followed by a BGP Message TLV, one indexed
   Informational TLV and further optional indexed Informational TLVs.
   An example of such structure is available in Section 4.2.1.1 of
   [I-D.ietf-grow-bmp-tlv].

   One or more Event Subjects are packed as part of a BGP Update PDU.
   The BGP Update PDU Section 4.3 of [RFC4271] is encoded itself as part
   of a BGP Message TLV with code point TBD1 and index set to zero.
   Each Event Subject is represented by an NLRI carried in the PDU.

   The BGP Message TLV may be preceeded and/or followed by indexed
   Informational TLVs that carry Event Attributes, where attributes are
   bound to subjects referring to their positional index within the PDU
   or via a Group TLV as described in Section 4.2.1 of
   [I-D.ietf-grow-bmp-tlv]

   Speaking comparatively to other existing message types, REL does not
   require an initial flooding of information as per the state
   synchronization nature of Route Monitoring and does not aim to
   provide a non-state-compressed full-fidelity view of all messages
   received as per the debugging nature of Route Mirroring.

   In the context of BMP REL message, and hence in the reminder of this
   document, the term Event Subject and NLRI will be used
   interchangeably.  Also the term Event Attribute and Informational TLV
   will be used interchangeably.

Lucente & Cardona       Expires 19 September 2024               [Page 3]
Internet-Draft                   BMP REL                      March 2024

   The following sections will describe each component of the REL
   message in more detail.

3.1.  Per-Peer Header

   The message does start with a BMP per-peer header as defined in RFC
   7854 [RFC7854], subsequently extended by RFC 8671 [RFC8671] and RFC
   9069 [RFC9069] allowing, among the other things, to timestamp an
   Event and set its observation point among those defined in BMP.

   Because the main purpose of the REL message is to log events at the
   time of applying an action, the Peer Flags field - even if applied to
   Adj-Rib-In or Adj-Rib-Out does not have the concept of pre- and post-
   policy.  The flags are hence defined as follows:

                              0 1 2 3 4 5 6 7
                             +-+-+-+-+-+-+-+-+
                             |V|A| Reserved  |
                             +-+-+-+-+-+-+-+-+

   The V flag and A flag do carry the same meaning as originally defined
   by RFC 7854 [RFC7854].  The remaining bits are reserved for future
   use.  They MUST be transmitted as 0 and their values MUST be ignored
   on receipt.

3.2.  BGP Update PDU

   The PDU enclosed as part of a BGP Message TLV can be either a
   verbatim copy or artificial, either packed from scratch or repacked
   starting from an existing BGP Update PDU to only contain the relevant
   NLRIs affected by an Event (one or multiple).  The Event is going to
   be further described by means of Event Attributes by indexed
   Informational TLVs.

   The choice of describing one or multiple Event Subjects via a BGP
   Update PDU is because, on one hand, this does allow to not have to
   invent new encodings for NLRIs, while on the other, to support all
   types and encodings already supported by BGP.  The advantage being
   that only minimal new code, on both the exporting and the receiving
   sides, will have to be produced.

3.3.  Informational TLVs

   Informational TLVs in BMP are formalized by the intersection of RFC
   7854 [RFC7854], TLV support for BMP Route Monitoring and Peer Down
   Messages [I-D.ietf-grow-bmp-tlv] and Support for Enterprise- specific
   TLVs in the BGP Monitoring Protocol [I-D.ietf-grow-bmp-tlv-ebit].
   TLVs in a REL message are indexed.

Lucente & Cardona       Expires 19 September 2024               [Page 4]
Internet-Draft                   BMP REL                      March 2024

   Contrary to other BMP messages where all Informational TLVs are
   entirely optional, in order for a REL message to be meaningful, it
   MUST contain at least one Event Reason TLV and MAY contain other
   optional attribute TLVs to further characterize the Event.

   A new registry called "Route Event Logging TLVs" is defined and is
   seeded with the TLVs detailed in the following sections.

3.3.1.  Event Reason TLV

   TBD2 = Event Reason TLV (4 octets).  Indicates the IANA-registered
   reason code describing the type of the event.  The following reason
   codes are defined as part of the "Event Reason TLV" registry:

                     +--------+----------------------+
                     | Value  | Reason               |
                     +-------------------------------+
                     | 0x0000 | Unknown              |
                     | 0x0001 | Log Action           |
                     | 0x0002 | Policy Discard       |
                     | 0x0004 | Validation Fail      |
                     | 0x0008 | Malformed Packet     |
                     +--------+----------------------+

                          Table 1: Event Reason Codes

3.3.2.  Policy Discard TLV

   TBD3 = Policy Discard TLV.  The value contains a UTF-8 string whose
   value can be organized freely by an implementation.  For example, it
   may contain the routing policy name that caused the discard; or it
   may list a sequence of policies and policy nodes traversed; or, more
   simply, it could be a meaningful return code.

3.4.  Group TLV

   The Group TLV is to form N:M relationships among NLRIs in the BGP
   Update PDU and TLVs of the same Route Event Logging message.  This
   TLV has code point TBD4 and follows the definition of Group TLV in
   TLV support for BMP Route Monitoring and Peer Down Messages
   [I-D.ietf-grow-bmp-tlv].

Lucente & Cardona       Expires 19 September 2024               [Page 5]
Internet-Draft                   BMP REL                      March 2024

3.5.  Stateless Parsing TLV

   The Stateless Parsing TLV is to allow parsing of the BGP Update PDU
   independently from a Peer Up message previously received for the same
   BGP session.  This TLV can be especially relevant to Route Event
   Logging where the BGP Update PDU is artificial.  The TLV has code
   point TBD5 , it follows the definition of Stateless Parsing TLV in
   TLV support for BMP Route Monitoring and Peer Down Messages
   [I-D.ietf-grow-bmp-tlv] and uses code point definitions in the
   Stateless Parsing Registry.

4.  Operational Considerations

   Route Event Logging messages are event-driven in nature so the
   general recommendation is to use them to report on specific
   conditions of interest in order, for example, to facilitate data
   mining or avoid differential analysis.  When the objective is to
   annotate every received or announced NLRI then the recommendation is
   to use Route Monitoring messages with BMP Path Marking
   [I-D.ietf-grow-bmp-path-marking-tlv].  As an example consider RPKI
   validation status: when the objective is to report on any validations
   tatus (ie. valid, invalid and unknown), BMP Path Marking should be
   used; when the objective is instead to report only invalids then
   Route Event Logging with Validation Fail Event Reason should be used.

   There exist a definite overlap between Route Event Logging when used
   to report Malformed Packet and the use-cases for Route Mirroring
   where Errored PDUs may be sampled for reporting.  For an
   implementation that wants to implement broader event-driven
   notifications and does not want to offer exact mirroring of monitored
   BGP sessions without state compression it may be adviceable to prefer
   implementing Route Event Logging message type over Route Mirroring.

5.  Security Considerations

   It is not believed that this document adds any additional security
   considerations.

6.  IANA Considerations

   TBD

7.  References

   [I-D.ietf-grow-bmp-path-marking-tlv]
              Cardona, C., Lucente, P., Francois, P., Gu, Y., and T.
              Graf, "BMP Extension for Path Status TLV", Work in
              Progress, Internet-Draft, draft-ietf-grow-bmp-path-

Lucente & Cardona       Expires 19 September 2024               [Page 6]
Internet-Draft                   BMP REL                      March 2024

              marking-tlv-01, 18 March 2024,
              <https://datatracker.ietf.org/doc/html/draft-ietf-grow-
              bmp-path-marking-tlv-01>.

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

   [I-D.ietf-grow-bmp-tlv-ebit]
              Lucente, P. and Y. Gu, "Support for Enterprise-specific
              TLVs in the BGP Monitoring Protocol", Work in Progress,
              Internet-Draft, draft-ietf-grow-bmp-tlv-ebit-04, 23
              October 2023, <https://datatracker.ietf.org/doc/html/
              draft-ietf-grow-bmp-tlv-ebit-04>.

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

   [RFC4271]  Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A
              Border Gateway Protocol 4 (BGP-4)", RFC 4271,
              DOI 10.17487/RFC4271, January 2006,
              <https://www.rfc-editor.org/info/rfc4271>.

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

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

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

   [RFC9069]  Evens, T., Bayraktar, S., Bhardwaj, M., and P. Lucente,
              "Support for Local RIB in the BGP Monitoring Protocol
              (BMP)", RFC 9069, DOI 10.17487/RFC9069, February 2022,
              <https://www.rfc-editor.org/info/rfc9069>.

Lucente & Cardona       Expires 19 September 2024               [Page 7]
Internet-Draft                   BMP REL                      March 2024

Acknowledgements

   The authors would like to thank Jeff Haas, Luuk Hendriks, Ruediger
   Volk and Ahmed Elhassany for their valuable input.  The authors would
   also like to thank Mike Booth for his review.

Authors' Addresses

   Paolo Lucente
   NTT
   Veemweg 23
   3771 Barneveld
   Netherlands
   Email: paolo@ntt.net

   Camilo Cardona
   NTT
   164-168, Carrer de Numancia
   08029 Barcelona
   Spain
   Email: camilo@ntt.net

Lucente & Cardona       Expires 19 September 2024               [Page 8]