Network Working Group P. Francois Internet-Draft M. Younsi Intended status: Standards Track INSA-Lyon Expires: 5 January 2025 P. Lucente NTT 4 July 2024 BMP Loc-RIB: Peer address draft-francois-grow-bmp-loc-peer-04 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 5 January 2025. Copyright Notice Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. Francois, et al. Expires 5 January 2025 [Page 1] Internet-Draft bmp-loc-peer July 2024 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 5 January 2025 [Page 2] Internet-Draft bmp-loc-peer July 2024 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 5 January 2025 [Page 3] Internet-Draft bmp-loc-peer July 2024 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 5 January 2025 [Page 4] Internet-Draft bmp-loc-peer July 2024 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 5 January 2025 [Page 5] Internet-Draft bmp-loc-peer July 2024 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 5 January 2025 [Page 6] Internet-Draft bmp-loc-peer July 2024 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 5 January 2025 [Page 7] Internet-Draft bmp-loc-peer July 2024 * 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, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC7911] Walton, D., Retana, A., Chen, E., and J. Scudder, "Advertisement of Multiple Paths in BGP", RFC 7911, DOI 10.17487/RFC7911, July 2016, . [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, . 6.2. Informative References Authors' Addresses Francois, et al. Expires 5 January 2025 [Page 8] Internet-Draft bmp-loc-peer July 2024 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 5 January 2025 [Page 9]