Thank you Martin for your insight. That is my understanding as well. I think this is quite clear actually.
Thanks, Cheng -----Original Message----- From: spring <spring-boun...@ietf.org> On Behalf Of Martin Vigoureux (Nokia) Sent: Thursday, April 4, 2024 8:51 PM To: spring@ietf.org Subject: Re: [spring] C-SIDs and upper layer checksums (draft-ietf-spring-srv6-srh-compression) Hi, in my view, this draft doesn't *change* the text of 8200. It provides information on how to determine the DA when C-SIDs are used. -m Le 2024-04-03 à 23:28, Joel Halpern a écrit : > > CAUTION:This is an external email. Please be very careful when > clicking links or opening attachments. See the URL nok.it/ext for > additional information. > > The concern with regard to the text that the chairs are asking about > is not about intermediate nodes verifying the checksum. The text does > not talk aabout that, so we are not asking about that. > > But, the text in 8200 specifies how the originating node is to compute > the upper layer checksum. It doesn't say "do whatever you need to do > to make the destination come out right". It provides specific > instructions. Yes, it is understandable that those instructions do > not cover the compressed container cases. Which is why the > compression document specifies changes to those procedures. > > Thus, we need to ask 6man how they want to handle the change in the > instructions in 8200. > > the question we are asking SPRING is whether there is any > clarification people want to the text in the compression draft before > we send the question over to 6man. > > Yours, > > Joel > > On 4/3/2024 5:15 PM, Robert Raszuk wrote: >> Hi Joel, >> >> My interpretation of text from RFC8200 is that it allows discrepancy >> between the header and the upper layer checksum as long as final >> packet's destination sees the correct one. >> >> The last condition is met. >> >> So I see no issue. >> >> Sure RFC8200 does not talk about SRH nor cSIDs, but provides a hint >> on how to handle such future situations. >> >> With that being said I would like to still understand what real >> problem are we hitting here ... >> >> Kind regards, >> Robert >> >> On Wed, Apr 3, 2024 at 11:09 PM Joel Halpern <j...@joelhalpern.com> wrote: >> >> There are two cases covered in section 6.5 of the compression >> draft that appear to be at variance with secton 8.1 of RFC 8200. >> >> First, if the final destination in the routing header is a >> compressed container, then the ultimate destination address will >> not be the same as the final destination shown in the routing header. >> >> Second, if a uSID container is used as the destination address and >> no SRH is present, then in addition to the above problem there is >> no routing header to trigger the behavior described. >> >> Yours, >> >> Joel >> >> On 4/3/2024 4:22 PM, Robert Raszuk wrote: >>> Hi Alvaro, >>> >>> 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._ >>> >>> >>> I would like you to clarify the above statement - specifically of >>> the last sentence. >>> >>> Reason for this that after looking at both drafts I find section >>> 6.5 of the subject draft to be exactly in line with RFC8200 >>> section 8.1 especially with the paragraf which says: >>> >>> * If the IPv6 packet contains a Routing header, the >>> Destination >>> Address used in the pseudo-header is that of the final >>> destination. At the originating node, that address will >>> be in >>> the last element of the Routing header; at the recipient(s), >>> that address will be in the Destination Address field of the >>> IPv6 header. >>> * >>> >>> So before we dive into solutions (as Andrew has already provided >>> a few of) I think we should first agree on what precise problem >>> are we solving here ? >>> >>> Many thx, >>> Robert >>> >>> PS. As a side note I spoke with my hardware folks - just to check >>> if validation of upper-layer checksum is even an option for >>> transit nodes. The answer is NO as most data plane hardware can >>> read at most 256 bytes of packets. So unless there is some >>> specialized hardware processing up to 9K packets in hardware at >>> line rates this entire discussion about checksum violations, >>> fears of firing appeals is just smoke. >>> > > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring _______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring _______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
