<?xmlversion="1.0" encoding="US-ASCII"?> <!-- This template is for creating an Internet Draft using xml2rfc, which is available here: http://xml.resource.org. -->version='1.0' encoding='UTF-8'?> <!DOCTYPE rfcSYSTEM "rfc2629.dtd"[ <!ENTITY nbsp " "> <!ENTITY zwsp "​"> <!ENTITY nbhy "‑"> <!ENTITY wj "⁠"> ]><?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?> <!-- used by XSLT processors --> <!-- For a complete list and description of processing instructions (PIs), please see http://xml.resource.org/authoring/README.html. --> <!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds might want to use. (Here they are set differently than their defaults in xml2rfc v1.32) --> <?rfc strict="yes" ?> <!-- give errors regarding ID-nits and DTD validation --> <!-- control the table of contents (ToC) --> <?rfc toc="yes"?> <!-- generate a ToC --> <?rfc tocdepth="4"?> <!-- the number of levels of subsections in ToC. default: 3 --> <!-- control references --> <?rfc symrefs="yes"?> <!-- use symbolic references tags, i.e, [RFC2119] instead of [1] --> <?rfc sortrefs="yes" ?> <!-- sort the reference entries alphabetically --> <!-- control vertical white space (using these PIs as follows is recommended by the RFC Editor) --> <?rfc compact="yes" ?> <!-- do not start each main section on a new page --> <?rfc subcompact="no" ?> <!-- keep one blank line between list items --> <!-- end of list of popular I-D processing instructions --><rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="std" docName="draft-ietf-grow-bmp-peer-up-05" number="9736" ipr="trust200902" updates="7854, 8671, 9069"consensus="true"> <!-- category values: std, bcp, info, exp, and historic ipr values: full3667, noModification3667, noDerivatives3667 you can add the attributes updates="NNNN" and obsoletes="NNNN" they will automatically be output with "(if approved)" --> <!-- ***** FRONT MATTER ***** -->consensus="true" obsoletes="" submissionType="IETF" xml:lang="en" tocInclude="true" tocDepth="4" symRefs="true" sortRefs="true" version="3"> <front> <title abbrev="BMP Peer UpNamespace"> BMPNamespace">The BGP Monitoring Protocol (BMP) Peer Up Message Namespace</title><!-- add 'role="editor"' below for the editors if appropriate --> <!-- Another author who claims to be an editor --><seriesInfo name="RFC" value="9736"/> <author fullname="John Scudder"initials="J.S."initials="J." surname="Scudder"> <organization>Juniper Networks</organization> <address> <postal> <street>1194 N. Mathilda Ave</street><!-- Reorder these if your country does things differently --><city>Sunnyvale</city> <region>CA</region> <code>94089</code><country>USA</country><country>United States of America</country> </postal> <email>jgs@juniper.net</email><!-- uri and facsimile elements may also be added --></address> </author> <author fullname="Paolo Lucente"initials="P"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><code>3771 MT</code> <country>Netherlands</country> </postal> <email>paolo@ntt.net</email> </address> </author> <dateyear="2024" /> <!-- Meta-data Declarations --> <area>General</area> <workgroup>GROW</workgroup>year="2025" month="February"/> <area>OPS</area> <workgroup>grow</workgroup> <keyword>IDR</keyword> <keyword>GROW</keyword> <keyword>BGP</keyword> <keyword>BMP</keyword> <abstract> <t> RFC 7854, the BGP MonitoringProtocol,Protocol (BMP), uses different message types for different purposes. Most of these are structured as Type, Length, Value(TLV) structured.(TLV). One message type, the Peer Up message, lacks a set of TLVs defined for its use, instead sharing a namespace with the Initiation message.Subsequent experienceExperience has shown that this namespace sharing was a mistake, as it hampers the extension of theprotocol. </t>protocol.</t> <t> This document updates RFC 7854 by creating an independent namespace for the Peer Up message. It also updates RFC 8671 and RFC 9069 by movingthedefined codepointsininto the newly introduced registry. Compliant implementations of RFC 7854, RFC86718671, and RFC 9069 also comply with this specification. </t> </abstract> </front> <middle> <section anchor="introduction"title="Introduction">numbered="true" toc="default"> <name>Introduction</name> <t> <xreftarget="RFC7854"/>target="RFC7854" format="default"/> defines a number of different BMP message types. With the exception of the Route Monitoring message type, these messages are TLV-structured. Most message types have distinct namespaces and IANA registries. However, the namespace of the Peer Up message overlaps that of the Initiation message. As the BGP Monitoring Protocol has been extended, thisoversightoverlap has become problematic. In this document, we createadistinctnamespacenamespaces for the Peer Upmessageand Initiation messages to eliminatethis overlap, and createthecorresponding missing registry.overlap. </t><!--We also supply a definition of "string" for convenience, since TLVs from multiple different registries include a string. --><t> Compliant implementations of <xreftarget="RFC7854"/>,target="RFC7854" format="default"/>, <xreftarget="RFC8671"/>target="RFC8671" format="default"/>, and <xreftarget="RFC9069"/>target="RFC9069" format="default"/> also comply with this specification. </t> <sectiontitle="Requirements Language"> <t>Thenumbered="true" toc="default"> <name>Requirements Language</name> <t> The key words"MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY","<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>", "<bcp14>MAY</bcp14>", and"OPTIONAL""<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as described inBCP 14BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, they appear in all capitals, as shownhere.</t>here. </t> </section> </section> <section anchor="string"title="String Definition">numbered="true" toc="default"> <name>String Definition</name> <t> A string TLV is a free-form sequence of UTF-8 characters whose length in bytes is given by the TLV's Length field. There is no requirement to terminate the string with a null (or any other particular) character -- the Length field gives its termination. </t> </section> <sectiontitle="Changesnumbered="true" toc="default"> <name>Changes toexisting RFCs">Existing RFCs</name> <t> <xreftarget="RFC7854"/>target="RFC7854" format="default"/> is updated as detailed in the followingsub-sections.subsections. </t> <section anchor="init_info_tlv"title="Revisionnumbered="true" toc="default"> <name>Revision to the InformationTLV, Renamed as Initiation Information TLV">TLV</name> <t> The Information TLV defined insection 4.4 of<xreftarget="RFC7854"/>target="RFC7854" sectionFormat="of" section="4.4"/> is renamed "Initiation Information TLV". It is used only by the Initiation message, not by the Peer Upmessage. </t>message.</t> <t> The definition of Type = 0 is revisedto be: <list style="symbols">as shown below. Type = 1 and Type = 2 are unchanged; they are provided for here for completeness. </t> <ul spacing="normal"> <li> <t> Type = 0: String. The Information field contains a <xreftarget="string">string</xref>.target="string" format="default">string</xref>. The value is administratively assigned. If multiple string TLVs are included, their orderingMUST<bcp14>MUST</bcp14> be preserved when they are reported. </t> </li> <li> <t> Type = 1: sysDescr. The Information field contains an ASCII string whose valueMUST<bcp14>MUST</bcp14> be set to be equal to the value of the sysDescr MIB-II <xreftarget="RFC1213"/>target="RFC1213" format="default"/> object. </t> </li> <li> <t> Type = 2: sysName. The Information field contains an ASCII string whose valueMUST<bcp14>MUST</bcp14> be set to be equal to the value of the sysName MIB-II <xreftarget="RFC1213"/>target="RFC1213" format="default"/> object. </t></list> </t></li> </ul> </section> <sectiontitle="Revisionnumbered="true" toc="default"> <name>Revision to the Peer UpNotification"> <t> TheNotification</name> <t>The final paragraph ofsection 4.10 of<xreftarget="RFC7854"/>target="RFC7854" sectionFormat="of" section="4.10"/> references the Information TLV (which is revised <xreftarget="init_info_tlv">above</xref>).target="init_info_tlv" format="default">above</xref>). That paragraph is replaced by the following:<list style="symbols"></t> <ul spacing="normal"> <li> <t> Information: Information about the peer, using the Peer Up Information TLV format defined in <xreftarget="peer_up_info_tlv">below</xref>.target="peer_up_info_tlv" format="default"/> of RFC 9736. The String type may be repeated. Inclusion of the Information field isOPTIONAL.<bcp14>OPTIONAL</bcp14>. Its presence or absence can be inferred by inspection of the Message Length in the common header. </t></list> </t></li> </ul> </section> <section anchor="peer_up_info_tlv"title="Definitionnumbered="true" toc="default"> <name>Definition of Peer Up InformationTLV">TLV</name> <t> The Peer Up Information TLV is used by the Peer Up message. </t><figure align="center"><!-- [rfced] Please confirm that the bit ruler appears as expected. Typically the numbers appear over the hyphens. Compare the alignment with the figure in Section 4.4 of RFC 7854 <https://www.rfc-editor.org/rfc/rfc7854.html#section-4.4>. Original (this doc): 0 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ --> <artworkalign="center"><![CDATA[align="center" name="" type="" alt=""><![CDATA[ 0 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Information Type | Information Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Information (variable) | ~ ~+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ]]></artwork> </figure> <t> <list style="symbols">+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork> <ul spacing="normal"> <li> <t> Information Type (2 bytes): defined typesare: <list style="symbols"> <t> Typeare:</t> <ul spacing="normal"> <li> <t>Type = 0: String. The Information field contains a <xreftarget="string">string</xref>.target="string" format="default">string</xref>. The value is administratively assigned. If multiple strings are included, their orderingMUST<bcp14>MUST</bcp14> be preserved when they arereported. </t> <t> Typereported.</t> </li> <li> <t>Type = 3: VRF/Table Name. The Information field contains a UTF-8 string whose valueMUST<bcp14>MUST</bcp14> be equal to the value of the VRF or table name (e.g., RD instance name) being conveyed. The string sizeMUST<bcp14>MUST</bcp14> be within the range of 1 to 255bytes. </t>bytes.</t> </li> <li> <t> Type = 4: Admin Label. The Information field contains a free-form UTF-8 string whose byte length is given by the Information Length field. The value is administratively assigned. There is no requirement to terminate the string a with null or any othercharacter. </t> </list> </t> <t> Informationcharacter.</t> </li> </ul> </li> <li> <t>Information Length (2 bytes): The length of the following Information field, inbytes. </t> <t> Informationbytes.</t> </li> <li> <t>Information (variable): Information about the monitored router, according to thetype. </t> </list> </t>type.</t> </li> </ul> </section> </section> <section anchor="IANA"title="IANA Considerations">numbered="true" toc="default"> <name>IANA Considerations</name> <t> IANAis requested to create a registry withinhas created theBMP group, named"BMP Peer Up MessageTLVs", referenceTLVs" within the "BGP Monitoring Protocol (BMP) Parameters" registry group and listed thisdocument.document as the reference. </t> <t> Registration procedures for this registryare: </t> <texttable> <ttcol align='center'>Range</ttcol> <ttcol align='center'>Registration Procedures</ttcol> <c>0, 3-32767</c> <c>Standards Action</c> <c>32768-65530</c> <c>First Come,are:</t> <table align="center"> <thead> <tr> <th align="left">Range</th> <th align="left">Registration Procedures</th> </tr> </thead> <tbody> <tr> <td align="left">0, 3-32767</td> <td align="left">Standards Action</td> </tr> <tr> <td align="left">32768-65530</td> <td align="left">First Come FirstServed</c> <c>65531-65534</c> <c>Experimental</c> <c>1-2, 65535</c> <c>Reserved</c> </texttable>Served</td> </tr> <tr> <td align="left">65531-65534</td> <td align="left">Experimental</td> </tr> <tr> <td align="left">1-2, 65535</td> <td align="left">Reserved</td> </tr> </tbody> </table> <t>InitialThe initial values for this registry are: </t><texttable> <ttcol align='center'>Type</ttcol> <ttcol align='center'>Description</ttcol> <ttcol align='center'>Reference</ttcol> <c>0</c> <c>String</c> <c>this document</c> <c>1</c> <c>Reserved</c> <c>this document</c> <c>2</c> <c>Reserved</c> <c>this document</c> <c>3</c> <c>VRF/Table Name</c> <c>this document</c> <c>4</c> <c>Admin Label</c> <c>this document</c> <c>65535</c> <c>Reserved</c> <c>this document</c> </texttable><table align="center"> <thead> <tr> <th align="center">Type</th> <th align="center">Description</th> <th align="center">Reference</th> </tr> </thead> <tbody> <tr> <td align="center">0</td> <td align="center">String</td> <td align="center">RFC 9736</td> </tr> <tr> <td align="center">1</td> <td align="center">Reserved</td> <td align="center">RFC 9736</td> </tr> <tr> <td align="center">2</td> <td align="center">Reserved</td> <td align="center">RFC 9736</td> </tr> <tr> <td align="center">3</td> <td align="center">VRF/Table Name</td> <td align="center">RFC 9736</td> </tr> <tr> <td align="center">4</td> <td align="center">Admin Label</td> <td align="center">RFC 9736</td> </tr> <tr> <td align="center">65535</td> <td align="center">Reserved</td> <td align="center">RFC 9736</td> </tr> </tbody> </table> <t> IANAishas alsorequested to renamerenamed theexisting"BMP Initiation and Peer Up Information TLVs" registry to "BMP Initiation Information TLVs" andseedpopulated it with the following values: </t><texttable> <ttcol align='center'>Type</ttcol> <ttcol align='center'>Description</ttcol> <ttcol align='center'>Reference</ttcol> <c>0</c> <c>String</c> <c>this document</c> <c>1</c> <c>sysDescr</c> <c>this document</c> <c>2</c> <c>sysName</c> <c>this document</c> <c>3</c> <c>Reserved</c> <c>this document</c> <c>4</c> <c>Reserved</c> <c>this document</c> <c>65535</c> <c>Reserved</c> <c>this document</c> </texttable><table align="center"> <thead> <tr> <th align="left">Type</th> <th align="left">Description</th> <th align="left">Reference</th> </tr> </thead> <tbody> <tr> <td align="left">0</td> <td align="left">String</td> <td align="left">RFC 9736</td> </tr> <tr> <td align="left">1</td> <td align="left">sysDescr</td> <td align="left">RFC 9736</td> </tr> <tr> <td align="left">2</td> <td align="left">sysName</td> <td align="left">RFC 9736</td> </tr> <tr> <td align="left">3</td> <td align="left">Reserved</td> <td align="left">RFC 9736</td> </tr> <tr> <td align="left">4</td> <td align="left">Reserved</td> <td align="left">RFC 9736</td> </tr> <tr> <td align="left">65535</td> <td align="left">Reserved</td> <td align="left">RFC 9736</td> </tr> </tbody> </table> </section> <section anchor="Security"title="Security Considerations">numbered="true" toc="default"> <name>Security Considerations</name> <t> This document does not alter the security considerations of <xreftarget="RFC7854"/> whichtarget="RFC7854" format="default"/> that continue to apply. </t> </section><section anchor="Implementation" title="Implementation status - RFC EDITOR: REMOVE BEFORE PUBLICATION"> <t> This section records the status of known implementations of the protocol defined by this specification at the time of posting of this Internet-Draft. The description of implementations in this section is intended to assist the IETF in its decision processes in progressing drafts to RFCs. Please note that the listing of any individual implementation here does not imply endorsement by the IETF. Furthermore, no effort has been spent to verify the information presented here that was supplied by IETF contributors. This is not intended as, and must not be construed to be, a catalog of available implementations or their features. Readers are advised to note that other implementations may exist. </t> <t> As of today these vendors have produced an implementation of the BMP Peer Up Namespace: <list style="symbols"> <t>FRRouting</t> <t>pmacct</t> </list> </t> </section></middle> <back> <references> <name>Normative References</name> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.1213.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7854.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8671.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9069.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/> </references> <section anchor="Acknowledgements"title="Acknowledgements"> <t> Thenumbered="false" toc="default"> <name>Acknowledgements</name> <t>The authors would like to thankMaxence Younsi<contact fullname="Maxence Younsi"/> for hisreview. </t>review.</t> </section></middle> <!-- *****BACK MATTER ***** --> <back> <references title="Normative References"> <!--?rfc include= "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml"?--> <?rfc include="reference.RFC.2119.xml"?> <?rfc include="reference.RFC.1213.xml"?> <?rfc include="reference.RFC.7854.xml"?> <?rfc include="reference.RFC.8671.xml"?> <?rfc include="reference.RFC.9069.xml"?> <?rfc include="reference.RFC.8174.xml"?> <!-- <?rfc include="reference.RFC.8126.xml"?> --> </references></back> </rfc>