Hi Tal,
Thank you very much for your valuable comments.
My answers are inline below with [HC].
Best Regards,
Huaimo
________________________________
From: Tal Mizrahi <tal.mizrahi....@gmail.com>
Sent: Wednesday, August 2, 2023 4:02 AM
To: draft-ietf-rtgwg-srv6-egress-protect...@ietf.org
<draft-ietf-rtgwg-srv6-egress-protect...@ietf.org>; rtgwg-cha...@ietf.org
<rtgwg-cha...@ietf.org>; rtg-...@ietf.org <rtg-...@ietf.org>
Cc: rtgwg@ietf.org <rtgwg@ietf.org>; spr...@ietf.org <spr...@ietf.org>;
rtgwg-...@ietf.org <rtgwg-...@ietf.org>
Subject: RtgDir Early review: draft-ietf-rtgwg-srv6-egress-protection
Hello,
I have been selected to do a routing directorate “early” review of this draft.
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-rtgwg-srv6-egress-protection%2F11%2F&data=05%7C01%7Chuaimo.chen%40futurewei.com%7Cfa4d4fccc7474865995f08db932ee890%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C638265601919139462%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=COMBtd7iPTSxEfNZmarAIsWRt8L72fqzhSzIYVAeDdo%3D&reserved=0<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://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwiki.ietf.org%2Fen%2Fgroup%2Frtg%2FRtgDir&data=05%7C01%7Chuaimo.chen%40futurewei.com%7Cfa4d4fccc7474865995f08db932ee890%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C638265601919139462%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=El1YggQtkCL3C5rIFkB2FnxDiagO4FP%2FIpcYKlblHmw%3D&reserved=0<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.
[HC]: Added some text for clarifying the use case that
draft-ietf-rtgwg-segment-routing-ti-lfa covers and the use case
that draft-ietf-rtgwg-segment-routing-ti-lfa falls short.
This document specifies the extensions to cover the use case that
draft-ietf-rtgwg-segment-routing-ti-lfa falls short.
- 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.
[HC]: Added some text to brief a solution without using Mirror SID
and IGP extensions, and the benefits of the solution with using
Mirror SID and IGP extensions compared to the one without.
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.
[HC]: Defined terms and pointed to corresponding references.
Removed the confusing sentence.
- 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]."
[HC]: Elaborated the paragraph and moved it to the end of
Section 3.1.
- 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.
[HC]: Used more MUSTs.
- 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.
[HC]: Added text to explicitly discuss the security considerations
as suggested.
Nits:
- The Requirements Language text is not the updated version that
includes RFC8174.
[HC]: Updated it accordingly to include RFC8174.
- Terminology: it would be useful if the terms were in alphabetical
order. The term "RL" is missing.
[HC]: Sorted the terms in alphabetical order and added the term "RL".
- 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.
[HC]: Updated them accordingly as suggested.
Cheers,
Tal.
_______________________________________________
rtgwg mailing list
rtgwg@ietf.org
https://www.ietf.org/mailman/listinfo/rtgwg
