BGP Unreachable Prefix Announcement (UPA)

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 19 November 2026.¶

Copyright Notice

Copyright (c) 2026 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

In modern networks, route summarization is a common practice to reduce routing table size and improve scalability. However, summarization can mask the loss of reachability of specific prefixes covered by the summary route, leading to slower convergence times.¶

To address this, an Unreachable Prefix Announcement (UPA) mechanism [RFC9929] has been specified for Interior Gateway Protocols (IGPs) to explicitly signal the loss of specific prefixes, enabling fast convergence mechanisms like BGP Prefix Independent Convergence (PIC) [I-D.ietf-rtgwg-bgp-pic] on ingress devices.¶

This document proposes a similar UPA mechanism for BGP. In multi-AS networks where IGP is not running end-to-end, a BGP-based UPA is crucial. It ensures that the loss of reachability for a specific prefix which might be part of a summarized route, can be quickly signaled across AS boundaries, thereby enabling fast convergence without compromising on the scaling benefits of route summarization.¶

2. Conventions and Definitions

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. Terminology

• UPA: Unreachable Prefix Announcement.¶

• BGP PIC: BGP Prefix Independent Convergence.¶

• PE: Provider Edge router.¶

• AS: Autonomous System.¶

• RIB: Routing Information Base.¶

• MP_REACH: Multiprotocol Reachable NLRI.¶

• MP_UNREACH: Multiprotocol Unreachable NLRI.¶

• ExtCom: Extended Community.¶

• AFI: Address Family Identifier.¶

• SAFI: Subsequent Address Family Identifier.¶

4. Applicability

BGP UPA applies to any operator network where BGP carries reachability information and summarization is performed. When a specific prefix within a summary becomes unreachable, the UPA mechanism is needed to signal this loss of reachability across the network to edge or leaf routers to trigger fast reconvergence (e.g., to trigger BGP-PIC at the ingress PEs).¶

A typical deployment scenario is a multi-AS network where BGP is used to carry IP Prefixes using either AFI=1/2, SAFI=1. However, the mechanism described in this document is equally applicable to any BGP address family that uses route summarization, such as BGP CAR for SRv6 [RFC9871] or Ethernet VPN (EVPN) Route Type 5 [RFC9136].¶

The BGP UPA mechanism is intended to be enabled and deployed in a network under the administration of a single operator or cooperative operators (either a single AS or multi-AS).¶

5. BGP UPA Signaling

A BGP UPA is signaled as a BGP UPDATE used to indicate the loss of reachability of a specific prefix.¶

The specific prefix whose reachability is lost is encoded in the MP_REACH_NLRI attribute [RFC4760]. The next-hop is set following standard BGP procedures.¶

The UPA Extended Community (as defined in Section 5.1) MUST be attached to the route to identify it as a UPA.¶

An Update message carrying a UPA MUST only contain UPA prefixes (i.e., no other reachability advertisements or withdrawals) due to the presence of the UPA Extended Community.¶

To withdraw a previously announced UPA, a BGP speaker sends an MP_UNREACH_NLRI [RFC4760] for the UPA prefix.¶

 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      |   Sub-Type    |     Flags     |   Reserved    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                       BGP Router ID                           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|D|   Reserved  |
+-+-+-+-+-+-+-+-+

6. Trigger for UPA Origination in BGP

UPA origination in BGP can be triggered by multiple scenarios and following are two scenarios:¶

7. UPA Origination in BGP

UPA origination is triggered by BGP only in the absence of a valid reachable route for that specific prefix. The origination of UPA indication involves the update generation of the BGP UPA message as specified in Section 5.¶

The UPA route MUST be withdrawn when the specific prefix becomes reachable. The originator MAY withdraw the UPA route before the specific prefix becomes reachable if the use of the UPA in the deployment was only to serve as an event notification of unreachability that does not require the unreachability state to be maintained until that prefix becomes reachable.¶

8. UPA Propagation in BGP

The propagation of UPA messages in BGP follows the same principles as UPA origination. BGP speakers receiving a UPA will process it (refer to Section 9) and propagate it to their peers as appropriate.¶

When a BGP speaker receives routes with the UPA ExtCom from multiple peers, it MUST aggregate the UPA ExtComs from all UPA routes when propagating the UPA message. This ensures that the receiver gets all the originators of the UPA when this is being triggered from multiple routers.¶

9. UPA Processing in BGP

A BGP speaker processes UPA messages only for those prefixes for which it does not have a valid reachable route. A route carrying the UPA Extended Community is not considered a valid reachable route for this purpose. If a valid reachable route for the prefix is subsequently received, it MUST take precedence over the UPA route.¶

In the absence of a valid reachable route for a prefix, the UPA route for that prefix becomes the best route. However, since it is not a reachable route, it MUST NOT be considered as valid for forwarding traffic or redistribution into other protocols except as unreachable. A forwarding entry SHOULD be programmed with indication to drop traffic matching that prefix, if the UPA ExtCom has the drop D-bit flag set.¶

The processing of UPA message on certain BGP speakers would also involve notification of unreachability depending on the deployment use case. The details of this mechanism are outside the scope of this document.¶

10. Backwards Compatibility

A BGP speaker that does not understand the UPA Extended Community will treat the UPA as a standard route advertisement for the prefix. Due to longest-prefix-match, this may attract traffic toward a next-hop that cannot deliver it to the unreachable destination. However, this would not be significantly different than when the forwarding happens using the summary. This can be addressed by mechanisms in Section 11.¶

Also, the UPA ExtCom being transitive will be carried as unknown ExtCom across BGP Speakers which do not understand it and get treated correctly at routers that understand UPA. To prevent this, a BGP speaker MUST only send UPA messages to peers that are known to support UPA processing.¶

Implementations SHOULD provide a configuration knob to enable UPA propagation to specific neighbors. The default MUST be to not propagate UPA messages. This ensures that UPA propagation can be limited to the desired domain or network boundary.¶

11. Operational Considerations

By default, UPA origination MUST be disabled. Implementations SHOULD provide a configurable option to enable UPA origination on a per-address-family basis.¶

By default, the propagation of UPA MUST be disabled across AS boundaries. Implementations SHOULD provide a configuration knob to enable UPA propagation to specific neighbors. This ensures that UPA propagation can be limited to the desired domain or network boundary.¶

Implementations SHOULD provide configuration to allow operators to enforce limits on the number of UPA routes that can be originated at any given time. This prevents excessive UPA generation during large-scale failures which could overwhelm BGP speakers and degrade network stability. The specific limits are implementation-defined and SHOULD be configurable by the operator.¶

12. Security Considerations

The primary security consideration relates to the potential for leakage of internal infrastructure details into the public Internet if filtering route policies are misconfigured. The explicit signaling of unreachable prefixes via UPA could reveal more granular internal network topology information if not properly contained.¶

Operators SHOULD ensure robust filtering policies are in place at AS boundaries. The operational considerations in this document can serve as a mitigation strategy to limit the scope of UPA messages to trusted domains.¶

13. IANA Considerations

This document requests IANA to perform the following actions.¶

14. References

Acknowledgments

The authors would like to acknowledge the contribution of Ketan Talaulikar, Clarence Filsfils for their valuable input and review of this document. The authors would like also to recognize Swadesh Agrawal and Dhananjaya Rao for the initial idea.¶

Contributors

Authors' Addresses