Skip to content

Commit 3bf6528

Browse files
author
ietf-corpus-bot
committed
auto-ingest: ietf-elements backfill — 241 new elements (2026-07-05)
1 parent 349e1de commit 3bf6528

241 files changed

Lines changed: 2306 additions & 0 deletions

File tree

Some content is hidden

Large Commits have some content hidden by default. Use the searchbox below for content that may be hidden.

‎corpus/elements/rfc-8518__design-rationale-max-metric-is-sometimes-set-on-a-link.yaml‎

Lines changed: 8 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,8 @@
1+
document: rfc-8518
2+
kind: design-rationale
3+
summary: MAX_METRIC is sometimes set on a link in one direction for TE purposes while primary traffic uses the link in the forward direction. Strictly excluding the link from LFA consideration per RFC 5286 can leave no viable alternate; this document permits its use as an LFA since the primary path already relies on it.
4+
section: "5.1"
5+
topics:
6+
- routing
7+
extracted_by: claude-sonnet-4-6
8+
extracted_at: "2026-07-05"

‎corpus/elements/rfc-8518__design-rationale-rfc-5286-section-6-1-allows-simplifying-mhp.yaml‎

Lines changed: 8 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,8 @@
1+
document: rfc-8518
2+
kind: design-rationale
3+
summary: RFC 5286 Section 6.1 allows simplifying MHP calculation by treating the MHP as solely attached to its pre-failure optimal point of attachment at the cost of lower coverage. This document improves coverage for ECMP MHPs without extra computational cost by comparing protection types across ECMP paths.
4+
section: "3.1"
5+
topics:
6+
- routing
7+
extracted_by: claude-sonnet-4-6
8+
extracted_at: "2026-07-05"

‎corpus/elements/rfc-8518__interoperability-note-for-mt-is-is-with-standard-unicast-topology.yaml‎

Lines changed: 8 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,8 @@
1+
document: rfc-8518
2+
kind: interoperability-note
3+
summary: 'For MT IS-IS with standard unicast topology MT-ID #0, if both IPv4 and IPv6 address families are present, network congruency (same AFs on all links and nodes) is required for LFA computation; a single LFA computation from all eligible neighbors yields all potential alternatives for both AFs.'
4+
section: "5.2"
5+
topics:
6+
- routing
7+
extracted_by: claude-sonnet-4-6
8+
extracted_at: "2026-07-05"

‎corpus/elements/rfc-8518__interoperability-note-for-ospf-asbr-selection-type-1-cost-asbrs.yaml‎

Lines changed: 8 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,8 @@
1+
document: rfc-8518
2+
kind: interoperability-note
3+
summary: For OSPF ASBR selection, type 1 cost ASBRs are preferred and type 2 cost ASBRs are pruned when mixed; among type 2 ASBRs, only those with equal external cost to the primary are eligible for LFA evaluation, with the cost to reach ASBR/forwarding address used as a tiebreaker.
4+
section: 4.2.1.2
5+
topics:
6+
- routing
7+
extracted_by: claude-sonnet-4-6
8+
extracted_at: "2026-07-05"

‎corpus/elements/rfc-8518__interoperability-note-in-multi-topology-igp-deployments-lfa-computation-per.yaml‎

Lines changed: 8 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,8 @@
1+
document: rfc-8518
2+
kind: interoperability-note
3+
summary: In multi-topology IGP deployments, LFA computation per RFC 5286 is applicable for each MT-ID independently, using topology-specific adjacencies; the eligible neighbor set for each LFA computation is determined by the presence of IGP adjacency on that MT-ID.
4+
section: "5.2"
5+
topics:
6+
- routing
7+
extracted_by: claude-sonnet-4-6
8+
extracted_at: "2026-07-05"

‎corpus/elements/rfc-8518__interoperability-note-lfa-evaluation-for-multi-homed-external-prefixes-in.yaml‎

Lines changed: 8 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,8 @@
1+
document: rfc-8518
2+
kind: interoperability-note
3+
summary: LFA evaluation for multi-homed external prefixes in IS-IS uses the same inequalities defined in Section 2 for multi-homed internal prefixes; no separate treatment is required.
4+
section: "4.1"
5+
topics:
6+
- routing
7+
extracted_by: claude-sonnet-4-6
8+
extracted_at: "2026-07-05"

‎corpus/elements/rfc-8518__interoperability-note-rfc-5286-sections-3-5-and-3-6.yaml‎

Lines changed: 8 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,8 @@
1+
document: rfc-8518
2+
kind: interoperability-note
3+
summary: RFC 5286 Sections 3.5 and 3.6 exclude links with MAX_METRIC from alternate paths, but when such a link is the only loop-free alternate, it MAY still be used as an LFA since primary traffic already traverses it. Alternatively, the reverse metric MAY be set to MAX_METRIC-1 to permit its use as an alternate while satisfying TE requirements.
4+
section: "5.1"
5+
topics:
6+
- routing
7+
extracted_by: claude-sonnet-4-6
8+
extracted_at: "2026-07-05"

‎corpus/elements/rfc-8518__interoperability-note-type-5-ospf-routes-always-take-preference-over.yaml‎

Lines changed: 8 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,8 @@
1+
document: rfc-8518
2+
kind: interoperability-note
3+
summary: Type 5 OSPF routes always take preference over type 7, and alternate ASBRs for LFA must be the same route type as the primary ASBR. Among type 7 routes, routes with p-bit and forwarding address set have higher preference; alternate ASBRs must share the same p-bit and forwarding address attributes.
4+
section: 4.2.1.4
5+
topics:
6+
- routing
7+
extracted_by: claude-sonnet-4-6
8+
extracted_at: "2026-07-05"

‎corpus/elements/rfc-8518__interoperability-note-when-an-mhp-has-multiple-pre-failure-optimal.yaml‎

Lines changed: 8 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,8 @@
1+
document: rfc-8518
2+
kind: interoperability-note
3+
summary: When an MHP has multiple pre-failure optimal points of attachment sharing the same primary next hop, an implementation MAY inherit the better protection (e.g., node-protecting via A instead of only link-protecting via C) without additional computation, as illustrated in Figure 1.
4+
section: "3.1"
5+
topics:
6+
- routing
7+
extracted_by: claude-sonnet-4-6
8+
extracted_at: "2026-07-05"

‎corpus/elements/rfc-8518__interoperability-note-when-rfc1583compatibility-is-disabled-asbrs-in-different-areas.yaml‎

Lines changed: 8 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,8 @@
1+
document: rfc-8518
2+
kind: interoperability-note
3+
summary: When RFC1583Compatibility is disabled, ASBRs in different areas advertising the same prefix are pruned per RFC 2328 Section 16.4 rules before LFA evaluation; alternate ASBRs pruned by these rules are not considered for LFA.
4+
section: 4.2.1.1
5+
topics:
6+
- routing
7+
extracted_by: claude-sonnet-4-6
8+
extracted_at: "2026-07-05"

0 commit comments

Comments
 (0)