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

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 mechanism, referred to as Unreachable Prefix Announcement (UPA), has been specified for IGPs. This document specifies an and equivalent BGP mechanism for multi-AS networks where BGP is used to carry summary routes. 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, Interior Gateway Protocols (IGPs) have implemented an Unreachable Prefix Announcement (UPA) mechanism 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, particularly those leveraging SRv6, where IGP is not running end-to-end, a BGP-based UPA is crucial. It ensures that the loss of reachability for an SRv6 locator or an egress PE loopback, which might be part of a summarized route, can be quickly communicated across AS boundaries, thereby maintaining fast convergence and network stability.

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.
• SRv6: Segment Routing over IPv6.
• BGP PIC: BGP Prefix Independent Convergence.
• PE: Provider Edge router.
• AS: Autonomous System.
• RIB: Routing Information Base.
• MP_UNREACH: Multiprotocol Unreachable NLRI.
• ExtCom: Extended Community.
• AFI: Address Family Identifier.
• SAFI: Subsequent Address Family Identifier.

Reference Deployment Scenario The primary deployment scenario for BGP UPA is a multi-AS network with an SRv6 deployment. In this environment, BGP is used to carry SRv6 locators across AS boundaries, and summarization is performed at these boundaries to maintain scalability. When a specific SRv6 locator within a summary becomes unreachable, the UPA mechanism is needed to signal this event across the ASes to the ingress PEs to trigger BGP-PIC. This document considers two primary BGP transport options for SRv6:

• BGP IPv6 Unicast (AFI=2, SAFI=1)
• BGP CAR for SRv6 (AFI=2, SAFI=83)

While both options are viable, the rest of this document primarily considers the use of BGP IPv6 Unicast but the described UPA mechanism is applicable to just as well to BGP CAR or any other BGP transport routing deployment that uses route summarization.

BGP UPA Message Format A BGP UPA message is used to announce the loss of reachability of a specific prefix. The specific prefix whose reachability is lost is encoded in the MP_UNREACH_NLRI attribute . The UPA Extended Community (as defined in Section 5.1) is the only other attribute that applies to a UPA message. 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.

UPA Extended Community A new Transitive IPv4-Address-Specific Extended Community is defined for UPA. The structure of this Extended Community is as follows:

• Type Field: TBD (assigned by IANA).
• Sub-Type Field: TBD (assigned by IANA).
• Global Administrator Field (4 bytes): This field carries the BGP Router-ID of the node originating the UPA in BGP. This is helpful for troubleshooting and tracing the originator in a multi-domain network. It is assumed that BGP Router-IDs are unique within the operator's managed ASes.
• Local Administrator Field (2 bytes): This field is set to zero.

Trigger for UPA Origination in BGP UPA origination in BGP can be triggered by two main 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 aggregation or 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 trigger (in either of the two scenarios) is processed by BGP only when in the absense of a valid reachable route in BGP 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 state for the prefix SHOULD be retained for a time period to ensure it has been propagated to its neighbors and avoid generation of multiple UPA messages for the same prefix.

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 Section 7) and propagate it to their peers as appropriate.

UPA Processing in BGP A BGP speaker processes UPA messages only for those prefixes for which it does not have a valid reachable route. The processing of UPA message involves notification of unreachability within the router to trigger BGP PIC. The details of this mechanism are outside the scope of this document.

UPA Timer The UPA state needs to be retained in the BGP table for a configurable duration. This is crucial to prevent unwanted flooding and to allow sufficient time for the UPA to be propagated to all relevant peers.

Backwards Compatibility The UPA mechanism is designed to be backwards compatible. Since a UPA is propagated as an MP_UNREACH_NLRI, a BGP speaker that does not understand the UPA Extended Community will simply discard or ignore the update as a withdrawal for a non-existent prefix. 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.

Security Considerations The primary security consideration relates to the use of BGP IPv6 Unicast for carrying SRv6 locators. There is a 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 configurable knob to disable UPA propagation to specific neighbors (Section 11) can serve as a mitigation strategy to limit the scope of UPA messages to trusted domains.

IANA Considerations This document requests that IANA assign a new Transitive IPv4-Address- Specific Extended Community type and sub-type from the FCFS range for UPA.

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 Cisco Systems Juniper Networks, Inc. Verizon Inc. Summarization is often used in multi-area or 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 describes how to use the existing protocol mechanisms in IS-IS and OSPF, together with the two new flags, to advertise such prefix reachability loss. 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 and Clarence Filsfils for their valuable input and review of this document.