After reading the long discussion. I realize that some people have some concerns of middle box checksum. Though I do not believe this is a common case, and I do not understand why a middle box should have this right to check the packet? * If the middle box does not have the right the check the packet, then it should not check the packet, and any result caused by it's checking is the problem of the middle box not the packet. * If the middle box does have the right to check, then we may consider what to do on it. Or we state that the checksum may be failed if the middle box checks it. But this is out of the scope of this document. That can be discussed of other draft, if any one would like to write a new draft.
But regarding the checksum on the final destination, I do not see any problem. As long as the originator node calculate the checksum using the real/targeted destination address received on the final node, then the final node can get the checksum right in the end. All the implementation on the originator node is an internal implementation. We DO NOT CARE that how it is implemented, but it has to MAKE SURE that the checksum to be correct on the final destination. Therefore the text in Section 6.5 is totally correct to me. Follow the text and implement it is the key to solve this problem. I do not see we have any need to update the RFC8200 itself. All we need to do is to follow the instruction of this draft. Thanks, Cheng -----Original Message----- From: spring <spring-boun...@ietf.org> On Behalf Of Alvaro Retana Sent: Thursday, March 28, 2024 1:05 PM To: SPRING WG List <spring@ietf.org> Cc: spring-cha...@ietf.org Subject: [spring] C-SIDs and upper layer checksums (draft-ietf-spring-srv6-srh-compression) Section 6.5 of draft-ietf-spring-srv6-srh-compression describes the behavior when an originating node inside an SRv6 domain creates a packet with a C-SID as the final destination. This description differs from the text in Section 8.1 of RFC8200. We plan to send the draft to the 6man WG for review and explicitly highlight this difference. Please comment on the text in Section 6.5. Does anything need to be added, deleted, changed, or clarified? We want to ask for feedback soon; please send comments on this topic by April 5th. Thanks! Alvaro. -- for spring-chairs _______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring _______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
