<?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-01"
     ipr="trust200902" updates="9069">
  <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="10" month="July" 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. Knowing
    the peer address is also especially useful when Loc-RIB paths come from Add-Path
    enabled peers as the path ID space of paths are defined per peer.</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.</t>

    <t><figure anchor="fig_flags" title="Per-peer flags">
            <artwork align="center"><![CDATA[
     0 1 2 3 4 5 6 7 
    +-+-+-+-+-+-+-+-+
    |F|V| | | | | | |
    +-+-+-+-+-+-+-+-+
]]></artwork>
          </figure></t>


    <t> A flag is introduced in the BMP Loc-RIB per-peer header flags to
    describe whether the peer address is IPv4 or IPv6.</t>

    <t>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 not supporting this document
    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 this section, we describe a variant of the solution based on BMPv4 TLVs. <xref target="sec_addr_tlv"/> describes a BMPv4 TLV used
to convey the peer address. <xref target="sec_vrf"/> introduces optional TLVs for the case of paths imported from another VRF.</t>

            <section title="Rx Peer-Address TLV" anchor ="sec_addr_tlv">

        <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 "Rx 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 of the peer from which the
        monitored path was received.</t>

       <t>The Rx Peer-Address TLV may describe a self originated path by setting the value of the peer address to 0. The length of 
        such a zero filled Peer-Address TLV SHOULD be either 4 or 16.</t>
 
        </section>

          <section title="VRF Import TLV" anchor="sec_vrf">

          <t>Path information advertised through BMP Loc-RIB might be related to a path imported from another VRF. In that scenario, 
        the sole knowledge of the remote peer IP address is not sufficient to obtain a clear picture of where this path was coming from.</t>

          <t>A TLV type "Origin VRF TLV" needs to be reserved from the BMP Route
        Monitoring TLVs registry. It describes the VRF
            context in which this path was received from a peer or where it was self-originated.  It contains a
            variable length field matching the definition of VRF/Table name from <xref
            target="RFC9069"/>.  The length field of this BMPv4 TLV is the length of the
            UTF-8 string of the VRF name. When this TLV is present, the Rx Peer-Address TLV associated
            with that path refers to the IP address of the peer from which it was received, in the VRF context
            refered in this TLV. </t> 

         <t>A TLV type "Previous VRF TLV" needs to be reserved from the BMP Route
        Monitoring TLVs registry. It describes the VRF
            from which this path was imported.  It contains a variable length field
            matching the definition of VRF/Table name from <xref target="RFC9069"/>. The
            length field of this BMPv4 TLV is the length of the UTF-8 string of the VRF
            name.</t>

        <t>As an example, if BMP Loc-RIB describes a path P in VRF C,  which was received from a peer I in VRF A, imported into VRF B, and finally imported from VRF B into VRF C, 
        the Origin VRF Name is A, the Previous VRF Name is B, the VRF/Table Name TLV (as per <xref target="RFC9069"/> is C, and the Rx Peer-Adress TLV is I.</t> 

         <t>A TLV type "Previous VRF sequence" needs to be reserved from the BMP Route
        Monitoring TLVs registry. It describes the
            entire chain of VRFs through which this path was imported before landing in the
            current VRF. The list starts with the previous VRF, and ends with the Origin
            VRF in which this path was received or originated. 
            One entry of this list has the format described in Figure <xref target="fig_vrf_list_entry"/>. The length field
            is an 8 bit value capturing the length of the Name field. The name field is the UTF-8 string of the VRF
            name of the described VRF of the sequence.</t>

 <t><figure anchor="fig_vrf_list_entry" title="VRF sequence entry">
            <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     
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Length     | Name                                            
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ~                                                               ~
   ~                                                               ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
          </figure></t>
            <t>The length of a "Previous VRF sequence" TLV is the number of elements of the sequence + the sum of the sizes of the VRF names of the sequence.<t> 

            </t>In the exemple above, the sequence listed in the Previous VRF sequence would be [B, A].</t>
            

       </section>



    </section>
    <section anchor="sec_iana" title="IANA Considerations">
    
        <t>This document requires IANA to reserve Flag 1 in the, described as "V Flag",         
        with this document as reference, in the BMP Peer Flags for Loc-RIB Instance Peer Type 3
        registry of BGP Monitoring Protocol (BMP) Parameters.</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>We would like to thank Camilo Cardona, Jeff Haas, for their
        valuable input on this document.</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>
