BGP Specific Route Refresh
draft-lin-idr-refresh-enhance-00
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Authors | Changwang Lin , Zhenqiang Li | ||
| Last updated | 2025-07-07 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-lin-idr-refresh-enhance-00
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 <AFI, SAFI> 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 <AFI, SAFI, SRRT,
SRRV>.
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, <https://www.rfc-
editor.org/rfc/rfc2119>.
[RFC2918] E. Chen, Redback Networks, September 2000, "Route Refresh
Capability for BGP-4", rfc2918.txt, DOI
10.17487/rfc2918.txt, September 2000, <https://www.rfc-
editor.org/info/rfc2918.txt>.
[RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter,
"Multiprotocol Extensions for BGP-4", RFC 4760, DOI
10.17487/RFC4760, January 2007, <http://www.rfc-
editor.org/info/rfc4760>.
[RFC5492] Scudder, J. and R. Chandra, "Capabilities Advertisement
with BGP-4", RFC 5492, DOI 10.17487/RFC5492, February
2009, <https://www.rfc-editor.org/info/rfc5492>.
[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, <https://www.rfc-editor.org/info/rfc6514>.
[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,
<https://www.rfc-editor.org/info/rfc7313.txt>.
[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, <https://www.rfc-editor.org/info/rfc7432>.
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, <https://www.rfc-editor.org/info/rfc8174>.
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]