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

[Joel Halpern <[e-mail]>]

<No Hats>

A uSID container is a list of destination.  It can  e specified as a DA 
without an SRH.  If I had a sysstme which was using that, and I was 
having trouble, trying a ping with the uSID container as the DA would 
seem to be an obvious diagnostic.   If we want to tell folks they cabn't 
do that, it seems like we need to say so. The existing text Francois 
points to seems too vague to expect folks to understand the limitation 
(assuming there is such a limitation.)

Yours,

Joel

On 4/4/2024 2:47 PM, Martin Vigoureux (Nokia) wrote:
> Joel,
>
> do you mean specifying the sid *list* as the DA?
>
> -m
>
> Le 2024-04-04 à 19:26, jmh.direct 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.
>>
>> So you can't ping a uSID list by just specifying the uSID as the DA?
>> Yours,
>> Joel
>>
>>
>>
>> Sent via the Samsung Galaxy S20 FE 5G, an AT&T 5G smartphone
>>
>>
>> -------- Original message --------
>> From: Francois Clad <[e-mail]>
>> Date: 4/4/24 1:10 PM (GMT-05:00)
>> To: Joel Halpern <[e-mail]>
>> Cc: SPRING WG List <[e-mail]>, Robert Raszuk 
>> <[e-mail]>, Andrew Alston - IETF <[e-mail]>
>> Subject: Re: [spring] C-SIDs and upper layer checksums 
>> (draft-ietf-spring-srv6-srh-compression)
>>
>> Hi Joel,
>>
>> One can ping a SID of this document without a segment list by simply 
>> running the ping command with that SID as an argument (2nd paragraph 
>> of section 9.1).
>>
>> To ping a SID of this document via a SID list, one needs to configure 
>> the originator node to impose that SID list, like any other SRv6 SID 
>> list.
>>
>> Hope this helps.
>>
>> Cheers,
>> Francois
>>
>>
>> On 4 Apr 2024 at 16:29:11, Joel Halpern <[e-mail] 
>> <mailto:[e-mail]>> wrote:
>>>
>>> <No Hats>
>>>
>>> It seems that the text you quote requires that the ping code or 
>>> kernel code know that the user has specified a uSID for the ping 
>>> DA.   Maybe I am missing something, but it is not obvious to me how 
>>> that would be achieved?  And does seem to imply that an unmodified 
>>> ping will get incompatible and unexpected results?
>>>
>>> Yours,
>>>
>>> Joel
>>>
>>> On 4/4/2024 10:23 AM, Francois Clad wrote:
>>>> Hi Joel,
>>>>
>>>> The ping behavior is described in section 9.1 of the draft 
>>>> (https://www.ietf.org/archive/id/draft-ietf-spring-srv6-srh-compression-14.html#section-9.1).
>>>>
>>>> Specifically,
>>>> "When pinging a SID of this document via a segment list, the SR 
>>>> source node MUST construct the IPv6 packet as described in Section 
>>>> 6 and compute the ICMPv6 checksum as described in Section 6.5."
>>>>
>>>> Please let me know if anything in this text is not clear.
>>>>
>>>> Thanks,
>>>> Francois
>>>>
>>>> On 4 Apr 2024 at 16:10:11, Joel Halpern 
>>>> <[e-mail]> wrote:
>>>>>
>>>>> <No Hat>
>>>>>
>>>>> Does this mean that if I have a source and destiantion host inside 
>>>>> an SRv6 domain, and I am trying to verify a uSID path between 
>>>>> them, so I issue the command ping <usUD-DA>, it will fail?  Given 
>>>>> that we have documents describing the use of ping and traceroute 
>>>>> with SRv6, shouldn't the comrpession document say someething about 
>>>>> this?
>>>>>
>>>>> Your,s
>>>>>
>>>>> Joel
>>>>>
>>>>> On 4/4/2024 9:59 AM, Francois Clad wrote:
>>>>>> Hi Andrew,
>>>>>>
>>>>>> The originator (TX Linux box in your case) acting as an SR source 
>>>>>> node for C-SID must follow the entire Section 6 of 
>>>>>> draft-ietf-spring-srv6-srh-compression, including section 6.5 
>>>>>> about the checksum calculation. One cannot expect it to work if 
>>>>>> it only implements half of it.
>>>>>>
>>>>>> On the receive side, there is nothing special to do. The DA in 
>>>>>> the received IPv6 header is the one that was used for the 
>>>>>> checksum calculation.
>>>>>>
>>>>>> I do not see anything broken.
>>>>>>
>>>>>> Cheers,
>>>>>> Francois
>>>>>>
>>>>>> On 4 Apr 2024 at 15:32:12, Andrew Alston - IETF 
>>>>>> <[e-mail]> wrote:
>>>>>>>
>>>>>>> So in investgiating this further, there is a further problem.
>>>>>>>
>>>>>>> I’ve checked on 4 different linux boxes with 4 different network 
>>>>>>> cards.
>>>>>>>
>>>>>>> Linux by default offloads TX checksumming on a lot of network 
>>>>>>> cards.  If you originate a packet with a microsid and no SRH – 
>>>>>>> and the linux box offloads the checksum generation – the 
>>>>>>> checksum generated by the NIC will be incorrect – and when the 
>>>>>>> packet arrives at the end host – if that end host is running RX 
>>>>>>> checksumming – the checksum will fail and the packet will be 
>>>>>>> dropped.
>>>>>>>
>>>>>>> If you disable TX checksumming – the kernel will have no way to 
>>>>>>> tell if the packet is an Ipv6 or a microsid packet, it will 
>>>>>>> therefore use the DA – and generate an incorrect checksum.  
>>>>>>> Again – if RX checksumming is enabled on the receiving end point 
>>>>>>> – the packet will get dropped.
>>>>>>>
>>>>>>> Effectively this does NOT just affect middle boxes – it effects 
>>>>>>> anything generating a packet directed to a microsid that either 
>>>>>>> offloads the tx to hardware (whichi will have no clue this is a 
>>>>>>> microsid) or in the alternative is generating tx checksums 
>>>>>>> itself via kernel mechanisms that will treat these packets as 
>>>>>>> standard Ipv6 packets.
>>>>>>>
>>>>>>> This is broken – severely broken.
>>>>>>>
>>>>>>> Andrew
>>>>>>>
>>>>>>> *
>>>>>>> *
>>>>>>>
>>>>>>> *
>>>>>>>
>>>>>>> Internal All Employees
>>>>>>>
>>>>>>> From: *spring <[e-mail]> on behalf of Francois 
>>>>>>> Clad <[e-mail]>
>>>>>>> *Date: *Thursday, 4 April 2024 at 14:49
>>>>>>> *To: *Joel Halpern <[e-mail]>
>>>>>>> *Cc: *SPRING WG List <[e-mail]>, Robert Raszuk 
>>>>>>> <[e-mail]>
>>>>>>> *Subject: *Re: [spring] C-SIDs and upper layer checksums 
>>>>>>> (draft-ietf-spring-srv6-srh-compression)
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Some people who received this message don't often get email from 
>>>>>>> [e-mail]. Learn why this is important 
>>>>>>> <https://aka.ms/LearnAboutSenderIdentification>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> CAUTION: This email has originated from a free email service 
>>>>>>> commonly used for personal email services, please be guided 
>>>>>>> accordingly especially if this email is asking to click links or 
>>>>>>> share information.
>>>>>>>
>>>>>>> Hi all,
>>>>>>>
>>>>>>> Section 6.5 of draft-ietf-spring-srv6-srh-compression specifies 
>>>>>>> how an SR source node originating a packet with an upper layer 
>>>>>>> checksum determines the Destination Address for use in the IPv6 
>>>>>>> pseudo-header.
>>>>>>>
>>>>>>> As a co-author, I’d say that the current text of 6.5 is good.
>>>>>>>
>>>>>>> This text is aligned with RFC 8200. It only indicates how the 
>>>>>>> text in Section 8.1 of RFC 8200 applies to the SIDs of 
>>>>>>> draft-ietf-spring-srv6-srh-compression. This is necessary since 
>>>>>>> RFC 8200 does not specify the format nor behavior of any source 
>>>>>>> routing scheme.
>>>>>>>
>>>>>>> Thanks,
>>>>>>>
>>>>>>> Francois
>>>>>>>
>>>>>>> On 4 Apr 2024 at 00:10:55, Joel Halpern 
>>>>>>> <[e-mail]> wrote:
>>>>>>>
>>>>>>>     I can not speak to the "norm" for other working groups.  The
>>>>>>>     SPRING charter is very specific about what we have to do if we
>>>>>>>     want to change an underlying protocol.  We have to go back to
>>>>>>>     the WG which owns that protocol.
>>>>>>>
>>>>>>>     6man gets to decide if the change is acceptable, and if it is
>>>>>>>     acceptable how it is to be represented.  SPRINGs job is to
>>>>>>>     make sure we are asking the question we intend.
>>>>>>>
>>>>>>>     Yours,
>>>>>>>
>>>>>>>     Joel
>>>>>>>
>>>>>>>     On 4/3/2024 6:05 PM, Robert Raszuk wrote:
>>>>>>>
>>>>>>>         Ok Joel,
>>>>>>>
>>>>>>>         Thank you for this clarification.
>>>>>>>
>>>>>>>         To me the actual spirit of RFC8200 8.1 is to say that it
>>>>>>>         is ok to compute the checksum by the src such that it
>>>>>>>         comes out right at the final destination.
>>>>>>>
>>>>>>>         But I guess we can have different opinions about that.
>>>>>>>
>>>>>>>         But what I find specifically surprising here is that it is
>>>>>>>         a norm in IETF to have new specifications
>>>>>>>         defining protocol extensions and their behaviour and never
>>>>>>>         go back to the original protocol RFC to check if this is
>>>>>>>         ok or not. If that would not be a normal process I bet we
>>>>>>>         would still be using classful IPv4 routing all over the
>>>>>>>         place.
>>>>>>>
>>>>>>>         Regards,
>>>>>>>
>>>>>>>         Robert
>>>>>>>
>>>>>>>         On Wed, Apr 3, 2024 at 11:28 PM Joel Halpern
>>>>>>>         <[e-mail]> wrote:
>>>>>>>
>>>>>>>             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
>
> _______________________________________________
> spring mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/spring