draft-ietf-grow-bmp-tlv-ebit.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 I-D.ietf-grow-bmp-tlv SYSTEM "https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-grow-bmp-tlv.xml">
        <!ENTITY IANA_RM_CODE_4B_ASN "TBD1">
        <!ENTITY IANA_RM_CODE_PATH_ID "TBD2">
        <!ENTITY IANA_RM_CODE_MULTI_LABELS "TBD3">
        ]>

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

    <front>
        <title abbrev="BMP TLV EBIT">
	    Support for Enterprise-specific TLVs in the BGP Monitoring Protocol
	</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="2024"/>

        <area>General</area>

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

        <abstract>
            <t>
		Message types defined by the BGP Monitoring Protocol (BMP) do provision
		for data in TLV - Type, Length, Value - format, either in the shape of
		a TLV message body, ie. Route Mirroring and Stats Reports, or optional
		TLVs at the end of a BMP message, ie. Peer Up and Peer Down. However
		the space for Type value is unique and governed by IANA. To allow the usage
		of vendor-specific TLVs, a mechanism to define per-vendor Type values is
		required. In this document we introduce an Enterprise Bit, or E-bit, for
		such purpose.
            </t>
        </abstract>
    </front>

    <middle>
        <section title="Introduction" anchor="Introduction">
            <t>
		The BGP Monitoring Protocol (BMP) is defined in <xref target="RFC7854">RFC 7854</xref>.
		Support for TLV data is extended by <xref target="I-D.ietf-grow-bmp-tlv">TLV
		support for BMP Route Monitoring and Peer Down Messages</xref>. 
	   </t>
           <t>
		Vendors need the ability to define proprietary Information Elements for
		various reasons such as delivering a pre-standard product. This aligns
		with <xref target="RFC8126">Section 4.1 of</xref>.
	   </t>
	   <t>
		Also for code point assignment to be eligible, an IETF document needs to
		be adopted at a Working Group and in a stable condition. In this context
		E-bit helps during early development phases where inter-operability among
		vendors is tested and shipped to network operators for testing. This aligns
		with <xref target="RFC8126">Section 4.2 of</xref>.
	   </t>
	   <t>
		This document re-defines the format of IANA-registered TLVs in a
		backward compatible manner with respect to previous documents and
		existing IANA allocations; it also defines the format for newly
		introduced enterprise-specific TLVs. 
	   </t>
	   <t>
		The concept of an E-bit, or Enterprise Bit, is not new. For example,
		such mechanism is defined in <xref target="RFC7011">Section 3.2 of</xref>
		for a very similar purpose.
           </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="TLV encoding">

	<section title="IANA-registered TLV encoding">
	    <t>
		Existing TLV encodings are defined in <xref target="RFC7854">Section 4.4 of</xref>
		(Information TLVs), <xref target="RFC7854">Section 4.7 of</xref> (Route Mirroring
                TLVs), <xref target="RFC7854">Section 4.8 of</xref> (Stats Reports
		TLVs), <xref target="I-D.ietf-grow-bmp-tlv">draft-ietf-grow-bmp-tlv</xref> and
		<xref target="I-D.ietf-grow-bmp-peer-up">draft-ietf-grow-bmp-peer-up</xref> and
		are updated as follows:
	    </t>
	    <t>
		<list style="symbols">
		    <t>
			1 bit to flag an enterprise-specific TLV, set to zero. The
			TLV Type value must have been defined in <xref target="IANA-BMP">IANA-BMP</xref>  
		    </t>
		    <t>
			15 bits of TLV Type,
		    </t>
		    <t>
			2 octets of TLV Value length,
		    </t>
		    <t>
			0 or more octets of TLV Value.
		    </t>
		</list>
	    </t>

	    <figure anchor="BMP-TLV-public-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
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |E|             Type            |     Length (2 octets)         |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                        Value (variable)                       |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	    	    ]]>
	    	</artwork>
	    </figure>
	</section>

	<section title="Enterprise-specific TLV encoding">
	    <t>
		Enterprise-specific TLV encoding is defined as follows:
	    </t>
	    <t>
		<list style="symbols">
		    <t>
			1 bit to flag an enterprise-specific TLV, set to one
		    </t>
		    <t>
			15 bits of TLV Type,
		    </t>
		    <t>
			2 octets of TLV length. Comprising length of IANA PEN plus TLV value,
		    </t>
		    <t>
			4 octets of IANA Private Enterprise Number <xref target="IANA-PEN">IANA-PEN</xref>
		    </t>
		    <t>
			0 or more octets of TLV Value.
		    </t>
		</list>
	    </t>

	    <figure anchor="BMP-TLV-enterprise-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
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |E|             Type            |     Length (2 octets)         |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                        Enterprise number                      |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                        Value (variable)                       |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	    	    ]]>
	    	</artwork>
	    </figure>
	    <t>
		In case of indexed TLVs, as defined by
		<xref target="I-D.ietf-grow-bmp-tlv">TLV support for BMP Route
                Monitoring and Peer Down Messages</xref>, the index value precedes
		the Enterprise number. 
	    </t>

	    <figure anchor="BMP-TLV-enterprise-index-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
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |E|             Type            |     Length (2 octets)         |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |        Index (2 octets)       |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                        Enterprise number                      |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                        Value (variable)                       |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	    	    ]]>
	    	</artwork>
	    </figure>
	</section>

	<section title="TLV encoding remarks">
	    <t>
		The TLV encoding specified in this document applies to all existing
		BMP Message Types and their namespaces defined in <xref target="RFC7854">RFC 7854</xref>,
		<xref target="I-D.ietf-grow-bmp-tlv">TLV support for BMP Route
		Monitoring and Peer Down Messages</xref> and
		<xref target="I-D.ietf-grow-bmp-peer-up">BMP Peer Up Message
		Namespace</xref>.
	    </t>
	    <t>
		Stats Report messages are also encoded in a TLV-like fashion, as
		documented in <xref target="RFC7854">Section 4.8 of</xref>. E-bit
		does hence similarly apply to these messages too, with the most
		relevant bit of Stat Type set to 1 in order to flag the presence
		of a 4-bytes PEN field following Stat Len field and preeceding Stat
		Data field, ie.:
	    </t>
	    <figure anchor="BMP-Stats-Report-enterprise--header" 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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |E|       Stat Type             |          Stat Len             |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                        Enterprise number                      |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                        Stat Data                              |
     ~                                                               ~
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	    	    ]]>
	    	</artwork>
	    </figure>
	    <t>
		While the proposed encoding is not per-se backward compatible, there
		is no existing IANA-allocated Type value that makes use of the most
		significant bit (which is being used in this document to define the
		E-bit), except the experimental and reserved ones mentioned in
		<xref target="RFC7854">Section 10.5 of</xref>,
		<xref target="RFC7854">Section 10.6 of</xref> and
		<xref target="RFC7854">Section 10.9 of</xref>. Of these, the
		Experimental values are being suppressed in favor of using the E-bit
		mechanism described in this document; the Reserved value is instead
		excluded by the E-bit mechanism such that no PEN will be included
		as part of the TLV.
	    </t>
	    <t>
		Future BMP Message Types MUST make use of the TLV encoding defined
		in this document.
	    </t>
	    <t>
		This document refers to <xref target="I-D.ietf-grow-bmp-tlv">TLV
		support for BMP Route Monitoring and Peer Down Messages</xref> for
		any recommendations regarding the use of TLVs (ie. repetitions,
		ordering, etc.).
	    </t>
	</section>

	</section>

        <section title="Security Considerations">
            <t>
                This document does not add any additional security considerations.
            </t>
        </section>

        <section title="Operational Considerations">
	    <t>
		It is recommended that vendors making use of the Enterprise Bit
		extension have a well-defined internal registry for privately
		assigned code points that is also exposed to the public.
	    </t>
        </section>

        <section title="IANA Considerations">
            <t>
		The TLV Type values used by BMP are managed by IANA as are the
		Private Enterprise Numbers used by enterprise-specific Type
		values <xref target="IANA-PEN">IANA-PEN</xref>.
            </t>

	    <t>
		This document requests to remove the Experimental allocation from
		BMP Initiation and Peer Up Information TLVs, BMP Termination Message
		TLVs and BMP Route Mirroring TLVs registries as the equivalent action
		(ie. expressing experimental values) will be instead performed as
		described in this document, ie. by setting the E-bit and defining
		the relevant PEN.
	    </t>
        </section>

    </middle>

    <back>

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

		<?rfc include="reference.RFC.8126.xml"?>
		<?rfc include="reference.RFC.7854.xml"?>

		&I-D.ietf-grow-bmp-peer-up;
		&I-D.ietf-grow-bmp-tlv;
        </references>

        <references title="Informative References">
		<?rfc include="reference.RFC.7011.xml"?>
		<reference anchor="IANA-PEN" target="http://www.iana.org/assignments/enterprise-numbers/">
			<front>
				<title>
					Private Enterprise Numbers
				</title>
				<author>
					<organization>
						IANA
					</organization>
				</author>
				<date year="1982" />
			</front>
		</reference>
		<reference anchor="IANA-BMP" target="https://www.iana.org/assignments/bmp-parameters/bmp-parameters.xhtml">
			<front>
				<title>
					BGP Monitoring Protocol (BMP) Parameters
				</title>
				<author>
					<organization>
						IANA
					</organization>
				</author>
				<date year="2016" />
			</front>
		</reference>
        </references>

        <section anchor="Acknowledgements" title="Acknowledgements" numbered="no">
            <t>
		The authors would like to thank Thomas Graf, Jeff Haas, Pierre Francois,
		Camilo Cardona, Ahmed Elhassany and Luuk Hendriks for their valuable input.
            </t>
        </section>

    </back>
</rfc>