Logging of routing events in BGP Monitoring Protocol (BMP)
draft-lucente-grow-bmp-rel-01
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Replaced".
|
|
|---|---|---|---|
| Authors | Paolo Lucente , Camilo Cardona | ||
| Last updated | 2023-05-12 (Latest revision 2022-11-10) | ||
| Replaced by | draft-ietf-grow-bmp-rel | ||
| RFC stream | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-lucente-grow-bmp-rel-01
Global Routing Operations P. Lucente
Internet-Draft C. Cardona
Updates: 7854 (if approved) NTT
Intended status: Standards Track 12 May 2023
Expires: 13 November 2023
Logging of routing events in BGP Monitoring Protocol (BMP)
draft-lucente-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 13 November 2023.
Copyright Notice
Copyright (c) 2023 IETF Trust and the persons identified as the
document authors. All rights reserved.
Lucente & Cardona Expires 13 November 2023 [Page 1]
Internet-Draft BMP REL May 2023
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
4. Security Considerations . . . . . . . . . . . . . . . . . . . 5
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 5
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 6
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6
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. 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 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
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.
Lucente & Cardona Expires 13 November 2023 [Page 2]
Internet-Draft BMP REL May 2023
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 indexed TLVs.
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 followed by indexed
Informational TLVs that carry Event Attributes, where attributes are
bound to subjects referring to their index in the PDU or via a Group
TLV as described in TLV support for BMP Route Monitoring and Peer
Down Messages [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.
The following sections will describe each component of the REL
message in more detail.
Lucente & Cardona Expires 13 November 2023 [Page 3]
Internet-Draft BMP REL May 2023
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 is 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 13 November 2023 [Page 4]
Internet-Draft BMP REL May 2023
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 per Event Subject (ie.
NLRI) carried by the BGP Update PDU and MAY contain further optional
attribute TLVs to further characterize the Event.
A new registry called "Route Event Logging TLVs" is defined and is
seeded with the following TLVs:
* 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 | Path type |
+-------------------------------+
| 0x0000 | Unknown |
| 0x0001 | Log Action |
| 0x0002 | Policy Discard |
| 0x0004 | Validation Fail |
+--------+----------------------+
Table 1: Event Reason Codes
4. Security Considerations
It is not believed that this document adds any additional security
considerations.
5. IANA Considerations
TBD
6. References
[I-D.ietf-grow-bmp-tlv]
Lucente, P. and Y. Gu, "TLV support for BMP Route
Monitoring and Peer Down Messages", Work in Progress,
Internet-Draft, draft-ietf-grow-bmp-tlv-12, 27 March 2023,
<https://datatracker.ietf.org/doc/html/draft-ietf-grow-
bmp-tlv-12>.
Lucente & Cardona Expires 13 November 2023 [Page 5]
Internet-Draft BMP REL May 2023
[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-02, 13 March
2023, <https://datatracker.ietf.org/doc/html/draft-ietf-
grow-bmp-tlv-ebit-02>.
[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>.
Acknowledgements
TBD
Authors' Addresses
Paolo Lucente
NTT
Veemweg 23
3771 Barneveld
Netherlands
Email: paolo@ntt.net
Lucente & Cardona Expires 13 November 2023 [Page 6]
Internet-Draft BMP REL May 2023
Camilo Cardona
NTT
164-168, Carrer de Numancia
08029 Barcelona
Spain
Email: camilo@ntt.net
Lucente & Cardona Expires 13 November 2023 [Page 7]