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 <j...@joelhalpern.com> 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 <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> >> <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> <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 >
_______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
