BMP Loc-RIB: Peer address
draft-francois-grow-bmp-loc-peer-03
| Document | Type | Active Internet-Draft (candidate for grow WG) | |
|---|---|---|---|
| Authors | Pierre Francois , Maxence Younsi , Paolo Lucente | ||
| Last updated | 2024-03-04 | ||
| 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-03
Network Working Group P. Francois
Internet-Draft M. Younsi
Intended status: Standards Track INSA-Lyon
Expires: 5 September 2024 P. Lucente
NTT
4 March 2024
BMP Loc-RIB: Peer address
draft-francois-grow-bmp-loc-peer-03
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 September 2024.
Copyright Notice
Copyright (c) 2024 IETF Trust and the persons identified as the
document authors. All rights reserved.
Francois, et al. Expires 5 September 2024 [Page 1]
Internet-Draft bmp-loc-peer March 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.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 [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.
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.
Francois, et al. Expires 5 September 2024 [Page 2]
Internet-Draft bmp-loc-peer March 2024
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 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 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
Francois, et al. Expires 5 September 2024 [Page 3]
Internet-Draft bmp-loc-peer March 2024
contains a variable length field matching the definition of VRF/
Table name from [RFC9069]. 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.
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, in bytes, 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 3. 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 4.
Francois, et al. Expires 5 September 2024 [Page 4]
Internet-Draft bmp-loc-peer March 2024
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 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
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 5 September 2024 [Page 5]
Internet-Draft bmp-loc-peer March 2024
[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
Pierre Francois
INSA-Lyon
Villeurbanne
France
Email: pierre.francois@insa-lyon.fr
Maxence Younsi
INSA-Lyon
Villeurbanne
France
Email: maxence.younsi@insa-lyon.fr
Francois, et al. Expires 5 September 2024 [Page 6]
Internet-Draft bmp-loc-peer March 2024
Paolo Lucente
NTT
Siriusdreef 70-72
Hoofddorp, WT 2132
Netherlands
Email: paolo@ntt.net
Francois, et al. Expires 5 September 2024 [Page 7]