Folks,
Has anyone proposed a solution to the L4 checksum problem that Andrew talks
about?
Ron
Juniper Business Use Only
________________________________
From: spring <[email protected]> on behalf of Andrew Alston - IETF
<[email protected]>
Sent: Monday, February 5, 2024 5:21 AM
To: [email protected] <[email protected]>
Subject: [spring] draft-ietf-spring-srv6-srh-compression
[External Email. Be cautious of content]
Hi All,
(In capacity as a contributor and wearing no other hats)
At this point I cannot support progression of this document until the issues
around the L4 Checksum have been resolved. It’s been clearly stated in other
emails on the list that in certain circumstances the behavior described in this
document break the L4 checksum as defined in RFC8200. This requires an update
to RFC8200 to fix it – and I’m not sure that spring can update 8200 absent the
consent of 6man, which I’m not sure has been asked for, nor am I sure that a
spring document can update something like 8200 in an area so fundamental as the
checksum without a -BIS, which would have to be done via 6man. The L4 checksum
issue though is real – and it cannot simply be ignored.
I also have deep concerns that the compression document creates something that
(in a similar way to SRv6) creates something that is completely non-conformant
with RFC4291. There are multiple references to this in draft-6man-sids, and
should draft-6man-sids become an RFC I would argue that it should probably be a
normative reference in this document – on the logic that this document relies
on similar RFC4291 violations that srv6 itself does (and for the record, just
because SRv6 itself violates RFC4291 as is clearly documented in
draft-6man-sids – does not make it acceptable to do so in yet another draft
without clear and unambiguously stating the deviations and ideally updating
RFC4291 to allow for said deviations)
I believe these two issues alone are sufficient that to pass this document
would create still further tensions about the relationship between SRv6 and
IPv6 and lead to confusion. As such – I believe these issues need to be
adequately dealt with – and the solutions to them need to be approved by 6man
as the working group that holds responsibility for ipv6 maintenance.
Thanks
Andrew Alston
Internal All Employees
_______________________________________________
spring mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/spring
