Hi Adrain,
Thanks for your careful review. All of the comments are helpful, and we will come back with updates in next revision. BR, Feng 发件人: Adrian Farrel <[email protected]> 发送时间: 2026年9月27日 3:20 收件人: [email protected] 抄送: [email protected] 主题: A review of draft-ietf-spring-sid-as-source-address Hi SPRING, Congratulations to the authors on a new WG draft. I watched the discussions during adoption triggered by Gyan's review and comments. It seems like some sort of agreement was reached, and I look forward to a new revision to address that. At the same time, I have done my own review of the draft. I know it is annoying to get a review when there are agreed updates that haven't been made yet, but I figure that since there is a new revision being made, some work on nits may be easily incorporated at the same time. Cheers, Adrian === Abstract I think we don't need the marketing statements in the Abstract. It is enough to say: OLD SRv6 is being rapidly deployed and is currently primarily used in trusted-domain backbone networks. Both the carrier market and the enterprise market are adopting SRv6 for end-to-end service delivery. NEW SRv6 is deployed in trusted-domain backbone networks for end-to-end service delivery in carrier and enterprise networks. END --- Abstract I suggest: OLD However, if a firewall exists along an SRv6 path, not only legitimate SRv6 traffic but also ICMP packets generated on SRv6 transit node will be dropped. NEW However, a stateful firewall on an SRv6 path may drop both legitimate SRv6 traffic and ICMP packets generated on SRv6 transit nodes because the bidirectional traffic flows are asymmetrical. END --- Absract s/proposal/document/ s/SID/a SID/ --- Introduction Same changes as in the Abstract. --- 1. OLD The reason has been elaborated in Section 8.1 of [I-D.draft-ietf-spring-srv6-security]. SRv6 implementations use the ingress PE's loopback IPv6 address as the outer IPv6 source address NEW As described in Section 8.1 of [I-D.draft-ietf-spring-srv6-security], SRv6 implementations use the ingress PE's loopback IPv6 address as the source address in the outer IPv6 packet header. END --- 1.2 Add "SRS" to the list --- 2. Only unicast traffic is eligible for using SID as source address. Are you saying that this approach cannot be used for multicast? If so, you need to say why. Or maybe you are saying that this document is only interested in unicast and that multicast is out of scope for this document. If so, just make that clear. --- 2. s/Several/Two/ s/SHOULD/should/ --- 2.1.1 The user traffic SHOULD use the SRv6 service SID as the source address of the outer IPv6 header. Why is this "SHOULD"? If you mean "to conform to this document an implementation SHOULD" then I would have thought this is a MUST because the document is all about getting through the firewall. If you are giving advice that implementations would be well advised to follow, then use "should". --- 2.1.1 All those End.DX* and End.DT* SIDs except End.DT2M SHOULD be used for source address. s/SHOULD/can/ --- 2.2 For SRv6 ping, the ICMP Echo Request MAY use an End SID as the outer IPv6 source address to verify the reachability of the return path. Some confusion over the use of "MAY" I think. It's true that the Echo Request MAY use an End SID. However, if the intention is to verify the reachability of the return path when there is a stateful firewall on the path, isn't this "MUST"? --- 3.1.1 s/taffics/traffic/ --- 3.1.2 OLD The proposed solution is to unify the semantic of the source and NEW The solution described in this document is to unify the semantic of the source and END --- 4. s/lists[RFC9800]/lists [RFC9800]/ --- Adding an Operational Considerations section per draf-ietf-opsawg- rfc5706bis would be great. It doesn't need to be done before adoption, but hopefully it can be added later down the line.
_______________________________________________ spring mailing list -- [email protected] To unsubscribe send an email to [email protected]
