Re: [spring] C-SIDs and upper layer checksums (draft-ietf-spring-srv6-srh-compression)
"Martin Vigoureux (Nokia)" <martin.vigoureux@nokia.com> Thu, 04 April 2024 18:51 UTC
Return-Path: <martin.vigoureux@nokia.com>
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 9DD7BC14F6E9 for <spring@ietfa.amsl.com>; Thu, 4 Apr 2024 11:51:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.177
X-Spam-Level:
X-Spam-Status: No, score=-2.177 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.08, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_NONE=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=nokia.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 1MkeYQLYS_8A for <spring@ietfa.amsl.com>; Thu, 4 Apr 2024 11:50:58 -0700 (PDT)
Received: from EUR02-VI1-obe.outbound.protection.outlook.com (mail-vi1eur02on2138.outbound.protection.outlook.com [40.107.241.138]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 858F8C151552 for <spring@ietf.org>; Thu, 4 Apr 2024 11:50:58 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=K1QGw+3IhAK6wL/xi4fI5BWcKAfMQnqcbU6ZjOEStaqTXdDg5/SLoyqGmiywm6nL9CaSTgbN1+7EVFEHT9nGfvT/DKG9oIWfcTzNqTChkV+RkVf5SZcJyQ1QE5eLLC6C+8yjBEXbAn38kI9elfYHz61OdDCqJ4wjht0ELBy2r/+RgXuitUq3puSokfsCrNqktv83lxz4QvjYxbiRH+MBGBOMyzNDcM+BwIY32SOCThm8+J1oheDXeGn7qtxLlhu9y72LkMCjPeOlZlWKL2603ENkLrRKSS/k01fHSx30yKLJoRKGH8CEN7LMW/QJcAxZ3B+97AR5YOhIs8ZR8KFsBQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=ZJ/6HkHJLBafSKzXXIh/3Mbk7AQBWyX6stkTxfEbj1M=; b=XTMpvSO59b6f83YVBYGsxN1WihebNnk4p3DL8p7uLn1WcjJvew0dEDgVGq7LvR8dUR/Iar/pg6lyQP8EQAAuj6bN9BHEYKVNzANVithe7BNZ3Mjmd+pDM2Qq8u9rZPwXdGiWibgCjUNHm8dmEdIdNoh9WgIGday1f8lWanwv07cWJh/LqwEv7cC22WwFV6gBLPQHCMuhFtaBsPRPYNVP250rdAg+zAcmXt4OvQXwZHXOpQePY4eegLDt47A4uOQeF6Al4wmFDF6aqGB4rsHf4fpTCyhghWmJnOhoEb2hbyeh6IPpKyhWINKWcgoPf5Q6/HiAWiTMrxhn5WWSlthwfw==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=nokia.com; dmarc=pass action=none header.from=nokia.com; dkim=pass header.d=nokia.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ZJ/6HkHJLBafSKzXXIh/3Mbk7AQBWyX6stkTxfEbj1M=; b=VyemIyUrJkPMJ7QWFFGP60Qc3IkYtmMyXUZdo/BQ2vIfF+/X3qnXnyhHUUPmE2R7SWkZNbVCEyyt+FxIuQ61AZFdUK9TeF9ReaoT5tFqHqgvU+Raji4hbgFrKDvxIR16q010yd1U+s1WftlfzGKqY/FbwBkDzMJJ0wDmYulgEg4mX5FLo1NQV6IQBc6B+6hzaTCbpvQjbtHwn2ZcOKZDkeKomy2DIiigRONCDy3Mbs+Ihkuo6IChRlfv9jCI407QYxlqgBo4t43IoTXZoiuEULgyk0OWOI3xG9cyrAUvWH8RgVk7gZ/vHws1pUqiQRAOh7Pc04Vd8bIm0m/LqQie5A==
Received: from AM6PR07MB5560.eurprd07.prod.outlook.com (2603:10a6:20b:6f::22) by AM8PR07MB7442.eurprd07.prod.outlook.com (2603:10a6:20b:234::7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7409.46; Thu, 4 Apr 2024 18:50:55 +0000
Received: from AM6PR07MB5560.eurprd07.prod.outlook.com ([fe80::4bba:985b:ad:55e8]) by AM6PR07MB5560.eurprd07.prod.outlook.com ([fe80::4bba:985b:ad:55e8%3]) with mapi id 15.20.7409.042; Thu, 4 Apr 2024 18:50:55 +0000
Message-ID: <a038845c-5a6e-4466-81f1-924df32e2ec9@nokia.com>
Date: Thu, 04 Apr 2024 20:50:53 +0200
User-Agent: Mozilla Thunderbird
Content-Language: en-GB
References: <CAMMESsyCYJwWP48=a9RWx3n8txS1eR4VLnUeE++VEdHKFeKOjw@mail.gmail.com> <CAOj+MMH9-F0nWG6zDZXxAGOQ7T8T9bUn74f4o=Fh2p0zah86Gg@mail.gmail.com> <e50b6a1b-08ae-4c8c-b3f0-0900fe8a9158@joelhalpern.com> <CAOj+MME5yL2S9Y8woVhLpkx8Xjq8g1+Ngw0RjH7o5u82p-38yg@mail.gmail.com> <71b6f07e-08d6-40a0-9436-e4acebf96c3b@joelhalpern.com>
From: "Martin Vigoureux (Nokia)" <martin.vigoureux@nokia.com>
To: "spring@ietf.org" <spring@ietf.org>
In-Reply-To: <71b6f07e-08d6-40a0-9436-e4acebf96c3b@joelhalpern.com>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
X-ClientProxiedBy: PA7P264CA0024.FRAP264.PROD.OUTLOOK.COM (2603:10a6:102:2df::8) To AM6PR07MB5560.eurprd07.prod.outlook.com (2603:10a6:20b:6f::22)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: AM6PR07MB5560:EE_|AM8PR07MB7442:EE_
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info: jPibxhiq8qubxqMIagvq+QtQ5M0/DHReyZSYjOn3WhLCFJuy3EpasmXToA7F7ZCcLhjrgDE+oqSRnB+TAB9JdvWvhZQ71dxWgWffiTGeVoOqq1xHIQLA6nT1K+Bp183t0mvXeqkwjfZuQ7bf9u1F8q+JHC73bGHCskeQCmyrFPXEVaOxXlMoZss2VaKdhKtO2c37wbhYHmCKMrEyDk5a5wIu+vwrha35l67WkM8F3vgOpa+331Ep5sRA9/KVpIJK00u1osvoLmNzjpu9IESJ6KifMPY1hw6w3DKgOjAuNLVJ+tP69g0JertN1oJlLP2EGxN3Vo2LVN+PeWRywUAjkAvNZu0UQinTWWON30S8AGLnd+4RhFi+k4RGdpaawE/8tnoNab61C+OGIUtI9zKlsifqk3kNImV78U2YNmTISPYtk/N2YjaDB+g+0gciULMy4PJKGcYb4BO6qGBDXG7WHumYnM53bHsiIANfzo45P0gyXEqjQ992DfwWWVKzF/B8KQwCMFQDKDlmgjncc0KIlU95lZkuKBUhlO7d660WR8FVK3BkDRo45XnhoLLD/gKgphGOxFzj7K97LCRateKlm3B9zxx9b5K567d1b/wdGm6SeHhML2s713Xa+3IJHUYU
X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM6PR07MB5560.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230031)(366007)(376005)(1800799015); DIR:OUT; SFP:1102;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: B9YogfTCf08wJr6s/q2NSTSKjbwZ/30BzbORJZLU/Z6oB3esui458L3+rrpJtPS+3ate69gZJK94RSJyCoPQLk47WVxeKq6VjgWcQF8z73o0XFbFSsTqUYl8+Okov5Fh7e1vkI09C4YEzIABJDjmAwlm7e35bFH9dO92fV9kE+IazqNe0pLrKO5fSXERAEZJ/ozfolcYuINduJfUQLbl1OPqUgARexe5gOxEHL/k6+guTZrH6BQx4nULmR+N3n8IsxOYDGhp2pqMHgCrkQYZvSuPklxLRJyTtdIMKHO6Z9MEcflVIXGrYqvFBJpCwnn4vvEKcKvxDJq5aGctbG2dAokQf3CsTfqiVf5bIR2bYr47n+tyZjbwynvbM+sFfsY9sM8b2VEDB0I9ynw2s8+DoL/yw/tHzF9AZSl7GDcdOaxcUT+pVZGvipTtDq3STCOK7G37DBaDTWWiI13SDsyBq/a23ZphHN6Iq8kzH0nWZQiDT2jSeDf0gWcISJPz1vgpRb/S+UV5H9Xegz0Tw84S1F4Ac8k39yqwaKXoyyMMVhowQV4NhFKhGO0dAdlzMsqVJwygSkRcKvkdIDGmKk/c1qf5QyRg8FahBL/AmFwOxDs3KisQ+MRIG4Lfch0Q1E2YOF/8equ6OiIgSrs2mJVKIXOnQs8qbmMlT/o4zp24RwoZT7JBMt+5turxBJcbXzwfBQ2qgoIQOWZfosoJoELP9oNonjs67yEoaWky6gFXIsArCl8FFZzPphUJDS2O5XjM9B0PpKTxGpJpy09CjDZskHLa0fUWgQrI+td7grMFexqDRqM9DuQwPjguIZL8PufkaRCZgFF5bL3ENSujKYuFSphKs3TFQcype1/KaOl5UVpUkw5Uot71uGoJIy8C8Z9LljCpqwEpX3FdLUqMs5FCwY2Q+I9ZM+A+ZhZgLCphDpsEWdANIxQsBOyATK0HxSY8nbXck0Ox1my1TS8I7Wr5I1N17ncC2N+QvOVaaamYRFC+Xw9iJ0PFIJdm1rZiApjThzc+pakA/5wRcmxnAvwltk0N/29vXbtxYSOM0tE8FaCf3AATOK1O+ze2JBFe4penIvCMij2n8k1IDYlyH0J87M0BxO2fI6Kriioje9WW7fW5tVqFa+tmF2IgzsNKUKF3aOiCNU2A4kMqmVTk1jaLCPbT1jzZr/aLGt7pvuiIM1Irz+iKOfYGSDZxg/xxl6XmRMJG7uBZMIJ2rTBqJeX+3NAYHMYmyJDtPPXkGdFhv58k0b0FkQtW/INnIU8yKUY0nXobKsei8mKWciCsNVcm02argBQyx+eZH659+uRl94rGDW5tCzMaZuUtV0swTs8nthplJUQiL+VlAsUWoWYWW6N1RPkfSWJampo1pkBfkAluq+dlwl0bFlhXnNEOAkxuAxBQYZ18Cp5nX7pfx/mChIyoXKq9DkmN97M4ydeT6mueKsHSN0zh8ORi1bvz5dy+mVeKkdOx56AmGtwzQ53OQCHQoi9v57N6GjxKE0QdkU3OPiLNYPrh22wMcMyxVVROmLrH/EESLfAvKJRfvgXqLTeWhauVRoSDZpew8GKhPh1CdYpAyyRBohfFnNA8b5OYxLSOqvtZK0mov5oAwCjcVtNTvceEbmyUr4IzscPo2nuKr7Qn8VPnMLwj05DLTZtcB1SK0IrZlKMyCdjZ8iyZHg==
X-OriginatorOrg: nokia.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 9a1df4fd-1dfd-4f5f-7b6f-08dc54d828a0
X-MS-Exchange-CrossTenant-AuthSource: AM6PR07MB5560.eurprd07.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 04 Apr 2024 18:50:55.2206 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 5d471751-9675-428d-917b-70f44f9630b0
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: uITZ9NSU4LG9TffEL1PUgfTKTYheFgifwWIoxeLjRsBNCqwBBDq2bIlKvVfTxoEKLOEoCsfLM8yUI6L2zT9R3KOI7nRY/mdErHYIFTBj+bY=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM8PR07MB7442
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/YbIiySUxkWK1vRc-07Odz7bZPEo>
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: Thu, 04 Apr 2024 18:51:02 -0000
Hi, in my view, this draft doesn't *change* the text of 8200. It provides information on how to determine the DA when C-SIDs are used. -m Le 2024-04-03 à 23:28, Joel Halpern 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. > > 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] 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… 梁艳荣