Re: [spring] C-SIDs and upper layer checksums (draft-ietf-spring-srv6-srh-compression)

[Tal Mizrahi <[e-mail]>]

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 <[e-mail]> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/spring