Skip to main content

Early Review of draft-ietf-rtgwg-srv6-egress-protection-11

Request Review of draft-ietf-rtgwg-srv6-egress-protection-09
Requested revision 09 (document currently at 16)
Type Early Review
Team Routing Area Directorate (rtgdir)
Deadline 2023-08-05
Requested 2023-07-11
Requested by Yingzhen Qu
Authors Zhibo Hu, Huaimo Chen , Mehmet Toy , Chang Cao , Tao He
I-D last updated 2023-08-02
Completed reviews Rtgdir Early review of -11 by Tal Mizrahi (diff)
Intdir Early review of -10 by Bob Halley (diff)
Opsdir Early review of -09 by Susan Hares (diff)
Kindly request early reviews of this document, specifically focusing on its consistency and effectiveness in relation to existing mechanisms.
Assignment Reviewer Tal Mizrahi
State Completed
Request Early review on draft-ietf-rtgwg-srv6-egress-protection by Routing Area Directorate Assigned
Posted at
Reviewed revision 11 (document currently at 16)
Result Has issues
Completed 2023-08-02

I have been selected to do a routing directorate “early” review of this draft.

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

For more information about the Routing Directorate, please see

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

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.

- 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