<?xml version="1.0" encoding="UTF-8"?>
<!-- This template is for creating an Internet Draft using xml2rfc,
    which is available here: http://xml.resource.org. -->
<!-- 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 submissionType="IETF" category="std" docName="draft-lin-grow-bmp-peer-interface-01"
ipr="trust200902" consensus="true" updates="" xmlns:xi="http://www.w3.org/2001/XInclude">
  <!-- 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 ***** -->

  <front>
    <title abbrev="BMP Peer Interface">
    Extension for BMP Peer Interface</title>

    <!-- add 'role="editor"' below for the editors if appropriate -->

    <!-- Another author who claims to be an editor -->
    <author fullname="Changwang Lin" initials="C." surname="Lin">
      <organization>New H3C Technologies</organization>
      <address>
        <postal>
          <!-- Reorder these if your country does things differently -->
          <city>Beijing</city>
          <country>China</country>
        </postal>
        <email>linchangwang.04414@h3c.com</email>
        <!-- uri and facsimile elements may also be added -->
      </address>
    </author>

   <author fullname="Yisong Liu" initials="Y." surname="Liu">
      <organization>China Mobile</organization>

      <address>
        <postal>
          <street>32 Xuanwumen West Street</street>

          <!-- Reorder these if your country does things differently -->

          <city>Beijing</city>

          <region>Xicheng District</region>

          <code>100053</code>

          <country>China</country>
        </postal>

        <email>liuyisong@chinamobile.com</email>

        <!-- uri and facsimile elements may also be added -->
      </address>
    </author>
	
	<author initials="M." surname="Srivastava" fullname="Mukul Srivastava">
      <organization>Hewlett Packard Enterprise</organization>
      <address>
        <email>mukul.srivastava@hpe.com</email>
      </address>
    </author>	

    <author fullname="Pierre Francois" initials="P." surname="Francois">
      <organization>INSA-Lyon</organization>

      <address>
        <postal>
          <city>Villeurbanne</city>
          <country>France</country>
        </postal>

        <phone />

        <facsimile />

        <email>pierre.francois@insa-lyon.fr</email>
      </address>
    </author>


    <author fullname="Maxence Younsi" initials="M." surname="Younsi">
      <organization>INSA-Lyon</organization>

      <address>
        <postal>
          <street />

          <city>Villeurbanne</city>

          <region />

          <code />

          <country>France</country>
        </postal>

        <phone />

        <facsimile />

        <email>maxence.younsi@insa-lyon.fr</email>

        <uri />
      </address>
    </author>	

    <date year="2026" />
    <!-- Meta-data Declarations -->
    <area>General</area>
    <workgroup>GROW</workgroup>

    <keyword>BMP</keyword>
    <keyword>BGP</keyword>
<abstract>
<t>
	This document introduces an option to allow BMP messages with the per-peer header to carry interface 
  information for the established peer session, especially in order to distinguish BGP peers established
  based on interfaces.
</t>
</abstract>

  </front>

  <middle>

<section anchor="Introduction" title="Introduction">
<t>
	When BGP establishes a peer relationship using a Link-Local address or unnumbered address,
  the local outgoing interface
  must be specified for the relationship to be established successfully. In other words,
  BGP Link-Local or unnumbered peers may only be distinguished by interface information.
</t>
<t>
  However, the per-peer information in a BMP message does not include interface information,
  making it impossible to distinguish which BGP Link-Local peer or unnumbered peer the reported
  BMP message originated from.
</t>
<t>
  This document introduces a new BMPv4 <xref target="I-D.ietf-grow-bmp-tlv"/> TLV that enables BMP messages
  with the per-peer header to carry interface information for the established peer session.
</t>
</section>
<section anchor="Terminology" 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"/> <xref
    target="RFC8174"/> when, and only when, they appear in all
    capitals, as shown here.
  </t>
</section>
<section anchor="New BMPv4 TLV" title="New BMPv4 TLV">
    <t>
      This section defines a new BMPv4 TLV for reporting the BMP messages that need to be distinguished
      through peer interface intormation. This BMPv4 TLV is designed to convey peer interface information
      and is therefore named the "Peer-Interface TLV".
    </t>
    <t>
      The TLV structure is illustrated in Figure 1.
    </t>
    <t><figure>
      <artwork align="center" name="1"><![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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|        Type (2 octets)        |       Length (2 octets)       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|    Subtype    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~             Peer Interface Infomation (variable)              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                          Figure 1: Peer-Interface TLV
      ]]></artwork>
    </figure></t>
    <t>
      The "Peer-Interface TLV" TLV type is TBD1. The value of the TLV is the "Subtype" code (1 octet)
      followed by the interface information used to establish the related peer session.
      The length field is one (for the "Subtype" field) plus the length of the "Peer Interface Infomation"
      field.
    </t>
    <t>
      The subtype is defined, as shown below:</t>
    <ul>
      <li>Subtype = 1: Interface Index. The "Peer Interface Infomation" is a 32-bit interface index.</li>
      <li>Subtype = 2: Interface Name. The "Peer Interface Infomation" is a variable interface name,
          encoded in UTF-8.</li>
    </ul>
    <t>
      The subtype MUST use type 1 or 2 defined in this document.
    </t>
</section>

<section anchor="Operational Considerations" title="Operational Considerations">
<t>
  When a BMP monitoring station needs to distinguish between parallel BGP sessions established over
  different interfaces (e.g., using link-local or unnumbered addresses), the "Peer-Interface TLV" SHOULD
  be included in the relevant BMP messages.
</t>
<t>
  When a BMP sender generates a BMP message that requires distinguishing peers by interface, it SHOULD
  include this TLV in the BMP message. The BMP receiver needs to be able to resolve this TLV to correctly
  associate the BMP message with the BGP peer on a specific interface.
</t>
<t>
   BMP receivers with older versions that do not support this TLV MAY ignore unknown TLVs, but this MAY
   prevent them from correctly identifying parallel interface-based peers.
</t>
</section>

<section anchor="Security Considerations" title="Security Considerations">
<t>
	TBD
</t>
</section>

<section anchor="IANA Considerations" title="IANA Considerations">
<t>
  TBD
</t>
</section>

<!-- <section anchor="Acknowledgements" title="Acknowledgements">
<t>
	The author would like to thank xxx for his valuable input.
</t>
</section> -->

  </middle>

  <!--  *****BACK MATTER ***** -->

  <back>
  <references title="References">
    <references title="Normative References">
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
        <!--<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7854.xml"/>-->
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>
        <!--<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8671.xml"/>-->
        <xi:include
        href="https://bib.ietf.org/public/rfc/bibxml-ids/reference.I-D.ietf-grow-bmp-tlv.xml"/>
        <!--<?rfc include="reference.I-D.li-dmsc-architecture.xml"?>-->
    </references>
  </references>
  </back>
</rfc>
