Hi, I think this text is good to me. It is aligned w/ RFC8200, nothing is needed. Using C-SID as the text specified doesn't modify the IPv6 dataplane. Thanks. B.R.
Zhu Yongqing China Telecom From: Alvaro Retana Date: 2024-06-03 20:00 To: 6man CC: int-...@ietf.org; rtg-...@ietf.org; 6man Chairs; spring-cha...@ietf.org; SPRING WG List Subject: [IPv6]C-SIDs and Upper-Layer Checksums (draft-ietf-spring-srv6-srh-compression) Dear 6man WG: As you may be aware, the spring WG is in the process of advancing draft-ietf-spring-srv6-srh-compression [1]. The WGLC discussions have resulted in the need to ask you the following questions (see below) related to the use/operation of compressed SIDs (C-SIDs). Please provide any opinions by June 14, 2024. Thanks! spring-chairs §6.5 (Upper-Layer Checksums) explains how to calculate the Upper-Layer Checksum in the presence of C-SIDs. §9.3 (Upper Layer Checksum Considerations) discusses the related operational considerations. For convenience, both sections are reproduced here: ===== ===== draft-ietf-spring-srv6-srh-compression-17 ===== ===== 6.5. Upper-Layer Checksums The Destination Address used in the IPv6 pseudo-header (Section 8.1 of [RFC8200]) is that of the ultimate destination. At the SR source node, that address will be the Destination Address as it is expected to be received by the ultimate destination. When the last element in the compressed SID list is a C-SID container, this address can be obtained from the last element in the uncompressed SID list or by repeatedly applying the segment behavior as described in Section 9.2. This applies regardless of whether an SRH is present in the IPv6 packet or omitted. At the ultimate destination(s), that address will be in the Destination Address field of the IPv6 header. ... 9.3. Upper Layer Checksum Considerations Upper layer checksums are computed by the originator of an IPv6 packet and verified by the ultimate destination(s) as it processes the upper layer protocol. As specified in Section 6.5, SR source nodes originating TCP/UDP packets ensure that the upper layer checksum is correctly calculated based on the ultimate destination of the session, which may be different from the address placed in the IPv6 destination address. Such SR source nodes leveraging TCP/UDP offload engines may require enhancements to convey the ultimate destination address. These implementation enhancements are outside the scope of this document. It was reported that some network node implementations, including middleboxes such as packet sniffers and one software router implementation, may attempt to verify the upper layer checksum of transit IPv6 packets. These nodes, if deployed inside the SR domain, may fail to verify the upper layer checksum of transit SRv6 traffic, possibly resulting in dropped packets or in the inability to carry out their function. Making these implementations SRv6 aware in general or C-SID aware in particular is out of the scope of this document. ===== ===== ===== ===== ===== ===== ===== ===== ===== ===== ===== ===== Is this text aligned with §8.1/rfc8200 (Upper-Layer Checksums) [2]? Does anything need to be added, deleted, changed, or clarified? Is using C-SIDs in the above scenarios (§9.3) compatible with IPv6 transit node deployments compliant with rfc8200? Does using C-SIDs as specified above represent a modification to the IPv6 dataplane? If so, is the modification considered acceptable to the WG? [1] https://datatracker.ietf.org/doc/html/draft-ietf-spring-srv6-srh-compression [2] https://datatracker.ietf.org/doc/html/rfc8200#autoid-17
_______________________________________________ spring mailing list -- spring@ietf.org To unsubscribe send an email to spring-le...@ietf.org
