Network Working Group                                        P. Francois
Internet-Draft                                                 M. Younsi
Intended status: Standards Track                               INSA-Lyon
Expires: 27 July 2025                                         P. Lucente
                                                                     NTT
                                                         23 January 2025


                       BMP Loc-RIB: Peer address
                    draft-ietf-grow-bmp-loc-peer-00

Abstract

   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.

Requirements Language

   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 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on 27 July 2025.

Copyright Notice

   Copyright (c) 2025 IETF Trust and the persons identified as the
   document authors.  All rights reserved.




Francois, et al.          Expires 27 July 2025                  [Page 1]

Internet-Draft                bmp-loc-peer                  January 2025


   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents (https://trustee.ietf.org/
   license-info) in effect on the date of publication of this document.
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.  Code Components
   extracted from this document must include Revised BSD License text as
   described in Section 4.e of the Trust Legal Provisions and are
   provided without warranty as described in the Revised BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  BMPv4 TLV Based Behavior  . . . . . . . . . . . . . . . . . .   3
     2.1.  Rx Peer-Address TLV . . . . . . . . . . . . . . . . . . .   3
       2.1.1.  Self-Originated . . . . . . . . . . . . . . . . . . .   4
       2.1.2.  IPv4 Peer Address . . . . . . . . . . . . . . . . . .   4
       2.1.3.  IPv6 Global Link Address  . . . . . . . . . . . . . .   4
       2.1.4.  IPv6 Address with Interface ID  . . . . . . . . . . .   4
       2.1.5.  IPv6 Address with Interface Name  . . . . . . . . . .   4
     2.2.  VRF Import TLVs . . . . . . . . . . . . . . . . . . . . .   4
       2.2.1.  Origin VRF TLV  . . . . . . . . . . . . . . . . . . .   5
       2.2.2.  Previous VRF TLV  . . . . . . . . . . . . . . . . . .   5
       2.2.3.  Previous VRF Sequence TLV . . . . . . . . . . . . . .   6
   3.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   7
   4.  Security Considerations . . . . . . . . . . . . . . . . . . .   8
   5.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   8
   6.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   8
     6.1.  Normative References  . . . . . . . . . . . . . . . . . .   8
     6.2.  Informative References  . . . . . . . . . . . . . . . . .   8
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   8

1.  Introduction

   Using BMP Loc-RIB [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 [RFC7911]
   enabled peers as the path ID space of paths are defined per peer.

   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.







Francois, et al.          Expires 27 July 2025                  [Page 2]

Internet-Draft                bmp-loc-peer                  January 2025


   This document introduces a BMPv4 [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.

2.  BMPv4 TLV Based Behavior

   In this section, we describe a solution based on BMPv4 TLVs.
   Section 2.1 describes a BMPv4 TLV used to convey the peer address.
   Section 2.2 introduces optional TLVs for the case of paths imported
   from another VRF.

2.1.  Rx Peer-Address TLV

   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.

   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.

   The value of the type field of this TLV is TBD1.

   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 [I-D.ietf-grow-bmp-tlv], not included in the length.

   The TLV structure is illustrated in Figure 1.


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


                       Figure 1: Rx Peer-Address TLV






Francois, et al.          Expires 27 July 2025                  [Page 3]

Internet-Draft                bmp-loc-peer                  January 2025


2.1.1.  Self-Originated

   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.

2.1.2.  IPv4 Peer Address

   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.

2.1.3.  IPv6 Global Link Address

   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.

2.1.4.  IPv6 Address with Interface ID

   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.

2.1.5.  IPv6 Address with Interface Name

   In the same cases as Section 2.1.4 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.

2.2.  VRF Import TLVs

   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.








Francois, et al.          Expires 27 July 2025                  [Page 4]

Internet-Draft                bmp-loc-peer                  January 2025


2.2.1.  Origin VRF TLV

   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 [RFC9069].  The value of the type field of this TLV
   is TBD2.  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 Figure 2.


      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)              ~
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


                          Figure 2: VRF Import TLV

2.2.2.  Previous VRF TLV

   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 [RFC9069].  The value of the type
   field of this TLV is TBD3.  The length field of this is the length,
   in bytes, of the UTF-8 string of the VRF name.  This TLV is
   illustrated in Figure 3.


      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)              ~
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+




Francois, et al.          Expires 27 July 2025                  [Page 5]

Internet-Draft                bmp-loc-peer                  January 2025


                         Figure 3: Previous VRF TLV

   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 [RFC9069] is
   C, and the Rx Peer-Adress TLV is I.

2.2.3.  Previous VRF Sequence TLV

   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 4.  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 [RFC9069].
   A complete Previous VRF Sequence TLV structure is illustrated in
   Figure 5.


      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)
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     ~                                                               ~
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


                   Figure 4: Previous VRF Sequence Entry


      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                 ~
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     ~                              ...                              ~
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+





Francois, et al.          Expires 27 July 2025                  [Page 6]

Internet-Draft                bmp-loc-peer                  January 2025


                    Figure 5: Previous VRF Sequence TLV

   The value of the type field of this TLV is TBD4.

   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 [I-D.ietf-grow-bmp-tlv].

   In the example above Section 2.2, the sequence listed in the Previous
   VRF sequence would be [B, A].

3.  IANA Considerations

   This document requests that IANA assign the following new parameters
   to the "BMP Route Monitoring TLVs" [I-D.ietf-grow-bmp-tlv] registry

   *  Type = TBD1: Rx Peer-Address TLV type.  The value of this TLV is
      defined in Section 2.1

   *  Type = TBD2: Origin VRF TLV type.  The value of this TLV is
      defined in Section 2.2.1

   *  Type = TBD3: Previous VRF TLV type.  The value of this TLV is
      defined in Section 2.2.2

   *  Type = TBD4: Previous VRF Sequence TLV type.  The value of this
      TLV is defined in Section 2.2.3

   This document also requests the definition of a "Local-RIB Peer
   Address" registry seeded as follows:

   *  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).

   *  Type = 2: IPv4 address type.  Set to 2 if the following Peer
      Address contained in the Rx Peer-Address TLV is an IPv4 address.

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

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




Francois, et al.          Expires 27 July 2025                  [Page 7]

Internet-Draft                bmp-loc-peer                  January 2025


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

4.  Security Considerations

   This document does not introduce new security considerations.

5.  Acknowledgements

   We would like to thank Camilo Cardona, Jeff Haas, for their valuable
   input on this document.

6.  References

6.1.  Normative References

   [I-D.ietf-grow-bmp-tlv]
              Lucente, P. and Y. Gu, "BMP v4: TLV support for BMP Route
              Monitoring and Peer Down Messages", Work in Progress,
              Internet-Draft, draft-ietf-grow-bmp-tlv-13, 23 October
              2023, <https://datatracker.ietf.org/doc/html/draft-ietf-
              grow-bmp-tlv-13>.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC7911]  Walton, D., Retana, A., Chen, E., and J. Scudder,
              "Advertisement of Multiple Paths in BGP", RFC 7911,
              DOI 10.17487/RFC7911, July 2016,
              <https://www.rfc-editor.org/info/rfc7911>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

   [RFC9069]  Evens, T., Bayraktar, S., Bhardwaj, M., and P. Lucente,
              "Support for Local RIB in the BGP Monitoring Protocol
              (BMP)", RFC 9069, DOI 10.17487/RFC9069, February 2022,
              <https://www.rfc-editor.org/info/rfc9069>.

6.2.  Informative References

Authors' Addresses




Francois, et al.          Expires 27 July 2025                  [Page 8]

Internet-Draft                bmp-loc-peer                  January 2025


   Pierre Francois
   INSA-Lyon
   Villeurbanne
   France
   Email: pierre.francois@insa-lyon.fr


   Maxence Younsi
   INSA-Lyon
   Villeurbanne
   France
   Email: maxence.younsi@insa-lyon.fr


   Paolo Lucente
   NTT
   Siriusdreef 70-72
   Hoofddorp, WT 2132
   Netherlands
   Email: paolo@ntt.net































Francois, et al.          Expires 27 July 2025                  [Page 9]