Early Review of draft-ietf-rtgwg-srv6-egress-protection-11
review-ietf-rtgwg-srv6-egress-protection-11-rtgdir-early-mizrahi-2023-08-02-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/11/

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.

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

Document: draft-ietf-rtgwg-srv6-egress-protection-11
Reviewer: Tal Mizrahi
Review Date: August 2, 2023
Intended Status: Standards Track

Summary:
I have concerns about this document. It needs more work before being
submitted to the IESG.

Main comments:
- Reading the document, it is not clear how the use case in
draft-ietf-rtgwg-segment-routing-ti-lfa is different than the use case
in the current document. Specifically, it would be useful to
explicitly explain where the procedures described in the ti-lfa
document fall short, and why it is necessary to define a new endpoint
behavior and IGP extensions.
- Specifically, it would be useful to explain whether it would be
possible to achieve the same behavior (as the behavior described in
Section 3.1) without the Mirror SID Endpoint Behavior and without the
IGP extensions, and to explain what this new endpoint behavior
contributes compared to previously achievable behavior.

Other comments:
- Introduction: the following sentence regarding the terminology is a
bit confusing: "Egress node and egress, fast protection and protection
as well as SRv6 path and SRv6 tunnel will be used exchangeably below."
These terms need to be defined, or there needs to be a pointer to a
document that defines them. For example, the terms SRv6 path and SRv6
tunnel are not used in RFC8402, and it would be great if the current
document would clarify how these terms are related to an SRv6 policy.
- Introduction: the following paragraph should either be omitted or
elaborated. Reading this paragraph the reader has to either read the
entire [RFC8679], or to be left curious. Here is the paragraph: "There
are a number of topics related to the egress protection, which include
the detection of egress node failure, the relation between egress
protection and global repair, and so on.  These are discussed in
details in [RFC8679]."
- The document uses only two instances of normative "MUST"s. There
needs to be normative language specifying what the SR endpoint is
expected to do with the Mirror SID endpoint behavior.
- The Security Considerations section just points to [RFC8679], which
is an MPLS document. However, it is not clear which parts of the
security considerations of the latter are relevant. For example, the
discussion about the service label distribution protocol in [RFC8679]
is clearly not relevant. It would be best if the current document
would explicitly discuss the security considerations, even at the cost
of some text replication.

Nits:
- The Requirements Language text is not the updated version that
includes RFC8174.
- Terminology: it would be useful if the terms were in alphabetical
order. The term "RL" is missing.
- Sections 4.1 and 4.2: it would be best to replace "Flags" by
reserved, or otherwise there needs to be an IANA registry for the
flags.

Cheers,
Tal.