<?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-02"
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 proposes extending BMP to allow BMP messages with the per-peer header to carry
  interface information for the established peer session, especially in order to distinguish
  parallel link-local and unnumbered BGP peers established based on distinct 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, parallel link-local or unnumbered BGP peers can only be
  distinguished by interface information.
</t>
<t>
  However, the peer information in a BMP message does not include peer interface information,
  making it impossible to distinguish which BGP peer the reported BMP message originated
  from or sent to in scenarios involving parallel link-local or unnumbered BGP peers.
</t>
<t>
  This document introduces two approaches 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="Solutions" title="Solutions">
  <t>
    This section presents two BMP extensions designed to convey peer interface information
    within BMP messages: one extends the BMPv4 TLV structure, while the other introduces
    an extension to the BMP per-peer header.
  </t>
  <section anchor="New BMPv4 TLV" title="BMPv4 TLV Extension">
    <t>
      In order to report the BMP messages that need to be distinguished through peer interface
      information, this section extends "Rx Peer-Address TLV" defined in <xref target="I-D.ietf-grow-bmp-loc-peer"/>,
      and defines a new BMPv4 <xref target="I-D.ietf-grow-bmp-tlv"/> TLV.
      This new BMPv4 TLV is designed to convey interface information of the peer to which
      the monitored path is sent and is therefore named the "Tx Peer-Interface TLV".
    </t>
    <section anchor="Rx Peer-Address TLV" title="Rx Peer-Address TLV Extension">
    <t>
      This section introduces the extension of the "Rx Peer-Address TLV" to carry the peer
      interface information. The structure of the "Rx Peer-Address TLV" is defined in
      <xref target="I-D.ietf-grow-bmp-loc-peer"/> and is shown 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)       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|G|      Index (15 bits)        | Address Type  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~                    Rx Peer Address (variable)                 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                Figure 1: Rx Peer-Address TLV
      ]]></artwork>
    </figure></t>
    <t>
      This document defines new four address types, as follows:
    </t>
    <ul>
      <li>Address Type = 4: IPv6 Address with Interface ID. The "Rx Peer Address" is
          the 16 bytes IPv6 Address of the peer, followed by an interface ID of a
          variable size S. The "Length" is thus set to 1 + 16 + S.</li>
      <li>Address Type = 5: IPv6 Address with Interface Name. The "Rx Peer Address" is
          the 16 bytes IPv6 Address of the peer, followed by an interface name of a
          variable size S, encoded in UTF-8 without specific termination characters.
          The "Length" is thus set to 1 + 16 + S.</li>
      <li>Address Type = 6: IPv4 Address with Interface ID. The "Rx Peer Address" is
          the 4 bytes IPv4 Address of the peer, followed by an interface ID of a
          variable size S. The "Length" is thus set to 1 + 4 + S.</li>
      <li>Address Type = 7: IPv4 Address with Interface Name. The "Rx Peer Address" is
          the 4 bytes IPv4 Address of the peer, followed by an interface name of a
          variable size S, encoded in UTF-8 without specific termination characters.
          The "Length" is thus set to 1 + 4 + S.</li>
    </ul>
    <t>
      The "Rx Peer-Address TLV" could be used for Local-RIB, Adj-RIB-In, and Adj-RIB-Out.
    </t>
    <t>
      For Local-RIB, this TLV is only used for BMP Route Monitoring Messages.
    </t>
    <t>
      For Adj-RIB-In, this TLV can be used for BMP Route Monitoring Messages, BMP Route Mirroring Messages,
      and BMP Stats Reports Messages, and the "Index" field MUST be ignored.
    </t>
    <t>
      For Adj-RIB-Out, this TLV can be used for BMP Route Monitoring Messages and BMP Route Mirroring Messages.
    </t>
    <t>
      For Non-Local-RIB peers, this TLV can be used for BMP Peer Down Notification Messages and Peer Up
      Notification Messages, and the "Index" field also MUST be ignored.
    </t>
    </section>
    <section anchor="Tx Peer-Interface TLV" title="Tx Peer-Interface TLV">
    <t>
      This section introduces the new "Tx Peer-Interface TLV" to carry the peer
      interface information. The TLV structure is illustrated in Figure 2.
    </t>
    <t><figure>
      <artwork align="center" name="2"><![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    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~                  Tx Peer Interface (variable)                 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                  Figure 2: Tx Peer-Interface TLV
      ]]></artwork>
    </figure></t>
    <t>
      The "Tx Peer-Interface TLV" type is TBD1. The value of the TLV is the "Subtype" code (1 octet)
      followed by the "Tx Peer Interface" information used to establish the related peer session.
      The "Length" field is one (for the "Subtype" field) plus the length of the "Tx Peer Interface"
      field.
    </t>
    <t>
      The "Subtype" field is defined, as shown below:</t>
    <ul>
      <li>Subtype = 1: IPv6 Address with Interface ID. The "Tx Peer Interface" is
          the 16 bytes IPv6 Address of the peer, followed by an interface ID of a
          variable size S. The "Length" is thus set to 1 + 16 + S.</li>
      <li>Subtype = 2: IPv6 Address with Interface Name. The "Tx Peer Interface" is
          the 16 bytes IPv6 Address of the peer, followed by an interface name of a
          variable size S, encoded in UTF-8 without specific termination characters.
          The "Length" is thus set to 1 + 16 + S.</li>
      <li>Subtype = 3: IPv4 Address with Interface ID. The "Tx Peer Interface" is
          the 4 bytes IPv4 Address of the peer, followed by an interface ID of a
          variable size S. The "Length" is thus set to 1 + 4 + S.</li>
      <li>Subtype = 4: IPv4 Address with Interface Name. The "Tx Peer Interface" is
          the 4 bytes IPv4 Address of the peer, followed by an interface name of a
          variable size S, encoded in UTF-8 without specific termination characters.
          The "Length" is thus set to 1 + 4 + S.</li>
    </ul>
    <t>
      The "Tx Peer-Interface TLV" could only be used for Adj-RIB-Out.
    </t>
    <t>
      For Adj-RIB-Out, this TLV can be used for BMP Route Monitoring Messages and BMP Route Mirroring Messages,
      and BMP Stats Reports Messages.
    </t>
    <t>
      For Non-Local-RIB peers, this TLV can also be used for BMP Peer Down Notification Messages and Peer Up
      Notification Messages.
    </t>
    <t>
      For BMP Peer Down Notification Messages and Peer Up Notification Messages, only one of the "Tx Peer-Interface TLV" and
      "Rx Peer-Address TLV" is allowed to carry the peer interface information.
    </t>
    </section>
  </section>
  <section anchor="New Per-Peer Header" title="Per-Peer Header Extension">
    <t>
      To enable the distinction of BMP messages based on peer interfaces, this section defines
      new BMP peer types and extends the BMP per-peer header accordingly.
    </t>
    <section anchor="Definition" title="BMP Peer Type Definition">
    <t>
      The peer types are defined as follows:</t>
    <ul>
      <li>Peer Type = TBD1 (RECOMMENDED value 4): Global Instance Interface Peer.</li>
      <li>Peer Type = TBD2 (RECOMMENDED value 5): RD Instance Interface Peer.</li>
    </ul>
    <t>
      BMP messages using the peer types defined in this document MUST include peer interface
      information in the per-peer header.
    </t>
    </section>
    <section anchor="Format" title="New Per-Peer Header Format">
    <t>
      For new BMP peer types defined in this document, this section defines a new per-peer header,
      called the "Interface Per-Peer Header".
      It is defined according to per-peer header of <xref target="RFC7854"/>, as shown in Figure 2.
    </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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   Peer Type   |  Peer Flags   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|         Peer Distinguisher (present based on peer type)       |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                 Peer Address (16 bytes)                       |
~                                                               ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|         Peer Interface Index (present based on peer type)     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                           Peer AS                             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                         Peer BGP ID                           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                    Timestamp (seconds)                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                  Timestamp (microseconds)                     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

           Figure 2: Interface Per-Peer Header Format
      ]]></artwork>
    </figure></t>
    <t>
      Compared with per-peer header of <xref target="RFC7854"/>, the Peer Interface Index is added to
      indicate the interface used to establish BGP peers. Other fields are defined in Section 4.2
      of <xref target="RFC7854"/> and Section 4 of <xref target="RFC8671"/>.
    </t>
    </section>
  </section>
</section>

<section anchor="Operational Considerations" title="Operational Considerations">
<t>
  This document introduces two solutions designed to convey peer interface information within BMP
  messages: one is the BMPv4 TLV extension, and the other is the BMP per-peer header extension.
  The BMP per-peer header extension could apply to BMPv3 and BMPv4 <xref target="I-D.ietf-grow-bmp-tlv"/>,
  but the interface is identified only by its interface index. If the interface name must be needed to
  identify a interface, the BMP per-peer header extension cannot be used; only the BMPv4 TLV extension
  can be used. The BMPv4 TLV extension applies exclusively to BMPv4.
  And when reporting BMP Local RIB messages requires peer interface information, the BMPv4 TLV extension
  MUST be used.
</t>
<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 BMPv4 TLV extension or
  BMP per-peer header extension SHOULD be included in the relevant BMP messages.
</t>
<t>
  When a BMP sender generates a BMP message that requires distinguishing peers by interface, the BMP
  message SHOULD include the BMPv4 TLV extension or BMP per-peer header extension.
  The BMP receiver needs to be able to resolve this TLV extension or this per-peer header extension
  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 or this new peer type MAY ignore
  unknown TLVs or peer types, 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-loc-peer.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>
