Reviewer: Gyan Mishra
Review result: Ready

I have reviewed the latest version 16 of the draft with Operational
Considerations section 9.3 added to address L4 checksum discussion on ML. The
draft is well written and is ready for publication.

I have been following the ML thread since it began related to L4 checksum.  The
key here for operators deploying c-SID SRv6 Compression Next SID is that
endpoints performing L4 checksum would not exist on the SRv6 network closed
domain and would exist within the customer payload which remains unaltered and
will always pass the L4 checksum.  Section 9.3 addresses the operational
consideration where the DA is not the same as the final destination and may
require enhancements to convey the final destination address.

Section 9.3
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.

Middleboxes such as packet sniffers, if deployed inside the SR domain, may fail
to verify the upper layer checksum of transit SRv6 traffic. Making these
middleboxes SRv6 aware in general or C-SID aware in particular is out of the
scope of this document.

Major issues:
None

Minor issues:
None

Nits:
None



_______________________________________________
spring mailing list -- spring@ietf.org
To unsubscribe send an email to spring-le...@ietf.org

Reply via email to