Skip to main content

BMP Loc-RIB: Peer address
draft-francois-grow-bmp-loc-peer-02

Document Type Active Internet-Draft (candidate for grow WG)
Authors Pierre Francois , Maxence Younsi , Paolo Lucente
Last updated 2023-10-24 (Latest revision 2023-10-23)
RFC stream Internet Engineering Task Force (IETF)
Intended RFC status (None)
Formats
Additional resources Mailing list discussion
Stream WG state Call For Adoption By WG Issued
Document shepherd (None)
IESG IESG state I-D Exists
Consensus boilerplate Unknown
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-francois-grow-bmp-loc-peer-02
Network Working Group                                        P. Francois
Internet-Draft                                                 M. Younsi
Updates: 9069 (if approved)                                    INSA-Lyon
Intended status: Standards Track                              P. Lucente
Expires: 25 April 2024                                               NTT
                                                         23 October 2023

                       BMP Loc-RIB: Peer address
                  draft-francois-grow-bmp-loc-peer-02

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 25 April 2024.

Copyright Notice

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

Francois, et al.          Expires 25 April 2024                 [Page 1]
Internet-Draft                bmp-loc-peer                  October 2023

   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  . . . . . . . . . . . . . . . . . .   2
     2.1.  Rx Peer-Address TLV . . . . . . . . . . . . . . . . . . .   3
     2.2.  VRF Import TLV  . . . . . . . . . . . . . . . . . . . . .   3
     2.3.  Previous VRF Sequence TLV . . . . . . . . . . . . . . . .   4
   3.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   5
   4.  Security Considerations . . . . . . . . . . . . . . . . . . .   5
   5.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   5
   6.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   5
     6.1.  Normative References  . . . . . . . . . . . . . . . . . .   5
     6.2.  Informative References  . . . . . . . . . . . . . . . . .   6
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   6

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

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

Francois, et al.          Expires 25 April 2024                 [Page 2]
Internet-Draft                bmp-loc-peer                  October 2023

2.1.  Rx Peer-Address TLV

   In BMPv4 [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.

   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.  The structure
   is illustrated in Figure Figure 1.

   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.

        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)       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       ~              Rx Peer IP Address (4 or 16 octets)              |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                       Figure 1: Rx Peer-Address TLV

2.2.  VRF Import TLV

   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.

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

Francois, et al.          Expires 25 April 2024                 [Page 3]
Internet-Draft                bmp-loc-peer                  October 2023

   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 length field of
   this BMPv4 TLV is the length of the UTF-8 string of the VRF name.

   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.

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

                          Figure 2: VRF Import TLV

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 Figure 3.  The
   length field is an 8 bit value capturing the length 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 Figure 4.

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

Francois, et al.          Expires 25 April 2024                 [Page 4]
Internet-Draft                bmp-loc-peer                  October 2023

                   Figure 3: 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                 ~
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       ~                              ...                              ~
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                    Figure 4: Previous VRF Sequence TLV

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

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

Francois, et al.          Expires 25 April 2024                 [Page 5]
Internet-Draft                bmp-loc-peer                  October 2023

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

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

   [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

   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 25 April 2024                 [Page 6]