Hi,
I've read v-15 and the update looks clear to me and is quite helpful for us as
a vendor when considering the aspect of upper layer checksum.
Considering that some middleboxs like FW might verify the checksum, should some
relevant descriptions be added to the security consideration section?
Yao
Original
From: RobertRaszuk <rob...@raszuk.net>
To: Ketan Talaulikar <ketant.i...@gmail.com>;
Cc: Alvaro Retana <aretana.i...@gmail.com>;SPRING WG List
<spring@ietf.org>;spring-cha...@ietf.org <spring-cha...@ietf.org>;
Date: 2024年04月10日 00:41
Subject: Re: [spring] C-SIDs and upper layer checksums
(draft-ietf-spring-srv6-srh-compression)
_______________________________________________
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring
Hi Ketan,
KT> Since these "group of folks" don't care about SRv6/CSID, they wouldn't be
deploying it and therefore aren't SRv6 operators? Therefore, there is nothing
to demux for these "group of folks" in their networks (for at least those
amongst them that are operators) since they won't have SRv6 in their limited
domains. SRv6 operators are already doing this demux using the recommendation
of RFC8754/8986 (SRv6 SID block) in their deployments - that said, we may be
digressing from the main topic of this thread.
This is actually getting interesting here.
If end hosts start to talk native SRv6 (no SRH no encap) there is literally no
way to distinguish SRv6 from IPv6.
So here goes all of great stories about limited domains :)
I think those SRv6 agnostic operators may one day try to debug IPv6 issues. And
perhaps will see lot's of checksum errors. Yes sure they can see those errors
for various reasons but those reasons are encoded explicitly in the packets.
SRv6OPS will be a fun group for sure :) For now from my perspective what
Francois has added as section 9.3 acknowledges the issue so I am good.
Cheers,
Robert
_______________________________________________
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring
