Re: [spring] C-SIDs and upper layer checksums (draft-ietf-spring-srv6-srh-compression)
Robert Raszuk <robert@raszuk.net> Fri, 05 April 2024 14:42 UTC
Return-Path: <robert@raszuk.net>
X-Original-To: spring@ietfa.amsl.com
Delivered-To: spring@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90B85C14F693 for <spring@ietfa.amsl.com>; Fri, 5 Apr 2024 07:42:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.096
X-Spam-Level:
X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=raszuk.net
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X0Z3yB6KZuIt for <spring@ietfa.amsl.com>; Fri, 5 Apr 2024 07:41:58 -0700 (PDT)
Received: from mail-ed1-x52b.google.com (mail-ed1-x52b.google.com [IPv6:2a00:1450:4864:20::52b]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D22B9C14F5ED for <spring@ietf.org>; Fri, 5 Apr 2024 07:41:57 -0700 (PDT)
Received: by mail-ed1-x52b.google.com with SMTP id 4fb4d7f45d1cf-5684db9147dso2869918a12.2 for <spring@ietf.org>; Fri, 05 Apr 2024 07:41:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=raszuk.net; s=google; t=1712328115; x=1712932915; darn=ietf.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=eYqqDUmSnbJzybUyKRIy/5Cj3JmQgr65zIhyrE6k+dY=; b=WRqnpbxPkax7bdxJbc3cqosdEjovqNc+qLlVPCsxVBiGn4dR7hWqsdE497NxMxKWD5 1Ub3PBP56ZdOmZjfZGZ6ZnYtKFbB1uBgYlwXMdi7eHzLhHrKAhgBVGmB3D7YRkQpoywG 01vM+uG2yRfl9ayQhdkYCb22Wgy/rDXe1otBz2RhOo8r33Unstw2VpJfrj9YwWKIeA7g PPBXV+sRQ0ZpNYbLAq0Xrid+TIS+il/kYO8TOdkF8ADCVf32NOLR45vHPSDks+IGfUTg cGxyPUUNve2yFAhACjUKZ2/LDvfMPcRTn9YNSI3l8p32iG1CK4D3JOLwXPWKymdgfY/+ GUPA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1712328115; x=1712932915; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=eYqqDUmSnbJzybUyKRIy/5Cj3JmQgr65zIhyrE6k+dY=; b=dpdvrzC/TfGsdpsPQ3SrlOWykAIrPkulWxWPAHHsHoEudUboIk/pKaZe8WAWmmLQHs utgXQHcGaA0M2UGGHWldAdE4Z70ai1GZx5wfLVPvQYOR7CTxG7gqPS/XibPS8kM5nt9d ct2x9j4qKjQLoSCeJVU2TAtBaH5K5yMq8PUM/rMZ2MOI3r5rQPgpzEn/ihomW/7LnYS2 Al1cd3CMRxF4Y7wHOzoqUCbv7kfP/7BOjxewDX33FOu9lz1yadTwVH9y002v9RwFTXF3 4iaE2vnBTV8jFTStIZ93biv4GzlYEcKDQ2H+nEw/jA+74XvdKoAyVgCAeZ/FQcjRo5CY mz2g==
X-Forwarded-Encrypted: i=1; AJvYcCXHPmw/uu8azhqt9XBFe3EUCBHhwQjyr4ZBEB8dJuqB24qKxNIEQLUegfIRH0ykoWgz67oGtdd/1LA27rvZ/Bc=
X-Gm-Message-State: AOJu0YxeuSN8Rf6UUd7Zs8JRL4GG1pxSzDoSfrdOL0IQBXH4l+O/lf3n o2Z4UixJuy0SSHDmlW95SyKds9pVYMGmuAuTjj7QrlzLOtf9crJq7CsNaILzrUTRHNV094XLmln J3duYc+1ZXpCWwUoDZ4XTqzI5VIR0VFqb3O9ajQ==
X-Google-Smtp-Source: AGHT+IENefBTQNaHRMD2+2xTOtCGQVs7LIXRaB5zdy8XYkccsmXiLnamc86JcIQcT0hSJHT0a5UTaHbB+x5rBPzZrlc=
X-Received: by 2002:a50:9fc1:0:b0:568:a9f3:b3fb with SMTP id c59-20020a509fc1000000b00568a9f3b3fbmr1269124edf.8.1712328115619; Fri, 05 Apr 2024 07:41:55 -0700 (PDT)
MIME-Version: 1.0
References: <4V9T74452Sz1nsk5@mailb2.tigertech.net> <548b1fbc-8106-40c0-aced-bc1f92bdf415@nokia.com> <c931f0af-8a98-4b61-bf19-44bffe29de7c@joelhalpern.com> <CAHT6gR_Ey4DGhyvZr_dfThPEe1SwFN++PfGFnJ=Edw91qv+S=A@mail.gmail.com> <ffdf030d-0988-4b39-b400-0e7744503d02@joelhalpern.com>
In-Reply-To: <ffdf030d-0988-4b39-b400-0e7744503d02@joelhalpern.com>
From: Robert Raszuk <robert@raszuk.net>
Date: Fri, 05 Apr 2024 16:41:44 +0200
Message-ID: <CAOj+MMFo9D=B0Nw4RB5a=-LFzjwddwjKxmsp04_E+cgQx2-t2Q@mail.gmail.com>
To: Joel Halpern <jmh@joelhalpern.com>
Cc: Francois Clad <fclad.ietf@gmail.com>, spring@ietf.org
Content-Type: multipart/alternative; boundary="000000000000122b3006155a7511"
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/bXOOGt1Jw_x4iqcf3ThL4lwdETs>
Subject: Re: [spring] C-SIDs and upper layer checksums (draft-ietf-spring-srv6-srh-compression)
X-BeenThere: spring@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" <spring.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/spring>, <mailto:spring-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/spring/>
List-Post: <mailto:spring@ietf.org>
List-Help: <mailto:spring-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/spring>, <mailto:spring-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 05 Apr 2024 14:42:02 -0000
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 <jmh@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 <jmh@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.ietf@gmail.com> >> >> > Date: 4/4/24 1:10 PM (GMT-05:00) >> >> > To: Joel Halpern <jmh.direct@joelhalpern.com> >> >> > Cc: SPRING WG List <spring@ietf.org>, Robert Raszuk >> >> > <robert@raszuk.net>, Andrew Alston - IETF <andrew-ietf@liquid.tech> >> <andrew-ietf@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.direct@joelhalpern.com >> >> > <mailto:jmh.direct@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.direct@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-ietf@liquid.tech> <andrew-ietf@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-bounces@ietf.org> on behalf of Francois >> >> >>>>>> Clad <fclad.ietf@gmail.com> >> >> >>>>>> *Date: *Thursday, 4 April 2024 at 14:49 >> >> >>>>>> *To: *Joel Halpern <jmh.direct@joelhalpern.com> >> >> >>>>>> *Cc: *SPRING WG List <spring@ietf.org>, Robert Raszuk >> >> >>>>>> <robert@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.ietf@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.direct@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 >> >> >>>>>> <jmh@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 >> >> >>>>>> <jmh@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] C-SIDs and upper layer checksums (draft-… Alvaro Retana
- Re: [spring] C-SIDs and upper layer checksums (dr… Alvaro Retana
- Re: [spring] C-SIDs and upper layer checksums (dr… Andrew Alston - IETF
- Re: [spring] C-SIDs and upper layer checksums (dr… Alvaro Retana
- Re: [spring] C-SIDs and upper layer checksums (dr… Andrew Alston - IETF
- Re: [spring] C-SIDs and upper layer checksums (dr… Alvaro Retana
- Re: [spring] C-SIDs and upper layer checksums (dr… Robert Raszuk
- Re: [spring] C-SIDs and upper layer checksums (dr… Joel Halpern
- Re: [spring] C-SIDs and upper layer checksums (dr… Robert Raszuk
- Re: [spring] C-SIDs and upper layer checksums (dr… Joel Halpern
- Re: [spring] C-SIDs and upper layer checksums (dr… Robert Raszuk
- Re: [spring] C-SIDs and upper layer checksums (dr… Joel Halpern
- Re: [spring] C-SIDs and upper layer checksums (dr… Francois Clad
- Re: [spring] C-SIDs and upper layer checksums (dr… Andrew Alston - IETF
- Re: [spring] C-SIDs and upper layer checksums (dr… Robert Raszuk
- Re: [spring] C-SIDs and upper layer checksums (dr… Andrew Alston - IETF
- Re: [spring] C-SIDs and upper layer checksums (dr… Francois Clad
- Re: [spring] C-SIDs and upper layer checksums (dr… Andrew Alston - IETF
- Re: [spring] C-SIDs and upper layer checksums (dr… Francois Clad
- Re: [spring] C-SIDs and upper layer checksums (dr… Andrew Alston - IETF
- Re: [spring] C-SIDs and upper layer checksums (dr… Andrew Alston - IETF
- Re: [spring] C-SIDs and upper layer checksums (dr… Joel Halpern
- Re: [spring] C-SIDs and upper layer checksums (dr… Francois Clad
- Re: [spring] C-SIDs and upper layer checksums (dr… jmh.direct
- Re: [spring] C-SIDs and upper layer checksums (dr… Andrew Alston - IETF
- Re: [spring] C-SIDs and upper layer checksums (dr… Cheng Li
- Re: [spring] C-SIDs and upper layer checksums (dr… Martin Vigoureux (Nokia)
- Re: [spring] C-SIDs and upper layer checksums (dr… Cheng Li
- Re: [spring] C-SIDs and upper layer checksums (dr… Joel Halpern
- Re: [spring] C-SIDs and upper layer checksums (dr… Antoine FRESSANCOURT
- Re: [spring] C-SIDs and upper layer checksums (dr… Martin Vigoureux (Nokia)
- Re: [spring] C-SIDs and upper layer checksums (dr… Tal Mizrahi
- Re: [spring] C-SIDs and upper layer checksums (dr… Francois Clad
- Re: [spring] C-SIDs and upper layer checksums (dr… Joel Halpern
- Re: [spring] C-SIDs and upper layer checksums (dr… Francois Clad
- Re: [spring] C-SIDs and upper layer checksums (dr… Francois Clad
- Re: [spring] C-SIDs and upper layer checksums (dr… Joel Halpern
- Re: [spring] C-SIDs and upper layer checksums (dr… Robert Raszuk
- Re: [spring] C-SIDs and upper layer checksums (dr… Joel Halpern
- Re: [spring] C-SIDs and upper layer checksums (dr… Ketan Talaulikar
- Re: [spring] C-SIDs and upper layer checksums (dr… Boris Hassanov
- Re: [spring] C-SIDs and upper layer checksums (dr… Joel Halpern
- Re: [spring] C-SIDs and upper layer checksums (dr… Ketan Talaulikar
- Re: [spring] [**EXTERNAL**] Re: C-SIDs and upper … Shah, Himanshu
- Re: [spring] C-SIDs and upper layer checksums (dr… Joel Halpern
- Re: [spring] [**EXTERNAL**] Re: C-SIDs and upper … Robert Raszuk
- Re: [spring] C-SIDs and upper layer checksums (dr… Francois Clad
- Re: [spring] C-SIDs and upper layer checksums (dr… liu.yao71
- Re: [spring] [**EXTERNAL**] Re: C-SIDs and upper … Mark Smith
- Re: [spring] C-SIDs and upper layer checksums (dr… Robert Raszuk
- Re: [spring] C-SIDs and upper layer checksums (dr… Robert Raszuk
- Re: [spring] C-SIDs and upper layer checksums (dr… linchangwang
- Re: [spring] C-SIDs and upper layer checksums (dr… liu.yao71
- Re: [spring] C-SIDs and upper layer checksums (dr… 梁艳荣