draft-ietf-grow-bmp-tlv.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 I-D.ietf-grow-bmp-peer-up SYSTEM "https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-grow-bmp-peer-up.xml">
        <!ENTITY IANA_RM_CODE_BGP_PDU "TBD1">
        <!ENTITY IANA_RM_CODE_GROUP "TBD2">
        <!ENTITY IANA_RM_CODE_VRF "TBD3">
        <!ENTITY IANA_RM_CODE_SP "TBD4">
        ]>

<?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-tlv-16"
     ipr="trust200902" submissionType="IETF"
     updates="7854">

    <front>
        <title abbrev="BMP TLV">
	    BMP v4: TLV support for BMP Route Monitoring and Peer Down Messages
	</title>

        <author fullname="Paolo Lucente" initials="P" surname="Lucente">
            <organization>NTT</organization>
            <address>
                <postal>
                    <street>Veemweg 23</street>
                    <city>Barneveld</city>
                    <code>3771</code>
                    <region>MT</region>
                    <country>NL</country>
                </postal>
                <email>paolo@ntt.net</email>
            </address>
        </author>
        <author fullname="Yunan Gu" initials="Y" surname="Gu">
            <organization>Huawei</organization>
            <address>
                <postal>
                    <street>Huawei Bld., No.156 Beiqing Rd.</street>
                    <city>Beijing</city>
                    <code>100095</code>
                    <region></region>
                    <country>China</country>
                </postal>
                <email>guyunan@huawei.com</email>
            </address>
        </author>

        <date year="2025"/>

        <area>General</area>

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

        <abstract>
            <t>
		Most of the message types defined by the BGP Monitoring Protocol (BMP)
		make provision for data in TLV format. However, Route Monitoring
		messages (which provide a snapshot of the monitored Routing Information
		Base) and Peer Down messages (which indicate that a peering session was
		terminated) do not. Supporting (optional) data in TLV format across
		all BMP message types allows for a homogeneous and extensible structure
		that would be useful for the most different use-cases that need to
		convey additional data to a BMP station. While it is not intended
		for this document to cover any specific utilization scenario, it defines
		a consistent and simple way to support TLV data in all message types.
            </t>
        </abstract>
    </front>

    <middle>
        <section title="Introduction" anchor="Introduction">
            <t>
		The BGP Monitoring Protocol (BMP) version 3 is defined in <xref target="RFC7854">RFC 7854</xref>.
	    </t>

            <t>
		The Route Monitoring message consists of:
		<list style="symbols">
			<t>Common Header</t>
			<t>Per-Peer Header</t>
			<t>BGP Update PDU</t>
		</list>
	    </t>

	    <t>
		The Peer Down Notification message consists of:
		<list style="symbols">
			<t>Common Header</t>
			<t>Per-Peer Header</t>
			<t>Reason</t>
			<t>Data (only if Reason code is 1, 2 or 3)</t>
			<t>TLV (only if Reason code is 6)</t>
		</list>
	   </t>

           <t>
		This means that both Route Monitoring and Peer Down messages have
		a non-extensible format (except for the specific case of Peer Down
		Reason Code 6 as <xref section="5.3" sectionFormat="of"
		target="RFC9069"/>). In the Route Monitoring case, this prevents
		the transmission of characteristics of transported NLRIs (e.g. to
		help with stateless parsing), status of a path after being
		processed by the BGP process or of vendor-specific data. In the
		Peer Down case, this prevents matching with TLVs previously sent
		with the Peer Up message. The proposal of this document is to:
		<list style="symbols">
			<t>Bump the BMP version for all message types defined in
			   <xref target="RFC7854">RFC 7854</xref> for backward compatibility</t>
			<t>Change the structure of Route Monitoring message type so that the BGP
			   Update PDU is enclosed in a TLV. The BGP Message PDU TLV is mandatory</t>
			<t>Allow all defined BMP message types to make provision for optional
			   TLV data.</t>
		</list>
            </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>
        </section>

	<section title="Message version">
	    <t>
		For an exporter to flag a receiver that it does comply with this document, the
		Version field of the Common Header, documented in <xref target="RFC7854">
		Section 4.4 of</xref>, MUST be set to 4. This applies to every BMP message
		type.	
	    </t>
	</section>

	<section title="TLV encoding">
	    <t>
		The TLV data type is already defined in <xref target="RFC7854">Section 4.4 of</xref>
		for the Initiation and Peer Up message types. A TLV consists of:
	    </t>
	    <t>
		<list style="symbols">
		    <t>
			2 octets of TLV Type,
		    </t>
		    <t>
			2 octets of TLV Length,
		    </t>
		    <t>
			0 or more octets of TLV Value.
		    </t>
		</list>
	    </t>

	    <figure anchor="BMP-TLV-header" align="center">
	    	<artwork align="center">
	    	    <![CDATA[
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |        Type (2 octets)        |     Length (2 octets)         |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  ~                      Value (variable)                         ~
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	    	    ]]>
	    	</artwork>
	    </figure>

	    <t>
		TLVs SHOULD be sorted by the sender by their code point. Multiple
		TLVs of the same type can be repeated as part of the same message,
		and it is left to the specific use-cases whether all, any, the
		first or the last TLV should be considered as well as whether
		ordering matters and repeating is allowed.
	    </t>

	    <t>
	        Route Monitoring messages may require per-NLRI TLVs, that is, there may
		be a need to map TLVs to NLRIs contained in the BGP Update message, for
		example, to express additional characteristics of a specific NLRI. For
		this purpose specifically, TLVs in Route Monitoring messages MUST be
		indexed, with the index starting at one (1) to refer to the first NLRI.
		Index zero (0) specifies that a TLV does apply to all NLRIs contained in
		the BGP Update message. The Index field is 2 bytes long of which the
		top-most bit, G-bit, is reserved to flag a Group Index (more in <xref
		target="GroupTLVinRM"/>).
		In general TLVs of the same type and with the same index can be repeated
		as part of the same message, unless specified otherwise by the definition
		of the specific TLV. Indexed TLVs are encoded as in the following figure:
	    </t>

	    <figure anchor="BMP-indexed-TLV-header" align="center">
	    	<artwork align="center">
	    	    <![CDATA[
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |        Type (2 octets)        |     Length (2 octets)         |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |G|      Index (15 bits)        |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  ~                      Value (variable)                         ~
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	    	    ]]>
	    	</artwork>
	    </figure>

	    <t>
		Indexed TLVs SHOULD be sorted by the sender by their code point and
		index value. Also in indexed TLVs, the reported length refers to the
		total encoded TLV value (ie. it does exclude the length of the index
		field).
	    </t>

	    <t>
		A decoder can properly match indexed TLVs to the corresponding NLRI
		only if - or as long as - NLRIs are decoded successfully. In case of
		any parsing or error condition that prevents full decoding of the BGP
		PDU, the decoder MUST stop matching indexed TLVs to NLRIs.
	    </t>

	    <t>
	        Of the BMP message types defined so far, indexed TLVs apply only to
		Route Monitoring messages and, for example, they do not apply to Route
		Mirroring messages because the sender may not be aware of the payload
		of the transported BGP Update message.
	    </t>
	</section>

        <section title="BMP Message Format">
            <section title="Common Header" anchor="CommonHeader">
                <t>
		    <xref section="4.1" sectionFormat="of" target="RFC7854"/> defines
			the Common Header. While the structure remains unaltered, the
			following two definitions are changed:
		     
		    <list style="symbols">
			<t>
				Version: Indicates the BMP version. This is set
				to '4' for all message types defined in
				<xref target="RFC7854">RFC 7854</xref>.
			</t>
			<t>
				Message Length: Total length of the message in
				bytes (including headers, encapsulated BGP Message
				PDU TLV and optional TLV data).
			</t>
		    </list> 
                </t>
            </section>
	    <section title="TLV data in Route Monitoring" anchor="TLVinRM">
		<t>
		    The Route Monitoring message type is defined in <xref section="4.6"
			sectionFormat="of" target="RFC7854"/>. The consistency model
			selected by this document to extend encoding of such message type
			with TLVs is with the Route Mirroring type defined in <xref
			section="4.7" sectionFormat="of" target="RFC7854"/> where the
		    Per-peer header is being followed by mandatory and optional TLVs.  
		</t>
		<t>
		    The BGP Update PDU <xref section="4.3" sectionFormat="of"
			target="RFC4271"/> is encoded itself as part of a BGP Message TLV
			with code point &IANA_RM_CODE_BGP_PDU; and index set to zero. A Route
			Monitoring message MUST contain one BGP Message TLV which may be
			preceeded and/or followed by other optional TLV data.
		</t>
		<t>
		    Corollary, in BMPv4 the BGP Update PDU is not just encoded as part
		    of the message as it was the case for BMPv3 but it is rather enclosed
		    in a TLV.
		</t>
	    <section title="Group TLV" anchor="GroupTLVinRM">
		<t>
		    In a Route Monitoring message where the BGP Update PDU carries N
		    NLRIs, indexed TLVs do allow to handle the cases of 1:1 and N:1
		    relationship among TLVs and NLRIs (ie. one TLV applies to one
		    NLRI, N TLVs apply to one same NLRI). The cases of 1:N and M:N
		    relationships (ie. one TLV applies to N NLRIs, M TLVs apply to
		    N NLRIs) can benefit by a form of grouping. This is the context
		    to define a Group TLV to achieve this with the aim to limit both
		    verbosity and repetitions.
		</t>
		<t>
		    The TLV value MUST contain:
		    <list style="symbols">
		    <t>A 2 bytes Group Index where the top-most bit, G-bit or Group
		    Bit MUST be set to one (1). The full 2 bytes value, that is
		    including the G-bit, MUST be unique to the message</t>
		    <t>Two or more 2 bytes NLRI indexes whose values MUST be less
		    or equal to the amount of NLRIs packed in the BGP Update PDU.</t>
		    </list>
		    A NLRI index can be listed as part of multiple Group TLVs within
		    the same message. NLRI indexes within a Group TLV SHOULD be sorted
		    by the sender. A Group Index can not reference an NLRI index 0.
		    A Group TLV MUST NOT include its own or another Group Index.
		    Multiple non-Group TLVs can point to the same Group Index, ie. a
		    group can be reused within the same Route Monitoring message.
		</t>
		<t>
		    The Group TLV code point is &IANA_RM_CODE_GROUP;. It is recommended
		    that this TLV is encoded first in order to ease parsing of the
            Route Monitoring message at the BMP station side.
		</t>
	    </section>
	    <section title="VRF/Table Name TLV" anchor="VrfTLVinRM">
		<t>
		    The Information field contains a UTF-8 string whose value MUST
		    be equal to the value of the VRF or table name (ie. RD instance
		    name) being conveyed.  The string size MUST be within the range
		    of 1 to 255 bytes.
		</t>
		<t>
		    The VRF/Table Name TLV code point is &IANA_RM_CODE_VRF;
		</t>
	    </section>
	    <section title="Stateless parsing TLV" anchor="SpTLVinRM">
		<t>
		    Stateless parsing helps scaling the amount of Route Monitoring
		    messages that can be processed at collection time, avoiding to
		    have to correlate them to BGP capabilities received as part of
		    the Peer Up message, for example.
		</t>
		<t>
		    Some BGP capabilities are not per AFI/SAFI, like 4-bytes ASN
		    <xref target="RFC6793">RFC 6793</xref>, and hence these can
		    potentially be part of the BMP Peer flags section of a Route
		    Monitoring message. Those that are, instead, per AFI/SAFI
		    require finer granularity and hence the need to use an indexed
		    TLV.
		</t>
		<t>
		    The Stateless Parsing TLV code point is &IANA_RM_CODE_SP; and
		    its Value is organized as follows:

		    <list style="symbols">
		    <t>Capability Type, 1 byte</t>
		    <t>Capability Value, variable length</t>
		    </list>
		</t>
		<t>
		    The Capability Type field encodes a code point from the <xref
		    target="IANA-BCC">BGP Capabilities Codes</xref> registry defined 
		    by <xref target="RFC5492">RFC 5492</xref>.
		</t>
		<t>
		    The Capability Value encodes the BGP capability exactly as it
		    is encoded in the BGP Open of the session. For example, an
		    ADD-PATH capability, as defined by <xref target="RFC7911">RFC
		    7911</xref>, for IP/Unicast with value Send/Receive would be
		    encoded in the Capability Value as: 
		</t>  
		<t>
		    <list style="symbols">
		    <t>AFI, 2 bytes, value=1</t>
		    <t>SAFI, 1 byte, value=1</t>
	            <t>Value, 1 byte, value=3</t>
		    </list>
		</t>
		<t>
		    The index of the Stateless Parsing TLV MUST be set to zero. 
		</t>
		<t>
		    If no Stateless Parsing TLV is present in a Route Monitoring
		    message, the receiver MUST fall back to use capabilities present
		    in the BGP Open PDU contained in the relevant BMP Peer Up message
		    in order to properly parse BGP Update PDUs. Each BGP capability  
		    is to be encoded in a separate Stateless Parsing TLV.
		</t>
		<t>
		    It is recommended that the Stateless Parsing TLV is encoded
		    preceeding the BGP Message TLV in order to ease parsing of the
		    Route Monitoring message at the BMP station side.
		</t>
	    </section>
        <section title="Wire-format example" anchor="TLVexample">
            <t>
                The diagram in <xref target="BMP-RM-TLVs"/> shows an example of a
                Route Monitoring message carrying a BGP UPDATE containing 10
                NLRIs. The TLVs are comprised of:
                <list style="numbers">
                    <t>
                        a Group TLV with index 0x000b, pointing to NLRI 1, 2, 3
                        and 10
                    </t>
                    <t>
                        a Group TLV with index 0x000c, pointing to NLRI 4, 5 and
                        6
                    </t>
		    <t>
			a Stateless Parsing TLV with index 0x0000
		    </t>
                    <t>
			a TLV pertaining to NLRI 7
		    </t>
                    <t>
                        a TLV pertaining to the NLRIs listed in the Group TLV
                        defined in 1
                    </t>
                    <t>
                        a TLV pertaining to the NLRIs listed in the Group TLV
                        defined in 2
                    </t>
                </list>
            </t>
            <t>
                <figure anchor="BMP-RM-TLVs" align="center">
                    <artwork align="center">
                        <![CDATA[
   0                   1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |        Common Header + Per-Peer Header (6 + 42 bytes)         ~
  ~                                                               |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |            type=TBD2            |         length=0x0008       |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |1|           index=0x000b        |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                  value={0x0001,   0x0002,                     |
  |                         0x0003,   0x000a}                     |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |            type=TBD2            |         length=0x0006       |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |1|           index=0x000c        |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                  value={0x0004,   0x0005,                     |
  |                         0x0006} |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |            type=TBD4            |         length=0x0005       |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |0|           index=0             |     cap=69    |	 afi=1	  ~ 
  ~                 |     safi=1    |    value=3    |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |            type=TBD1            |         length=X            |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |0|           index=0             |    value=$BGP_UPDATE_PDU{   ~
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                             ~
  ~                                                               ~
  ~                       NLRI_1 .. NLRI_10                       ~
  ~                                                            }  |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |            type=SomeTlvX        |         length=0x0004       |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |1|           index=0x000b        |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                          value={4 bytes}                      |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |            type=SomeTlvY        |         length=0x0008       |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |1|           index=0x000c        |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                          value={8 bytes}                      ~
  ~                                                               |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |            type=SomeTlvZ        |         length=0x0008       |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |0|           index=0x0007        |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                          value={8 bytes}                      ~
  ~                                                               |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                            ]]>
                    </artwork>
                </figure>
            </t>
        </section>
        </section>
	    <section title="TLV data in Peer Down" anchor="TLVinPD">
		<t>
		    The Peer Down Notification message type is defined in 
			<xref section="4.9" sectionFormat="of" target="RFC7854"/>.
		    The consistency model selected by this document to extend encoding
		    of such message type is with the Peer Up type defined in
		    <xref section="4.10" sectionFormat="of" target="RFC7854"/> where
			optional TLVs are placed at the end of the message.
		</t>
		<t>
		    This means for Reason codes 1 or 3, a BGP Notification
		    PDU follows; the PDU MAY be further followed by optional
		    TLV data. For Reason code 2, a 2-byte field follows to
		    provide additional FSM info; this field MAY be followed
		    by optional TLV data. For all other Reason codes, optional
		    TLV data MAY follow the Reason field.
		</t>
	    </section>
	    <section title="TLV data in other BMP messages" anchor="TLVinOther">
		<t>
		    All other message types defined in <xref target="RFC7854">RFC7854</xref>
		    do already provision for TLV data. It is RECOMMENDED that
		    all future defined BMP message types will also provide for
		    optional TLV data following a consistency model for encoding
		    with existing message types.
		</t>
	    </section>
        </section>

        <section title="Error handling">
	    <t>
		It is worth nothing that <xref target="RFC8654">RFC8654</xref>
		permits BGP Update and other messages to grow to a length of
		65535 octets. This may cause a BMP PDU that attempts to encapsulate
		such long messages to overflow.
	    </t>
        </section>

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

        <section title="Operational Considerations">
            <t>
                In Route Monitoring messages, the number of TLVs can be bound to
		the amount of NLRIs carried in the BGP Update message. This may
		degrade the packing of information in such messages and have
		specific impacts on the memory and CPU used in a BMP implementation.
		As a result of that it should always be possible to disable such
		features to mitigate their impact.
            </t>
        </section>

        <section title="IANA Considerations">
            <t>
		This document requests the renaming of the "Peer Up TLVs" registry defined by
		<xref target="I-D.ietf-grow-bmp-peer-up">BMP Peer Up Message Namespace</xref>
		into "Peer Up and Peer Down TLVs" and the definition of one new registry "BMP
		Route Monitoring TLVs". As part of the "BMP Route Monitoring TLVs" registry,
		the following new TLV types are defined (<xref target="TLVinRM"/>):

		<list style="symbols">
		    <t>
			Type = &IANA_RM_CODE_BGP_PDU;: Support for BGP Message TLV. The value
			field is defined in <xref target="TLVinRM"/>
		    </t>
		    <t>
			Type = &IANA_RM_CODE_GROUP;: Support for grouping of TLVs. The value
			field is defined in <xref target="GroupTLVinRM"/>. The recommended
			value for this TLV is 0.
		    </t>
		    <t>
			Type = &IANA_RM_CODE_VRF;: Support for VRF/Table Name TLV. The value
			field is defined in <xref target="VrfTLVinRM"/>
		    </t>
		    <t>
			Type = &IANA_RM_CODE_SP;: Support for Stateless Parsing TLV. The value
			field is defined in <xref target="SpTLVinRM"/>. The recommended value
			for this TLV is 1.
		    </t>
		</list>
            </t>
        </section>

    </middle>

    <back>

        <references title="Normative References">
		&RFC2119;
		&RFC8174;

		<?rfc include="reference.RFC.4271.xml"?>
		<?rfc include="reference.RFC.7854.xml"?>
		<?rfc include="reference.RFC.6793.xml"?>
		<?rfc include="reference.RFC.8654.xml"?>
		<?rfc include="reference.RFC.9069.xml"?>

		&I-D.ietf-grow-bmp-peer-up;
        </references>
	<references title="Informative References">
                <?rfc include="reference.RFC.5492.xml"?>
		<?rfc include="reference.RFC.7911.xml"?>
                <reference anchor="IANA-BCC" target="https://www.iana.org/assignments/capability-codes/">
                        <front>
                                <title>
                                        Capabilities Codes
                                </title>
                                <author>
                                        <organization>
                                                IANA
                                        </organization>
                                </author>
                                <date year="2025" />
                        </front>
                </reference>
        </references>

        <section anchor="Acknowledgements" title="Acknowledgements" numbered="no">
            <t>
		The authors would like to thank Jeff Haas, Camilo Cardona, Thomas Graf,
		Pierre Francois, Ben Maddison, Tim Evens, Luuk Hendriks, Maxence Younsi,
		Ahmed Elhassany, Colin Petrie, Dhananjay Pakti and Shunwan Zhuang for
		their valuable input. The authors would also like to thank Greg Skinner
		and Zongpeng Du for their review.
            </t>
        </section>

    </back>
</rfc>