From aretana.ietf@gmail.com Mon Mar 25 11:17:18 2024 Return-Path: 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 DDA88C151097 for ; Mon, 25 Mar 2024 11:17:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.107 X-Spam-Level: X-Spam-Status: No, score=-2.107 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 L3b-rrYTjpdE for ; Mon, 25 Mar 2024 11:17:18 -0700 (PDT) Received: from mail-pf1-x42a.google.com (mail-pf1-x42a.google.com [IPv6:2607:f8b0:4864:20::42a]) (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 618D9C151095 for ; Mon, 25 Mar 2024 11:17:18 -0700 (PDT) Received: by mail-pf1-x42a.google.com with SMTP id d2e1a72fcca58-6ea7f2d093aso2930506b3a.3 for ; Mon, 25 Mar 2024 11:17:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1711390637; x=1711995437; darn=ietf.org; h=cc:to:subject:message-id:date:mime-version:references:in-reply-to :from:from:to:cc:subject:date:message-id:reply-to; bh=QveQj6fj4ELHIB+KJSG5NaYvrbJdK49qbDIUCukfJgw=; b=aDL5AXLVXYJe9nYTm3k3ZlfbkPGmjmFP9ZaHnh1x7oT2tJ027aJTkdb9Wo/WkqPhND cFGLMb0/naByoeRcar5s9Y3YfDy8PkqhCyQXmUsDHwqMWg8pwvwd1weW6eB+kNMH8xoB luxr6I1BM3qPWo/omb7l3oYKSTih5r60GUzdsFQ5/kIY8Ca87Ufbj9VjT+XCeDopyh8M cqXzWfeWk87++n/P9Bem1tCCHFBrtnMWW3qnsesDolHdvSryrjc0iN/eMs3bp45YyPtm qQYJ+GZSJfmpSkwZN/HNTHG8h048YSWCsLuYST07IEMv5UplOgFmiGgH5uoSvIhLaTGp neoA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1711390637; x=1711995437; h=cc:to:subject:message-id:date:mime-version:references:in-reply-to :from:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=QveQj6fj4ELHIB+KJSG5NaYvrbJdK49qbDIUCukfJgw=; b=DBo0zcWmyWLMvVkgP56BfAutV3EOgnFl1hZDUhJWkVMxICf9Ux2+hK20xONb1zjJPb BwVMFNQepxyLu6toslsA9wbNOtxOFIQ2v/lB3MsyPaaTCE0jGkyvD5Ul0C69HOWneUWy iR93QHFY4sziRo+vyo5c8XhqDlquYnvImJ6Mfh49i2Ipyj/IlN42gy1gtsae5eT3ddBB cHLGlxccQ+N3r8fFxCoWakPRuabIe15kkijm4nbsywwzxSQkMtHUlHuIcamNNgEPhy5e Wn178z+JI/r6kMfSbooZ9SgvhjXltCA/DLMYVnyfDjJwtm7HP4+5R7BZkdzrcIykRxtA CaPA== X-Gm-Message-State: AOJu0YzgiHN57ZJT4biHfc06hnUFO8AuIYyTl4WcoSWH2Ey/AexrzEXr 6cCtc72K988o7ByzyNXWjJ82aADfFCU2/OgqQ6NgZyqjA3aIPxXOJTiD2LNkdpdZqX7LI3Azj5C wrP5n2Mc0tjKLtm7eTvOy5ifVy5g= X-Google-Smtp-Source: AGHT+IHefSXZ7oA8KkJFPK9xKNfzwu7qcv6QsaCzwlsL6A+wl506rqbNsrMw2QnTNDZSxj6Bc2MQEv6G84p3sp4IaOU= X-Received: by 2002:a05:6a20:a81e:b0:19f:f059:c190 with SMTP id cb30-20020a056a20a81e00b0019ff059c190mr5710632pzb.24.1711390637587; Mon, 25 Mar 2024 11:17:17 -0700 (PDT) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Mon, 25 Mar 2024 11:17:15 -0700 From: Alvaro Retana In-Reply-To: <5e644c97-c316-4618-97ec-cb8ec8c097bd@joelhalpern.com> References: <5e644c97-c316-4618-97ec-cb8ec8c097bd@joelhalpern.com> MIME-Version: 1.0 Date: Mon, 25 Mar 2024 11:17:15 -0700 Message-ID: To: Robert Raszuk , Tom Herbert , Joel Halpern Cc: "spring@ietf.org" , Andrew Alston - IETF , Ron Bonica Content-Type: multipart/alternative; boundary="0000000000000683960614802f59" Archived-At: Subject: Re: [spring] Chair Review of draft-ietf-spring-srv6-srh-compression-11 X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.39 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Mar 2024 18:17:19 -0000 --0000000000000683960614802f59 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable FWIW, I agree with most of what Joel wrote. ;-) I see another path forward: Given that the issue is constrained to an SR domain, the draft could also point out the issues as operational/deployment considerations. Operators can then make an informed decision on whether they want to/can use C-SIDs without an SRH in their network. This path forward (or leaving it out of scope, as Joel suggests below) is something the spring WG can reach consensus on by itself (i.e., without needing to consult or agree with other WGs). Other solutions that may require updates to rfc8200 or, at least, consultation with 6man may also be possible. Those solutions should be discussed with both WGs. While this topic has been discussed before, I suggest at least using a different thread (with a better subject line). Thanks! Alvaro. On March 25, 2024 at 1:25:57=E2=80=AFPM, Joel Halpern (jmh@joelhalpern.com)= wrote: (Speaking technically as an individual, but noting that Alvaro and I are the responsible chairrs who will have to resolve any technical standards incompatibility. And I have not talked with Alvaro. So I may be putting my foot in my mouth.) As I understand it, the current view is that the compressed SID draft permists the case where a single container represents the SR policy. If that contianer is using uSID, and if the packet is going between two hosts in the SRv6 domain, then the SRH may be omitted and no encapsulation is needed. In that case, the sending host needs to compute the checksum based on what the receiver will see. It can do that, and there is text in the draft to do so. There are however two related issues. First, that direction for computing the upper layer checksum does not match what RFC 8200 says. If indeed that is a change to 8200, then that needs to be indicated somehow, and presumably approved by 6man. related to that, any intermediate node looking at the packet will see an apparently ordinary IPv6 packet whose upper layer checksum is incorrect. Tom Herbert, if I am understanding him correctly, is arguing that since the shifting of the uSID container is essentially a DA rewrite, the operation is sufficiently similar to NAT that one should expect the NAT device to correct the checksum (which is a different repair than the current compression draft calls for.) As far as I can tell, this intradomain, non-SRH, uSID case is intendedd to be supported by the compression solution. (Another option for the WG would be to declare that out of scope, but I have not seen evidence the WG wants that restriction.) If so, we need to reach agreement on what we expect of this case, and where it needs to be documented. Yours, Joel M. Halpern PS: Ron has suggested that a HbH optioncould be used to address the inconsistency. I do not yet understand the desired behavior there. --0000000000000683960614802f59 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =
FWIW, I agree = with most of what Joel wrote. ;-)

=
I see another path forward: Given that the issue = is constrained to an SR domain, the draft could also point out the issues a= s operational/deployment considerations. Operators can then make an informe= d decision on whether they want to/can use C-SIDs without an SRH in their n= etwork. This path forward (or leaving it out of scope, as Joel suggests bel= ow) is something the spring WG can reach consensus on by itself (i.e., with= out needing to consult or agree with other WGs).

Other solutions that may require u= pdates to rfc8200 or, at least, consultation with 6man may also be possible= . Those solutions should be discussed with both WGs. While this topic has b= een discussed before, I suggest at least using a different thread (with a b= etter subject line).

Thanks!

Alvaro.

On March 25, 2= 024 at 1:25:57=E2=80=AFPM, Joel Halpern (jmh@joelhalpern.com) wrote:

=20 =20 =20 =20

(Speaking technically as an individual, but noting that Alvaro and I are the responsible chairrs who will have to resolve any technical standards incompatibility.=C2=A0 And I have not talked with Alvaro.=C2=A0 So I may be putting my foot in my mouth.)

As I understand it, the current view is that the compressed SID draft permists the case where a single container represents the SR policy.=C2=A0 If that contianer is using uSID, and if the packet is going between two hosts in the SRv6 domain, then the SRH may be omitted and no encapsulation is needed.

In that case, the sending host needs to compute the checksum based on what the receiver will see.=C2=A0 It can do that, and there = is text in the draft to do so.=C2=A0 There are however two related issues.=C2=A0 First, that direction for computing the upper layer checksum does not match what RFC 8200 says.=C2=A0 If indeed that is a change to 8200, then that needs to be indicated somehow, and presumably approved by 6man.=C2=A0 related to that, any intermediate node looking at the packet will see an apparently ordinary IPv6 packet whose upper layer checksum is incorrect.=C2=A0

Tom Herbert, if I am understanding him correctly, is arguing that since the shifting of the uSID container is essentially=C2=A0 a DA rewrite, the operation is sufficiently similar to NAT that one should expect the NAT device to correct the checksum (which is a different repair than the current compression draft calls for.)

As far as I can tell, this intradomain, non-SRH, uSID case is intendedd to be supported by the compression solution.=C2=A0 (Another option for the WG would be to declare that out of scope, but I have not seen evidence the WG wants that restriction.)=C2=A0 If so, w= e need to reach agreement on what we expect of this case, and where it needs to be documented.

Yours,

Joel M. Halpern

PS: Ron has suggested that a HbH optioncould be used to address the inconsistency.=C2=A0 I do not yet understand the desired behavior there.

--0000000000000683960614802f59--