Hi Sue,
Thank you very much for your valuable comments and suggestions.
The document has been updated accordingly and uploaded.
Have a great long weekend.
Best Regards,
Huaimo
________________________________
From: Huaimo Chen <[email protected]>
Sent: Monday, August 21, 2023 11:42 PM
To: Susan Hares <[email protected]>; [email protected] <[email protected]>
Cc: [email protected]
<[email protected]>; [email protected]
<[email protected]>
Subject: RE: Opsdir early review of draft-ietf-rtgwg-srv6-egress-protection-09
Hi Sue,
Thank you very much for your time.
My responses are inline below.
Best Regards,
Huaimo
From: Susan Hares <[email protected]>
Sent: Monday, August 21, 2023 6:47 PM
To: Huaimo Chen <[email protected]>; [email protected]
Cc: [email protected]; [email protected]
Subject: RE: Opsdir early review of draft-ietf-rtgwg-srv6-egress-protection-09
Huaimo:
I apologize for the late response to your resolution.
I was out sick last week. Unfortunately, the pollution from wild fires in
Wisconsin and Canada is creating difficulties for my respiratory system. It
makes me thankful that this type of wild fires occur once in 30+ years.
California seems to have these issues every year.
[HC]: Hope you have fully recovered. It seems that there are much more and much
longer wild fires in Canada this year than before.
The text in the abstract and introduction has improved. I do not have any more
issues with these sections.
[HC]: Thank you.
The additions to sections 4.1 and 4.2 covered the issues I raised. Thanks for
the edits. Error handling for packets are difficult to write. I will review
these again in the next version as a final check.
[HC]: Thank you very much.
The new security section is greatly improved.
[HC]: Thank you.
My major issue is not address in sections 3.1 and 3.2. Thank you for letting
me know the steps are correct. It now becomes an editorial issue. It took me
a great deal of time to figure out the steps. I think a format like the steps
to make this text readable and save you time in the long-run.
[HC]: We will make it more readable accordingly.
I’m available to chat on Tuesday 8/22 from 9:30-11:00am. Would you like to
chat real-time on how to fix these issues?
[HC]: I will have a Dr. appointment (annual physical exam) from 10:20am EST on
8/22. How about 3:00 – 4:30pm EST on 8/22, or 9:30-11:00am on 8/23 or 8/24?
Sue
Your comment on the mechanisms
Mechanisms:
The mechanisms provide steps that are unclear and are not easily aligned with
the example. The mechanism section contains the following: - description of
figure 1 - step 1: a normal path set-up (PEA) - step 2: a backup pat set-up
(PEB)
step 2a: PEB announcement to PEA with PEB
step 2b: PEA processes the announcement and sends forwarding behavior to PEB
step 2c: PEB processes forwarding based on Mirror SID into table
step 2d: processing of anycast that links PEA/PEB to compute LFA with SIDs
- step 3: Steps in fail-over in failure scenario
step 3a: failure detected via BFD
step 3b: send IPv6 packet with an encapsulated packet (H.Encaps) at PL1
step 3c: decapsulate IPv6 packet with End.M (a variant of End.DT6)
- step 4: Handle processing and forwarding a PEB
If these are the correct steps, then the example in section 3.2.
If these are not the correct steps, you confirm the reading is difficult.
[HC]: These steps are correct.
From: Huaimo Chen <[email protected]<mailto:[email protected]>>
Sent: Κυριακή, 13 Αυγούστου 2023 11:33 μμ
To: [email protected]<mailto:[email protected]>; Susan Hares
<[email protected]<mailto:[email protected]>>
Cc:
[email protected]<mailto:[email protected]>;
[email protected]<mailto:[email protected]>
Subject: Re: Opsdir early review of draft-ietf-rtgwg-srv6-egress-protection-09
Hi Sue,
Thank you very much for your valuable comments.
My responses are inline below with [HC].
Best Regards,
Huaimo
________________________________
From: Susan Hares via Datatracker <[email protected]<mailto:[email protected]>>
Sent: Tuesday, August 8, 2023 8:51 AM
To: [email protected]<mailto:[email protected]>
<[email protected]<mailto:[email protected]>>
Cc:
[email protected]<mailto:[email protected]>
<[email protected]<mailto:[email protected]>>;
[email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>>
Subject: Opsdir early review of draft-ietf-rtgwg-srv6-egress-protection-09
Reviewer: Susan Hares
Review result: Has Issues
This is an OPS-DIR review of draft-ietf-rtgwg-srv6-egress-protection-09.
This review should be taken as an early review just as other reviews.
Status: Serious Issues + editorial issues
Why: The text describes mechanisms, ISIS sub-TLVs, OSPF sub-TLVs, and security
issues. Each of these sections has problems that need to be fixed before WG LC.
What should the authors do:
I'll happily work with the authors to correct the text. The text in version 09
does not provide a clear way for interoperable implementations. I will also
review -12 to check if these issues have been resolved.
Mechanisms:
The mechanisms provide steps that are unclear and are not easily aligned with
the example. The mechanism section contains the following: - description of
figure 1 - step 1: a normal path set-up (PEA) - step 2: a backup pat set-up
(PEB)
step 2a: PEB announcement to PEA with PEB
step 2b: PEA processes the announcement and sends forwarding behavior to PEB
step 2c: PEB processes forwarding based on Mirror SID into table
step 2d: processing of anycast that links PEA/PEB to compute LFA with SIDs
- step 3: Steps in fail-over in failure scenario
step 3a: failure detected via BFD
step 3b: send IPv6 packet with an encapsulated packet (H.Encaps) at PL1
step 3c: decapsulate IPv6 packet with End.M (a variant of End.DT6)
- step 4: Handle processing and forwarding a PEB
If these are the correct steps, then the example in section 3.2.
If these are not the correct steps, you confirm the reading is difficult.
[HC]: These steps are correct.
Extensions to IS-IS.
The following fields need to be given a range.
Section 4.1
For figure 3 description, please correct the following:
a) length: Please give a valid range.
[HC]: Added some text specifying the range of the length.
b) Flags: Normally a reserved value has a default setting (all zeros?) for
transmit,
and ignore upon reception.
[HC]: Changed Flags to Reserved and added some text like below:
MUST be set to zero on transmission and ignored on receipt.
c) SRv6 Endpoint Function: Please give valid range.
[HC]: Used normative language specifying the value of SRv6 Endpoint
Function and added the description about exceptional handling.
d) SID: 16 octets (please give valid ranges. For example, is SID 0 valid?)
[HC]: Added some text about SID.
for Figure 4, please valid ranges for length field.
Section 4.2
For figure 5, please correct the following:
length: Please give the valid range.
[HC]: Added some text specifying the range of the length.
flags: Normally a reserved value has a default setting (all zeros?) for
transmit,
and ignore upon reception.
[HC]: Changed Flags to Reserved and added some text like below:
MUST be set to zero on transmission and ignored on receipt.
SRv6 Endpoint Function: Please give valid range.
[HC]: Used normative language specifying the value of SRv6 Endpoint
Function and added the description about exceptional handling.
SID: 16 octets (please give valid ranges. For example, is SID 0 v
[HC]: Added some text about SID.
The Security Considerations section should provide reasons why this mechanism
to provide re-routing does not provide a potential threat. It may work in a
walled garden, but it is not clear there are "no extra security issues."
[HC]: This section is updated.
_______________________________________________
rtgwg mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/rtgwg
