<?xml version="1.0" encoding="US-ASCII"?>
<?xml-model href="rfc7991bis.rnc"?>
<!DOCTYPE rfc [
  <!ENTITY IANA_RX_PEER_ADDR_TLV "TBD1">
  <!ENTITY IANA_ORIGIN_VRF_TLV "TBD2">
  <!ENTITY IANA_PREV_VRF_TLV "TBD3">
  <!ENTITY IANA_PREV_VRF_SEQ_TLV "TBD4">
]>

<?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-ietf-grow-bmp-loc-peer-00"
  xmlns:xi="http://www.w3.org/2001/XInclude"
  submissionType="IETF"
  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="23" month="January" year="2025" />

    <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 <xref target="RFC7911" /> enabled peers as the path ID space of
        paths are defined per peer.</t>

      <t>When VRFs are in use, the peer address information can only be
        interpreted in the VRF context within which the corresponding peering is taking
        place. </t>

      <t> This document introduces a BMPv4 <xref target="I-D.ietf-grow-bmp-tlv" /> TLV describing
        the address of the peer that announced the path to the current router, and BMPv4 TLVs
        describing the VRF context in which the path was received.</t>

    </section>

    <section title="BMPv4 TLV Based Behavior">

      <t>In this section, we describe a 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 BMPv4, 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 value of the TLV is the "Address Type" code followed by
          the address of the peer from which the monitored path was received.
          The address type 0 is reserved.
          A set of address types is described in the following subsections.
        </t>

        <t>
          The value of the type field of this TLV is &IANA_RX_PEER_ADDR_TLV;.
        </t>

        <t>The length field is one (for the "Address Type" field) plus the length of the "Rx Peer
          Address" field. The "Index" field is, as described by <xref target="I-D.ietf-grow-bmp-tlv" />,
          not included in the length.</t>

        <t> The TLV structure is illustrated in <xref target="fig_rx_peer_address_tlv" />. </t>

        <figure anchor="fig_rx_peer_address_tlv" align="center"
          title="Rx Peer-Address TLV">
          <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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|        Type (2 octets)        |       Length (2 octets)       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|        Index (2 octets)       | Address Type  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~                    Rx Peer Address (variable)                 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      ]]>
      </artwork>
        </figure>

        <section title="Self-Originated">
          <t>The "Rx Peer-Address TLV" may describe a self originated path by
            setting the value of the "Address Type" to 1.
            The "Rx Peer Address" is empty.
            The "Length" is thus set to 1.
          </t>
        </section>

        <section title="IPv4 Peer Address">
          <t>
            In case of a BGP peering established using IPv4, the "Address Type" is set to 2.
            The "Rx Peer Address" is the 4 bytes IPv4 Address of the peer.
            The "Length" is thus set to 5.
          </t>
        </section>

        <section title="IPv6 Global Link Address">
          <t>
            In case of a BGP peering established using an IPv6 Global Link Address, the "Address
            Type" is set to 3.
            The "Rx Peer Address" is the 16 bytes IPv6 Global Link Address of the peer.
            The "Length" is thus set to 17.
          </t>
        </section>

        <section title="IPv6 Address with Interface ID" anchor="ipv6_itf_id">
          <t>
            In some scenarii, for example in the case case of a BGP peering established using IPv6
            Link Local Addresses,
            an interface identifier is needed to disambiguate the address.
            The "Address Type" is set to 4.
            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.
          </t>
        </section>

        <section title="IPv6 Address with Interface Name">
          <t> In the same cases as <xref target="ipv6_itf_id" /> but with interfaces identified
            using a name instead of an ID, the "Address Type" is set to 5. 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. </t>
        </section>
      </section>

      <section title="VRF Import TLVs" 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>

        <section title="Origin VRF TLV" anchor="sec_origin_vrf_tlv">
          <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 value of the type field of this TLV is &IANA_ORIGIN_VRF_TLV;.
            The length field of this BMPv4 TLV is the length, in bytes, 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. This TLV is illustrated in <xref target="fig_origin_vrf_tlv" />. </t>

          <figure anchor="fig_origin_vrf_tlv" align="center" title="VRF Import TLV">
            <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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|        Type (2 octets)        |       Length (2 octets)       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|        Index (2 octets)       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~                 Origin VRF/Table Name (Variable)              ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
            ]]>
          </artwork>
          </figure>
        </section>

        <section title="Previous VRF TLV" anchor="sec_previous_vrf_tlv">
          <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 value of the type field of this TLV is &IANA_PREV_VRF_TLV;. The length field of this
            is the length, in bytes, of the UTF-8 string of the VRF name. This TLV is illustrated in <xref
              target="fig_previous_vrf_tlv" />. </t>

          <figure anchor="fig_previous_vrf_tlv" align="center" title="Previous VRF TLV">
            <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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|        Type (2 octets)        |       Length (2 octets)       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|        Index (2 octets)       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~               Previous VRF/Table Name (Variable)              ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
            ]]>
          </artwork>
          </figure>

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

        <section title="Previous VRF Sequence TLV" anchor="sec_prev_seq_tlv">
          <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 <xref target="fig_vrf_list_entry" />. The length
            field is an 8 bit value capturing the length, in bytes, of the Name field. The name
            field is the VRF name of the described VRF of the sequence, matching the definition of
            VRF/Table name from <xref target="RFC9069" />. A complete Previous VRF Sequence TLV
            structure is illustrated in <xref target="fig_vrf_list_seq" />. </t>

          <figure anchor="fig_vrf_list_entry" title="Previous 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       | VRF/Table Name (Variable)                                            
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~                                                               ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
              ]]>
            </artwork>
          </figure>

          <figure anchor="fig_vrf_list_seq" align="center" title="Previous VRF Sequence TLV">
            <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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|        Type (2 octets)        |       Length (2 octets)       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|        Index (2 octets)       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~                   Previous VRF Sequence Entry                 ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~                              ...                              ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
              ]]>
            </artwork>
          </figure>

          <t>
            The value of the type field of this TLV is &IANA_PREV_VRF_SEQ_TLV;.
          </t>

          <t> The length of a "Previous VRF Sequence" TLV is the sum of the total lengths of each
            VRF entry in the sequence (1 byte for the length field + the value of the length field).
            This does not include the length of the Index field as defined in <xref
              target="I-D.ietf-grow-bmp-tlv" />. </t>

          <t>In the example above <xref target="sec_vrf" />, the sequence listed in the Previous VRF
            sequence would be [B, A]. </t>
        </section>
      </section>
    </section>


    <section title="IANA Considerations">
      <t> This document requests that IANA assign the following new parameters to the "BMP Route
        Monitoring TLVs" <xref target="I-D.ietf-grow-bmp-tlv" /> registry <list style="symbols">
          <t> Type = &IANA_RX_PEER_ADDR_TLV;: Rx Peer-Address TLV type. The value of this TLV is
        defined in <xref target="sec_addr_tlv" />
          </t>
          <t> Type = &IANA_ORIGIN_VRF_TLV;: Origin VRF TLV type. The value of this TLV is defined in <xref
              target="sec_origin_vrf_tlv" />
          </t>
          <t> Type = &IANA_PREV_VRF_TLV;: Previous VRF TLV type. The value of this TLV is defined in <xref
              target="sec_previous_vrf_tlv" />
          </t>
          <t> Type = &IANA_PREV_VRF_SEQ_TLV;: Previous VRF Sequence TLV type. The value of this TLV
        is defined in <xref target="sec_prev_seq_tlv" />
          </t>
        </list>
      </t>

      <t> This document also requests the definition of a "Local-RIB Peer Address" registry seeded
        as follows: <list style="symbols">
          <t>
            Type = 1: Self-Originated address type. Set to 1
            if the route described by the BGP PDU enclosed in the BMP Route Monitoring Message
            was originated from the BMP station (router).
          </t>
          <t>
            Type = 2: IPv4 address type. Set to 2
            if the following Peer Address contained in the Rx Peer-Address TLV is
            an IPv4 address.
          </t>
          <t>
            Type = 3: Global Link IPv6 address type. Set to 3
            if the following Peer Address contained in the Rx Peer-Address TLV is
            a Global Link IPv6 address.
          </t>
          <t>
            Type = 4: IPv6 + Interface ID address type. Set to 4
            if the following Peer Address contained in the Rx Peer-Address TLV is
            an IPv6 address followed by a numerical interface ID of variable size.
          </t>
          <t>
            Type = 5: IPv6 + Interface Name address type. Set to 5
            if the following Peer Address contained in the Rx Peer-Address TLV is
            an IPv6 address followed by an interface name encoded as an UTF-8 string of variable
        size.
          </t>
        </list>
      </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">
      <xi:include href="http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml" />
      <xi:include href="http://xml.resource.org/public/rfc/bibxml/reference.RFC.7911.xml" />
      <xi:include href="http://xml.resource.org/public/rfc/bibxml/reference.RFC.8174.xml" />
      <xi:include href="http://xml.resource.org/public/rfc/bibxml/reference.RFC.9069.xml" />
      <xi:include
        href="https://bib.ietf.org/public/rfc/bibxml-ids/reference.I-D.draft-ietf-grow-bmp-tlv-13.xml" />
    </references>

    <references title="Informative References">


    </references>

  </back>
</rfc>
