| Internet-Draft | BGP Unreachability SAFI | April 2026 |
| Tantsura, et al. | Expires 21 October 2026 | [Page] |
This document defines a new BGP Subsequent Address Family Identifier (SAFI) called "Unreachability Information" that allows the propagation of prefix unreachability information through BGP without affecting the installation or removal of routes in the Routing Information Base (RIB) or Forwarding Information Base (FIB). This mechanism enables network operators to share information about unreachable prefixes for monitoring, debugging, and coordination purposes while maintaining complete separation from the active routing plane.¶
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 (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
BGP-4 [RFC4271] withdrawals are only propagated for prefixes that have been previously announced. This behavior, while preventing certain attack vectors, limits the ability of operators to share information about prefix unreachability for prefixes that were never announced in the first place.¶
There are several use cases where propagating unreachability information without affecting routing decisions would be valuable:¶
This document defines a new SAFI that creates a parallel information plane for unreachability data, allowing BGP speakers to share this information while maintaining complete separation from the routing plane.¶
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.¶
This document defines a new SAFI:¶
A BGP speaker that wishes to exchange Unreachability Information MUST advertise the corresponding AFI/SAFI capability as defined in [RFC5492].¶
The Capability Code for Multiprotocol Extensions is 1. The Capability Value field contains:¶
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI | Reserved | SAFI | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+¶
Where:¶
Additionally, this document defines a new capability:¶
0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ |A| Reserved | +-+-+-+-+-+-+-+-+¶
Where:¶
The A bit indicates support for the aggregation procedures in Section 4.2.1. A speaker that advertises A=1 SHALL combine Reporter TLVs from multiple paths into a single NLRI. A speaker that advertises A=0 MUST NOT perform aggregation and therefore only advertises the Reporter TLVs present on its best path. A peer receiving A=0 MUST NOT send aggregated NLRIs on that session.¶
Unreachability Information NLRI is carried in BGP UPDATE messages using the Multiprotocol Extensions for BGP-4 as defined in [RFC4760]. Specifically:¶
MP_REACH_NLRI (Path Attribute Type Code 14): Used to announce unreachability information for one or more prefixes. The presence of a prefix in MP_REACH_NLRI with AFI/SAFI indicating Unreachability Information signifies that the prefix is being reported as unreachable by one or more Reporting Speakers.¶
MP_UNREACH_NLRI (Path Attribute Type Code 15): Used to withdraw previously announced unreachability information. The presence of a prefix in MP_UNREACH_NLRI with AFI/SAFI indicating Unreachability Information signifies that the unreachability condition for that prefix has been cleared by all previously Reporting Speakers.¶
The AFI field in both attributes MUST be set to 1 (IPv4) or 2 (IPv6), and the SAFI field MUST be set to 81 (Unreachability Information).¶
The NLRI field within MP_REACH_NLRI contains the Unreachability Information NLRI as described in Section 3. The NLRI field within MP_UNREACH_NLRI contains only the prefix (Prefix Length and Prefix) without TLVs.¶
Standard BGP path attributes (AS_PATH, ORIGIN, NEXT_HOP via MP_REACH_NLRI, etc.) apply as defined in [RFC4760] and [RFC4271]. These attributes represent the path taken by the UPDATE message itself, not the paths of individual reporters (which are preserved in Reporter TLVs).¶
The NLRI is uniquely identified by the combination of Prefix Length and Prefix. Reporter TLVs are NOT part of the NLRI key but provide information about each Reporting Speaker. The presence of an Unreachability Information NLRI for a prefix signifies that one or more speakers report the prefix as unreachable. The withdrawal of such an NLRI indicates that all reporters have cleared their unreachability reports for that prefix.¶
When multiple BGP speakers report unreachability for the same prefix, implementers have several options:¶
Single Reporter: Do nothing and allow the Reporter Identifier of the best path to be used as the only Reporter. This is the simplest approach but loses information from other reporters.¶
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 BGP path per prefix.¶
BGP ADD-PATH: Use BGP ADD-PATH [RFC7911] to maintain multiple paths, each carrying its own Reporter TLV. This preserves full BGP path attributes per reporter but requires ADD-PATH support.¶
This specification focuses on the nested TLV aggregation approach as the preferred mechanism, providing detailed procedures and encodings for this method throughout the remainder of this document.¶
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Prefix Length | IPv4 Prefix (variable) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reporter TLVs (variable) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+¶
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Prefix Length | IPv6 Prefix (variable) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reporter TLVs (variable) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+¶
Example IPv6 prefix: 2001:db8::/32.¶
The Reporter TLV is a container that encapsulates information about a single reporting BGP speaker and its associated unreachability details. Multiple Reporter TLVs MAY appear in a single NLRI to represent reports from different speakers.¶
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:¶
The combination of Reporter Identifier and Reporter AS Number uniquely identifies the Reporting Speaker. 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.¶
Sub-TLVs appear within Reporter TLVs and provide specific details about the unreachability observation by that reporter.¶
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sub-Type | Sub-Length | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Sub-Value (variable) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+¶
Defined Sub-TLV Types:¶
Implementations MUST ignore unknown Sub-TLV types to allow for future extensibility. Multiple Sub-TLVs of the same type SHOULD NOT appear within a single Reporter TLV; if present, only the first occurrence SHOULD be processed.¶
Defined Reason Codes:¶
Inclusion of the Unreachability Reason Code Sub-TLV is RECOMMENDED. When this Sub-TLV is absent from a Reporter TLV, receivers MUST treat the reason as Unspecified (code 0); this is semantically equivalent to an explicitly encoded Reason Code of 0. A bare Reporter TLV carrying no Sub-TLVs therefore conveys the fact of unreachability with reason Unspecified.¶
Example: 192.0.2.0/24 unreachable, reported by AS 65001, Router ID 198.51.100.1, Reason: RPKI Invalid¶
Prefix Length: 24 (0x18)
Prefix: 192.0.2.0 (0xC0000200)
Reporter TLV:
Type: 1
Length: 24 (0x0018)
Reporter Identifier: 198.51.100.1 (0xC6336401)
Reporter AS: 65001 (0x0000FDE9)
Sub-TLV (Reason):
Sub-Type: 1
Sub-Length: 2 (0x0002)
Sub-Value: 3 (0x0003) [RPKI Invalid]
Sub-TLV (Timestamp):
Sub-Type: 2
Sub-Length: 8 (0x0008)
Sub-Value: 1733789400 (0x00000000675786D8)
Hexadecimal encoding:
18 C0 00 02 01 00 18 C6 33 64 01 00 00 FD E9 01
00 02 00 03 02 00 08 00 00 00 00 67 57 86 D8¶
Example: 192.0.2.0/24 unreachable, reported by two speakers¶
Prefix Length: 24 Prefix: 192.0.2.0 Reporter TLV #1: Type: 1 Length: 24 Reporter Identifier: 198.51.100.1 Reporter AS: 65001 Sub-TLV (Reason): 3 (RPKI Invalid) Sub-TLV (Timestamp): 1733789400 Reporter TLV #2: Type: 1 Length: 24 Reporter Identifier: 198.51.100.2 Reporter AS: 65002 Sub-TLV (Reason): 1 (Policy Blocked) Sub-TLV (Timestamp): 1733789410 Total NLRI length: 4 + 27 + 27 = 58 octets¶
A BGP speaker MAY generate an Unreachability Information NLRI 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.5.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 Speaker MUST populate the Reporter TLV with its own BGP Identifier and AS Number. The speaker SHOULD include a Reason Code Sub-TLV and SHOULD include a Timestamp Sub-TLV to facilitate temporal correlation.¶
When a BGP speaker receives an UPDATE message with Unreachability Information SAFI:¶
When multiple UPDATE messages arrive advertising unreachability for the same prefix from different neighbors, a BGP speaker supporting aggregation (A bit set in capability) SHOULD combine the Reporter TLVs according to the following procedure:¶
Perform standard BGP path selection on the received updates. The "best path" is determined based on standard BGP decision process, considering only standard BGP attributes (AS_PATH length, LOCAL_PREF, etc.), NOT the content of Reporter TLVs.¶
Extract all Reporter TLVs from the best path.¶
For each non-selected path that would be feasible (not filtered by policy):¶
Create a new NLRI containing all unique Reporter TLVs¶
Advertise this aggregated NLRI to appropriate neighbors, with BGP path attributes taken from the best path¶
A speaker performing aggregation (A=1) 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. Except for the first position, receivers MUST NOT derive meaning from Reporter TLV ordering; implementations MUST tolerate any ordering of Reporter TLVs past the first.¶
The interoperability case of an aggregating sender paired with a non-aggregating receiver is resolved by capability negotiation (Section 2.2): a speaker that advertises A=0 will not receive aggregated NLRIs on that session, since its peer MUST NOT send them. The first-position rule above applies regardless, so that any speaker transiting a single aggregated NLRI (for local inspection, BMP export, or display) has a deterministic "first Reporter TLV = best path" invariant to rely on.¶
The maximum number of Reporter TLVs that can be aggregated in a single NLRI is limited by the maximum BGP UPDATE message size (4096 octets). Implementations SHOULD limit the number of Reporter TLVs to prevent NLRI size from becoming unwieldy. A RECOMMENDED maximum is 50 Reporter TLVs per prefix, which allows for comprehensive multi-vantage-point monitoring while maintaining reasonable message sizes.¶
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), unless this is the reporter of the best path. In that case the second oldest reporter should be removed.¶
Withdrawal of unreachability information operates at two levels:¶
When a BGP speaker determines that a specific reporter no longer considers a prefix unreachable (e.g., receives an UPDATE from that reporter's AS that doesn't include the unreachability NLRI, or local policy determines the report is stale), it SHOULD:¶
To facilitate individual reporter withdrawal, implementations MUST track the source of each Reporter TLV (which BGP neighbor or local process it came from).¶
A BGP speaker MUST withdraw an Unreachability Information NLRI (send the prefix in MP_UNREACH_NLRI) when:¶
The MP_UNREACH_NLRI contains only the prefix (Prefix Length and Prefix) without any TLVs.¶
Implementations SHOULD implement aging mechanisms to remove stale Reporter TLVs:¶
The path selection for Unreachability Information SAFI follows standard BGP best path selection (RFC 4271 Section 9.1) 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, 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.¶
Route Reflectors process Unreachability Information SAFI like any other AFI/SAFI combination:¶
The distinction between the ORIGINATOR_ID BGP attribute and the Reporter Identifier field in Reporter TLVs is important:¶
Standard BGP communities and attributes apply to the UPDATE message:¶
BGP Graceful Restart (GR) as defined in [RFC4724] applies to the Unreachability Information SAFI. This section describes how UI-RIB is handled during restart scenarios.¶
A BGP speaker that supports Graceful Restart for Unreachability Information SAFI MUST include the AFI/SAFI pair (AFI=1 or 2, SAFI=81) in the Graceful Restart Capability advertisement as defined in RFC 4724.¶
The "Forwarding State" (F) bit for this SAFI:¶
Since Unreachability Information does not affect the forwarding plane (Loc-RIB or FIB), there is no forwarding state to preserve.¶
The F bit SHOULD be set to 0 in the Graceful Restart Capability for this AFI/SAFI combination.¶
Receiving Speakers MUST NOT interpret the F bit for this SAFI as indicating preservation of forwarding state. The F bit, if set, has no defined meaning for this SAFI and MUST be ignored.¶
Implementations MAY use the F bit in future extensions to signal UI-RIB preservation capabilities, but such usage is outside the scope of this document.¶
When a BGP speaker restarts and has negotiated GR for the Unreachability Information SAFI:¶
The speaker SHOULD set the F bit to 0 in the Graceful Restart Capability for this AFI/SAFI pair, as there is no forwarding state associated with this SAFI.¶
If the speaker preserved its UI-RIB across the restart, it SHOULD re-advertise all retained UI-RIB entries to its peers as soon as possible after restart, but MAY do so gradually to avoid overwhelming the network.¶
If the speaker did NOT preserve its UI-RIB across the restart, it SHOULD rebuild the UI-RIB from local information sources before re-advertising entries.¶
The speaker MUST send an End-of-RIB (EoR) marker for this SAFI after completing the re-advertisement of UI-RIB entries. The EoR marker is an UPDATE message with no NLRI and the MP_UNREACH_NLRI attribute containing the AFI/SAFI pair but no withdrawn routes.¶
When a BGP speaker detects that a peer has restarted with GR capability for Unreachability Information SAFI:¶
The speaker MUST mark all UI-RIB entries learned from the restarting peer as stale. Stale marking occurs regardless of the F bit value, since the F bit has no defined semantics for this SAFI.¶
Stale entries MUST NOT be immediately withdrawn. They MUST be retained for the duration of the Restart Time advertised in the peer's GR Capability, or until the End-of-RIB marker is received, whichever comes first.¶
During the Restart Time period:¶
Upon receiving the End-of-RIB marker from the restarting peer:¶
If the Restart Time expires before receiving the End-of-RIB marker, all stale entries MUST be removed immediately.¶
Route Reflectors implementing Graceful Restart for this SAFI:¶
To prevent unbounded growth of the UI-RIB:¶
Error handling for the Unreachability Information SAFI follows [RFC7606] and [RFC4760] Section 7. Per-class actions are specified in Section 5.1 through Section 5.4.¶
The primary action for session-level errors is "session reset". A receiver that supports "AFI/SAFI disable" per [RFC7606] Section 7 MAY apply it in place of "session reset", confining the impact to the Unreachability Information SAFI rather than the entire BGP session.¶
Checks in Section 5.1 are performed before those in Section 5.2; on first error the corresponding action MUST be taken and further NLRI parsing MUST cease. All error conditions MUST be logged.¶
A receiver MUST apply "session reset" per [RFC7606] Section 4, or "AFI/SAFI disable" per [RFC7606] Section 7 if supported, on any of the following:¶
A receiver MUST apply "treat-as-withdraw" per [RFC7606] Section 2 on any of the following:¶
Consistent with the principle in [RFC9552] Section 5.1, unknown or malformed Reporter TLVs MUST NOT cause the enclosing NLRI to be considered malformed.¶
Unrecognized Sub-TLV Types within a Reporter TLV MUST be silently ignored per Section 3.5. A Sub-TLV whose Sub-Length is inconsistent with the available data within the enclosing Reporter TLV MUST be discarded; processing of the enclosing Reporter TLV and any remaining Sub-TLVs continues. Duplicate Sub-TLVs of the same Sub-Type within a single Reporter TLV are handled per Section 3.5: only the first occurrence is processed.¶
The Unreachability Information SAFI can be deployed incrementally:¶
Example deployment scenarios:¶
The Unreachability Information SAFI introduces new security considerations:¶
Information Leakage: Unreachability information might reveal network topology or operational issues. Reporter TLVs explicitly identify reporting ASes and routers. Operators SHOULD carefully consider peering policies for this SAFI.¶
State Exhaustion: Malicious peers could attempt to exhaust memory by advertising large numbers of unreachable prefixes or including excessive Reporter TLVs. Implementations SHOULD enforce limits as described in Section 4.8.¶
False Information: Peers could advertise false unreachability information or spoof Reporter TLVs. This SAFI SHOULD only be enabled with trusted peers. Consider validating Reporter Identifiers and AS Numbers against known valid values.¶
Prefix Hijacking: The SAFI could be used to claim prefixes are unreachable when they're not. Since this doesn't affect routing, the impact is limited to monitoring systems.¶
Reporter Impersonation: A malicious speaker could include Reporter TLVs claiming to represent other ASes. Implementations SHOULD validate that Reporter AS Numbers in TLVs are consistent with the AS_PATH of UPDATEs that introduced them.¶
Aggregation Amplification: A malicious speaker could send many UPDATEs with different Reporter TLVs for the same prefix, causing downstream aggregating speakers to accumulate and propagate large numbers of Reporter TLVs. Rate limiting and Reporter TLV limits mitigate this.¶
Operators SHOULD:¶
IANA has assigned a SAFI value from the "Subsequent Address Family Identifiers (SAFI) Parameters" registry within the "Border Gateway Protocol (BGP) Parameters" registry group, applicable to AFI 1 (IPv4) and AFI 2 (IPv6):¶
IANA is requested to assign a new BGP Capability Code from the "Capability Codes" registry within the "Border Gateway Protocol (BGP) Parameters" registry group:¶
IANA is requested to create a new registry called "BGP Unreachability Information Reporter TLV Types" under the "Border Gateway Protocol (BGP) Parameters" registry page.¶
Registration Procedure: Standards Action¶
Initial registrations:¶
Value Description Reference ----- ------------------------------------ ----------- 0 Reserved This document 1 Reporter TLV This document 2-254 Unassigned 255 Reserved This document¶
IANA is requested to create a new registry called "BGP Unreachability Information 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-254 Unassigned 255 Reserved This document¶
IANA is requested to create a new registry called "BGP 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:¶
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-64535 Unassigned 64536-65535 Reserved for Private Use This document¶
Implementers should consider the following aspects when implementing the Unreachability Information SAFI with nested Reporter TLVs:¶
An UPDATE message advertising that 192.0.2.0/24 is unreachable, reported by AS 65001 (Router 198.51.100.1) due to RPKI validation failure:¶
BGP UPDATE Message:
Withdrawn Routes Length: 0
Total Path Attribute Length: (calculated)
Path Attributes:
MP_REACH_NLRI (Type 14, Flags 0x90):
AFI: 1 (IPv4)
SAFI: 81 (Unreachability Information)
Next Hop Length: 0
Reserved: 0
NLRI:
Prefix Length: 24
Prefix: 192.0.2.0
Reporter TLV:
Type: 1
Length: 24
Reporter ID: 198.51.100.1
Reporter AS: 65001
Sub-TLV (Reason):
Sub-Type: 1
Sub-Length: 2
Reason: 3 (RPKI Invalid)
Sub-TLV (Timestamp):
Sub-Type: 2
Sub-Length: 8
Value: 1733789400
AS_PATH (Type 2):
Segment Type: AS_SEQUENCE
Segment Length: 1
AS: 65001
ORIGIN (Type 1):
Value: INCOMPLETE (2)¶
Router R1 receives two UPDATEs for 192.0.2.0/24:¶
UPDATE 1 (from Neighbor N1, AS 65100):
AS_PATH: 65100
Reporter TLV:
Reporter ID: 198.51.100.1, AS: 65001
Reason: RPKI Invalid (3)
Timestamp: 1733789400
UPDATE 2 (from Neighbor N2, AS 65200):
AS_PATH: 65200
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 ID: UPDATE 1 wins
R1 Aggregation:
- Extract Reporter TLV from UPDATE 1 (best path)
- Extract Reporter TLV from UPDATE 2 (add to aggregated set)
- Result: NLRI with 2 Reporter TLVs
R1 Advertisement to downstream:
AS_PATH: 65100 (from best path)
NLRI for 192.0.2.0/24:
Reporter TLV #1:
Reporter ID: 198.51.100.1, AS: 65001
Reason: 3, Timestamp: 1733789400
Reporter TLV #2:
Reporter ID: 198.51.100.2, AS: 65002
Reason: 1, Timestamp: 1733789410¶
Scenario: Reporter 198.51.100.1 (AS 65001) clears its unreachability report, but Reporter 198.51.100.2 (AS 65002) maintains its report.¶
Initial State on Router R1:
UI-RIB Entry for 192.0.2.0/24:
Reporter TLV #1: 198.51.100.1/AS65001 (from Neighbor N1)
Reporter TLV #2: 198.51.100.2/AS65002 (from Neighbor N2)
Event: N1 sends MP_UNREACH_NLRI for 192.0.2.0/24
R1 Processing:
1. Identify that withdrawal came from N1
2. Find Reporter TLVs associated with N1
3. Remove Reporter TLV for 198.51.100.1/AS65001
4. Check remaining Reporter TLVs
5. Reporter TLV #2 still present
6. Re-advertise NLRI with remaining Reporter TLV
R1 Advertisement to downstream:
MP_REACH_NLRI for 192.0.2.0/24:
Reporter TLV #2:
Reporter ID: 198.51.100.2, AS: 65002
Reason: 1, Timestamp: 1733789410
Later Event: N2 also sends MP_UNREACH_NLRI for 192.0.2.0/24
R1 Processing:
1. Remove Reporter TLV for 198.51.100.2/AS65002
2. No Reporter TLVs remain
3. Send MP_UNREACH_NLRI for 192.0.2.0/24
R1 Advertisement to downstream:
MP_UNREACH_NLRI:
AFI: 1, SAFI: 81
Withdrawn Route: 192.0.2.0/24¶
This nested TLV approach differs from using BGP ADD-PATH [RFC7911] in several fundamental ways:¶
The authors would like to thank the IDR working group for their valuable feedback and suggestions on this proposal. Special thanks to Pooja Jagadeesh Doijode for her review and to Ketan Talaulikar for his guidance.¶