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]>
Sent: Tuesday, August 8, 2023 8:51 AM
To: [email protected] <[email protected]>
Cc: [email protected]
<[email protected]>; [email protected]
<[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
