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

[Cheng Li <[e-mail]>]

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 <[e-mail]> On Behalf Of Martin Vigoureux (Nokia)
Sent: Thursday, April 4, 2024 8:51 PM
To: [e-mail]
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 <[e-mail]> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/spring

_______________________________________________
spring mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/spring