Internet DRAFT - draft-younsi-grow-local-path-id
draft-younsi-grow-local-path-id
Network Working Group M. Younsi
Internet-Draft P. Francois
Intended status: Standards Track INSA-Lyon
Expires: 5 September 2024 P. Lucente
NTT
4 March 2024
BMP Local Path-ID
draft-younsi-grow-local-path-id-01
Abstract
Intelligence is required to track BGP paths throughout the various
RIBs and VRFs of a routing platform, due to potential attribute
modifications and the use of BGP multipath. This document introduces
the option to identify a path within a router in order to ease
correlation in monitoring. A BMPv4 TLV is defined in order to
communicate this locally significant identifier in monitoring
messages.
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.
Younsi, et al. Expires 5 September 2024 [Page 1]
Internet-Draft local-path-id March 2024
Copyright Notice
Copyright (c) 2024 IETF Trust and the persons identified as the
document authors. All rights reserved.
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. Local Path ID . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Local Path ID Properties . . . . . . . . . . . . . . . . 3
2.2. Design Recommendation . . . . . . . . . . . . . . . . . . 3
3. Advertising the Local Path ID in BMP . . . . . . . . . . . . 4
4. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 5
5. Normative References . . . . . . . . . . . . . . . . . . . . 5
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6
1. Introduction
When using VRFs and/or BGP Multipath, multiple paths to the same
destination may be shared among various routing information bases.
From a collection perspective, tracking the identity of a path thus
requires some form of modeling, which is subject to inaccuracy. This
aspect is exacerbated as path attributes may be modified in the
process. This is especially problematic when a PE using BGP
multipath in VPN instances exports multiple paths for the same
destination into the default VRF, which were learned from different
peers.
While BGP ADD-PATH [RFC7911] provides a way to identify paths in BGP
multi-path scenarios, the scope of the ADD-PATH path-id is local to a
single BGP peering session, and thus cannot be used to distinguish
paths received over multiple sessions.
Younsi, et al. Expires 5 September 2024 [Page 2]
Internet-Draft local-path-id March 2024
This document introduces a way to identify paths globally within a
router, allowing operators to not resort to modeling when monitoring
BGP paths on a router. In Section 2, we introduce the concept of
Local Path ID, which is an identifier of a path for a given NLRI,
preserved through the import/export operations performed onto them.
In Section 3, we introduce a BMPv4 TLV allowing to communicate the
value of a Local Path ID on a BMP session.
2. Local Path ID
In this section, we define an identifier called Local Path ID, which
allows to uniquely identify a path for a given NLRI on a router.
According to this specification, a path to be advertised by BMP is
provided with an associated Local Path ID. The Local Path ID is an
opaque numerical value with a few properties guaranteeing its
utility. The exact approach to generate a Local Path ID is however
left for the implementation.
2.1. Local Path ID Properties
The Local Path ID of each path MUST be unique for a given NLRI. We
scope the identifier space to each NLRI to keep it a small value.
Indeed, most Internet routers have at most a few tens of paths for a
given NLRI. While we put a minimum scope (the NLRI) for the
identifier space, an implementor may decide to use a broader space
for this unicity, as long as Local Path IDs are still unique for a
given NLRI. For example, Local Path IDs can be unique accross VRFs,
even though they will have to be larger, as this does not violate the
rule.
The Local Path ID only has a meaning locally on the router generating
it.
Once generated, the Local Path ID MUST be preserved between VRFs, and
Routing Information Bases. It, however, MUST NOT be exchanged or
synchronized between routers.
The value of 0 for a Local Path ID is reserved.
2.2. Design Recommendation
In this section, we give general recommendations for the Local Path
ID generation. These recommendations may or may not be applicable
depending on the platform, the implementation of BGP, etc. The
actual generation process of the Local Path ID does not matter as
long as the the properties defined in Section 2.1 are respected.
Younsi, et al. Expires 5 September 2024 [Page 3]
Internet-Draft local-path-id March 2024
We recommend having the Local Path ID made of three concatenated
parts: < process_id | vrf_id | path_discriminator >.
The path_discriminator allows differentiation between different paths
for a NLRI, coming from the same table and process (with the same
vrf_id and process_id). The process originating the path is in
charge of guaranteeing the uniqueness of the path_discriminator it
produces for each path of its NLRIs.
The vrf_id represents a unique identifier for the VRF in which the
path to the NLRI is contained. It allows leveraging the already
existing routing table structures of most BGP implementations by
having to guarantee the uniqueness of the path_discriminator only
within the table.
The process_id is the identifier of the process which produced,
originated, or received a path. The process_id allows
differentiation between path IDs generated in BGP from path IDs
generated in other processes like an IGP. Redistributed IGP paths
will then have a different Local Path ID no matter if BGP or another
IGP has chosen the same path_discriminator value. Using the
process_id avoids requiring interprocess synchronization of
path_discriminators or the use of a Local Path ID management process.
To ensure traceability in monitoring, processes importing a path
(like BGP redistribution or VRF imports) MUST keep the same Local
Path ID if provided by the source.
3. Advertising the Local Path ID in BMP
The Local Path ID is to be included in BMPv4 Route Monitoring
messages [I-D.ietf-grow-bmp-tlv] as an optional TLV, called "Local
Path ID TLV".
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 (TBD) | Length (2 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Index (2 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ local_path_id ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1
Younsi, et al. Expires 5 September 2024 [Page 4]
Internet-Draft local-path-id March 2024
Type: set to TBD
Length: the length of the Local Path ID, in bytes
Index: index of the NLRI in the BGP Update PDU as described by
[I-D.ietf-grow-bmp-tlv]. The Index MUST refer to a single NLRI
(no Group TLV).
local_path_id: the Local Path ID defined in Section 2
4. Error Handling
An implementation enabled for Local Path ID usage MUST notify if a
Local Path ID is unavailable (for any reason) by setting the value
field to the reserved value of 0, on a single byte, followed by a
2-byte error code from Table 1. The Length field of the "Local Path
ID TLV" is thus set to 3 in this case.
+======+=================================================+
| Code | Description |
+======+=================================================+
| 0x00 | Unknown Reason |
+------+-------------------------------------------------+
| 0x01 | Origin process did not provide a Local Path ID. |
+------+-------------------------------------------------+
| 0x02 | All Local Path ID have already been allocated. |
+------+-------------------------------------------------+
Table 1: Local Path ID Unavailability Reason Codes
This means such implementations SHOULD always include a Local Path ID
TLV (Section 3).
5. Normative References
[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>.
Younsi, et al. Expires 5 September 2024 [Page 5]
Internet-Draft local-path-id 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>.
Authors' Addresses
Maxence Younsi
INSA-Lyon
Villeurbanne
France
Email: maxence.younsi@insa-lyon.fr
Pierre Francois
INSA-Lyon
Villeurbanne
France
Email: pierre.francois@insa-lyon.fr
Paolo Lucente
NTT
Siriusdreef 70-72
Hoofddorp, WT 2132
Netherlands
Email: paolo@ntt.net
Younsi, et al. Expires 5 September 2024 [Page 6]
