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

[Joel Halpern <[e-mail]>]

<No Hats.>

I think I understand your description.  At base, I think you are arguing 
that a compresssed container should be understood to be a representation 
of a segment list.  As a corollary of that, you are saying that the text 
in 9.1 means that a host in an SRv6 domain must not have explicitly 
configured uSID containers as destination addresses (either in config 
files, in manually entered destinations, or from DNS resolution>)  And 
that 9.1 is sufficiently clear that users or admins will not be 
surprised by failures?

Yours,

Joel

On 4/5/2024 4:02 AM, Francois Clad wrote:
> Hi Joel,
>
> The current text of section 9.1 says:
>
> "When pinging a SID of this document without a segment list, the SR 
> source node places the SID in the destination address of the ICMPv6 
> echo request and MUST set the Argument of the SID to 0. [...]"
>
> "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.”
>
> It seems to me that the two cases are explicitly spelled out.
>
> If I understand correctly, the system that you are referring to is 
> steering traffic onto a segment list. Diagnostic packets should thus 
> be handled in the same way (2nd case above). From a user perspective, 
> the diagnostic tools (e.g., ping) are used with a compressed SRv6 
> SID-list in the same that they are used with any other SRv6 SID-list.
>
> Cheers,
> Francois
>
> On 4 Apr 2024 at 23:17:53, Joel Halpern <[e-mail]> wrote:
>> <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 
>>> <http://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
>>
>> _______________________________________________
>> spring mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/spring