]> Cisco Systems

De Kleetlaan 6a Diegem 1831 Belgium sekrier@cisco.com

Cisco Systems

Milpitas CA 95035 USA jakuhorn@cisco.com

Swisscom AG

Alte Tiefenaustrasse 6 Worblaufen 3048 Switzerland mihai.ciurea@swisscom.com

Nvidia

USA jefftant.ietf@gmail.com

Arrcus, Inc.

2077 Gateway Pl San Jose, CA 95110 USA keyur@arrcus.com

Routing Inter-Domain Routing UPA PIC Summarization is often used in multi-domain networks to improve network efficiency and scalability. With summarization in place, there is a need to signal loss of reachability to an individual prefix covered by the summary. This enables fast convergence by steering traffic away from the node which owns the prefix and is no longer reachable. This document specifies the mechanism, referred to as Unreachable Prefix Announcement (UPA), for networks where BGP is used to carry summary routes. It is also equally beneficial for operators to share the unreachable prefixes. About This Document Status information for this document may be found at . Discussion of this document takes place on the Inter-Domain Routing Working Group mailing list (), which is archived at . Subscribe at .

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

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 when, and only when, they appear in all capitals, as shown here.

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.

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 or Ethernet VPN (EVPN) Route Type 5 . 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).

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 . 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 for the UPA prefix.

UPA Extended Community A new Transitive Opaque Extended Community is defined for UPA. The structure of this Extended Community is as follows:

• Type Field: 0x03 (Transitive Opaque Extended Community, per ).
• Sub-Type Field: TBD (assigned by IANA).
• Flags Field (1 byte): See below.
• Reserved (1 byte): MUST be set to zero on transmission and ignored on receipt.
• BGP Router ID (4 bytes): This field carries the BGP Router-ID of the node originating the UPA in BGP. This is helpful for the identification of the originator in a multi-domain network since the deployment is intended within a single administrative domain. It is assumed that BGP Router-IDs are unique within the operator's managed ASes. It does not influence route selection or forwarding behavior.

The Flags field is 8 bits in length and is defined as follows:

• Bit 0 (D bit): If set, the forwarding entry corresponding to the route SHOULD be set to drop the traffic received for it. The receiver MAY skip installing such a forwarding entry due to local policy or when it is a route-reflector that is not in the forwarding path.
• Bits 1-7: These bits MUST be set to zero and ignored on receipt.

Trigger for UPA Origination in BGP UPA origination in BGP can be triggered by multiple scenarios and following are two scenarios:

Scenario A: IGP Redistribution of Summary into BGP When an IGP summary route is redistributed into BGP, and a specific component prefix within that summary loses reachability in the IGP, the UPA indication is conveyed from IGP to BGP. The details of this mechanism is implementation specific and outside the scope of this document.

Scenario B: BGP Aggregation/Summarization When BGP itself is performing summarization, and a constituent specific route goes away, the UPA is triggered internally within BGP. Implementations SHOULD provide a configurable option to specify which types of specific prefixes trigger UPA (e.g., only /48 prefixes for SRv6 locators).

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

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

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.

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

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.

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.

IANA Considerations This document requests IANA to perform the following actions.

BGP Transitive Opaque Extended Community Sub-Type IANA is requested to assign a Sub-Type for the "UPA Extended Community" (defined in this document) from the "BGP Extended Communities" registry, specifically within the "Transitive Opaque Extended Community Sub-Types" sub-registry. New Transitive Opaque Extended Community Sub-Type

Sub-Type Value	Description	Reference
TBD	UPA Extended Community	[This-Doc]

Note to IANA: The assignment should be made from the First Come First Served (FCFS) range (0x00-0xBF) as per .

UPA Flags Registry IANA is requested to create a new registry for the 8-bit "UPA Flags" field of the UPA Extended Community. The registration policy for this registry is "IETF Review" or "Expert Review" as per . UPA Flags

Bit	Description	Reference
0	D-bit (Drop bit)	[This-Doc]
1-7	Unassigned

References Normative References This document defines extensions to BGP-4 to enable it to carry routing information for multiple Network Layer protocols (e.g., IPv6, IPX, L3VPN, etc.). The extensions are backward compatible - a router that supports the extensions can interoperate with a router that doesn't support the extensions. [STANDARDS-TRACK] In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Informative References Cisco Systems Cisco Systems Sproute Networks In a network comprising thousands of BGP peers exchanging millions of routes, many routes are reachable via more than one next-hop. Given the large scaling targets, it is desirable to restore traffic after failure in a time period that does not depend on the number of BGP prefixes. This document describes an architecture by which traffic can be re- routed to equal cost multi-path (ECMP) or pre-calculated backup paths in a timeframe that does not depend on the number of BGP prefixes. The objective is achieved through organizing the forwarding data structures in a hierarchical manner and sharing forwarding elements among the maximum possible number of routes. The described technique yields prefix independent convergence while ensuring incremental deployment, complete automation, and zero management and provisioning effort. It is noteworthy to mention that the benefits of BGP Prefix Independent Convergence (BGP-PIC) are hinged on the existence of more than one path whether as ECMP or primary-backup.

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 Cisco Systems

170 W. Tasman Drive San Jose, CA 95134 United States of America kriswamy@cisco.com