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 <j...@joelhalpern.com> 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 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 <fclad.i...@gmail.com> > > > Date: 4/4/24 1:10 PM (GMT-05:00) > > > To: Joel Halpern <jmh.dir...@joelhalpern.com> > > > Cc: SPRING WG List <spring@ietf.org>, Robert Raszuk > > > <rob...@raszuk.net>, Andrew Alston - IETF <andrew-i...@liquid.tech> > > > 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 <jmh.dir...@joelhalpern.com > > > <mailto:jmh.dir...@joelhalpern.com>> 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 > > >>> <jmh.dir...@joelhalpern.com> 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 > > >>>>> <andrew-i...@liquid.tech> 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 <spring-boun...@ietf.org> on behalf of Francois > > >>>>>> Clad <fclad.i...@gmail.com> > > >>>>>> *Date: *Thursday, 4 April 2024 at 14:49 > > >>>>>> *To: *Joel Halpern <jmh.dir...@joelhalpern.com> > > >>>>>> *Cc: *SPRING WG List <spring@ietf.org>, Robert Raszuk > > >>>>>> <rob...@raszuk.net> > > >>>>>> *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 > > >>>>>> fclad.i...@gmail.com. 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 > > >>>>>> <jmh.dir...@joelhalpern.com> 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 > > >>>>>> <j...@joelhalpern.com> 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 > > >>>>>> <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 > > > _______________________________________________ > 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
