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

[Joel Halpern <[e-mail]>]

Thanks for catching the typo.

I am trying to understand what the text in the draft means about 
originating hosts sending SRv6 packets with (direct or indirectly 
specified) compressed containers.

Yours,

Joel

On 4/5/2024 10:41 AM, Robert Raszuk wrote:
> Joel,
>
> > a host in an SRv6 domain must not have explicitly configured uSID 
> containers
>
> I presume you wanted to say instead "not have" - "now have"
>
> And if so I think it applies only to segment endpoints and only such 
> segment endpoint must know his own uSID isn't it ?
>
> Is there any reason to that such segment endpoint should know uSIDs in 
> entire container/carrier ?
>
> Thx,
> R.
>
>
>
>
> On Fri, Apr 5, 2024 at 4:26 PM Joel Halpern <[e-mail]> wrote:
>
>     <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]> <mailto:[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]>
>>>>     <mailto:[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
>     _______________________________________________
>     spring mailing list
>     [e-mail]
>     https://www.ietf.org/mailman/listinfo/spring
>