Early Review of draft-ietf-rtgwg-srv6-egress-protection-24
review-ietf-rtgwg-srv6-egress-protection-24-intdir-early-fressancourt-2026-07-09-00

I am an assigned INT directorate early reviewer for
draft-ietf-rtgwg-srv6-egress-protection "SRv6 Path Egress Protection". These
comments were written primarily for the benefit of the Internet Area Directors.
Document editors and shepherd(s) should treat these comments just like they
would treat comments from any other IETF contributors and resolve them along
with any other Last Call comments that have been received. For more details on
the INT Directorate, see https://datatracker.ietf.org/group/intdir/about/
<https://datatracker.ietf.org/group/intdir/about/>.

Based on my review, if this document was discussed in the IESG at this stage
and if I was on the IESG I would ballot this document as DISCUSS.

## DISCUSS level comments

I have the following DISCUSS/ABSTAIN level issues:

### Document motivation - egress node or link protection

I think the document should clarify its motivation with regards of the egress
node protection. Indeed, in the Introduction, the document mentions that RFC
9855 does not address egress node protection. After a careful read of RFC 9855,
it mentions in the introduction that "Protecting domain exit routers and/or
links attached to another routing domain is beyond the scope of this document."
and later refine this statement in section 7.2 mentionning that "If the traffic
is protected at an SR Segment Endpoint Node, first the Segment Endpoint packet
processing is executed. Then, the packet is protected as if it were a transit
packet.", implying that the egress point can be protected if it is within the
IGP domain. The document should be more precise about the goal, which seems to
me to protect egress point or link when they are the exit node or link for the
(IGP) domain.

### Egress link protection example choice

Throughout the document, the authors try to discourage the reader from adopting
the proposed protection mechanism for service SID, but the example detailed in
section 3.2 targets such a SID. I would expect the example to document a
prefered situation than a situation the authors actually discourage in their
document.

### IPv6 and IPv4 addressing used in the document

The example prefixes and addresses used throughout the document are not
consistent with the address documentation space (RFC 3849, RFC 9637) for IPv6
prefixes. The document includes one IPv4 address which is a very well known
public address (1.1.1.1). This address should be replaced.

### Security threat from BFD misuse

Besides, throughout the security considerations section, BFD is mentionned as a
reliable failure mechanism, but little detail or consideratiosn are given about
the way BFD can be deployed to avoid security threats listed in the draft. For
instance, is BFD authentication recommended? Which document or method do the
authors recommend? Can BFD authentication be used if the egress is a domain
border node?

### Details on PEA failure or egress link failure detection

In both examples given by the authors, in step 3a, the draft says very little
about the failure detection mechanism to be used. BFD is mentionned, but very
little details are provided. Could you point to a reference of a preferred
detection mechanism you would advise or that you have in mind? Can you detail
whether you expect the CE to be involved in the failure detection? Besides BFD,
do you have other mechanism in mind?

## Other issues

The following are other issues I found with this document that SHOULD be
corrected before publication:

### Packet format notation

Throughout the document, the authors use a packet notation in the form "(T,
Mirror SID) (S, SIDa)Pkt0". This notation is, from my perspective,
insufficiently explained, especially when nested encapsulation is mentionned. I
would appreciate a better explanation of this notation in the beginning of the
document or, if appropriate, a reference to the document explaining this
notation.

### Security threat - attack to be considered

In the Security considerations section, the authors consider an unauthorized
rerouting attack in which the attacker attempts to become a protector node to
intercept traffic. I think the document should mention the associated attack in
which the attacker controls the link between the egress protector and the CE.

### Operational guidelines - Protector consolidation

In section 3.3, it is advised that the choice of protecting PE for each PE is
consolidated. I think this is actually depending on the multi-homing choice for
the destination CE receiving traffic from the protecting link.

### Mirror SID reference

Section 3.1.1 ends with a reference to the mirror SID behavior. This reference
should be placed earlier in the text (at the beginning of the section or when
the mirror SID is introduced).