BESS Working Group J. Tantsura
Internet-Draft V. Venkatraman
Intended status: Standards Track K. Muppalla
Expires: 21 October 2026 P. Doijode
Nvidia
M. Rzehak
CoreWeave
19 April 2026
EVPN Unreachability Signaling
draft-tantsura-bess-evpn-unreachability-00
Abstract
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.
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 21 October 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.
Tantsura, et al. Expires 21 October 2026 [Page 1]
Internet-Draft EVPN Unreachability Signaling April 2026
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 . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
2. EVPN Unreachability Route Type . . . . . . . . . . . . . . . 5
2.1. Route Type Definition . . . . . . . . . . . . . . . . . . 5
2.2. Route Distinguisher and Route Targets . . . . . . . . . . 6
3. NLRI Encoding . . . . . . . . . . . . . . . . . . . . . . . . 6
3.1. Design Philosophy . . . . . . . . . . . . . . . . . . . . 6
3.2. Approach to Multiple Reporters . . . . . . . . . . . . . 6
3.3. IP Prefix Unreachability Route NLRI . . . . . . . . . . . 7
3.4. Field Usage for Information-Only Routes . . . . . . . . . 9
3.5. Reporter TLV Format . . . . . . . . . . . . . . . . . . . 10
3.6. Sub-TLV Types . . . . . . . . . . . . . . . . . . . . . . 11
3.6.1. Unreachability Reason Code Sub-TLV . . . . . . . . . 11
3.6.2. Timestamp Sub-TLV . . . . . . . . . . . . . . . . . . 12
3.6.3. EVI Sub-TLV . . . . . . . . . . . . . . . . . . . . . 12
3.6.4. Sub-TLV Processing Rules . . . . . . . . . . . . . . 13
4. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 13
4.1. Forwarding Plane Separation . . . . . . . . . . . . . . . 13
4.2. Generating Unreachability Routes . . . . . . . . . . . . 14
4.3. Processing Unreachability Routes . . . . . . . . . . . . 14
4.4. Aggregation Procedures . . . . . . . . . . . . . . . . . 15
4.5. Withdrawal Procedures . . . . . . . . . . . . . . . . . . 16
4.5.1. Individual Reporter Withdrawal . . . . . . . . . . . 16
4.5.2. Complete NLRI Withdrawal . . . . . . . . . . . . . . 17
4.5.3. Stale Reporter Detection . . . . . . . . . . . . . . 17
4.6. Interaction with Graceful Restart . . . . . . . . . . . . 17
4.6.1. Graceful Restart Capability . . . . . . . . . . . . . 18
4.6.2. Restarting Speaker Behavior . . . . . . . . . . . . . 18
4.6.3. Receiving Speaker Behavior . . . . . . . . . . . . . 18
4.6.4. Route Reflector Considerations . . . . . . . . . . . 19
4.6.5. Implementation Recommendations . . . . . . . . . . . 19
4.7. Preventing State Explosion . . . . . . . . . . . . . . . 19
4.8. Relationship to BGP Route Damping . . . . . . . . . . . . 20
4.9. Path Selection for Aggregation . . . . . . . . . . . . . 20
4.10. Communities and Attributes . . . . . . . . . . . . . . . 21
4.11. Error Handling . . . . . . . . . . . . . . . . . . . . . 21
4.11.1. NLRI Structural Errors . . . . . . . . . . . . . . . 22
4.11.2. Non-Key Field Errors . . . . . . . . . . . . . . . . 22
4.11.3. Reporter TLV Errors . . . . . . . . . . . . . . . . 22
Tantsura, et al. Expires 21 October 2026 [Page 2]
Internet-Draft EVPN Unreachability Signaling April 2026
4.11.4. Sub-TLV Errors . . . . . . . . . . . . . . . . . . . 23
5. Interoperability Considerations . . . . . . . . . . . . . . . 23
5.1. Incremental Deployment . . . . . . . . . . . . . . . . . 23
5.2. Interaction with Route Reflectors . . . . . . . . . . . . 23
5.3. Interaction with Other EVPN Route Types . . . . . . . . . 24
6. Deployment Considerations . . . . . . . . . . . . . . . . . . 24
6.1. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . 24
6.2. Operational Recommendations . . . . . . . . . . . . . . . 25
7. Security Considerations . . . . . . . . . . . . . . . . . . . 25
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26
8.1. EVPN Route Type . . . . . . . . . . . . . . . . . . . . . 26
8.2. EVPN Unreachability Reporter TLV Types . . . . . . . . . 26
8.3. EVPN Unreachability Sub-TLV Types . . . . . . . . . . . . 27
8.4. EVPN Unreachability Reason Codes . . . . . . . . . . . . 27
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 28
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 28
10.1. Normative References . . . . . . . . . . . . . . . . . . 28
10.2. Informative References . . . . . . . . . . . . . . . . . 29
Appendix A: Encoding Examples . . . . . . . . . . . . . . . . . . 30
Example 1: Minimal Unreachability Route . . . . . . . . . . . . 30
Example 2: Aggregated Route with Multiple Reporters . . . . . . 31
Example 3: IPv6 Unreachability Route . . . . . . . . . . . . . 32
Example 4: Complete BGP UPDATE Message . . . . . . . . . . . . 33
Example 5: Aggregation at a Receiving PE . . . . . . . . . . . 35
Example 6: Withdrawal Procedures . . . . . . . . . . . . . . . 36
Appendix B: Design Tradeoffs . . . . . . . . . . . . . . . . . . 37
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 38
1. Introduction
EVPN (Ethernet VPN) [RFC7432] 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) [RFC9136], 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
Tantsura, et al. Expires 21 October 2026 [Page 3]
Internet-Draft EVPN Unreachability Signaling April 2026
* 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 [RFC9136], applying similar concepts
to EVPN as defined for standard BGP in
[I-D.tantsura-idr-unreachability-safi].
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.
1.2. Terminology
EVPN: Ethernet VPN
NVE: Network Virtualization Edge, as defined in [RFC7365] and
[RFC9136]. 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 [RFC9136]
Tantsura, et al. Expires 21 October 2026 [Page 4]
Internet-Draft EVPN Unreachability Signaling April 2026
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 [RFC4760]; this document defines no new
values and creates no new registry. See Section 3.3.
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
[RFC7365], [RFC7432], [RFC8365], and [RFC9136].
2. EVPN Unreachability Route Type
2.1. 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 [RFC9136],
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 [RFC4760], with AFI = 25 (L2VPN)
and SAFI = 70 (EVPN), following the same procedures as other EVPN
route types defined in [RFC7432] and [RFC9136].
Tantsura, et al. Expires 21 October 2026 [Page 5]
Internet-Draft EVPN Unreachability Signaling April 2026
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.
2.2. Route Distinguisher and Route Targets
The Route Distinguisher (RD) field and Route Target (RT) extended
communities operate as defined in [RFC7432] and [RFC9136].
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.
3. NLRI Encoding
3.1. Design Philosophy
The IP Prefix Unreachability Route encoding uses the Route Type 5
field order and definitions from [RFC9136] 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
3.2. Approach to Multiple Reporters
When multiple PE routers report unreachability for the same prefix,
implementers have several options:
Tantsura, et al. Expires 21 October 2026 [Page 6]
Internet-Draft EVPN Unreachability Signaling April 2026
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 [RFC7911] 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.
3.3. IP Prefix Unreachability Route NLRI
The IP Prefix Unreachability Route uses the Route Type 5 field order
and definitions from [RFC9136], 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, [RFC9136] 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
Tantsura, et al. Expires 21 October 2026 [Page 7]
Internet-Draft EVPN Unreachability Signaling April 2026
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.
+---------------------------------------+
| Route Type (1 octet) |
+---------------------------------------+
| Length (1 octet) |
+---------------------------------------+
| Route Distinguisher (8 octets) |
+---------------------------------------+
| Ethernet Segment Identifier (10 octets)|
+---------------------------------------+
| Ethernet Tag ID (4 octets) |
+---------------------------------------+
| Address Family (1 octet) |
+---------------------------------------+
| IP Prefix Length (1 octet) |
+---------------------------------------+
| IP Prefix (4 or 16 octets) |
+---------------------------------------+
| GW IP Address Length (1 octet) = 0 |
+---------------------------------------+
| MPLS Label (3 octets) = 0 |
+---------------------------------------+
| Reporter TLVs (variable) |
+---------------------------------------+
Where:
* Route Type: TBD1 (IP Prefix Unreachability Route Type)
* Length: As defined in [RFC7432], 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
[RFC9136], where Length is 34 (IPv4) or 58 (IPv6) and does not
include Reporter TLVs.
* Route Distinguisher: As defined in [RFC7432] and [RFC9136], used
to identify the EVPN instance. The RD MUST be used as specified
in those documents.
Tantsura, et al. Expires 21 October 2026 [Page 8]
Internet-Draft EVPN Unreachability Signaling April 2026
* Ethernet Segment Identifier: As defined in [RFC7432]. MUST be set
to 0 (all bytes zero) for unreachability routes.
* Ethernet Tag ID: As defined in [RFC7432] and [RFC9136], 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 [RFC4760]; 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 [RFC9136]. 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 Section 3.5
3.4. 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.
Tantsura, et al. Expires 21 October 2026 [Page 9]
Internet-Draft EVPN Unreachability Signaling April 2026
* 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 [RFC9136];
Address Family is an extension defined in this document.
The [RFC9136] 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 [RFC7432] and [RFC9136] are
unchanged.
3.5. 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.
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 | Length | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| Reporter Identifier (4 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reporter AS Number (4 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-TLVs (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Reporter TLV Fields:
Type: 1 octet. Value: 1 (Reporter)
Length: 2 octets. Total length of Reporter Identifier, Reporter AS
Tantsura, et al. Expires 21 October 2026 [Page 10]
Internet-Draft EVPN Unreachability Signaling April 2026
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 (Section 3.6.1)
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 Section 4.4), 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.
3.6. Sub-TLV Types
3.6.1. 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
Tantsura, et al. Expires 21 October 2026 [Page 11]
Internet-Draft EVPN Unreachability Signaling April 2026
* 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
[I-D.tantsura-idr-unreachability-safi] for consistency across
standard BGP and EVPN unreachability signaling. Reason codes 10-12
are EVPN-specific extensions.
3.6.2. 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
3.6.3. EVI Sub-TLV
* Sub-Type: 3
* Sub-Length: 4 octets
* Sub-Value: EVPN Instance (EVI) identifier where the unreachability
was observed
Tantsura, et al. Expires 21 October 2026 [Page 12]
Internet-Draft EVPN Unreachability Signaling April 2026
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.
3.6.4. 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).
4. Operation
4.1. 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
Tantsura, et al. Expires 21 October 2026 [Page 13]
Internet-Draft EVPN Unreachability Signaling April 2026
* 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.
4.2. 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 (Section 3.6.1). 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
4.3. 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 Section 3. Error handling for invalid
Address Family or IP Prefix Length values is specified in
Section 4.10.1.
Tantsura, et al. Expires 21 October 2026 [Page 14]
Internet-Draft EVPN Unreachability Signaling April 2026
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 Section 4.4
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.
4.4. 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
Tantsura, et al. Expires 21 October 2026 [Page 15]
Internet-Draft EVPN Unreachability Signaling April 2026
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.
4.5. Withdrawal Procedures
Withdrawal of unreachability information operates at two levels:
4.5.1. 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
Tantsura, et al. Expires 21 October 2026 [Page 16]
Internet-Draft EVPN Unreachability Signaling April 2026
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).
4.5.2. 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.
4.5.3. 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
4.6. Interaction with Graceful Restart
BGP Graceful Restart [RFC4724] applies to the EVPN SAFI (AFI=25,
SAFI=70) and thus to Unreachability Routes. GR procedures for other
EVPN route types ([RFC7432], [RFC9136]) are unchanged.
Unreachability Routes follow the same GR procedures as RT-5
[RFC9136]: 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
Tantsura, et al. Expires 21 October 2026 [Page 17]
Internet-Draft EVPN Unreachability Signaling April 2026
forwarding state (Section 4.1); the F bit has no meaning for this
Route Type. Its interpretation for forwarding-state-bearing route
types is unchanged.
4.6.1. 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.
4.6.2. 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 [RFC4724] after re-advertisement
completes. This marker covers all EVPN route types in the SAFI;
no Route-Type-specific EoR is defined.
4.6.3. 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;
Tantsura, et al. Expires 21 October 2026 [Page 18]
Internet-Draft EVPN Unreachability Signaling April 2026
* 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 (Section 4.4).
5. If the Restart Time expires before the EoR arrives, all stale
routes MUST be removed.
4.6.4. 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.
4.6.5. 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.
4.7. Preventing State Explosion
To prevent unbounded growth of the UI-RIB, implementations SHOULD
enforce the following limits:
Tantsura, et al. Expires 21 October 2026 [Page 19]
Internet-Draft EVPN Unreachability Signaling April 2026
* 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.
4.8. 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
4.9. Path Selection for Aggregation
Path selection for Unreachability Routes follows standard BGP best
path selection ([RFC7432] Section 15, incorporating [RFC9136]) with
the following clarifications:
* Weight/Local Preference: Apply normally based on local policy.
Tantsura, et al. Expires 21 October 2026 [Page 20]
Internet-Draft EVPN Unreachability Signaling April 2026
* 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.
4.10. 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 [RFC8092] 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).
4.11. Error Handling
Error handling for IP Prefix Unreachability Routes follows [RFC7606]
and [I-D.ietf-bess-rfc7432bis] Section 7.14.1. Per-class actions are
specified in Sections 4.10.1 through 4.10.4. Per
[I-D.ietf-bess-rfc7432bis] 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
Tantsura, et al. Expires 21 October 2026 [Page 21]
Internet-Draft EVPN Unreachability Signaling April 2026
error the corresponding action MUST be taken and further NLRI parsing
MUST cease. All error conditions MUST be logged.
4.11.1. NLRI Structural Errors
A receiver MUST apply "session reset" per [I-D.ietf-bess-rfc7432bis]
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.
4.11.2. Non-Key Field Errors
A receiver MUST apply "treat-as-withdraw" per
[I-D.ietf-bess-rfc7432bis] 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).
4.11.3. Reporter TLV Errors
Per [RFC9552] 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.
Tantsura, et al. Expires 21 October 2026 [Page 22]
Internet-Draft EVPN Unreachability Signaling April 2026
4.11.4. 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.
5. Interoperability Considerations
5.1. 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
5.2. 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:
Tantsura, et al. Expires 21 October 2026 [Page 23]
Internet-Draft EVPN Unreachability Signaling April 2026
* 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.
5.3. 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 [RFC9136]) 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.
6. Deployment Considerations
6.1. Use Cases
Multi-Tenant Data Centers: Share unreachability information across
tenant networks for coordinated security response without
affecting tenant traffic forwarding
Tantsura, et al. Expires 21 October 2026 [Page 24]
Internet-Draft EVPN Unreachability Signaling April 2026
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)
6.2. 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.
7. 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.
Tantsura, et al. Expires 21 October 2026 [Page 25]
Internet-Draft EVPN Unreachability Signaling April 2026
2. State Exhaustion: Malicious peers could exhaust UI-RIB memory.
Implementations SHOULD enforce the limits described in
Section 4.4 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 [RFC5925]),
validate Reporter Identifiers against known PE lists, configure per-
peer rate limits, and maintain audit logs of unreachability route
updates.
8. IANA Considerations
8.1. 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
8.2. 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
Tantsura, et al. Expires 21 October 2026 [Page 26]
Internet-Draft EVPN Unreachability Signaling April 2026
Initial registrations:
Value Description Reference
----- ------------------------------------ -----------
0 Reserved This document
1 Reporter TLV This document
2-254 Unassigned
255 Reserved This document
8.3. 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:
Value Description Reference
----- ------------------------------------ -----------
0 Reserved This document
1 Unreachability Reason Code This document
2 Timestamp This document
3 EVI This document
4-254 Unassigned
255 Reserved This document
8.4. 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:
Tantsura, et al. Expires 21 October 2026 [Page 27]
Internet-Draft EVPN Unreachability Signaling April 2026
Value Description Reference
----- ------------------------------------ -----------
0 Unspecified This document
1 Policy Blocked This document
2 Security Filtered This document
3 RPKI Invalid This document
4 No Export Policy This document
5 Martian Address This document
6 Bogon Prefix This document
7 Route Dampening This document
8 Local Administrative Action This document
9 Local Link Down This document
10 MAC Mobility Limit Exceeded This document
11 Tenant Isolation Violation This document
12 VTEP Unreachable This document
13-64535 Unassigned
64536-65535 Reserved for Private Use This document
9. 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.
10. References
10.1. Normative References
[I-D.ietf-bess-rfc7432bis]
Sajassi, A., Ed., Burdet, L., Ed., Drake, J., and J.
Rabadan, "BGP MPLS-Based Ethernet VPN", Work in Progress,
Internet-Draft, draft-ietf-bess-rfc7432bis-14, March 2026,
.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
.
Tantsura, et al. Expires 21 October 2026 [Page 28]
Internet-Draft EVPN Unreachability Signaling April 2026
[RFC4724] Sangli, S., Chen, E., Fernando, R., Scudder, J., and Y.
Rekhter, "Graceful Restart Mechanism for BGP", RFC 4724,
DOI 10.17487/RFC4724, January 2007,
.
[RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter,
"Multiprotocol Extensions for BGP-4", RFC 4760,
DOI 10.17487/RFC4760, January 2007,
.
[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, .
[RFC7606] Chen, E., Ed., Scudder, J., Ed., Mohapatra, P., and K.
Patel, "Revised Error Handling for BGP UPDATE Messages",
RFC 7606, DOI 10.17487/RFC7606, August 2015,
.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, .
[RFC9136] Rabadan, J., Ed., Henderickx, W., Drake, J., Lin, W., and
A. Sajassi, "IP Prefix Advertisement in Ethernet VPN
(EVPN)", RFC 9136, DOI 10.17487/RFC9136, October 2021,
.
[RFC9552] Talaulikar, K., Ed., "Distribution of Link-State and
Traffic Engineering Information Using BGP", RFC 9552,
DOI 10.17487/RFC9552, January 2024,
.
10.2. Informative References
[I-D.tantsura-idr-unreachability-safi]
Tantsura, J., Sharp, D., Venkatraman, V., Muppalla, K.,
and M. Rzehak, "BGP Unreachability Information SAFI", Work
in Progress, Internet-Draft, draft-tantsura-idr-
unreachability-safi-03, April 2026,
.
[RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP
Authentication Option", RFC 5925, DOI 10.17487/RFC5925,
June 2010, .
Tantsura, et al. Expires 21 October 2026 [Page 29]
Internet-Draft EVPN Unreachability Signaling April 2026
[RFC7365] Lasserre, M., Balus, F., Morin, T., Bitar, N., and Y.
Rekhter, "Framework for Data Center (DC) Network
Virtualization", RFC 7365, DOI 10.17487/RFC7365, October
2014, .
[RFC7911] Walton, D., Retana, A., Chen, E., and J. Scudder,
"Advertisement of Multiple Paths in BGP", RFC 7911,
DOI 10.17487/RFC7911, July 2016,
.
[RFC8092] Heitz, J., Ed., Snijders, J., Ed., Patel, K., Bagdonas,
I., and N. Hilliard, "BGP Large Communities Attribute",
RFC 8092, DOI 10.17487/RFC8092, February 2017,
.
[RFC8365] Sajassi, A., Ed., Drake, J., Ed., Bitar, N., Isaac, A.,
Henderickx, W., and R. Shekhar, "A Network Virtualization
Overlay Solution Using Ethernet VPN (EVPN)", RFC 8365,
DOI 10.17487/RFC8365, March 2018,
.
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"):
Tantsura, et al. Expires 21 October 2026 [Page 30]
Internet-Draft EVPN Unreachability Signaling April 2026
Route Type: TBD1
Length: 48 octets (route-type-specific)
Route Distinguisher: 198.51.100.1:100 (RD Type 1, 8 octets)
Ethernet Segment Identifier: 0 (10 octets)
Ethernet Tag ID: 0 (4 octets)
Address Family: 1 (IPv4)
IP Prefix Length: 24 (1 octet)
IP Prefix: 192.0.2.0 (4 octets)
GW IP Address Length: 0 (1 octet)
MPLS Label: 0 (3 octets)
Reporter TLV (on-wire: 16 octets = 1 Type + 2 Length + 13 payload):
Type: 1
Length: 13 (payload octets)
Reporter Identifier: 198.51.100.1 (4 octets)
Reporter AS: 65001 (4 octets)
Sub-TLV Reason Code:
Sub-Type: 1
Sub-Length: 2
Value: 4 (No Export Policy)
Route-type-specific = 8 + 10 + 4 + 1 + 1 + 4 + 1 + 3 + 16 = 48 octets
NLRI (with Route Type + Length) = 2 + 48 = 50 octets
Hexadecimal encoding (TT = TBD1 Route Type):
TT 30 00 01 C6 33 64 01 00 64 00 00 00 00 00 00
00 00 00 00 00 00 00 00 01 18 C0 00 02 00 00 00
00 00 01 00 0D C6 33 64 01 00 00 FD E9 01 00 02
00 04
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:
Route Type: TBD1
Length: 113 octets (route-type-specific)
Route Distinguisher: 198.51.100.1:100
Ethernet Segment Identifier: 0
Ethernet Tag ID: 0
Address Family: 1 (IPv4)
IP Prefix Length: 24
IP Prefix: 198.51.100.0
Tantsura, et al. Expires 21 October 2026 [Page 31]
Internet-Draft EVPN Unreachability Signaling April 2026
GW IP Address Length: 0
MPLS Label: 0
Reporter TLV #1 (on-wire: 27 octets):
Type: 1, Length: 24 (payload)
Reporter Identifier: 198.51.100.1
Reporter AS: 65001
Sub-TLVs:
Reason Code (Type 1, Length 2): 8 (Local Administrative Action)
Timestamp (Type 2, Length 8): 1704672000
Reporter TLV #2 (on-wire: 27 octets):
Type: 1, Length: 24
Reporter Identifier: 198.51.100.2
Reporter AS: 65001
Sub-TLVs:
Reason Code (Type 1, Length 2): 8
Timestamp (Type 2, Length 8): 1704672005
Reporter TLV #3 (on-wire: 27 octets):
Type: 1, Length: 24
Reporter Identifier: 198.51.100.3
Reporter AS: 65001
Sub-TLVs:
Reason Code (Type 1, Length 2): 8
Timestamp (Type 2, Length 8): 1704672008
Fields through MPLS Label: 32 octets
Reporter TLVs on wire: 3 x 27 = 81 octets
Route-type-specific total: 32 + 81 = 113 octets
NLRI (with Route Type + Length) = 2 + 113 = 115 octets
Hexadecimal encoding (TT = TBD1 Route Type):
TT 71 00 01 C6 33 64 01 00 64 00 00 00 00 00 00
00 00 00 00 00 00 00 00 01 18 C6 33 64 00 00 00
00 00 01 00 18 C6 33 64 01 00 00 FD E9 01 00 02
00 08 02 00 08 00 00 00 00 65 9B 3B 00 01 00 18
C6 33 64 02 00 00 FD E9 01 00 02 00 08 02 00 08
00 00 00 00 65 9B 3B 05 01 00 18 C6 33 64 03 00
00 FD E9 01 00 02 00 08 02 00 08 00 00 00 00 65
9B 3B 08
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"):
Tantsura, et al. Expires 21 October 2026 [Page 32]
Internet-Draft EVPN Unreachability Signaling April 2026
Route Type: TBD1
Length: 60 octets (route-type-specific)
Route Distinguisher: 198.51.100.1:100 (RD Type 1, 8 octets)
Ethernet Segment Identifier: 0 (10 octets)
Ethernet Tag ID: 0 (4 octets)
Address Family: 2 (IPv6)
IP Prefix Length: 32 (1 octet)
IP Prefix: 2001:db8:: (16 octets)
GW IP Address Length: 0 (1 octet)
MPLS Label: 0 (3 octets)
Reporter TLV (on-wire: 16 octets = 1 Type + 2 Length + 13 payload):
Type: 1
Length: 13 (payload octets)
Reporter Identifier: 198.51.100.1 (4 octets)
Reporter AS: 65001 (4 octets)
Sub-TLV Reason Code:
Sub-Type: 1
Sub-Length: 2
Value: 9 (Local Link Down)
Route-type-specific = 8 + 10 + 4 + 1 + 1 + 16 + 1 + 3 + 16 = 60 octets
NLRI (with Route Type + Length) = 2 + 60 = 62 octets
Hexadecimal encoding (TT = TBD1 Route Type):
TT 3C 00 01 C6 33 64 01 00 64 00 00 00 00 00 00
00 00 00 00 00 00 00 00 02 20 20 01 0D B8 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 01 00
0D C6 33 64 01 00 00 FD E9 01 00 02 00 09
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:
Tantsura, et al. Expires 21 October 2026 [Page 33]
Internet-Draft EVPN Unreachability Signaling April 2026
BGP UPDATE Message:
Withdrawn Routes Length: 0
Total Path Attribute Length: (calculated)
Path Attributes:
ORIGIN (Type 1):
Value: INCOMPLETE (2)
AS_PATH (Type 2):
Segment Type: AS_SEQUENCE
Segment Length: 1
AS: 65001
MP_REACH_NLRI (Type 14, Flags 0x90):
AFI: 25 (L2VPN)
SAFI: 70 (EVPN)
Next Hop Length: 4
Next Hop: 198.51.100.1
Reserved: 0
NLRI:
Route Type: TBD1 (IP Prefix Unreachability)
Length: 59
Route Distinguisher: 198.51.100.1:100
Ethernet Segment Identifier: 0
Ethernet Tag ID: 0
Address Family: 1 (IPv4)
IP Prefix Length: 24
IP Prefix: 192.0.2.0
GW IP Address Length: 0
MPLS Label: 0
Reporter TLV:
Type: 1
Length: 24
Reporter Identifier: 198.51.100.1
Reporter AS: 65001
Sub-TLV (Reason):
Sub-Type: 1
Sub-Length: 2
Value: 3 (RPKI Invalid)
Sub-TLV (Timestamp):
Sub-Type: 2
Sub-Length: 8
Value: 1733789400
EXTENDED_COMMUNITIES (Type 16):
Route Target: 65001:100
Tantsura, et al. Expires 21 October 2026 [Page 34]
Internet-Draft EVPN Unreachability Signaling April 2026
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.
Tantsura, et al. Expires 21 October 2026 [Page 35]
Internet-Draft EVPN Unreachability Signaling April 2026
UPDATE 1 (from Neighbor N1, AS 65100):
AFI: 25, SAFI: 70
AS_PATH: 65100
NLRI (192.0.2.0/24 Unreachability):
Reporter TLV:
Reporter ID: 198.51.100.1, AS: 65001
Reason: RPKI Invalid (3)
Timestamp: 1733789400
UPDATE 2 (from Neighbor N2, AS 65200):
AFI: 25, SAFI: 70
AS_PATH: 65200
NLRI (192.0.2.0/24 Unreachability):
Reporter TLV:
Reporter ID: 198.51.100.2, AS: 65002
Reason: Policy Blocked (1)
Timestamp: 1733789410
R1 Path Selection:
- Compare AS_PATH length: both length 1
- Compare by BGP Identifier: UPDATE 1 wins
R1 Aggregation:
- Extract Reporter TLV from UPDATE 1 (best path)
- Extract Reporter TLV from UPDATE 2 (feasible path)
- No duplicate (distinct Reporter ID + AS)
- Build NLRI with both Reporter TLVs
R1 Advertisement to downstream:
AFI: 25, SAFI: 70
AS_PATH: 65100 (from best path)
NLRI (192.0.2.0/24 Unreachability):
Reporter TLV #1:
Reporter ID: 198.51.100.1, AS: 65001
Reason: 3 (RPKI Invalid)
Timestamp: 1733789400
Reporter TLV #2:
Reporter ID: 198.51.100.2, AS: 65002
Reason: 1 (Policy Blocked)
Timestamp: 1733789410
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).
Tantsura, et al. Expires 21 October 2026 [Page 36]
Internet-Draft EVPN Unreachability Signaling April 2026
Initial State on R1:
UI-RIB Entry for NLRI key
(RD 198.51.100.1:100, ETag 0, IPv4, 192.0.2.0/24):
Reporter TLV #1: 198.51.100.1 / AS 65001 (from N1)
Reporter TLV #2: 198.51.100.2 / AS 65002 (from N2)
Event: N1 sends MP_UNREACH_NLRI for the NLRI key.
R1 Processing:
1. Identify withdrawal source: N1
2. Remove Reporter TLVs sourced from N1
(Reporter 198.51.100.1 / AS 65001)
3. Reporter TLV #2 remains
4. Re-advertise with the remaining Reporter TLV
R1 Advertisement to downstream:
MP_REACH_NLRI (AFI 25, SAFI 70):
NLRI (192.0.2.0/24 Unreachability):
Reporter TLV:
Reporter ID: 198.51.100.2, AS: 65002
Reason: 1 (Policy Blocked)
Timestamp: 1733789410
Later Event: N2 also sends MP_UNREACH_NLRI for the NLRI key.
R1 Processing:
1. Remove Reporter TLVs sourced from N2
2. No Reporter TLVs remain
3. Withdraw the entire NLRI
R1 Advertisement to downstream:
MP_UNREACH_NLRI (AFI 25, SAFI 70):
Withdrawn NLRI:
Route Type: TBD1
Length: 32
Route Distinguisher: 198.51.100.1:100
Ethernet Segment Identifier: 0
Ethernet Tag ID: 0
Address Family: 1 (IPv4)
IP Prefix Length: 24
IP Prefix: 192.0.2.0
GW IP Address Length: 0
MPLS Label: 0
Appendix B: Design Tradeoffs
This appendix summarizes encoding choices and their rationale.
Tantsura, et al. Expires 21 October 2026 [Page 37]
Internet-Draft EVPN Unreachability Signaling April 2026
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
([RFC7432]), 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.
Authors' Addresses
Jeff Tantsura
Nvidia
Email: jefftant.ietf@gmail.com
Vivek Venkatraman
Nvidia
Email: vivek@nvidia.com
Karthikeya Venkat Muppalla
Nvidia
Email: kmuppalla@nvidia.com
Pooja Jagadeesh Doijode
Nvidia
Email: pdoijode@nvidia.com
Maciej Rzehak
CoreWeave
Email: mrzehak@coreweave.com
Tantsura, et al. Expires 21 October 2026 [Page 38]