]> Nvidia

jefftant.ietf@gmail.com

Nvidia

vivek@nvidia.com

Nvidia

kmuppalla@nvidia.com

Nvidia

pdoijode@nvidia.com

CoreWeave

mrzehak@coreweave.com

Routing BESS Working Group BGP EVPN Unreachability Monitoring Route Type This document defines a new EVPN Route Type for signaling prefix unreachability information without affecting the forwarding plane. The route type reuses the Route Type 5 (IP Prefix Advertisement) field order defined for EVPN IP prefix routes, adds an Address Family octet for unambiguous IPv4/IPv6 parsing, and appends Reporter TLVs that allow aggregation of unreachability reports from multiple network vantage points.

Introduction EVPN (Ethernet VPN) provides a flexible framework for Layer 2 and Layer 3 VPN services. While EVPN includes mechanisms for advertising reachable prefixes via Route Type 5 (IP Prefix Advertisement Route) , there is no standard way to signal unreachability information for monitoring and troubleshooting purposes without affecting the forwarding plane. Similar to the challenges in standard BGP, EVPN withdrawals are only propagated for prefixes that have been previously announced. This behavior limits the ability of operators to share information about prefix unreachability for prefixes that were never announced or to correlate unreachability reports from multiple PE (Provider Edge) routers. Use cases for EVPN unreachability signaling include but not limited to:

• Multi-tenant network debugging and troubleshooting
• Security event coordination across EVPN instances
• DDoS attack target information sharing without null-routing
• Monitoring tenant prefix health across multiple data centers
• Correlating unreachability from multiple PE vantage points

The goal of this mechanism is to provide comprehensive information about unreachability events:

• Where the event has happened: Reporter Identifier, Reporter AS Number, and optionally EVPN Instance (EVI)
• Why the event has happened: Reason Code indicating the cause of unreachability
• When the event has happened: Timestamp of the unreachability detection

This document defines a new EVPN Route Type that creates a parallel information channel for unreachability data, maintaining complete separation from the forwarding plane. The encoding follows the architecture and terminology of , applying similar concepts to EVPN as defined for standard BGP in .

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

Terminology

EVPN:

Ethernet VPN

NVE:

Network Virtualization Edge, as defined in and . An NVE is a network entity that provides virtualization functions. In this document, NVE and PE are used interchangeably.

PE:

Provider Edge router

RT-5:

EVPN Route Type 5 (IP Prefix Advertisement Route), as defined in

Address Family (unreachability NLRI):

1-octet field in the IP Prefix Unreachability Route NLRI, immediately after the Ethernet Tag ID, indicating IPv4 (value 1) or IPv6 (value 2). The values are the existing BGP Address Family Identifier (AFI) numeric values assigned by IANA in the "Address Family Numbers" registry ; this document defines no new values and creates no new registry. See .

UI-RIB:

Unreachability Information RIB

NLRI:

Network Layer Reachability Information

TLV:

Type-Length-Value

Reporter TLV:

A nested TLV structure containing information about one Reporting PE and its associated unreachability details

Aggregation:

The process of combining multiple Reporter TLVs from different paths into a single NLRI

Advertising PE:

The PE router that sends the BGP UPDATE message containing the unreachability information

Reporting PE:

The PE router that originally generated the unreachability information (identified within a Reporter TLV)

This document also assumes familiarity with the terminology of , , , and .

EVPN Unreachability Route Type

Route Type Definition This document defines a new EVPN Route Type:

• Route Type: TBD1 (to be assigned by IANA)
• Name: IP Prefix Unreachability Route Type
• Based on: Route Type 5 field order and definitions from , plus an Address Family octet after the Ethernet Tag ID (not present in reachability RT-5)

This route type is carried in BGP UPDATE messages using the Multiprotocol Extensions for BGP-4 , with AFI = 25 (L2VPN) and SAFI = 70 (EVPN), following the same procedures as other EVPN route types defined in and . This route type creates a parallel information plane for unreachability signaling. It MUST NOT affect the EVPN Loc-RIB or forwarding plane in any way. PE routers receiving this route type MUST maintain it in a separate Unreachability Information RIB (UI-RIB) and MUST NOT install or remove routes in the Loc-RIB or forwarding table based on these advertisements.

Route Distinguisher and Route Targets The Route Distinguisher (RD) field and Route Target (RT) extended communities operate as defined in and . Unreachability routes for an EVPN instance SHOULD use the same RD and RTs as the corresponding reachability routes (Route Type 5), ensuring correlation with the same EVPN instance and following established EVPN patterns. Implementations MAY use distinct RTs for unreachability routes to limit distribution to specific PEs (e.g., monitoring systems) or to prevent distribution to legacy systems during incremental deployment.

NLRI Encoding

Design Philosophy The IP Prefix Unreachability Route encoding uses the Route Type 5 field order and definitions from to maximize consistency with existing EVPN implementations. Implementations can reuse much of existing RT-5 parsing logic but MUST insert handling for the Address Family octet (immediately after the Ethernet Tag ID) before reading the IP Prefix field, because reachability RT-5 has no such field. This approach provides:

• Structural consistency with Route Type 5 (with the Address Family extension noted above)
• Simplified implementation by following familiar RT-5 field order and semantics aside from that extension
• Extensibility via TLV-based reporter information
• Future-proof design if any currently unused fields become relevant

Approach to Multiple Reporters When multiple PE routers report unreachability for the same prefix, implementers have several options:

1. Single Reporter: Do nothing and allow the Reporter Identifier of the best route to be used as the only Reporter. This is the simplest approach but loses information from other reporters. This approach is fully compatible with all EVPN implementations.
2. Nested TLV Aggregation (Recommended): Implement the nested TLV aggregation approach described in this specification to preserve all reporter perspectives in a single NLRI. This provides the most comprehensive view while maintaining a single EVPN route per prefix. This approach is designed specifically for EVPN and does not require additional protocol extensions beyond this specification.
3. BGP ADD-PATH: Use BGP ADD-PATH to maintain multiple paths, each carrying its own Reporter TLV. ADD-PATH is defined for BGP-4 and can be applied to EVPN route types by prepending a Path Identifier to each NLRI. However, ADD-PATH support for EVPN varies by implementation, and this approach would require both ADD-PATH capability negotiation and proper handling of Path Identifiers with EVPN Route Type structures. This option preserves full BGP path attributes per reporter but has higher complexity and deployment requirements.

This specification focuses on the nested TLV aggregation approach (option 2) as the preferred mechanism, providing detailed procedures and encodings for this method throughout the remainder of this document. Option 2 is recommended because it provides comprehensive multi-reporter visibility while maintaining compatibility with standard EVPN processing and minimizing implementation complexity.

IP Prefix Unreachability Route NLRI The IP Prefix Unreachability Route uses the Route Type 5 field order and definitions from , extended with Reporter TLVs and one additional field for address-family disambiguation (see below). The NLRI is uniquely identified by the combination of Route Distinguisher, Ethernet Tag ID, Address Family, IP Prefix Length, and IP Prefix. Reporter TLVs are NOT part of the NLRI key but provide information about each Reporting PE. The presence of an Unreachability Route for a prefix signifies that one or more PEs report the prefix as unreachable. The withdrawal of such a route indicates that all reporters have cleared their unreachability reports for that prefix. For reachability RT-5 routes, fixes the size of the route-type-specific NLRI (34 octets for IPv4 or 58 octets for IPv6), which allows a receiver to infer whether the IP Prefix field is 4 or 16 octets. Because unreachability routes append a variable number of Reporter TLVs, the route-type-specific length is no longer sufficient to infer the address family: for example, an IPv4 prefix with a large set of Reporter TLVs can yield the same total size as a shorter IPv6 encoding. Furthermore, IP Prefix Length alone is ambiguous (e.g., a /24 can be valid for both IPv4 and IPv6). Therefore, this route type includes an explicit Address Family field immediately after the Ethernet Tag ID. Receivers MUST use this field to determine the width of the IP Prefix field before parsing Reporter TLVs. Where:

• Route Type: TBD1 (IP Prefix Unreachability Route Type)
• Length: As defined in , the number of octets in the Route Type specific field (from Route Distinguisher through the end of the last Reporter TLV). This differs from reachability RT-5 in , where Length is 34 (IPv4) or 58 (IPv6) and does not include Reporter TLVs.
• Route Distinguisher: As defined in and , used to identify the EVPN instance. The RD MUST be used as specified in those documents.
• Ethernet Segment Identifier: As defined in . MUST be set to 0 (all bytes zero) for unreachability routes.
• Ethernet Tag ID: As defined in and , identifies the broadcast domain. For unreachability routes, this SHOULD be set to 0 unless VLAN-aware bundle service is used, following the same conventions as reachability RT-5 routes.
• Address Family: 1 octet. The values are the existing BGP Address Family Identifier (AFI) numeric values assigned by IANA in the "Address Family Numbers" registry ; this document defines no new values and creates no new registry. Value 1 (IPv4, BGP AFI 1) requires an IP Prefix field of 4 octets and IP Prefix Length in the range 0-32 inclusive. Value 2 (IPv6, BGP AFI 2) requires an IP Prefix field of 16 octets and IP Prefix Length in the range 0-128 inclusive. Handling of any other Address Family value is specified in Section 4.10.1.
• IP Prefix Length: Length of the IP prefix in bits. Constraints depend on Address Family as described above.
• IP Prefix: IPv4 (4 octets) or IPv6 (16 octets) prefix being reported as unreachable, consistent with Address Family.
• GW IP Address Length: MUST be set to 0. The GW IP Address field is not used for unreachability routes.
• GW IP Address: MUST be zero octets (GW IP Address Length = 0). Unreachability routes do not use overlay index resolution.
• MPLS Label: 3-octet field where the high-order 20 bits contain the MPLS label value, as specified in . MUST be set to 0 (reserved). Since unreachability routes are information-only and do not establish forwarding state, and do not use overlay index resolution, the label field has no semantic meaning and MUST be zero.
• Reporter TLVs: One or more Reporter TLVs as defined in

Field Usage for Information-Only Routes Since unreachability routes are information-only and do not use overlay indexes for recursive resolution, the following constraints apply to fields inherited from Route Type 5:

• ESI: MUST be 0 (all bytes zero).
• GW IP Address Length: MUST be 0; GW IP Address: zero octets.
• MPLS Label: MUST be 0.
• Address Family: Used only to determine IP Prefix width for NLRI parsing.

Receiving PEs MUST NOT use any of these fields for forwarding decisions or recursive resolution. ESI, GW IP Address, and MPLS Label are maintained for structural consistency with ; Address Family is an extension defined in this document. The Section 3.1 rule that a route with a zero MPLS Label and no Overlay Index MUST be treated as withdrawn, and the Section 3.2 rule that a route with ESI, GW IP, Router's MAC, and MPLS Label all zero SHOULD be treated as withdrawn, apply only to Route Type 5. The IP Prefix Unreachability Route Type defined here uses a distinct EVPN Route Type (Section 3.3) and is not subject to those rules. Unreachability Routes carry ESI=0 and encode no Ethernet-Segment membership. They signal IP-prefix unreachability from the Reporting PE's local perspective. DF election, Ethernet-Segment failure, and non-DF transitions do not in themselves trigger Unreachability Routes; the multi-homing procedures of and are unchanged.

Reporter TLV Format The Reporter TLV encapsulates information about a single Reporting PE router. Multiple Reporter TLVs may be included in a single NLRI to support aggregation of reports from different network vantage points. Reporter TLV Fields:

Type:

1 octet. Value: 1 (Reporter)

Length:

2 octets. Total length of Reporter Identifier, Reporter AS Number, and Sub-TLVs fields in octets (minimum 8 octets when no Sub-TLVs are present)

Reporter Identifier:

4 octets. BGP Identifier (Router ID) of the Reporting PE in network byte order

Reporter AS Number:

4 octets. 4-octet AS number of the Reporting PE in network byte order. If the AS number is less than 65536, the upper 2 octets are set to 0.

Sub-TLVs:

Variable length. Contains zero or more Sub-TLVs providing additional context about the unreachability event. A Reporter TLV carrying no Sub-TLVs is valid: the presence of the Reporter TLV itself conveys the fact of unreachability, with the Reporter Identifier and Reporter AS Number identifying the PE that observed it. When the Unreachability Reason Code Sub-TLV () is absent, the reason is treated as Unspecified (code 0).

The combination of Reporter Identifier and Reporter AS Number uniquely identifies the Reporting PE. Multiple Reporter TLVs with the same Reporter Identifier and AS Number MUST NOT appear in the same NLRI. If such duplication occurs, only the first occurrence SHOULD be processed. Except that the first Reporter TLV in an NLRI corresponds to the best path (see ), the order of subsequent Reporter TLVs is not significant; receivers MUST NOT derive meaning from their relative ordering. Implementations MUST tolerate any ordering of Reporter TLVs past the first position.

Sub-TLV Types

Unreachability Reason Code Sub-TLV

• Sub-Type: 1
• Sub-Length: 2 octets
• Sub-Value: 2-octet reason code in network byte order

Defined Reason Codes:

• 0: Unspecified
• 1: Policy Blocked
• 2: Security Filtered
• 3: RPKI Invalid
• 4: No Export Policy
• 5: Martian Address
• 6: Bogon Prefix
• 7: Route Dampening
• 8: Local Administrative Action
• 9: Local Link Down
• 10: MAC Mobility Limit Exceeded (EVPN-specific)
• 11: Tenant Isolation Violation (EVPN-specific)
• 12: VTEP Unreachable (EVPN-specific)
• 13-64535: Reserved for Future Use (IANA allocation required)
• 64536-65535: Reserved for Private/Experimental Use

Reason codes 0-9 align with the BGP Unreachability Information SAFI for consistency across standard BGP and EVPN unreachability signaling. Reason codes 10-12 are EVPN-specific extensions.

Timestamp Sub-TLV

• Sub-Type: 2
• Sub-Length: 8 octets
• Sub-Value: Unix timestamp (seconds since epoch) in network byte order, indicates when the unreachability event occurred or was detected by this reporter

EVI Sub-TLV

• Sub-Type: 3
• Sub-Length: 4 octets
• Sub-Value: EVPN Instance (EVI) identifier where the unreachability was observed

Since the Route Distinguisher in the NLRI already identifies the EVPN instance in most deployments, this Sub-TLV SHOULD only be included when additional EVI-specific information is necessary that cannot be derived from the RD. Examples of when EVI Sub-TLV may be useful:

• Multiple EVIs share the same RD (non-recommended configuration)
• Correlation with locally-significant EVI identifiers
• Debugging scenarios requiring explicit EVI identification

Omitting this Sub-TLV when not needed saves 7 octets (3 octets TLV overhead + 4 octets EVI value) per Reporter TLV.

Sub-TLV Processing Rules Implementations MUST be prepared to receive Sub-TLVs in any order. Unknown Sub-TLV types MUST be silently ignored to allow for future extensibility. The Reason Code Sub-TLV SHOULD be included in all Reporter TLVs. If absent, implementations SHOULD treat it as Reason Code 0 (Unspecified).

Operation

Forwarding Plane Separation This route type creates a parallel information plane that operates independently of the EVPN forwarding plane. Implementations MUST maintain strict separation between unreachability information and forwarding decisions. Specifically, implementations MUST:

• NOT install or remove any routes in the Loc-RIB or forwarding table based on unreachability information
• Maintain unreachability routes in a separate Unreachability Information RIB (UI-RIB) that is not consulted for forwarding decisions
• NOT modify forwarding table entries (including next-hop, label, or other attributes) based on unreachability information
• Process unreachability routes with lower priority than forwarding routes to prevent resource contention
• Implement separate rate limiting for unreachability routes

Violation of these separation requirements could lead to incorrect forwarding behavior, traffic blackholing, or routing instability. Implementers MUST ensure proper separation through careful software architecture and testing.

Generating Unreachability Routes A PE MAY generate an IP Prefix Unreachability Route when local processing determines, for any reason, that a prefix is to be reported as unreachable. The triggering condition is conveyed by the Reason Code Sub-TLV (). This document does not mandate the set of local conditions that cause generation; that set is implementation- and deployment-specific, constrained only by the Reason Codes defined in this document or subsequently registered. The Reporting PE MUST set Address Family to 1 (IPv4) or 2 (IPv6) consistent with the IP Prefix field. The Reporting PE MUST populate the Reporter TLV with its own BGP Identifier and AS Number. The PE SHOULD include a Reason Code Sub-TLV and SHOULD include a Timestamp Sub-TLV to facilitate temporal correlation. Implementations SHOULD provide configuration options to control:

• Which events trigger unreachability route generation
• Rate limiting on route generation per prefix and globally
• Filtering criteria for which prefixes can be reported
• Default Reason Codes for different trigger conditions

Processing Unreachability Routes When a PE router receives an IP Prefix Unreachability Route:

1. It MUST validate that the route type is recognized
2. It MUST parse the NLRI using the Address Family field to determine whether the IP Prefix is 4 or 16 octets, then parse Reporter TLVs according to . Error handling for invalid Address Family or IP Prefix Length values is specified in Section 4.10.1.
3. It MUST NOT install or remove any routes in the Loc-RIB or forwarding table based on this route
4. It MUST maintain a separate UI-RIB for unreachability routes
5. It SHOULD apply standard BGP path selection to UI-RIB entries for consistency
6. It MAY propagate the route according to standard EVPN rules and local policy
7. It MAY aggregate Reporter TLVs as described in
8. It SHOULD make unreachability information available to management systems and monitoring tools

Unknown Sub-TLV types within Reporter TLVs MUST be silently ignored to allow for future extensibility.

Aggregation Procedures When multiple routes arrive for the same prefix (identified by RD, Ethernet Tag ID, Address Family, IP Prefix Length, and IP Prefix), a PE supporting aggregation SHOULD combine Reporter TLVs from multiple paths into a single advertisement. Aggregation procedure:

1. Perform standard BGP path selection based on BGP attributes (NOT Reporter TLV content) to select the best path
2. Extract Reporter TLVs from the best path
3. For each non-selected feasible path, extract Reporter TLVs and add unique reporters (by Reporter Identifier and Reporter AS) to the aggregated set. If a reporter already exists, keep the entry with the most recent timestamp (if present).
4. Create a new NLRI with all unique Reporter TLVs
5. Advertise the aggregated NLRI using BGP attributes from the best path

A speaker performing Reporter TLV aggregation MUST place the Reporter TLV corresponding to the best path in the first position of the resulting NLRI. Reporter TLVs drawn from non-selected feasible paths MAY follow in any order. Pinning the first position provides a deterministic fallback for speakers that do not perform aggregation (see below). A receiver MUST parse all Reporter TLVs present in a received NLRI, up to the implementation limit defined in this section (RECOMMENDED 50). How the received Reporter TLVs are consumed locally -- stored in the UI-RIB, exported via BMP, displayed to operators -- is an implementation matter and does not affect wire behavior. A speaker that does not perform Reporter TLV aggregation, when re-advertising an IP Prefix Unreachability Route to its peers, MUST include only the first Reporter TLV from the received NLRI and MUST NOT append Reporter TLVs drawn from other paths. Because EVPN does not negotiate per-Route-Type capabilities, this rule -- together with the sender ordering rule above -- constitutes the interoperability contract between aggregating and non-aggregating speakers: at the first non-aggregating hop, the propagated view degrades to the best-path Reporter TLV only, with no loss of correctness. The maximum number of Reporter TLVs per route SHOULD be limited to prevent excessive route sizes. RECOMMENDED maximum: 50 Reporter TLVs per route. If the maximum is reached and a new reporter must be added, implementations SHOULD remove the oldest Reporter TLV based on Timestamp Sub-TLV (if present). The reporter from the best path MUST NOT be removed; if it is the oldest, remove the second-oldest instead.

Withdrawal Procedures Withdrawal of unreachability information operates at two levels:

Individual Reporter Withdrawal When a PE determines that a specific reporter no longer considers a prefix unreachable (e.g., receives an UPDATE from that reporter's PE that does not include the unreachability NLRI, or local policy determines the report is stale), it SHOULD:

1. Remove the corresponding Reporter TLV from the NLRI
2. If other Reporter TLVs remain, re-advertise the NLRI with the remaining Reporter TLVs
3. If no Reporter TLVs remain, withdraw the entire NLRI as described below

To facilitate individual reporter withdrawal, implementations MUST track the source of each Reporter TLV (which BGP neighbor or local process it came from).

Complete NLRI Withdrawal A PE MUST withdraw an Unreachability Route (send the NLRI key fields in MP_UNREACH_NLRI) when:

• All Reporter TLVs have been removed
• The prefix is explicitly withdrawn by all upstream sources
• Local policy dictates the information should no longer be propagated

The MP_UNREACH_NLRI contains the NLRI fields (Route Distinguisher, Ethernet Segment Identifier, Ethernet Tag ID, Address Family, IP Prefix Length, IP Prefix, GW IP Address Length, and MPLS Label) without any Reporter TLVs.

Stale Reporter Detection Implementations MAY implement aging mechanisms to remove stale Reporter TLVs:

• If a Timestamp Sub-TLV is present and indicates the report is older than a configurable threshold (RECOMMENDED default: 24 hours), the Reporter TLV MAY be removed
• If the BGP session to the neighbor that provided a Reporter TLV goes down, implementations MAY mark associated Reporter TLVs as potentially stale and MAY remove them after a grace period

Interaction with Graceful Restart BGP Graceful Restart applies to the EVPN SAFI (AFI=25, SAFI=70) and thus to Unreachability Routes. GR procedures for other EVPN route types (, ) are unchanged. Unreachability Routes follow the same GR procedures as RT-5 : one GR Capability for SAFI=70, one End-of-RIB (EoR) marker, one Restart Time. They are marked stale, retained, refreshed, and removed identically. The sole departure is the "Forwarding State" (F) bit. Unreachability Routes install no forwarding state (); the F bit has no meaning for this Route Type. Its interpretation for forwarding-state-bearing route types is unchanged.

Graceful Restart Capability No new capability is defined. GR is negotiated using the EVPN AFI/SAFI (25/70). Implementations MUST NOT treat any F bit value as indicating forwarding-state preservation for Unreachability Routes. The F bit advertised for SAFI=70 is determined by the preservation properties of the other route types carried in the SAFI.

Restarting Speaker Behavior A PE that has negotiated GR for SAFI=70:

1. SHOULD re-advertise its preserved Unreachability Information RIB (UI-RIB) as soon as practicable; gradual re-advertisement is permitted to limit burstiness.
2. If the UI-RIB was not preserved, SHOULD rebuild it from local sources (link-down state, policy decisions) before re-advertising.
3. MUST send the SAFI=70 EoR marker after re-advertisement completes. This marker covers all EVPN route types in the SAFI; no Route-Type-specific EoR is defined.

Receiving Speaker Behavior On detection of peer restart:

1. All Unreachability Routes from the restarting peer MUST be marked stale, irrespective of the F bit.
2. Stale routes MUST NOT be withdrawn. They MUST be retained until the SAFI=70 EoR is received or the peer's Restart Time expires, whichever occurs first.
3. While stale, the routes MAY be used for monitoring and correlation, MAY be distinguished in display and APIs, and SHOULD NOT be propagated to other peers absent explicit configuration.
4. On receipt of the EoR:
   • unrefreshed stale routes MUST be removed;
   • Reporter TLVs from the restarted peer within aggregated NLRIs MUST be removed if not refreshed;
   • if Reporter TLVs from other sources remain for the same NLRI key, the route SHOULD be re-advertised with those remaining TLVs ().
5. If the Restart Time expires before the EoR arrives, all stale routes MUST be removed.

Route Reflector Considerations A Route Reflector participating in GR for SAFI=70:

• MUST stale-mark Unreachability Routes from restarting clients identically to other EVPN route types;
• SHOULD NOT reflect stale Unreachability Routes absent an explicit reflection policy;
• MUST preserve ORIGINATOR_ID and CLUSTER_LIST across stale-to-refreshed transitions;
• SHOULD send the SAFI=70 EoR to clients after completing its own restart processing.

Implementation Recommendations Restart Time is shared with the rest of SAFI=70. Operators SHOULD account for the additional UI-RIB re-advertisement volume when tuning it. Implementations SHOULD expose:

• UI-RIB preservation, toggled independently of other EVPN route types;
• propagation of stale Unreachability Routes during GR;
• action on EoR timeout.

Implementations SHOULD log, per GR cycle: peer-restart detection affecting the UI-RIB, stale marking, EoR receipt, and stale removal.

Preventing State Explosion To prevent unbounded growth of the UI-RIB, implementations SHOULD enforce the following limits:

• Maximum Reporter TLVs per route (RECOMMENDED: 50)
• Maximum total UI-RIB routes (SHOULD be configurable; RECOMMENDED default: 100,000)
• Rate limiting on accepting new unreachability routes
• Per-peer rate limiting

When limits are reached, implementations SHOULD log the event, apply aging policies to remove oldest entries, and continue accepting withdrawals to allow state to decrease.

Relationship to BGP Route Damping Unreachability routes SHOULD NOT be subject to standard BGP route damping mechanisms since they do not affect forwarding and represent information that operators explicitly want to propagate. However, implementations MAY implement rate limiting specific to unreachability routes to prevent:

• UI-RIB resource exhaustion
• Excessive BGP UPDATE message generation
• Processing overhead on Receiving PEs
• Malicious or misconfigured PEs flooding the network

Rate limiting should be applied at:

• Route generation (at Reporting PE)
• Route acceptance (at Receiving PE)
• Per-peer basis
• Global aggregate level

Path Selection for Aggregation Path selection for Unreachability Routes follows standard BGP best path selection ( Section 15, incorporating ) with the following clarifications:

• Weight/Local Preference: Apply normally based on local policy.
• AS_PATH Length: Shorter AS_PATH is preferred. This represents the path the UPDATE message took.
• ORIGIN: IGP preferred over EGP over INCOMPLETE.
• MED: Apply if comparing paths from the same neighboring AS.
• BGP Identifier: Use for tie-breaking.

The content of Reporter TLVs (number of reporters, reason codes, timestamps, etc.) MUST NOT influence path selection. Path selection determines which UPDATE's BGP attributes are used for propagation, while aggregation combines Reporter TLVs from multiple paths.

Communities and Attributes Standard BGP communities and attributes apply to the UPDATE message carrying Unreachability Routes:

• NO_EXPORT, NO_ADVERTISE, and NO_EXPORT_SUBCONFED work as defined in their respective specifications
• Large Communities MAY be used for policy control of aggregation behavior
• AS_PATH is constructed normally for the UPDATE message path
• ORIGIN SHOULD be set to INCOMPLETE for locally generated unreachability information, reflecting that the information does not originate from routing protocol state
• The Router's MAC Extended Community has no effect on Unreachability Routes; overlay index semantics do not apply (Section 3.4). Senders SHOULD NOT attach it; receivers MUST ignore it if present.

These attributes represent the path taken by the UPDATE message itself, not the paths of individual reporters (which are preserved in Reporter TLVs).

Error Handling Error handling for IP Prefix Unreachability Routes follows and Section 7.14.1. Per-class actions are specified in Sections 4.10.1 through 4.10.4. Per Section 7.14, "session reset" MAY be replaced with "AFI/SAFI disable" behavior where supported. Checks in Section 4.10.1 are performed before those in Section 4.10.2; on first error the corresponding action MUST be taken and further NLRI parsing MUST cease. All error conditions MUST be logged.

NLRI Structural Errors A receiver MUST apply "session reset" per Section 7.14.1 on:

• Length below the minimum for this route type.
• Length inconsistent with the enclosing MP_REACH_NLRI or MP_UNREACH_NLRI attribute.
• Address Family other than 1 or 2: the IP Prefix field boundary cannot be determined, and subsequent Key fields cannot be parsed.
• IP Prefix Length outside the range permitted for the indicated Address Family: the prefix cannot be unambiguously constructed and is not suitable as a lookup key.

Non-Key Field Errors A receiver MUST apply "treat-as-withdraw" per Section 7.14.1 on:

• Non-zero Ethernet Segment Identifier, GW IP Address Length, GW IP Address, or MPLS Label (Section 3.4 requires each to be zero).
• No Reporter TLVs present (Section 3.3 requires one or more).

Reporter TLV Errors Per Section 5.1, unknown or malformed Reporter TLVs MUST NOT cause the NLRI to be considered malformed.

• Unrecognized TLV Type: the TLV is ignored; parsing resumes at the next TLV boundary.
• Malformed TLV (Length inconsistent with remaining NLRI data or below the 8-octet minimum): the TLV MUST be discarded. If well-formed Reporter TLVs remain, they are processed; otherwise "treat-as-withdraw" MUST be applied.
• Duplicate Reporter TLVs (same Identifier and AS Number): only the first is processed (Section 3.5).
• Reporter TLV count exceeding the implementation limit (Section 4.6): excess TLVs MUST be discarded.

Sub-TLV Errors An unrecognized Sub-TLV Type within a Reporter TLV is silently ignored (Section 3.6.4). A Sub-TLV whose Length is inconsistent with available data MUST be discarded; processing of the enclosing Reporter TLV and remaining Sub-TLVs continues.

Interoperability Considerations

Incremental Deployment The IP Prefix Unreachability Route Type can be deployed incrementally without requiring network-wide upgrades:

• PEs that don't support this route type will ignore it per standard BGP behavior (unknown route type handling)
• Mixed environments with supporting and non-supporting PEs work correctly
• The feature can be enabled on specific EVPN instances for testing before broader deployment
• Aggregation support is OPTIONAL; PEs that do not implement aggregation can still propagate single-reporter routes
• Distinct Route Targets allow control over which PEs receive unreachability information

Interaction with Route Reflectors Route Reflectors process Unreachability Routes like any other EVPN route type:

• Apply standard route reflection rules
• ORIGINATOR_ID and CLUSTER_LIST attributes apply normally to the UPDATE message, not to individual reporters
• Route Reflectors SHOULD support aggregation to combine reports from multiple clients
• When reflecting to clients, include all aggregated Reporter TLVs

The distinction between the ORIGINATOR_ID BGP attribute and the Reporter Identifier field in Reporter TLVs is important:

• ORIGINATOR_ID identifies the originator of the BGP UPDATE message for loop prevention
• Reporter Identifier identifies the PE that observed and reported the unreachability condition
• These MAY be different in aggregated scenarios

Route Reflectors that do not support aggregation will still properly reflect unreachability routes using standard route reflection procedures. In this case, only the best path's Reporter TLV(s) will be visible to clients. Operators deploying this feature SHOULD enable aggregation on Route Reflectors to maximize the utility of multi-vantage-point reporting.

Interaction with Other EVPN Route Types IP Prefix Unreachability Routes are completely independent from other EVPN route types. Specifically:

• A Route Type 5 (IP Prefix Advertisement) and an IP Prefix Unreachability Route for the same logical prefix (same Route Distinguisher, Ethernet Tag ID, IP Prefix Length, and IP Prefix value, with the unreachability Address Family value matching the IPv4 or IPv6 encoding of that RT-5 per ) are independent and may coexist
• Presence of an unreachability route does NOT imply absence of a reachability route
• Withdrawal of a reachability route does NOT automatically generate an unreachability route
• BGP path selection is performed independently for each route type

This independence is crucial for maintaining forwarding plane separation and allowing unreachability signaling for prefixes that were never advertised as reachable.

Deployment Considerations

Use Cases

Multi-Tenant Data Centers:

Share unreachability information across tenant networks for coordinated security response without affecting tenant traffic forwarding

DCI (Data Center Interconnect):

Correlate unreachability reports from multiple data centers to distinguish between local issues and global prefix problems

Security Monitoring:

Track suspicious prefix patterns across EVPN instances, coordinate DDoS response, and share threat intelligence

Troubleshooting:

Debug prefix reachability issues without impacting production forwarding, identify asymmetric reachability, and correlate with overlay network health

Compliance and Auditing:

Maintain records of unreachability events for compliance purposes and SLA verification

Policy-Driven Actions:

Trigger an action, as defined by a local policy, in response to received unreachability information (e.g., traffic engineering adjustments, alerting, or logging)

Operational Recommendations

• Enable aggregation on Route Reflectors to maximize visibility while minimizing route count
• Include Timestamp Sub-TLVs for temporal correlation
• Monitor UI-RIB size for capacity planning
• Test the feature on non-production EVPN instances before production deployment

Implementations SHOULD provide management interfaces to query the UI-RIB, display reporters per prefix, and export unreachability data to external monitoring systems.

Security Considerations This route type SHOULD only be enabled between trusted BGP peers. The trust model is similar to that required for standard EVPN route types. The following threats are specific to unreachability signaling:

1. Information Leakage: Unreachability information may reveal network topology or operational issues. Operators SHOULD use Route Target filtering to restrict distribution.
2. State Exhaustion: Malicious peers could exhaust UI-RIB memory. Implementations SHOULD enforce the limits described in and the Preventing State Explosion section.
3. False Information: Peers could advertise false unreachability data. Since this SAFI does not affect forwarding, the impact is limited to monitoring systems.
4. Reporter Impersonation: A peer could include Reporter TLVs claiming to represent other PEs. Implementations SHOULD validate that Reporter AS Numbers are consistent with the AS_PATH of the UPDATE that introduced them.
5. Aggregation Amplification: A peer could send many UPDATEs with different Reporter TLVs for the same prefix. Reporter TLV limits and rate limiting mitigate this.
6. Tenant Isolation: Improper RT configuration could leak unreachability information between tenants. Use separate RDs and tenant-specific RTs.

Operators SHOULD use BGP session security (TCP-AO per ), validate Reporter Identifiers against known PE lists, configure per-peer rate limits, and maintain audit logs of unreachability route updates.

IANA Considerations

EVPN Route Type IANA is requested to assign a new EVPN Route Type value from the "EVPN Route Types" registry within the "Border Gateway Protocol (BGP) Parameters" registry group:

• Value: TBD1
• Description: IP Prefix Unreachability Route Type
• Reference: This document

EVPN Unreachability Reporter TLV Types IANA is requested to create a new registry called "EVPN Unreachability Reporter TLV Types" under the "Border Gateway Protocol (BGP) Parameters" registry page. Registration Procedure: Standards Action Initial registrations:

EVPN Unreachability Sub-TLV Types IANA is requested to create a new registry called "EVPN Unreachability Sub-TLV Types" under the "Border Gateway Protocol (BGP) Parameters" registry page. Registration Procedure: RFC Required Initial registrations:

EVPN Unreachability Reason Codes IANA is requested to create a new registry called "EVPN Unreachability Reason Codes" under the "Border Gateway Protocol (BGP) Parameters" registry page. Registration Procedure: RFC Required for values 0-64535, Reserved for Private Use for values 64536-65535 Initial registrations:

Acknowledgements The authors would like to thank the BESS working group for their valuable feedback and suggestions on this proposal. Special thanks to the EVPN protocol designers whose work on RFC 7432, RFC 9136, and related specifications provided the foundation for this extension. The aggregation mechanism in this specification draws inspiration from similar multi-reporter approaches in other monitoring and troubleshooting protocols.

References Normative References Informative References

Appendix A: Encoding Examples

Example 1: Minimal Unreachability Route IPv4 tenant prefix 192.0.2.0/24 reported unreachable by a single leaf PE because egress export policy suppresses the prefix (Reason Code 4, "No Export Policy"): See Example 3 for the equivalent IPv6 encoding.

Example 2: Aggregated Route with Multiple Reporters IPv4 tenant prefix 198.51.100.0/24 reported by three leaf PEs in the same DC fabric following a coordinated administrative action (Reason Code 8, "Local Administrative Action"). Timestamps are spaced by a few seconds, consistent with propagation of the administrative event across the fabric:

Example 3: IPv6 Unreachability Route IPv6 tenant prefix 2001:db8::/32 reported unreachable by a leaf PE following a local CE-facing link-down event (Reason Code 9, "Local Link Down"):

Example 4: Complete BGP UPDATE Message A PE (198.51.100.1, AS 65001) advertises that 192.0.2.0/24 is unreachable, with Reason RPKI Invalid and a detection timestamp:

Example 5: Aggregation at a Receiving PE Router R1 receives two UPDATEs for the same Unreachability NLRI key (RD 198.51.100.1:100, Ethernet Tag 0, IPv4, 192.0.2.0/24) from different upstream neighbors. R1 selects a best path by standard BGP procedure, extracts Reporter TLVs from the best path plus feasible paths, de-duplicates by (Reporter Identifier, Reporter AS), and re-advertises a single aggregated NLRI.

Example 6: Withdrawal Procedures Continuing from Example 5, Reporter 198.51.100.1 clears its report first (partial withdrawal), then Reporter 198.51.100.2 also clears (complete withdrawal).

Appendix B: Design Tradeoffs This appendix summarizes encoding choices and their rationale.

Explicit Address Family vs inferring IPv4/IPv6:

Reachability RT-5 uses a fixed route-type-specific size (34 or 58 octets), so receivers can infer prefix width. Unreachability NLRIs append variable-length Reporter TLVs, so total length no longer implies address family, and IP Prefix Length alone is ambiguous (e.g., /24 is valid for both). A 1-octet Address Family field resolves this.

One route type vs two (per address family):

Separate route type values would remove the Address Family octet but duplicate specifications and IANA registrations. This document uses one type with an explicit family indicator.

RT-5-shaped NLRI vs minimal custom encoding:

Reusing the RT-5 field order maximizes familiarity and parser reuse, at the cost of carrying unused fields (ESI, GW IP, MPLS Label) plus one new octet for Address Family. Reporter detail is concentrated in TLVs.

Route-type-specific Length limit:

The Length field is one octet (), so the route-type-specific portion cannot exceed 255 octets. Implementations MUST stay within that limit by bounding the number of Reporter TLVs per NLRI.