Network Working Group P. Francois Internet-Draft M. Younsi Updates: 9069 (if approved) INSA-Lyon Intended status: Standards Track P. Lucente Expires: 11 January 2024 NTT 10 July 2023 BMP Loc-RIB: Peer address draft-francois-grow-bmp-loc-peer-01 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 11 January 2024. Copyright Notice Copyright (c) 2023 IETF Trust and the persons identified as the document authors. All rights reserved. Francois, et al. Expires 11 January 2024 [Page 1] Internet-Draft bmp-loc-peer July 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. BMPv3 Behavior . . . . . . . . . . . . . . . . . . . . . . . 2 3. BMPv4 TLV Based Behavior . . . . . . . . . . . . . . . . . . 3 3.1. Rx Peer-Address TLV . . . . . . . . . . . . . . . . . . . 3 3.2. VRF Import TLV . . . . . . . . . . . . . . . . . . . . . 3 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 5. Security Considerations . . . . . . . . . . . . . . . . . . . 5 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 7.1. Normative References . . . . . . . . . . . . . . . . . . 5 7.2. Informative References . . . . . . . . . . . . . . . . . 5 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 5 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. 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. 2. BMPv3 Behavior 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. 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ |F|V| | | | | | | +-+-+-+-+-+-+-+-+ Francois, et al. Expires 11 January 2024 [Page 2] Internet-Draft bmp-loc-peer July 2023 Figure 1: Per-peer flags A flag is introduced in the BMP Loc-RIB per-peer header flags to describe whether the peer address is IPv4 or IPv6. 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. 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. 3. BMPv4 TLV Based Behavior In this section, we describe a variant of the solution based on BMPv4 TLVs. Section 3.1 describes a BMPv4 TLV used to convey the peer address. Section 3.2 introduces optional TLVs for the case of paths imported from another VRF. 3.1. Rx Peer-Address TLV In BMP v4 [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 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. 3.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 Francois, et al. Expires 11 January 2024 [Page 3] Internet-Draft bmp-loc-peer July 2023 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. 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. 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 2. 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. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ ~ ~ ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2: VRF sequence entry 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. In the exemple above, the sequence listed in the Previous VRF sequence would be [B, A]. Francois, et al. Expires 11 January 2024 [Page 4] Internet-Draft bmp-loc-peer July 2023 4. 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. 5. Security Considerations This document does not introduce new security considerations. 6. Acknowledgements We would like to thank Camilo Cardona, Jeff Haas, for their valuable input on this document. 7. References 7.1. Normative References [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, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [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, . 7.2. Informative References Authors' Addresses Francois, et al. Expires 11 January 2024 [Page 5] Internet-Draft bmp-loc-peer July 2023 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 11 January 2024 [Page 6]