Hello, Regarding the computation of the L4 checksum with C-SIDs, I think the text in section 6.5 is clear enough, and I would not modify the text as it appears in version 14 of the draft. It is very clear that the L4 checksum is computed using the destination address seen by the destination.
Regarding the debate about whether middleboxes on the path should be able to compute the L4 checksum in flight, I think this should be clarified in 6man. Yet, I think that fields belonging to L4 headers and upper should not be checked or modified on the path between the source and destination, as I think this was the intention in RFC 8200's text. Best regards, Antoine Fressancourt -----Original Message----- From: spring <spring-boun...@ietf.org> On Behalf Of Alvaro Retana Sent: jeudi 28 mars 2024 13:05 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
