draft-ietf-grow-bmp-rel.xml

<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
        <!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
        <!ENTITY RFC8174 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8174.xml">
        <!ENTITY RFC8210 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8210.xml">
        <!ENTITY RFC9067 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.9067.xml">
        <!ENTITY RFC7606 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7606.xml">
        <!ENTITY RFC8126 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8126.xml">
        <!ENTITY RFC9582 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.9582.xml">
        <!ENTITY I-D.ietf-grow-bmp-tlv SYSTEM "https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-grow-bmp-tlv.xml">
        <!ENTITY I-D.ietf-grow-bmp-path-marking-tlv SYSTEM "https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-grow-bmp-path-marking-tlv.xml">
        <!ENTITY I-D.ietf-grow-bmp-bgp-rib-stats SYSTEM "https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-grow-bmp-bgp-rib-stats.xml">
        <!ENTITY I-D.ietf-idr-bgp-model SYSTEM "https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-idr-bgp-model.xml">
        <!ENTITY I-D.ietf-sidrops-aspa-verification SYSTEM "https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-sidrops-aspa-verification.xml">

	<!ENTITY IANA_REL_CODE_ET_ROUTING "1">
	<!ENTITY IANA_REL_CODE_ET_HEALTH "2">

	<!ENTITY IANA_REL_CODE_RESERVED0 "0">
	<!ENTITY IANA_REL_CODE_SP "1">
	<!ENTITY IANA_REL_CODE_GROUP "2">
	<!ENTITY IANA_REL_CODE_RESERVED3 "3">
	<!ENTITY IANA_REL_CODE_BGP_PDU "4">
	<!ENTITY IANA_REL_CODE_EVENT_REASON "5">
	<!ENTITY IANA_REL_CODE_LOG_ACTION "6">
	<!ENTITY IANA_REL_CODE_POLICY_DISCARD "7">
	<!ENTITY IANA_REL_CODE_VALIDATION "8">
	<!ENTITY IANA_REL_CODE_MALFORMED_PACKET "9">

	<!ENTITY IANA_REL_CODE_ER_LOG_ACTION "0x01">
	<!ENTITY IANA_REL_CODE_ER_POLICY_DISCARD "0x02">
	<!ENTITY IANA_REL_CODE_ER_VALIDATION_STATE_CHANGE "0x04">
	<!ENTITY IANA_REL_CODE_ER_MALFORMED_PACKET "0x08">

	<!ENTITY IANA_REL_CODE_LA_CONFIG "1">
	<!ENTITY IANA_REL_CODE_LA_UNSTABLE "2">
	<!ENTITY IANA_REL_CODE_LA_CWB "3">
	<!ENTITY IANA_REL_CODE_LA_CUB "4">

	<!ENTITY IANA_REL_CODE_PD_STRING "1">
	<!ENTITY IANA_REL_CODE_PD_STRUCT "2">

	<!ENTITY IANA_REL_VSC_TYPE_TLV "1">
	<!ENTITY IANA_REL_VSC_REASON_TLV "2">
	<!ENTITY IANA_REL_VSC_RPKI_CACHE_CONTEXT_TLV "3">

	<!ENTITY IANA_REL_CODE_VSC_T_RPKI_INVALID "1">
	<!ENTITY IANA_REL_CODE_VSC_T_RPKI_COVERED_INVALID "2">
	<!ENTITY IANA_REL_CODE_VSC_T_RPKI_VALID "3">

	<!ENTITY IANA_REL_CODE_VSC_R_RPKI_ASOM "0x01">
	<!ENTITY IANA_REL_CODE_VSC_R_RPKI_MLV "0x02">

	<!ENTITY IANA_REL_CODE_MP_ERRORED_PDU "1">
]>

<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc strict="yes" ?>
<?rfc toc="yes"?>
<?rfc tocdepth="4"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes" ?>
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>

<rfc category="std" docName="draft-ietf-grow-bmp-rel-06"
     ipr="trust200902" submissionType="IETF"
     updates="7854" consensus="true">

    <front>
        <title abbrev="BMP REL">
	    Logging of routing events in BGP Monitoring Protocol (BMP)
	</title>

        <author fullname="Paolo Lucente" initials="P" surname="Lucente">
            <organization>NTT</organization>
            <address>
                <postal>
                    <street>Veemweg 23</street>
                    <city>Barneveld</city>
                    <code>3771</code>
                    <country>NL</country>
                </postal>
                <email>paolo@ntt.net</email>
            </address>
        </author>

	<author fullname="Camilo Cardona" initials="C" surname="Cardona ">
	  <organization>NTT</organization>
	    <address>
	      <postal>
		<street>164-168, Carrer de Numancia</street>
		<city>Barcelona</city>
		<code>08029</code>
		<country>Spain</country>
	      </postal>
              <email>camilo@ntt.net</email>
	    </address>
	</author>

        <date year="2026"/>

        <area>General</area>

        <workgroup>Global Routing Operations</workgroup>
        <keyword>BMP</keyword>
        <keyword>BGP</keyword>
        <keyword>REL</keyword>

        <abstract>
            <t>
		The BGP Monitoring Protocol (BMP) does provide for BGP session event
		logging (Peer Up, Peer Down), state synchronization (Route Monitoring),
		debugging (Route Mirroring) and Statistics messages, among 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.
            </t>
        </abstract>
    </front>

    <middle>
        <section title="Introduction" anchor="Introduction">
            <t>
		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 instead be more useful if a monitored router could export
		event-driven data with the relevant information.
            </t>
            <t>
		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. 
            </t>
            <t>
		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 <xref target="RFC7854">RFC 7854</xref> and to the Route
		Monitoring message type as defined in <xref target="I-D.ietf-grow-bmp-tlv"/>,
		the semantics are different.
            </t>
        </section>

        <section title="Terminology">
            <t>
		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 <xref target="RFC2119">RFC 2119</xref>
		<xref target="RFC8174">RFC 8174</xref> when, and only when, they
		appear in all capitals, as shown here.
            </t>
            <t>
		The term "RPKI cache" in this document refers to the router local
		store of RPKI data received via the RTR protocol
		<xref target="RFC8210"/>, including Route Origin Authorizations
		(ROAs) <xref target="RFC9582"/>, Autonomous System Provider Authorization (ASPA)
		objects <xref target="I-D.ietf-sidrops-aspa-verification"/>, and
		other RPKI objects.
            </t>
        </section>

	<section title="Route Event Logging (REL) message" anchor="RELStruct">
            <t>
		In basic terms a REL message carries events. Each event is
		logically composed by one Event Type, one or more Event Subjects
		and one or more Event Attributes.
	    </t>
	    <t>
		More specifically, the REL message is composed of the BMP Common Header,
		an Event Type Header, a Per-Peer Header (mandatory or optional
		depending on the Event Type), one mandatory TLV packing one or more
		Event Subjects, one mandatory Informational TLV indicating the reason
		of the event and any further optional Informational TLVs to better
		characterize the nature of the event.
	    </t>
	    <t>
		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.
	    </t>
	    <t>
		In the context of BMP REL message, and hence in the remainder 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.
	    </t>
	    <t>
		The following sections will describe each component of the REL
		message in more detail. 
	    </t>
	<section title="Common Header">
	    <t>
		The BMP Common Header is mandatory and defined in <xref target="RFC7854">
		Section 4.1 of</xref>. The version field is set to 4 meaning the REL
		message depends on definitions made in <xref target="I-D.ietf-grow-bmp-tlv"/>. 
	    </t>
	</section>
	<section title="Event Type Header">
	    <t>
		The Event Type Header is a 1 byte field to determine whether the
		event is related to routing, a peer or some aspect of the health
		of the BGP or the BMP protocols on the reporting router. It also
		influences the structure of the remainder of the REL message. The
		defined Event Types are: 
	    </t>
            <t>
                <list style="symbols">
                        <t>
                        Code = &IANA_REL_CODE_ET_ROUTING;: The event is related to Routing and Validation.
                        </t>
                        <t>
                        Code = &IANA_REL_CODE_ET_HEALTH;: The event is related to the health
			of the BGP or the BMP protocols. 
                        </t>
                </list>
                        In this registry reason code 0 (zero) is reserved.
            </t>
	    <section title="Routing and Validation Event Type">
            	<t>
			The Per-Peer Header will follow. One or more Event Subjects
			are packed as part of the BGP Update PDU. The BGP Update PDU
			<xref target="RFC4271">Section 4.3 of</xref> is encoded itself
			as part of the BGP Message TLV with code point &IANA_REL_CODE_BGP_PDU;
			and index set to zero. Each Event Subject is represented by an
			NLRI carried in the PDU. 
            	</t>
            	<t>
			RPKI Cache updates may trigger Routing and Validation events.
			In such cases the BGP Update PDU is artificial and carries
			Validation State Change TLV and optional RPKI Cache Context TLV
			providing further context.
            	</t>
            	<t>
			The BGP Message TLV may be preceded 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 <xref target="I-D.ietf-grow-bmp-tlv">
			Section 5.2.1 of</xref>
            	</t>
	    </section>
	    <section title="Health Event Type">
            	<t>
			In typical BMP implementations on routers, BMP operates as a
			low-priority process to avoid competing with core routing and
			data plane functions. Consequently, BMP message generation, state
			maintenance, and transmission may be preempted by higher-priority
			tasks during periods of high system load.
		</t>
		<t>
			Under certain conditions, BMP can accumulate substantial internal
			state - particularly Route Monitoring state during synchronization
			phases - leading to significant physical memory consumption.
		</t>
		<t>
			When memory pressure becomes critical, router implementations may
			choose to discard BMP oldest internal state as a defensive measure
			to prevent system instability or crashes, rather than allowing BMP
			to trigger broader resource exhaustion that could impact core
			forwarding functions.
		</t>
		<t>
			The Health Event Type enables reporting of such and other conditions
			through REL messages. A REL Health event with Event Reason "Log
			Action" and Log Action code "Unstable" (&IANA_REL_CODE_LA_UNSTABLE;)
			can convey this situation.
            	</t>
	    </section>
	</section>
	<section title="Per-Peer Header">
	    <t>
		The BMP per-peer header as defined in <xref target="RFC7854">Section 4.2 of</xref>,
		subsequently extended by <xref target="RFC8671">RFC 8671</xref> and <xref
		target="RFC9069">RFC 9069</xref> allowing, among other things, an event to be
		timestamped and set its observation point among those defined in BMP.  
	    </t>
	    <t>
		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:
	    </t>
	    <t>
	    <figure align="center">
        <artwork align="center"><![CDATA[
 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|V|A| Reserved  |
+-+-+-+-+-+-+-+-+
            ]]></artwork>
	    </figure>
	    </t>
	    <t>
		The V flag and A flag do carry the same meaning as originally defined
		by <xref target="RFC7854">RFC 7854</xref>. The remaining bits are
		reserved for future use. They MUST be transmitted as 0 and their
		values MUST be ignored on receipt. 
	    </t>
	</section>
	<section title="BGP Update PDU">
	    <t>
		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.
	    </t>
	    <t>
		The choice of describing one or multiple Event Subjects via
		a BGP Update PDU is because, on one hand, this avoids 
		having 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. 
	    </t>
	</section>
	<section title="Informational TLVs">
	    <t>
		Informational TLVs in BMP are formalized by the
		intersection of <xref target="RFC7854">RFC 7854</xref> and
		<xref target="I-D.ietf-grow-bmp-tlv"/>. TLVs in a REL message
		are indexed.
	    </t>
	    <t>
		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.
	    </t>
	    <t>
		A new registry called "Route Event Logging TLVs" is defined and
		is seeded with the TLVs detailed in the following sections.
	    </t>
	    <section title="Event Reason TLV" anchor="EventReasonTLV">
		<t>
		    &IANA_REL_CODE_EVENT_REASON; = 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:
		</t>
		<table anchor="EventReasonTLVCodes">
		<name>IANA-Registered Event Reasons</name>
		<thead>
		<tr>
			<th align="center">Value</th>
			<th align="left">Event Reason</th>
		</tr>
		</thead>
		<tbody>
		<tr>
			<td align="center">&IANA_REL_CODE_ER_LOG_ACTION;</td>
			<td align="left">Log Action</td>
		</tr>
		<tr>
			<td align="center">&IANA_REL_CODE_ER_POLICY_DISCARD;</td>
			<td align="left">Policy Discard</td>
		</tr>
		<tr>
			<td align="center">&IANA_REL_CODE_ER_VALIDATION_STATE_CHANGE;</td>
			<td align="left">Validation State Change</td>
		</tr>
		<tr>
			<td align="center">&IANA_REL_CODE_ER_MALFORMED_PACKET;</td>
			<td align="left">Malformed Packet</td>
		</tr>
		</tbody>
		</table>
	    </section>
	    <section title="Log Action TLV" anchor="LogActionTLV">
		<t>
		    &IANA_REL_CODE_LOG_ACTION; = Log Action TLV. The length is variable.
		    The first byte defines the nature of the logging, depending on the
		    code point additional data may follow. The following code points are
		    defined:

		    <list style="symbols">
			<t>
			    &IANA_REL_CODE_LA_CONFIG; = Config. Prefix is being logged
			    due to a configuration statement. Data contains a UTF-8
			    string whose value can be organized freely by an
			    implementation and is meant to give additional information
			    about why the log was made.
			</t>
			<t>
			    &IANA_REL_CODE_LA_UNSTABLE; = Route unstable. Optional data
			    contains a 4 bytes value representing the observed timeframe
			    in seconds, followed by a 4 bytes value indicating the amount
			    of times the event occurred within the timeframe.
			</t>
			<t>
			    &IANA_REL_CODE_LA_CWB; = Crossed Warning Bound. Prefix is
			    over the warning threshold of the maximum number of prefixes
			    that can be received from a BGP neighbor. Data contains a
			    4 bytes value representing the threshold number.
			</t>
			<t>
			    &IANA_REL_CODE_LA_CUB; = Crossed Upper Bound. Prefix is over
			    the upper threshold of the maximum number of prefixes that
			    can be received from a BGP neighbor. Data contains a 4 bytes
			    value representing the threshold number.
			</t>
		    </list>
	        </t>
	    </section>
	    <section title="Policy Discard TLV" anchor="PolicyDiscardTLV">
		<t>
		    &IANA_REL_CODE_POLICY_DISCARD; = Policy Discard TLV. The length is
		    variable. The first byte of the value field indicates how the rest
		    is organized:

		    <list style="symbols">
		    <t>
		    	&IANA_REL_CODE_PD_STRING; = String. 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.
		    </t>
		    <t>
			&IANA_REL_CODE_PD_STRUCT; = Structured. In the spirit of <xref
			target="RFC9067">Section 4 of</xref> and <xref
			target="I-D.ietf-idr-bgp-model">YANG Model for Border Gateway
			Protocol (BGP-4)</xref> the value is organized as two
			consecutive null-terminated strings, the first indicating the
			policy name, the second the statement name within the policy.
		     </t>
		     </list>
		  </t>
	    </section>
	    <section title="Validation State Change TLV" anchor="ValidationStateChangeTLV">
		<t>
		    &IANA_REL_CODE_VALIDATION; = Validation State Change TLV. The value
		    is in the form of TLVs. The Validation State Change Type TLV is
		    mandatory and defined with Type &IANA_REL_VSC_TYPE_TLV;, Length
		    1 and Value among the following Validation Fail Type code points:
		</t>
		<t>
		<list style="symbols">
			<t>
			Code = &IANA_REL_CODE_VSC_T_RPKI_INVALID;: RPKI Invalid. The
			prefix is being marked as RPKI 'invalid' and either has no
			coverage or it is unknown whether it has coverage by a valid
			prefix.
			</t>
			<t>
			Code = &IANA_REL_CODE_VSC_T_RPKI_COVERED_INVALID;: RPKI Invalid
			with covering Valid prefix. The NLRI is being marked as RPKI
			'invalid' but is covered by a Valid prefix.
			</t>
			<t>
			Code = &IANA_REL_CODE_VSC_T_RPKI_VALID;: RPKI Valid. The prefix
			validation state has transitioned to RPKI 'valid', for example
			following an RPKI cache update that introduced or updated a matching
			Route Origin Authorization (ROA).
			</t>
		</list>
		</t>

		<section title="Reason Sub-TLV" anchor="VSCReasonSubTLV">
			<t>
				The Reason Sub-TLV aims at providing more information about
				the validation state change. This Sub-TLV is optional and
				defined with Type &IANA_REL_VSC_REASON_TLV;, Length 1 and
				Value among the following Reason code points:
			</t>
			<t>
			<list style="symbols">
				<t>
				Code = &IANA_REL_CODE_VSC_R_RPKI_ASOM;: AS Origin Mismatch.
				</t>
				<t>
				Code = &IANA_REL_CODE_VSC_R_RPKI_MLV;: Max Length Violation. 
				</t>
			</list>
				In this registry reason code 0 (zero) is reserved.
			</t>
		</section>
		<section title="RPKI Cache Context Sub-TLV" anchor="VSCRPKICacheContextSubTLV">
			<t>
				The RPKI Cache Context Sub-TLV aims at helping correlate the
				reported validation state change with the RPKI cache update
				that triggered it. This Sub-TLV is optional and defined with
				Type &IANA_REL_VSC_RPKI_CACHE_CONTEXT_TLV;. The value field
				is organized as follows:
			<list style="symbols">
			<t>
				RTR Session ID (2 octets): The RTR protocol session identifier
				as defined in <xref target="RFC8210">RFC8210</xref>,
				identifying the RPKI cache session.
			</t>
			<t>
				Serial Number (4 octets): The RTR serial number of the cache
				update that triggered the validation state change
				as defined in <xref target="RFC8210">RFC8210</xref>.
			</t>
			<t>
				Cache Identifier (variable, optional): A UTF-8 string
				identifying the RPKI cache, for example a hostname or IP
				address. Its presence is indicated by a non-zero remaining
				TLV length after the Serial Number field.
			</t>
			</list>
			</t>
		</section>
	    </section>
	    <section title="Malformed Packet TLV" anchor="MalformedPacketTLV">
		<t>
		    &IANA_REL_CODE_MALFORMED_PACKET; = Malformed Packet TLV. The
		    length is set to 1 byte and the value represents a code giving
		    more information about the specific format error. Following are
		    the defined code points:
		</t>
		<t>
		<list style="symbols">
			<t>
			Code = &IANA_REL_CODE_MP_ERRORED_PDU;: Errored PDU. The BGP
			message was found to have some error that made it unusable,
			causing it to be treated-as-withdraw <xref target="RFC7606">
			RFC7606</xref>.
			</t>
		</list>
		</t>
	    </section>
	</section>
        <section title="Group TLV" anchor="GroupTLV">
            <t>
		The Group TLV is to form N:M relationships among NLRIs in the BGP
		Update PDU and TLVs of the same REL message. This TLV has code
		point &IANA_REL_CODE_GROUP; and follows the definition of Group
		TLV in <xref target="I-D.ietf-grow-bmp-tlv"/>.
            </t>
	</section>
        <section title="Stateless Parsing TLV" anchor="SPTLV">
            <t>
		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 &IANA_REL_CODE_SP; , it follows the definition of
		Stateless Parsing TLV in <xref target="I-D.ietf-grow-bmp-tlv"/>.
            </t>
	</section>
	</section>

        <section title="Examples and use cases">
	    <t>
		REL can be used to send real-time notifications for specific routing
		events enabling rapid alerting of issues like policy discards,
		validation state changes, or malformed packets to operators. For example,
		an operator is notified immediately when a route is discarded due to
		policy, assisting quick diagnosis and policy refinement.
	    </t>
	    <t>
		By logging every routing event and the corresponding reason code, REL
		enables thorough audits of route changes and network behavior over
		time. For example, when a route fails validation, a log entry with
		the "Validation State Change" reason is stored for compliance checks and
		future forensics.
	    </t>
	    <t>
		REL events, especially with machine-readable reason codes, can feed
		analytics engines and automated workflows to correlate events across
		the network and trigger remediation. For example, analytics dashboards
		continuously monitor for spikes in "Malformed Packet" events to detect
		possible protocol attacks or systemic misconfigurations.
	    </t>
	</section>

        <section title="Operational Considerations">
	    <t>
		REL 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 <xref
		target="I-D.ietf-grow-bmp-path-marking-tlv"> BMP Path Marking</xref>.
		As an example consider RPKI validation status: when the objective is
		to report on any validations status (ie. valid, invalid),
		BMP Path Marking should be used; when the objective is instead to
		report only invalids then REL with Validation State Change Event Reason should
		be used.
	    </t>
	    <t>
		RPKI Cache resets or large serial advances can cause large volumes
		of validation status changes. Implementations SHOULD apply rate limiting.
	    </t>
	    <t>
		There exists a definite overlap between REL when used to report Malformed
		Packet and the use cases for Route Mirroring where Errored PDUs may be
		sampled for reporting. From implementors perspective, if one 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 advisable to prefer implementing REL message type over Route
		Mirroring. From a collector perspective, similarly, one may want to
		activate distinct BMP feeds for event logging and route collection and,
		also in this case, reporting malformed packets via REL message type may
		be preferable over Route Mirroring.
	    </t>
	    <t>
		Crossed warning bound and crossed upper bound events refer to
		the received route thresholds that can be configured according
		to <xref target="RFC4271">Section 6.7 of</xref>. Also the stats
		counters part of these events is being addressed by the <xref
		target="I-D.ietf-grow-bmp-bgp-rib-stats">Definition For New BMP
		Statistics Type</xref> document.
	    </t>
	</section>

        <section title="Security Considerations">
            <t>
		It is not believed that this document adds any additional security
		considerations.
            </t>
        </section>

        <section title="IANA Considerations">
            <t>
		This document requests that IANA creates all the new registries in the
		following sections under the "BGP Monitoring Protocol (BMP) Parameters"
		group. The registries will record type code points for TLVs specific to
		the Route Event Logging (REL) message type, as defined in this document.
	    </t>
	    <section>
	    	<name>BMP Route Event Logging TLVs Registry</name>
	    	<t>
		    TLV Type consists of a code point (unsigned 16-bit value) and initial
		    allocations are as follows:
		</t>
		<list style="symbols">
			<t>
				Type = &IANA_REL_CODE_RESERVED0;: Reserved for future use
			</t>
			<t>
				Type = &IANA_REL_CODE_SP;: Stateless Parsing TLV
			</t>
			<t>
				Type = &IANA_REL_CODE_GROUP;: Group TLV
			</t>
			<t>
				Type = &IANA_REL_CODE_RESERVED3;: Reserved for future use
			</t>
			<t>
				Type = &IANA_REL_CODE_BGP_PDU;: BGP Message TLV
			</t>
			<t>
				Type = &IANA_REL_CODE_EVENT_REASON;: Event Reason TLV
			</t>
			<t>
				Type = &IANA_REL_CODE_LOG_ACTION;: Log Action TLV
			</t>
			<t>
				Type = &IANA_REL_CODE_POLICY_DISCARD;: Policy Discard TLV
			</t>
			<t>
				Type = &IANA_REL_CODE_VALIDATION;: Validation State Change TLV
			</t>
			<t>
				Type = &IANA_REL_CODE_MALFORMED_PACKET;: Malformed Packet TLV
			</t>
		</list>
		<t>
			Values 0 through 16383 is to be assigned using the Standards Action policy as
			defined in <xref target="RFC8126">Section 4.9 of</xref>; values 16384 through
			32767 is to be assigned using the First Come First Served policy as defined in
			<xref target="RFC8126">Section 4.4 of</xref>. The upper bound of the registry
			is 65535. Value 65535 is Reserved.
		</t>
		</section>
		<section>
			<name>BMP Event Reason TLV Registry</name>
	    		<t>
				TLV Type consists of a code point (unsigned 8-bit value) and is defined
				in <xref target="EventReasonTLV"/>. Initial allocations are as follows:
			</t>
			<list>
				<t>
					Type = &IANA_REL_CODE_ER_LOG_ACTION;: Log Action
				</t>
				<t>
					Type = &IANA_REL_CODE_ER_POLICY_DISCARD;: Policy Discard
				</t>
				<t>
					Type = &IANA_REL_CODE_ER_VALIDATION_STATE_CHANGE;: Validation State Change
				</t>
				<t>
					Type = &IANA_REL_CODE_ER_MALFORMED_PACKET;: Malformed Packet
				</t>
			</list>
			<t>
				Values 0 through 63 is to be assigned using the Standards Action policy as
				defined in <xref target="RFC8126">Section 4.9 of</xref>; values 64 through
				127 is to be assigned using the First Come First Served policy as defined in
				<xref target="RFC8126">Section 4.4 of</xref>. The upper bound of the registry
				is 255. Values 0 and 255 are Reserved.
			</t>
		</section>
		<section>
			<name>BMP Log Action TLV Registry</name>
	    		<t>
				TLV Type consists of a code point (unsigned 8-bit value) and is defined
				in <xref target="LogActionTLV"/>. Initial allocations are as follows:
			</t>
			<list>
				<t>
					Type = &IANA_REL_CODE_LA_CONFIG;: Config (prefix logged due to configuration)
				</t>
				<t>
					Type = &IANA_REL_CODE_LA_UNSTABLE;: Route unstable
				</t>
				<t>
					Type = &IANA_REL_CODE_LA_CWB;: Crossed Warning Bound
				</t>
				<t>
					Type = &IANA_REL_CODE_LA_CUB;: Crossed Upper Bound
				</t>
			</list>
			<t>
				Values 0 through 63 is to be assigned using the Standards Action policy as
				defined in <xref target="RFC8126">Section 4.9 of</xref>; values 64 through
				127 is to be assigned using the First Come First Served policy as defined in
				<xref target="RFC8126">Section 4.4 of</xref>. The upper bound of the registry
				is 255. Values 0 and 255 are Reserved.
			</t>
		</section>
      
		<section>
			<name>BMP Policy Discard TLV Registry</name>
	    		<t>
				TLV Type consists of a code point (unsigned 8-bit value) and is defined
				in <xref target="PolicyDiscardTLV"/>. Initial allocations are as follows:
			</t>
			<list>
				<t>
					Type = &IANA_REL_CODE_PD_STRING;: String (UTF-8 policy name/reason)
				</t> 
				<t>
					Type = &IANA_REL_CODE_PD_STRUCT;: Structured (policy and statement, null-terminated)
				</t>
			</list>
			<t>
				Values 0 through 63 is to be assigned using the Standards Action policy as
				defined in <xref target="RFC8126">Section 4.9 of</xref>; values 64 through
				127 is to be assigned using the First Come First Served policy as defined in
				<xref target="RFC8126">Section 4.4 of</xref>. The upper bound of the registry
				is 255. Values 0 and 255 are Reserved.
			</t>
		</section>

		<section>
			<name>BMP Validation State Change TLV Registry</name>
	    		<t>
				TLV Type consists of a code point (unsigned 8-bit value) and is defined in
				<xref target="ValidationStateChangeTLV"/>. Initial allocations are as follows:
			</t>
			<list>
				<t>
					Type = &IANA_REL_VSC_TYPE_TLV;: Type Sub-TLV
				</t>
				<t>
					Type = &IANA_REL_VSC_REASON_TLV;: Reason Sub-TLV
				</t>
				<t>
					Type = &IANA_REL_VSC_RPKI_CACHE_CONTEXT_TLV;: RPKI Cache Context Sub-TLV
				</t>
			</list>
			<t>
				Values 0 through 63 is to be assigned using the Standards Action policy as
				defined in <xref target="RFC8126">Section 4.9 of</xref>; values 64 through
				127 is to be assigned using the First Come First Served policy as defined in
				<xref target="RFC8126">Section 4.4 of</xref>. The upper bound of the registry
				is 255. Values 0 and 255 are Reserved.
			</t>
		</section>
		<section>
			<name>BMP Validation State Change Type Sub-TLV Registry</name>
	    		<t>
				TLV Type consists of a code point (unsigned 8-bit value) and is defined in
				<xref target="ValidationStateChangeTLV"/>. Initial allocations are as follows:
			</t>
			<list>
				<t>
					Type = &IANA_REL_CODE_VSC_T_RPKI_INVALID;: RPKI Invalid
				</t>
				<t>
					Type = &IANA_REL_CODE_VSC_T_RPKI_COVERED_INVALID;: RPKI Invalid with Covering Valid Prefix
				</t>
				<t>
					Type = &IANA_REL_CODE_VSC_T_RPKI_VALID;: RPKI Valid
				</t>
			</list>
			<t>
				Values 0 through 63 is to be assigned using the Standards Action policy as
				defined in <xref target="RFC8126">Section 4.9 of</xref>; values 64 through
				127 is to be assigned using the First Come First Served policy as defined in
				<xref target="RFC8126">Section 4.4 of</xref>. The upper bound of the registry
				is 255. Values 0 and 255 are Reserved.
			</t>
		</section>

		<section>
			<name>BMP Validation State Change Reason Sub-TLV Registry</name>
	    		<t>
				The registry consists of a unsigned 8-bit code point and is defined in
				<xref target="VSCReasonSubTLV"/>. Initial allocations are as follows:
			</t>
			<list style="symbols">
				<t>
					Code = &IANA_REL_CODE_VSC_R_RPKI_ASOM;: AS Origin Mismatch
				</t>
				<t>
					Code = &IANA_REL_CODE_VSC_R_RPKI_MLV;: Max Length Violation
				</t>
			</list>
			<t>
				Values 0 through 63 is to be assigned using the Standards Action policy as
				defined in <xref target="RFC8126">Section 4.9 of</xref>; values 64 through
				127 is to be assigned using the First Come First Served policy as defined in
				<xref target="RFC8126">Section 4.4 of</xref>. The upper bound of the registry
				is 255. Value 0 is Reserved.
			</t>
		</section>

		<section>
			<name>BMP Malformed Packet TLV Registry</name>
	    		<t>
				TLV Type consists of a code point (unsigned 8-bit value) and is defined in
				<xref target="MalformedPacketTLV"/>. Initial allocations are as follows:
			</t>
			<list>
				<t>
					Type = &IANA_REL_CODE_MP_ERRORED_PDU;: Errored PDU (treated-as-withdraw per RFC 7606)
				</t>
			</list>
			<t>
				Values 0 through 63 is to be assigned using the Standards Action policy as
				defined in <xref target="RFC8126">Section 4.9 of</xref>; values 64 through
				127 is to be assigned using the First Come First Served policy as defined in
				<xref target="RFC8126">Section 4.4 of</xref>. The upper bound of the registry
				is 255. Values 0 and 255 are Reserved.
			</t>
		</section>
	</section>
    </middle>
    <back>

    <references title="References">
		&RFC2119;
		&RFC9582;
		&RFC8174;
		&RFC8210;

		<?rfc include="reference.RFC.4271.xml"?>
		<?rfc include="reference.RFC.7606.xml"?>
		<?rfc include="reference.RFC.7854.xml"?>
                <?rfc include="reference.RFC.8126.xml"?>
                <?rfc include="reference.RFC.8671.xml"?>
                <?rfc include="reference.RFC.9067.xml"?>
                <?rfc include="reference.RFC.9069.xml"?>

		&I-D.ietf-grow-bmp-tlv;
		&I-D.ietf-grow-bmp-path-marking-tlv;
		&I-D.ietf-grow-bmp-bgp-rib-stats;
		&I-D.ietf-sidrops-aspa-verification;
		&I-D.ietf-idr-bgp-model;
    </references>

    <section anchor="RELExamples" title="Wire Format examples">
            <t>
<figure anchor="fig-rel-routing-example">
  <name>Example of BMP REL Routing Event</name>
  <artwork><![CDATA[
+---------------------------------------------------------------+
|                     BMP Common Header                         |
+-------------------------------+-------------------------------+
| Version = 4                   |  Msg Length (total)           |
+-------------------------------+-------------------------------+
| Msg Type = REL (TBD)          |  Reserved                     |
+-------------------------------+-------------------------------+

+---------------------------------------------------------------+
|                    Event Type Header                          |
+-------------------------------+-------------------------------+
| Event Type = Routing (1)      |
+-------------------------------+

+---------------------------------------------------------------+
|                       Per-Peer Header                         |
+---------------------------------------------------------------+
| Peer Type | Flags (V,A,...) | Peer Distinguisher              |
+---------------------------------------------------------------+
| Peer Address (IPv4 or IPv6)                                   |
+---------------------------------------------------------------+
| Peer AS                     |  Peer BGP ID                    |
+---------------------------------------------------------------+
| Timestamp (seconds)                                           |
+---------------------------------------------------------------+
| Timestamp (microseconds)                                      |
+---------------------------------------------------------------+

+---------------------------------------------------------------+
|                    Route Event Logging TLVs                   |
+---------------------------------------------------------------+
| TLV: BGP Message (Type = 4)					|
|   Length = N                                                  |
|   Value:                                                      |
|     BGP UPDATE PDU                                            |
|       +---------------------------------------------------+   |
|       | Withdrawn Routes Length = 0                       |   |
|       +---------------------------------------------------+   |
|       | Total Path Attr Length                            |   |
|       +---------------------------------------------------+   |
|       | Path Attributes (e.g., ORIGIN, AS_PATH, NEXT_HOP) |   |
|       +---------------------------------------------------+   |
|       | NLRI #1 (Event Subject 1)                         |   |
|       +---------------------------------------------------+   |
|       | NLRI #2 (Event Subject 2)                         |   |
|       +---------------------------------------------------+   |
+---------------------------------------------------------------+

+---------------------------------------------------------------+
| TLV: Event Reason (Type = 5)      				|
|   Length = 4                                                  |
|   Value:                                                      |
|     0x00000002						|
+---------------------------------------------------------------+

+---------------------------------------------------------------+
| TLV: Policy Discard (Type = 7)				|
|   Length = L                                                  |
|   Value:                                                      |
|     0x01							|
|     "INBOUND-EDGE-FILTER" (UTF-8 string)                      |
+---------------------------------------------------------------+
  ]]></artwork>
</figure>
            </t>
	    <t>
<figure anchor="fig-rel-health-example">
  <name>Example of BMP REL Health Event</name>
  <artwork><![CDATA[
+---------------------------------------------------------------+
| BMP Common Header (Version=4, Msg Type=REL)                   |
+---------------------------------------------------------------+
| Event Type Header: Health Event (2)                           |
+---------------------------------------------------------------+
| TLV: Event Reason (Type=5)                                    |
|   Length=4, Value=0x00000001 (Log Action)                     |
+---------------------------------------------------------------+
| TLV: Log Action (Type=6)                                      |
|   Length=13, Value=0x02 ("Unstable") | 0x00000064 (100s)      |
|                 | 0x00000005 (5 occurrences)                  |
+---------------------------------------------------------------+
  ]]></artwork>
</figure>
            </t>

    </section>

    <section anchor="Acknowledgements" title="Acknowledgements" numbered="no">
            <t>
		The authors would like to thank Jeff Haas, Luuk Hendriks,
		Ruediger Volk, Ahmed Elhassany, Thomas Graf, Ben Maddison and
		Mukul Srivastava for their valuable input. The authors would
		also like to thank Mike Booth for his review.
            </t>
    </section>

    </back>
</rfc>