Re: RtgDir Early review: draft-ietf-rtgwg-srv6-egress-protection

[Huaimo Chen]

Hi Yingzhen,

Thank you very much for your valuable comments.
My answers are inline below with [HC].

Best Regards,
Huaimo

From: Yingzhen Qu 
Sent: Friday, August 4, 2023 5:24 PM
To: Tal Mizrahi 
Cc: draft-ietf-rtgwg-srv6-egress-protect...@ietf.org 
; rtgwg-cha...@ietf.org 
; rtg-...@ietf.org ; rtgwg@ietf.org 
; spr...@ietf.org ; rtgwg-...@ietf.org 

Subject: Re: RtgDir Early review: draft-ietf-rtgwg-srv6-egress-protection

With RTGWG chair hat.

Hi Tal,

Thanks for the review and comments.

As an individual contributor:

Authors,

I have the same question about ti-lfa. Please provide more explanation about 
why the use case in the draft can't be addressed using ti-lfa?
[HC]: ti-lfa 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.
   This document presents a solution which provides fast protections for
   the egress node and link of an SRv6 path through extending IGP and
   using Mirror SID.

In section 3.1:
 "

   After PEA receives the information , it may
   send the forwarding behavior of the SIDa at PEA to PEB with the
   Mirror SID using some protocols such as BGP if PEB can not obtain
   this behavior from other approaches and PEB wants to protect SIDa of
   PEA.  How to send the forwarding behavior of the SIDa to PEB is out
   scope of this document.

"
How PEB gets the forwarding behavior of PEA is considered out of scope here, 
however it's a required piece of information for the complete solution. I'd 
suggest to add some references to existing technologies for completeness.
[HC]: Added some text for PEB to get the forwarding behavior of PEA
through using existing protocols in some cases and updated the
related text.

Thanks,
Yingzhen

On Wed, Aug 2, 2023 at 1:03 AM Tal Mizrahi 
mailto:tal.mizrahi@gmail.com>> wrote:
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

Re: RtgDir Early review: draft-ietf-rtgwg-srv6-egress-protection

[Huaimo Chen]

Hi Tal,

Thank you very much for your valuable comments.
My answers are inline below with [HC].

Best Regards,
Huaimo

From: Tal Mizrahi 
Sent: Wednesday, August 2, 2023 4:02 AM
To: draft-ietf-rtgwg-srv6-egress-protect...@ietf.org 
; rtgwg-cha...@ietf.org 
; rtg-...@ietf.org 
Cc: rtgwg@ietf.org ; spr...@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=05%7C01%7Chuaimo.chen%40futurewei.com%7Cfa4d4fccc7474865995f08db932ee890%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C638265601919139462%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=COMBtd7iPTSxEfNZmarAIsWRt8L72fqzhSzIYVAeDdo%3D=0

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=05%7C01%7Chuaimo.chen%40futurewei.com%7Cfa4d4fccc7474865995f08db932ee890%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C638265601919139462%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=El1YggQtkCL3C5rIFkB2FnxDiagO4FP%2FIpcYKlblHmw%3D=0

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 

Re: RtgDir Early review: draft-ietf-rtgwg-srv6-egress-protection

[Yingzhen Qu]

With RTGWG chair hat.

Hi Tal,

Thanks for the review and comments.

As an individual contributor:

Authors,

I have the same question about ti-lfa. Please provide more explanation
about why the use case in the draft can't be addressed using ti-lfa?

In section 3.1:
 "

   After PEA receives the information , it may
   send the forwarding behavior of the SIDa at PEA to PEB with the
   Mirror SID using some protocols such as BGP if PEB can not obtain
   this behavior from other approaches and PEB wants to protect SIDa of
   PEA.  How to send the forwarding behavior of the SIDa to PEB is out
   scope of this document.

"
How PEB gets the forwarding behavior of PEA is considered out of scope
here, however it's a required piece of information for the complete
solution. I'd suggest to add some references to existing technologies for
completeness.

Thanks,
Yingzhen

On Wed, Aug 2, 2023 at 1:03 AM Tal Mizrahi 
wrote:

> 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.
>
___
rtgwg mailing list
rtgwg@ietf.org
https://www.ietf.org/mailman/listinfo/rtgwg