Hi, I believe that Section 6.5 is sufficient as-is. Note that I have raised my concerns about the L4 checksum issue in previous versions of the draft, and I believe the current text in Section 6.5 resolves my concerns.
Regarding the middlebox discussion, I have not seen (please correct me if I am wrong) any middlebox that verifies the L4 checksum in packets that have an SRH (even without compression). In that context RFC 8200 defines the behavior of the "originating node" and "recipient", but does not define the behavior of a middlebox. Furthermore, I have seen middleboxes that have "Drop Source Routed Packets" enabled by default. Obviously, SRv6 does not coexist well with NATs either. My point is that SRv6 (with or without compression) requires operators to carefully consider the location and configuration of middleboxes. As suggested in IETF 119, this operational aspect can be mentioned in the SRH compression document without further modifications. Cheers, Tal. On Thu, Mar 28, 2024 at 2:04 PM Alvaro Retana <[email protected]> wrote: > > 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 > [email protected] > https://www.ietf.org/mailman/listinfo/spring _______________________________________________ spring mailing list [email protected] https://www.ietf.org/mailman/listinfo/spring
