Skip to content

Commit 600e81f

Browse files
author
ietf-corpus-bot
committed
auto-ingest: ietf-elements backfill — 226 new elements (2026-07-12)
1 parent 2a8326f commit 600e81f

226 files changed

Lines changed: 2090 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-9516__design-rationale-the-mac-1-context-header-rfc-9145-is.yaml‎

Lines changed: 9 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,9 @@
1+
document: rfc-9516
2+
kind: design-rationale
3+
summary: The MAC#1 Context Header (RFC 9145) is preferred over MAC#2 for SFC active OAM integrity protection because MAC#1 does not require recalculation of the MAC when the NSH Base Header TTL field changes, which happens at every hop during forwarding.
4+
section: "7"
5+
topics:
6+
- security
7+
- routing
8+
extracted_by: claude-sonnet-4-6
9+
extracted_at: "2026-07-12"

‎corpus/elements/rfc-9516__design-rationale-the-sfc-active-oam-header-was-introduced-to.yaml‎

Lines changed: 8 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,8 @@
1+
document: rfc-9516
2+
kind: design-rationale
3+
summary: The SFC Active OAM Header was introduced to demultiplex active OAM protocols on SFC without requiring IP/UDP encapsulation. Adding an extra IP/UDP header, especially in IPv6 networks, adds significant overhead compared to the length of typical Active OAM Control Packets such as BFD Control packets.
4+
section: "5"
5+
topics:
6+
- routing
7+
extracted_by: claude-sonnet-4-6
8+
extracted_at: "2026-07-12"

‎corpus/elements/rfc-9516__interoperability-note-fate-sharing-between-active-oam-packets-and-monitored.yaml‎

Lines changed: 8 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,8 @@
1+
document: rfc-9516
2+
kind: interoperability-note
3+
summary: Fate sharing between active OAM packets and monitored SFC data traffic cannot be guaranteed when reclassification occurs along the SFP or when the load balancing principle is unknown. In such cases, OAM results may only reflect the state of an SFC segment rather than the entire SFC. Operators must consider this limitation.
4+
section: "8"
5+
topics:
6+
- routing
7+
extracted_by: claude-sonnet-4-6
8+
extracted_at: "2026-07-12"

‎corpus/elements/rfc-9516__interoperability-note-sfc-elements-classifiers-or-sffs-that-do-not.yaml‎

Lines changed: 9 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,9 @@
1+
document: rfc-9516
2+
kind: interoperability-note
3+
summary: SFC elements (Classifiers or SFFs) that do not support SFC active OAM will discard the protocol's packets during incremental deployment. The SFC Echo Request/Reply mechanism is defined for NSH encapsulation; applicability to other SFC encapsulations such as MPLS (RFC 8595) is outside scope.
4+
section: "8"
5+
topics:
6+
- routing
7+
- mpls
8+
extracted_by: claude-sonnet-4-6
9+
extracted_at: "2026-07-12"

‎corpus/elements/rfc-9516__normative-requirement-an-sff-receiving-an-sfc-echo-request-must.yaml‎

Lines changed: 9 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,9 @@
1+
document: rfc-9516
2+
kind: normative-requirement
3+
summary: 'An SFF receiving an SFC Echo Request MUST validate in order: verify authentication if integrity-protected (failing auth triggers Echo Reply with Return Code 3), validate Source ID TLV (malformed TLV causes silent drop with optional logging), check overall packet well-formedness (malformed triggers Return Code 1), report unknown TLVs with Return Code 2, and at the end of the SFP reply with Return Code 5.'
4+
section: "6.4"
5+
rfc2119_level: MUST
6+
topics:
7+
- routing
8+
extracted_by: claude-sonnet-4-6
9+
extracted_at: "2026-07-12"

‎corpus/elements/rfc-9516__normative-requirement-an-sff-should-not-accept-an-sfc-echo.yaml‎

Lines changed: 9 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,9 @@
1+
document: rfc-9516
2+
kind: normative-requirement
3+
summary: An SFF SHOULD NOT accept an SFC Echo Reply unless the message is well-formed, a matching Echo Request is found with equal Sender's Handle values, and the Sequence Number matches an outstanding transmitted Echo Request's Sequence Number.
4+
section: 6.5.3
5+
rfc2119_level: SHOULD NOT
6+
topics:
7+
- routing
8+
extracted_by: claude-sonnet-4-6
9+
extracted_at: "2026-07-12"

‎corpus/elements/rfc-9516__normative-requirement-each-sff-in-the-sfp-must-send-exactly.yaml‎

Lines changed: 9 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,9 @@
1+
document: rfc-9516
2+
kind: normative-requirement
3+
summary: Each SFF in the SFP MUST send exactly one CVRep per CVReq. For multiple SFs attached to the same SFF as different SFP hops, information about each SF MUST be listed as separate SF Information Sub-TLVs. For load-balanced SFs sharing the same Service Index, all SF Identifiers MUST be listed sequentially within a single sub-TLV.
4+
section: 6.6.3
5+
rfc2119_level: MUST
6+
topics:
7+
- routing
8+
extracted_by: claude-sonnet-4-6
9+
extracted_at: "2026-07-12"

‎corpus/elements/rfc-9516__normative-requirement-the-sender-s-handle-field-must-be-filled.yaml‎

Lines changed: 10 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,10 @@
1+
document: rfc-9516
2+
kind: normative-requirement
3+
summary: The Sender's Handle field MUST be filled in by the sender of the Echo Request and returned unchanged by the Echo Reply sender. The sender SHOULD use a pseudorandom number generator to set the Sender's Handle value.
4+
section: "6"
5+
rfc2119_level: MUST
6+
topics:
7+
- routing
8+
- security
9+
extracted_by: claude-sonnet-4-6
10+
extracted_at: "2026-07-12"

‎corpus/elements/rfc-9516__normative-requirement-the-sequence-number-in-an-sfc-echo-request.yaml‎

Lines changed: 9 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,9 @@
1+
document: rfc-9516
2+
kind: normative-requirement
3+
summary: The Sequence Number in an SFC Echo Request MUST be pseudorandomly generated and SHOULD be monotonically increasing during the test session. If a reply is sent, the Echo Reply sender MUST copy the Sequence Number from the received Echo Request.
4+
section: "6"
5+
rfc2119_level: MUST
6+
topics:
7+
- routing
8+
extracted_by: claude-sonnet-4-6
9+
extracted_at: "2026-07-12"

‎corpus/elements/rfc-9516__normative-requirement-to-identify-an-sfc-active-oam-message-the.yaml‎

Lines changed: 10 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,10 @@
1+
document: rfc-9516
2+
kind: normative-requirement
3+
summary: To identify an SFC active OAM message, the NSH Next Protocol field MUST be set to SFC Active OAM (0x07) and the O bit in the NSH MUST be set per RFC 9451. An erroneous combination where the O bit is clear but Next Protocol is 0x07 MUST be reported with rate-limiting control, and the packet SHOULD be dropped.
4+
section: "4"
5+
rfc2119_level: MUST
6+
topics:
7+
- routing
8+
- security
9+
extracted_by: claude-sonnet-4-6
10+
extracted_at: "2026-07-12"

0 commit comments

Comments
 (0)