Network Working Group C. Lin Internet Draft New H3C Technologies Intended status: Standards Track Z. Li Expires: January 09, 2026 China Mobile July 07, 2025 BGP Specific Route Refresh draft-lin-idr-refresh-enhance-00 Abstract In certain scenarios, a BGP router may not require its peer to update all routes within an address family, but rather only the specific routes it needs. For example, in an EVPN network, a router might only require updates for all MAC/IP Advertisement Routes or all IP Prefix Advertisement Routes, or even just a subset of IP Prefix routes. This document presents a method for requesting the update of specific routes from a peer, thereby minimizing the impact of additional BGP updates. 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), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This Internet-Draft will expire on January 09, 2026. lin, et al. Expires January 09, 2026 [Page 1] Internet-Draft BGP Specific Route Refresh July 2025 Copyright Notice Copyright (c) 2025 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 (http://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 Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction...................................................2 1.1. Requirements Language.....................................3 2. Specific Route-Refresh Message.................................3 3. Specific Route-Refresh Capability..............................4 4. Operation......................................................5 5. Security Considerations........................................5 6. IANA Considerations............................................5 7. References.....................................................6 7.1. Normative References......................................6 7.2. Informational References..................................7 Authors' Addresses................................................7 1. Introduction [RFC2918] describes the method for BGP to request route updates via Refresh messages. When the ingress router's policy changes, it can send Refresh messages to its peers to re-update BGP routes and reapply policies, thereby avoiding the need to locally store all routes. BGP Refresh messages update routes based on the address family + sub-address family. Upon receiving a BGP Refresh message, a peer will send Update messages to update all routes associated with the specified address family. In certain scenarios, a BGP router may not require its peer to update all routes within an address family, but rather only the specific routes it needs. For example, in an EVPN network, a router might only require updates for all MAC/IP Advertisement Routes or lin, et al. Expires December 30, 2024 [Page 2] Internet-Draft BGP Specific Route Refresh July 2025 all IP Prefix Advertisement Routes, or even just a subset of IP Prefix routes. This document presents a method for requesting the update of specific routes from a peer, thereby minimizing the impact of additional BGP updates. 1.1. 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. 2. Specific Route-Refresh Message RFC 2918 defines the Route-Refresh Message format. Type: 5 - ROUTE-REFRESH Message Format: One encoded as 0 7 15 23 31 +-------+-------+-------+-------+ | AFI | Res. | SAFI | +-------+-------+-------+-------+ AFI - Address Family Identifier (16 bit). Res. - Reserved (8 bit) field. SAFI - Subsequent Address Family Identifier (8 bit). The "Reserved" field of the ROUTE-REFRESH message specified in [RFC2918] is redefined as the "Message Subtype" with the following values in [RFC7313]: 0 - Normal route refresh request [RFC2918] with/without Outbound Route Filtering (ORF) [RFC5291] 1 - Demarcation of the beginning of a route refresh (BoRR) operation 2 - Demarcation of the ending of a route refresh (EoRR) operation 255 - Reserved This document defines a new message subtype for a Specific Route Refresh request. TBD - Specific route refresh request. lin, et al. Expires December 30, 2024 [Page 3] Internet-Draft BGP Specific Route Refresh July 2025 At the end of the Specific Route Refresh message, the required Route to be refreshed is specified. The format is as follows: +--------------------------------------------------+ | Address Family Identifier (2 octets) | +--------------------------------------------------+ | Message Subtype (TBD, 1 octet) | +--------------------------------------------------+ | Subsequent Address Family Identifier (1 octet) | +--------------------------------------------------+ | Specific Route Refresh Type (1 octet) | +--------------------------------------------------+ | Specific Route Refresh Value (variable) | +--------------------------------------------------+ This document defines the following values for the "Specific Route Refresh Type (SRRT)": 1 - Specific Route Type: Specify a particular route type for route refresh when the corresponding AFI/SAFI has multiple route types; 2 - Specific Route Prefix: Specify a particular route prefix for route refresh; The "Specific Route Refresh Value (SRRV)" field is variable according to the "SRRT", the detailed description is as follows: * "SRRT" = 1: The "SRRV" is a 1-octet route type of the corresponding AFI/SAFI, such as Ethernet VPN (EVPN) [RFC7432] and MCAST-VPN [RFC6514], which has multiple route types. * "SRRT" = 2: The "SRRV" is a variable-octet BGP Network Layer Reachability Information (NLRI) of the corresponding AFI/SAFI, such as unicast NLRI [RFC4760] and EVPN NLRI [RFC7432]. 3. Specific Route-Refresh Capability In order to allow the dynamic exchange of the Specific route refresh request between BGP speakers and subsequent re-advertisement of the respective Adj-RIB-Out, this document defines a new BGP capability [RFC5492] termed 'Specific Route Refresh Capability'. The Specific Route Refresh Capability is defined as follows: lin, et al. Expires December 30, 2024 [Page 4] Internet-Draft BGP Specific Route Refresh July 2025 Capability code: TBD Capability length: 0 By advertising the Specific Route Refresh Capability to a peer, a BGP can convey to the peer that the speaker has capability to receive and properly handle the Specific Route-Refresh message (as defined in Section 2) from the peer. 4. Operation A BGP speaker that supports the message subtypes for the ROUTE- REFRESH message and the related procedures SHOULD advertise the "Specific Route Refresh Capability". When the speaker needs to refresh specific route of BGP routes, it sends a Specific Route Refresh message, specifying . In processing a ROUTE-REFRESH message from a peer, the BGP speaker MUST examine the "message subtype" field of the message and take the appropriate actions. The message processing rules for ROUTE-REFRESH message with subtype of 0 are described in [RFC2918] and [RFC5291]. The message processing rules for ROUTE-REFRESH message with subtype of 1 and 2 are described in [RFC7313]. Upon receiving a subtype of specific route refresh request (TBD), the BGP speaker sends routes of the corresponding route type or prefix from its local routing table to its neighbor via an Update message. 5. Security Considerations This extension to BGP does not change the underlying security issues. 6. IANA Considerations This document defines a new subcode for the Specific Route Refresh Message. It should be registered with the IANA in a new registry, as follows: Value Code Reference 0 Route-Refresh [RFC2918], [RFC5291] lin, et al. Expires December 30, 2024 [Page 5] Internet-Draft BGP Specific Route Refresh July 2025 1 BoRR [RFC7313] 2 EoRR [RFC7313] TBD Specific Route-Refresh This Document 3-254 Unassigned 255 Reserved [RFC7313] This document also defines a new BGP Capability - the Specific Route Refresh Capability. This new Capability Code also should be assigned in the "Capability Codes" registry by the IANA. 7. References 7.1. 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, . [RFC2918] E. Chen, Redback Networks, September 2000, "Route Refresh Capability for BGP-4", rfc2918.txt, DOI 10.17487/rfc2918.txt, September 2000, . [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, . [RFC6514] Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, "BGP Encodings and Procedures for Multicast in MPLS/BGP IP VPNs", RFC 6514, DOI 10.17487/RFC6514, February 2012, . [RFC7313] K. Patel, E. Chen, Cisco Systems, B. Venkatachalapathy, "Enhanced Route Refresh Capability for BGP-4", rfc7313.txt, DOI 10.17487/rfc7313.txt, July 2014, . [RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A., Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February 2015, . lin, et al. Expires December 30, 2024 [Page 6] Internet-Draft BGP Specific Route Refresh July 2025 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . 7.2. Informational References [RFC5291] Chen, E. and Y. Rekhter, "Outbound Route Filtering Capability for BGP-4", RFC 5291, August 2008. Authors' Addresses Changwang Lin New H3C Technologies China Email: linchangwang.04414@h3c.com Zhenqiang Li China Mobile China Email: lizhenqiang@chinamobile.com lin, et al. Expires December 30, 2024 [Page 7]