Inter-Domain Routing D. Abraitis Internet-Draft NetDef Intended status: Standards Track A. Retana Expires: 26 April 2027 Futurewei Technologies, Inc. J. Haas HPE 23 October 2026 Paths Limit for Multiple Paths in BGP draft-abraitis-idr-addpath-paths-limit-06 Abstract This document specifies a BGP capability that complements the ADD- PATH Capability by indicating the maximum number of paths a BGP speaker can receive from a peer, optimizing the transmission of BGP routes by selectively relaying pertinent routes instead of the entire set. This document also defines a new BGP Cease NOTIFICATION message subcode, "Maximum Number of Paths Reached", used when a BGP speaker terminates a peering because the number of paths received from a neighbor for a prefix exceeds the Paths Limit advertised in the PATHS-LIMIT Capability. 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 26 April 2027. Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. Abraitis, et al. Expires 26 April 2027 [Page 1] Internet-Draft Paths Limit for Multiple Paths in BGP October 2026 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. Specification of Requirements . . . . . . . . . . . . . . . . 3 3. PATHS-LIMIT Capability . . . . . . . . . . . . . . . . . . . 3 4. Maximum Number of Paths Reached Cease NOTIFICATION Subcode . 4 5. Operational Considerations . . . . . . . . . . . . . . . . . 5 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 6.1. BGP Capability Code . . . . . . . . . . . . . . . . . . . 6 6.2. BGP Cease NOTIFICATION Message Subcode . . . . . . . . . 6 7. Security Considerations . . . . . . . . . . . . . . . . . . . 6 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 7 References . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 Normative References . . . . . . . . . . . . . . . . . . . . . 7 Informative References . . . . . . . . . . . . . . . . . . . . 8 Appendix A. Implementation Report . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 1. Introduction BGP ADD-PATH [RFC7911] defines a BGP extension that allows the advertisement of multiple paths for the same address prefix without the new paths implicitly replacing any previous ones. Multiple paths for a large number of prefixes may be received by a BGP speaker, potentially depleting memory resources or even causing network-wide instability. Such instability could be considered a denial-of-service attack. Without knowing the maximum number of paths the receiver wants to receive, the sender may send more than that number of paths. [I-D.ietf-idr-add-paths-guidelines] provides recommendations for the use of BGP ADD-PATH while implementing specific applications. This document specifies a BGP capability [RFC5492] that complements the ADD-PATH Capability [RFC7911] by indicating the maximum number of paths a BGP speaker can receive from a peer. This indication allows the sender to optimize the transmission of BGP routes by selectively relaying pertinent routes instead of the entire set. Abraitis, et al. Expires 26 April 2027 [Page 2] Internet-Draft Paths Limit for Multiple Paths in BGP October 2026 The BGP Cease NOTIFICATION message [RFC4271] is used when a BGP speaker terminates its peering with a neighbor. [RFC4486] defines subcodes for the Cease NOTIFICATION message to aid network operators in correlating network events and diagnosing BGP peering issues, including the "Maximum Number of Prefixes Reached" subcode. A sender may not support the PATHS-LIMIT Capability, or may otherwise send more paths for a prefix than the receiver indicated in its Paths Limit. No existing Cease subcode precisely describes the termination of a peering because the advertised Paths Limit was exceeded. This document therefore also defines the "Maximum Number of Paths Reached" Cease NOTIFICATION subcode for this purpose. 2. Specification of Requirements 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. 3. PATHS-LIMIT Capability The PATHS-LIMIT Capability is a BGP capability [RFC5492], with Capability Code 76. The Capability Length field of this capability is variable. The Capability Value field consists of one or more of the following tuples: +------------------------------------------------+ | Address Family Identifier (2 octets) | +------------------------------------------------+ | Subsequent Address Family Identifier (1 octet) | +------------------------------------------------+ | Paths Limit (2 octet) | +------------------------------------------------+ Figure 1 The meaning and use of the fields are as follows: Address Family Identifier (AFI): This field is the same as the one used in [RFC4760]. Subsequent Address Family Identifier (SAFI): This field is the same as the one used in [RFC4760]. Abraitis, et al. Expires 26 April 2027 [Page 3] Internet-Draft Paths Limit for Multiple Paths in BGP October 2026 Paths Limit: This field indicates the maximum paths limit the receiver wants to receive from its peer. If the received Paths Limit is zero (0), the tuple SHOULD be ignored. A BGP speaker that wishes to indicate support for multiple AFI/SAFIs MUST do so by including the information in a single instance of the PATHS-LIMIT capability. The PATHS-LIMIT capability MUST be ignored if the ADD-PATH capability is not present. If the PATHS-LIMIT capability is empty (i.e. the Capability Length field is set to 0), it means that the sender doesn't have any specific limits to communicate. An AFI/SAFI tuple MUST be ignored if the same tuple was not received in the ADD-PATH capability. If more than one tuple is received for the same AFI/SAFI pair, only the first tuple should be considered. All others MUST be ignored. A sender advertising multiple paths for the same prefix SHOULD send only the specified maximum number of paths indicated in the PATHS- LIMIT capability. An implementation SHOULD provide a configuration knob to specify the maximum number of paths to accept from a sender. The handling of a sender that exceeds this limit is described in Section 5. 4. Maximum Number of Paths Reached Cease NOTIFICATION Subcode This document defines the "Maximum Number of Paths Reached" Cease NOTIFICATION message subcode, with value TBD (see Section 6). When a BGP speaker terminates a peering because the number of paths [RFC7911] received from the neighbor for a prefix exceeds the Paths Limit the BGP speaker advertised for the corresponding in the PATHS-LIMIT Capability (Section 3), the BGP speaker SHOULD send a NOTIFICATION message with the error code "Cease" and the error subcode "Maximum Number of Paths Reached". A BGP speaker MUST NOT send this subcode for an unless it advertised a non-zero Paths Limit for that in the PATHS- LIMIT Capability, and ADD-PATH [RFC7911] was negotiated with the peer such that the BGP speaker is able to receive multiple paths for that . Abraitis, et al. Expires 26 April 2027 [Page 4] Internet-Draft Paths Limit for Multiple Paths in BGP October 2026 Following the format defined in [RFC4486], Section 4, the message MAY optionally include the Address Family information [RFC4760] and the advertised Paths Limit in the "Data" field, as shown in Figure 2. +------------------------------------------------+ | Address Family Identifier (2 octets) | +------------------------------------------------+ | Subsequent Address Family Identifier (1 octet) | +------------------------------------------------+ | Paths Limit (2 octets) | +------------------------------------------------+ Figure 2: Maximum Number of Paths Reached Data Field The "Paths Limit" field contains the Paths Limit the BGP speaker advertised in the PATHS-LIMIT Capability for the indicated , which was exceeded and triggered the termination. If a BGP speaker terminates a peering because the Paths Limit was exceeded for more than one , it MAY include the Data field for any one of them. 5. Operational Considerations The PATHS-LIMIT Capability lets a receiver signal its Paths Limit to the sender, so that the sender can avoid exceeding it in the first place. The "Maximum Number of Paths Reached" subcode is the complementary enforcement signal: it indicates termination when the number of paths received for a prefix exceeds the advertised Paths Limit, for example because the sender does not support the PATHS- LIMIT Capability, ignored it, or sent more paths than indicated. A speaker that terminates a peering because it exceeded a bound on the number of prefixes continues to use the "Maximum Number of Prefixes Reached" subcode [RFC4486]. Terminating the peering is the most disruptive response, because it discards all paths for all prefixes even when only a small number of prefixes exceed the Paths Limit. Where feasible, a receiver SHOULD prefer graceful handling that preserves the session, as recommended in [I-D.ietf-idr-add-paths-guidelines], over termination. Such handling includes treating the affected prefixes as withdrawn, or accepting only the permitted number of paths for those prefixes and discarding the excess, while logging the event for the operator. A receiver SHOULD send the "Maximum Number of Paths Reached" subcode only when its local policy does terminate the peering. When BGP Graceful Restart with NOTIFICATION support has been negotiated, a speaker that sends or receives this subcode follows the procedures of [RFC8538]. A speaker whose local policy requires the Abraitis, et al. Expires 26 April 2027 [Page 5] Internet-Draft Paths Limit for Multiple Paths in BGP October 2026 immediate discard of the routes received from the peer uses the Hard Reset mechanism of [RFC8538], carrying the "Cease" code and "Maximum Number of Paths Reached" subcode in the Data field of the Hard Reset message. 6. IANA Considerations 6.1. BGP Capability Code IANA has assigned capability number 76 for the PATHS-LIMIT Capability described in this document. This registration is in the BGP Capability Codes registry. +=======+========================+ | Value | Description | +=======+========================+ | 76 | PATHS-LIMIT Capability | +-------+------------------------+ Table 1: PATHS-LIMIT Capability 6.2. BGP Cease NOTIFICATION Message Subcode IANA is requested to assign a value from the "BGP Cease NOTIFICATION message subcodes" registry, with the name "Maximum Number of Paths Reached" and a reference to this document. +=======+=================================+ | Value | Name | +=======+=================================+ | TBD | Maximum Number of Paths Reached | +-------+---------------------------------+ Table 2: Maximum Number of Paths Reached Cease Subcode 7. Security Considerations This document defines a BGP extension that allows a receiver to better control the number of routes it receives when using BGP ADD- PATH [RFC7911]. Use of the PATHS-LIMIT capability can then mitigate some of the security-related concerns expressed in [RFC7911]. Abraitis, et al. Expires 26 April 2027 [Page 6] Internet-Draft Paths Limit for Multiple Paths in BGP October 2026 A rogue node or misconfiguration can result in the advetisement of a Paths Limit value that is too low for the application being used. This can result in inconsistent forwarding. Describing applications for BGP ADD-PATH is outside the scope of this document. Users of the PATHS-LIMIT Capability are encouraged to examine the behavior and potential impact by studying the best practices described in [I-D.ietf-idr-add-paths-guidelines]. The "Maximum Number of Paths Reached" Cease NOTIFICATION subcode defined in this document provides information to aid network operators in correlating network events and diagnosing BGP peering issues. This subcode is purely informational and has no impact on the BGP Finite State Machine beyond that already documented by [RFC4271], Sections 6.6 and 6.7. Acknowledgements The authors would like to thank everyone who has commented on this work, including Robert Raszuk, Shyam Sethuram. References 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, . [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, DOI 10.17487/RFC4271, January 2006, . [RFC4486] Chen, E. and V. Gillet, "Subcodes for BGP Cease Notification Message", RFC 4486, DOI 10.17487/RFC4486, April 2006, . [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, "Multiprotocol Extensions for BGP-4", RFC 4760, DOI 10.17487/RFC4760, January 2007, . [RFC5492] Scudder, J. and R. Chandra, "Capabilities Advertisement with BGP-4", RFC 5492, DOI 10.17487/RFC5492, February 2009, . Abraitis, et al. Expires 26 April 2027 [Page 7] Internet-Draft Paths Limit for Multiple Paths in BGP October 2026 [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, . [RFC8538] Patel, K., Fernando, R., Scudder, J., and J. Haas, "Notification Message Support for BGP Graceful Restart", RFC 8538, DOI 10.17487/RFC8538, March 2019, . Informative References [I-D.ietf-idr-add-paths-guidelines] Uttaro, J., Francois, P., Patel, K., Haas, J., Simpson, A., and R. Fragassi, "Best Practices for Advertisement of Multiple Paths in IBGP", Work in Progress, Internet-Draft, draft-ietf-idr-add-paths-guidelines-08, 25 April 2016, . Appendix A. Implementation Report According to RFC 7942, "This will allow reviewers and working groups to assign due consideration to documents that have the benefit of running code, which may serve as evidence of valuable experimentation and feedback that have made the implemented protocols more mature". FRRouting (https://github.com/opensourcerouting/frr/ commit/786cf4d2b488f38fcb43e3ea8e49de06a69ef175) implementation. Authors' Addresses Donatas Abraitis NetDef Email: donatas@opensourcerouting.org Alvaro Retana Futurewei Technologies, Inc. Email: aretana@futurewei.com Jeffrey Haas HPE Abraitis, et al. Expires 26 April 2027 [Page 8] Internet-Draft Paths Limit for Multiple Paths in BGP October 2026 Email: jeffrey.haas@hpe.com Abraitis, et al. Expires 26 April 2027 [Page 9]