<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="std" docName="draft-francois-grow-bmp-loc-peer-00"
     ipr="trust200902">
  <front>
    <title abbrev="bmp-loc-peer">BMP Loc-RIB: Peer address</title>

    <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>

    <author fullname="Paolo Lucente" initials="P." surname="Lucente">
      <organization>NTT</organization>

      <address>
        <postal>
          <street>Siriusdreef 70-72</street>

          <city>Hoofddorp, WT 2132</city>

          <region/>

          <code/>

          <country>NL</country>
        </postal>

        <phone/>

        <facsimile/>

        <email>paolo@ntt.net</email>

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

    <date day="13" month="March" year="2023"/>

    <workgroup></workgroup>

    <abstract> <t>BMP Loc-RIB lets a BMP publisher set the Peer Address value
    of a path information to zero.  This document introduces the option to
    communicate the actual peer from which a path was received when advertising
    that path with BMP Loc-RIB.</t> </abstract>

    <note title="Requirements Language">
      <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>
    </note>
  </front>

  <middle>
    <section title="Introduction">

      <t>Using BMP Loc-RIB <xref target="RFC9069"/>, the Peer Address field of
    a Per-Peer header is Zero-filled. This prevents a collector from knowing from
    which peer a path selected as best was received. The nexthop attribute of a path is
    indeed not an identifier of the peer from which the path was received. </t>

    <t> This document introduces the option to actually set this field to the
    IP Address of the peer from which the installed path was received. For BMPv4,
    it introduces a TLV describing the Peer Address. </t>

    </section>

    <section title="BMPv3 Behavior">

    <t>  A BMPv3 Loc-RIB enabled node following this specification sets the Peer
    Address field in the Per-Peer header to the address of the Peer from which this
    path was received. The V flag is applicable, so that if the peer address is an
    IPv6 address, the V flag MUST be set to 1. If the peer address is an IPv4
    address, the V flag MUST be set to 0.</t>

    <t> This behavior SHOULD be disabled by default and enabled through
    configuration, so that a defensive BMP receiver would not terminate a BMP
    session over which it receives a BMP Loc-RIB messages with a non-zero Peer
    Address field. This behavior can be enabled when the operator knows that the
    receiver can receive BMP Loc-RIB messages following this specification.</t>



    </section>

    <section title="BMPv4 TLV Based Behavior">

    <t>In BMP v4 <xref target="I-D.ietf-grow-bmp-tlv"/>, TLV's can be used to
    provide optional information along with monitored paths.  
    Peer Address information can be included using one such TLV. </t>

    <t>A TLV type "Peer-Address TLV" needs to be reserved from the BMP Route
    Monitoring TLVs registry. The length field is 4 when the peer is IPv4 and 16
    when the peer is IPv6, as the index field of the TLV is not included in the
    length field. The value is the IP address the peer from which the
    monitored path was received.</t> 

    </section>

    

<section anchor="sec_security_considerations"
              title="Security Considerations">
      <t>This document does not introduce new security considerations.</t>

    </section>

    <section anchor="Acknowledgements" title="Acknowledgements">
      <t>These are the acks.</t>
    </section>
  </middle>

  <back>
    <references title="Normative References">
    <?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml"?>
    <?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.8174.xml"?>
    <?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.9069.xml"?>
    <?rfc include="https://bib.ietf.org/public/rfc/bibxml-ids/reference.I-D.draft-ietf-grow-bmp-tlv-10.xml"?>
    </references>

    <references title="Informative References">


    </references>

  </back>
</rfc>
