Early Review of draft-ietf-rtgwg-srv6-egress-protection-24
review-ietf-rtgwg-srv6-egress-protection-24-rtgdir-early-chen-2026-07-13-00

Hello

I have been selected to do a routing directorate “early” review of this draft.
https://datatracker.ietf.org/doc/draft-ietf-rtgwg-srv6-egress-protection/

The routing directorate will, on request from the working group chair, perform
an “early” review of a draft before it is submitted for publication to the
IESG. The early review can be performed at any time during the draft’s lifetime
as a working group document. The purpose of the early review depends on the
stage that the document has reached.

As this document is in working group last call, my focus for the review was to
determine whether the document is ready to be published. Please consider my
comments along with the other working group last call comments.

For more information about the Routing Directorate, please see
https://wiki.ietf.org/en/group/rtg/RtgDir

Document: draft-ietf-rtgwg-srv6-egress-protection-24
Reviewer: Mach Chen
Review Date: 2026-07-13
Intended Status: Standards Track

## Summary:
I have some minor concerns about this document that I think should be resolved
before it is submitted to the IESG.

## Minor&Nits:

1. Abstract Section
s/IGP extensions (IS-IS/OSPFv3)/IGP (IS-IS/OSPFv3) extensions

Could you clarify the intent behind this sentence: 'The IGP extensions
(IS-IS/OSPFv3) can be used to advertise Mirror SID and protected locators.'?
Does this imply that these extensions will be defined in a separate future
document, or are they already defined in an existing specification?

2. Introduction Section
1)
 "[RFC9855] specifies fast protections for nodes and links that are within a
 link-state IGP area. In other words, it specifies fast protections for transit
 nodes and links of an SR path, but does not describe any fast protections for
 the egress node or link of an SR path. While TI-LFA provides fast protection
 for transit nodes and links within an IGP area, it does not address egress
 node protection because the egress node is the endpoint of the SR path."

The text above is somewhat redundant, as it restates the same concept in
multiple ways. I'd suggest simplifying and refining the wording for greater
clarity.

2)
While this document introduces the 1+1 global protection solution as the sole
baseline for comparison, other viable candidate solutions exist, such as 1:1
protection and the mechanism proposed in
draft-cheng-rtgwg-srv6-multihome-egress-protection. To ensure a comprehensive
and objective evaluation, it would be beneficial to expand the comparison to
include these additional candidates.

3)
"The solution is scoped to a single link-state IGP area/level."
The solution only work for intra-area, and exclude the inter-area scenario. Is
this choice due to a technical constraint or a use-case need?

4)
"It relies on IGP to distribute the tuple <PEB, PEA, Mirror SID> with the
protected locators." Since it relies on the IGP extensions, it should give a
normal reference to the definition of those extensions. Without these
references, it is difficult to properly evaluate the viability of the solution.

5) It's better to expand the acronyms and abbreviations (e.g., IGP, TI-LFA,
SID, PEA, PEB.....) when first used.

3. Section 3.1.1,
1) There need some text to describe what the " SIDa" is. It should not be just
an active segment, it's a SID that identifies the protected service/link...,
right?

2) Step 2a:
It says that "PEB MUST advertise this information through IGP, which includes
the Mirror SID and the egress PEA. The information is represented by <PEB, PEA,
Mirror SID>, together with the protected locators. ", is this already defined
in an existing document(e.g., RFC8667) or a new extensions to defined?

3) Step 2b:
"After PEA receives the information <PEB, PEA, Mirror SID>, it may provide to
PEB the forwarding behavior for the active SRv6 segment SIDa at PEA by existing
means." What are those existing means? Why does it use "may" here?  Use "may"
implies there will be "may not", if PEA does not provide the forwarding
behavior of SIDa to PEB, how does PEB process the packet when SIDa becomes the
active segment? So, maybe it's better to describe this from the view of PEB,
for example, PEB MUST learn the forwarding behavior of the protected SIDa via
BGP-based overlay as per [RFC9252] or by configuration.

4) Step 2c:
"When PEB gets the forwarding behavior of SIDa of PEA, it MUST add a forwarding
entry for SIDa into the forwarding table identified by the Mirror SID (the PEA
context)." This description is too specific about one implementation, there may
be other way to implement this.

5) Step 3b:
s/When egress node PEA fails,/ Upon detecting egress node PEA failure,
"...by executing H.Encaps with the Repair List RL and a Source Address T."
s/Repair List RL/Repair List (RL)
What the Source Address T is? What address should be used?

s/P1 as PLR needs to retain the route.../P1 as PLR will retain the route ...

"Suppose that the packet received by P1 is represented by Pkt = (S,
SID-P1)(SIDa,SID-P1; SL=1)Pkt0, where SA = S and DA = SID-P1 (i.e., SID of P1),
and Pkt0 is the rest of the packet. P1 sets DA to SIDa, updates SL and executes
H.Encaps." RFC8754 defines Illustrations (Section 6.1) that shows how to
represent an IPv6 packet, it's better not to introduce new way as above.

6) Step 3c:
" When PEB receives the re-routed packet, which is (T, Mirror SID) (S,
SIDa)Pkt0,..." Only mentions "(T, Mirror SID) (S, SIDa)Pkt0" here, is the
process same for the case of "(T, S1)(Mirror SID, Sn, ..., S1; SL=n) (S,
SIDa)Pkt0"? If so, maybe it can just simply remove the "which is (T, Mirror
SID) (S, SIDa)Pkt0,".

Best regards,
Mach