Re: [Detnet] on signaling the packet treatment vs. the flow/OAM

"Pascal Thubert (pthubert)" <pthubert@cisco.com> Fri, 29 July 2022 14:04 UTC

Return-Path: <pthubert@cisco.com>
X-Original-To: detnet@ietfa.amsl.com
Delivered-To: detnet@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78E71C14F72A for <detnet@ietfa.amsl.com>; Fri, 29 Jul 2022 07:04:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.604
X-Spam-Level:
X-Spam-Status: No, score=-9.604 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, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=gsS8zYWh; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=sEHGxjX1
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 QrQnH6BmEcoz for <detnet@ietfa.amsl.com>; Fri, 29 Jul 2022 07:04:46 -0700 (PDT)
Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 23DA7C13CCEA for <detnet@ietf.org>; Fri, 29 Jul 2022 07:03:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11726; q=dns/txt; s=iport; t=1659103435; x=1660313035; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=3xHgpbOufeVme+0j9bgKK0eOqv5Nmw6lRA0e4ATimuE=; b=gsS8zYWhkqHE5rL/YmCqorlTBlNsQ3zthaA9wDQ8+lbJdGYUdCDePtEu opM+2pBtD6XWeqx6tyjVu6P7LcCQ7BQHK9AWI6wF6Ri2ZnkPmKNp2ZnRA Whuu8yFtHtlNR8ggefJno2xZbjFVRlLFZPULLa6DZ2BZnL0B8wm3etw4z w=;
X-IPAS-Result: A0CeBACo5+NimIwNJK1aHgEBCxIMQIFEC4FSUn8CWjpFA4RLg0wDhS+FC4MCA4sgkC2BLBSBEQNUCwEBAQ0BASwIDgQBAYFSgm9FAhaEXQIlNAkOAQIEAQEBAQMCAwEBAQEBAQMBAQUBAQECAQcEFAEBAQEBAQEBCRQHBgwFDhAnhWgNCQUChjIBAQEBAgEBARARBA0MAQEjCQsBBAcEAgEIEQEDAQEDAiMDAgICHwYLFAECBggBAQQBDQUIGoJbAYJlAw0lAwEPm0IBgT8Cih96fzKBAYIIAQEGBASBTUGDAg0LgjgDBoERLIMZgxkDYE6BLIFqhCInHIFJRIEVQ4FmUTA+giBCAQECAYEoARIBIwUxAoMcN4IuhzKBG4M4gSyKFhw4A0UfRAQNWwIFCAoXEhAQAgQRGgsGAxY+CQIEDgNACA0DEQQDDxgJEggQBAYDMQwlCwMFDwwBBgMGBQMBAxsDFAMFJAcDHw8jDQ0EGAcdAwMFJQMCAhsHAgIDAgYVBgICTjkIBAgEKyMPBQIHLwUELwIeBAUGEQgCFgIGBAQEBBYCEAgCCCcXBxMzGQEFWRAJIRwOGgoGBQYTAyBtBUUPKDIBNTwrHxsKgRIqKxUDBAQDAgYaAwMiAhAuMQMVBikTEi0JKnUJAgMibQMDBCouAwkeBBwHCTEBG5RIgguBFBZ5SQcNBycIDgIgOyoTLQhkRpIig02pfUVsCoNRiyKHCIdvhhsVqGeWfCCNGINfkQAEhRACBAIEBQIOAQEGgWGBJXBwFTuCaFEZD44gCw4JgkmBB4UUhUp1AgE4AgYBCgEBAwmPBgEB
IronPort-PHdr: A9a23:Rh48PBcMuhQYTLI+vzOhVDm5lGM/tYqcDmcuAtIPh7FPd/Gl+JLvd Aza6O52hVDEFYPc97pfiuXQvqyhPA5I4ZuIvH0YNpAZURgDhJYamgU6C5uDDkv2ZPfhcy09G pFEU1lot3G2OERYAoDwfVrX93az9jUVXB74MFkdGw==
IronPort-Data: A9a23:Yg39naxp1XhAYC9LolJ6t+frxirEfRIJ4+MujC+fZmUNrF6WrkVRy 2oXDWzVOqqCZzP0f4snaIW+/E1S7J+Hz9RiSwQ+/FhgHilAwSbn6Xt1DatR0we6dJCroJdPt p1GAjX4BJloCCea/H9BC5C5xZVG/fngqoHUVaiVYUideSc+EH170U05yrZj6mJVqYHR7z2l6 IuaT/L3YDdJ6xYsWo7Dw/vewP/HlK2aVAIw5jTSV9gS1LPtvyV94KYkGE2EByCQrr+4sQKNb 72rILmRpgs19vq2Yz+vuu6TnkYiGtY+MeUS45Zbc/DKv/RMmsA9+qkZasJAcGVrtzyikflSx upIpYa7Zxh8a8UgmMxFO/VZOyh6OasD87jdLD3g98eS1EbBNXDrxp2CDmlvYtZeobgxWDoIr KBAQNwORkjra+ae2K67V+NhnNgLJ8jwN4RZsXZlpd3cJad/EcmcG/6Rvre02h8vj9JSPNf1W fNaVmp/by7kcwVdBXwYXcdWcOCA3ymjLGIwREiujaY6/27e0CRw3aTjdt3PdbSiacxLn0rej GbP9GesXkkWOdibjzGC91qgg+bVlmX6VZ4cUrqi+ZZCj0eeyW0WCQcNVkqTrvywi0r4UNVaQ 2QG+i0zsak78laiSPH9QhSnrX/CtRkZM+e8CMUz7AWLj6HT+QvcWS4PTyVKb5ots8peqSEWO kGhkPG3PWB2koGpQFmT35SakjaiIyM7MjpXDcMbdjct797mqYA1qxvASNd/DaK45uEZ/xmtm FhmSwBj2d0uYd43O7aTpgue2m3yznTdZktkuFuIDzvNAhZRPtbNWmC+1bTMAR+sxq6wSl2Mu hDocODBsbhXVvlheMFxKdjh8Zmg4/KDdTbbm1MqQN8q9i+m/DioeoU4DNBCyKVBb5ZsldzBO RK7VeZtCHl7ZivCgUhfONnZNijS5fK8fekJr9iNBja0XrB/dRWc4AZlblOK0mbmnSAEyP9ia M/AKp73VyxKWMyLKQZaoc9AgdfHIQhjlQvuqWzTlHxLLJLHPifOEOdZWLdwRrlhvfvsTPrpH yZ3bpvWlEo3vBzWaSjM+olbNkERMXU+HvjLRz9/KIa+zv5dMDh5UZf5mOp5E6Q8xvg9vrqYr xmVBx4DoHKi1CKvAVvRMBhLNuiwNauTWFpmZ0TAy37yhSh6CWtuhY9CH6YKkU4PrrQzk6YtE 6RfJa1twJ1nE1z6xtjUVrGlxKQKSfhhrVjm0/aNCNTnQ6Ndeg==
IronPort-HdrOrdr: A9a23:CIfCdKCHwlcJQNnlHegHsceALOsnbusQ8zAXPh9KJyC9I/b2qy nxppgmPEfP+UkssHFJo6HlBEDyewKjyXcT2/hfAV7CZnirhILMFuBfBOTZskXd86OVzJ8n6U 4NSdkdNDS0NykHsS+Y2nj3Lz9D+qj8zEnAv463pB0BLXAIV0gj1XYFNu/xKDwQeOAyP+tBKH Pq3Lsgm9PPQwVzUu2LQl0+G8TTrdzCk5zrJTQcAQQ81QWIhTS0rJbnDhmxxH4lInJy6IZn1V KAvx3y562lvf3+4ATbzXXv45Nfn8ak4sdfBfaLltMeJlzX+0aVjcVaKv6/VQIO0aSSAWUR4Z 3xStAbToNOAkbqDyOISN3Wqk/dOXgVmibfIBSj8AreSITCNUIH4ox69Npkmt+z0Tt7gDm6u5 g7hF5x/qAnfi/ojWDz4cPFWAptkVfxqX0+kfQLh3gaSocGbqRNxLZvt3+9Pa1wVR4S0rpXWN VGHYXZ/rJbYFmaZ3fWsi1mx8GtRG06GlODTlIZssKY3jBKlDQhpnFoifA3jzMF7tYwWpNE7+ PLPuBhk6xPVNYfaeZ4CP0aScW6B2TRSVbHMX6UI17gCKYbUki94aLf8fEw/qWnaZYIxJw9lN DIV05Zr3c7fwb0BciHzPRwg2bwqaWGLEPQI+1llu1EU+fHNcjW2AW4OSQTr/c=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.93,201,1654560000"; d="scan'208";a="918170333"
Received: from alln-core-7.cisco.com ([173.36.13.140]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 29 Jul 2022 14:03:53 +0000
Received: from mail.cisco.com (xfe-rtp-001.cisco.com [64.101.210.231]) by alln-core-7.cisco.com (8.15.2/8.15.2) with ESMTPS id 26TE3rI9005313 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=OK); Fri, 29 Jul 2022 14:03:53 GMT
Received: from xfe-rtp-001.cisco.com (64.101.210.231) by xfe-rtp-001.cisco.com (64.101.210.231) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.986.14; Fri, 29 Jul 2022 10:03:52 -0400
Received: from NAM10-MW2-obe.outbound.protection.outlook.com (64.101.32.56) by xfe-rtp-001.cisco.com (64.101.210.231) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.986.14 via Frontend Transport; Fri, 29 Jul 2022 10:03:52 -0400
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=mUgwVcYq6Tm9eIksFPgw5d3kLYM9R9giT3x+GNIAhSvfebUyDAUBkfHwtCH8dGQcKQdipHutoeUenxtgdQ8sB7zkwS60kFzj+KT4cYf/Qk41ju13X9I4F1+84pS+rqblczXC4TqsmjWHMzYgPikh5p/K8t42B6MjKGwzq4H7TEBbr2a4V5GR7+8g2gnN8XmF7tA+DQsKqIElNekzob+UBMb6fgq7WMzWnRU5q7j5tfS86qW5nfV97AziWTQE4/yDJ5xDYNcP9dNxF/MyvFYK9yOJ68pH1bJzpZ73vvTjNNpKctwRrmxfatU/Gk7UBItyJZXNRSw0zbZfZGoZ3kktJg==
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=3xHgpbOufeVme+0j9bgKK0eOqv5Nmw6lRA0e4ATimuE=; b=aBBQlC+iqLy2jyXp60icLbpgkjNy1SDn7IRBr+iewbZtvek43V/N78c7otZUv+CkagmEGxF3NYp0RIjpVphqmR6OFKpTYvxfuTG+IZQZbKuJEn+zmuhtd9HbhOG7GQ0OKE+ryMwCUmNaPLU9AOUB/g94xJDHtmm7Vz3dv27wIj44rBYdwh5Dt4wie3cpdkXHAa4okaiV1cONdaSXHRxP79j1uNGyRtk2SYLTfx8rL6fVDO0oVexEjbrvhj7w/PAw/cI6NCnIu1Q/ARvYJ7mTZF2PKg3RkwYaELEy2IdjyDoqwdFfVkUObTNObr43ksIp/rIZDFikgZW87o1PGYdDRg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=3xHgpbOufeVme+0j9bgKK0eOqv5Nmw6lRA0e4ATimuE=; b=sEHGxjX142kbDVXaXRe1clkXbWHuyE1S6NM9PJmTGBHtwtzK6kGwGsMYFLfCzE2+uy1eh3ocM8pVxteBAI8Eqr/FO/QO+THzoJifsLGMrtn8bKlnwmds4TZwDboV6VVNP8giZi6U+wyKM5k+HUwTbAW/0LnNSJH/soaLkFZoBpI=
Received: from CO1PR11MB4881.namprd11.prod.outlook.com (2603:10b6:303:91::20) by PH0PR11MB5610.namprd11.prod.outlook.com (2603:10b6:510:e9::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5482.11; Fri, 29 Jul 2022 14:03:51 +0000
Received: from CO1PR11MB4881.namprd11.prod.outlook.com ([fe80::ecc3:1b8d:4d31:ff3c]) by CO1PR11MB4881.namprd11.prod.outlook.com ([fe80::ecc3:1b8d:4d31:ff3c%3]) with mapi id 15.20.5482.012; Fri, 29 Jul 2022 14:03:50 +0000
From: "Pascal Thubert (pthubert)" <pthubert@cisco.com>
To: Tianran Zhou <zhoutianran@huawei.com>, Greg Mirsky <gregimirsky@gmail.com>
CC: "Black, David" <David.Black=40dell.com@dmarc.ietf.org>, "detnet@ietf.org" <detnet@ietf.org>, "Black, David" <David.Black@dell.com>
Thread-Topic: [Detnet] on signaling the packet treatment vs. the flow/OAM
Thread-Index: AdiiuN+AifH1GufmQaWO7tvTMHi/9gAA/19wAACuFFIAAT3rgAAIJBSAABCTE4A=
Date: Fri, 29 Jul 2022 14:03:24 +0000
Deferred-Delivery: Fri, 29 Jul 2022 14:02:32 +0000
Message-ID: <CO1PR11MB4881DE932DDE8716054B03F6D8999@CO1PR11MB4881.namprd11.prod.outlook.com>
References: <CO1PR11MB488192B11EF759264FB05614D8969@CO1PR11MB4881.namprd11.prod.outlook.com> <DM6PR19MB40422DD5B4BB7F0095AB87D583969@DM6PR19MB4042.namprd19.prod.outlook.com> <D7BF068C-3873-4A66-A39D-8FD8168C9C47@cisco.com> <CA+RyBmVXXqr_A5ch3W8ThAGS3UPvtC_M3j+Tdo5yTf=P27y1JA@mail.gmail.com> <fa5f417ba88641ccb9e7b5e3fc810eef@huawei.com>
In-Reply-To: <fa5f417ba88641ccb9e7b5e3fc810eef@huawei.com>
Accept-Language: fr-FR, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=cisco.com;
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 7355c6ae-3dc5-4cdc-e3d6-08da716b2a28
x-ms-traffictypediagnostic: PH0PR11MB5610:EE_
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: DqiNoD0ptBGIbZuJrobE1IVJ5CnZ5jr/aVOtSZeBN7Qd2GLICq2wlSdr2GAmk5QFi72ZCc3UqNWVRtMOp9egecBbvzmIAjZDsdrpjsDHjj9ccB7htenSfFMnEKikXVNz7fXNTj6v01dBLCiA6s5CBexE+BsZC6BuSATKLt8aZumCX0OOy5mcQL0qCQ488jJ2lCi5TWxtr/OTN0kSFJeB7oZhCGUg1hPgMiqO6qY4+w6oQUFvXpWvlFzcTA3SZuA4E0/TqtI5CjeUUdUoLQFuZNOMyWsWC95U9kmA1VHSCz7ehMh5VIn8w58Lkescp1dwMetFS24qOegS5/SqrQzHuitzM7ZELF0cbly6+9g9Bfo/XdqzKciBaMfUAyDy3Bu0WlY7TTVNosmA38Y1myAwqy7/ZaZBvGhTdIis3CNSJmBOKGk0E1mUTx0tEpeMu3FsfWXQWiJjXgPzz/hO0hsGMF+8K/rN43oRjO3dEzRH2H5ca/TgRngOkHKuCIFrR3sQCiceWLbab4sJn9zVCP+xBYrwVJhq9TjJMvqweOk6MG9+rsnWrcNCB5dIKo6AO0wJ6ucpmiDOmBQd7ccLycbAPVgintqcKwVetHCSm/VEOnUwBdJQXE5h13rsHl0uajiL3Iw128uVnMHUskwWt2qCIccyYfqV/E9G1ePoXmcA42GfDKoK1X6zmLf5JyiJrnVh645hm37T47Gr6UVgtWzm6rCuKl9PFyhCtqjan1e1AaAJznxaAV7T/mT0ryEFLSWgo/jD0blFdYO+1/abBLSaNkJvw3UtlA+wHiqeX2ARFYb2p9g6DPWFg+YSKyjBwWWDsIQCwPwUCMuXH7hDSYmFXYhbiTNhXxZbMsliFfmKGNIwSdoZAGieobeWLglwu+LM
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:CO1PR11MB4881.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230016)(4636009)(366004)(136003)(396003)(376002)(39860400002)(346002)(86362001)(83380400001)(38100700002)(38070700005)(66556008)(66946007)(76116006)(64756008)(66446008)(8676002)(55016003)(110136005)(316002)(122000001)(4326008)(54906003)(66476007)(2906002)(5660300002)(6506007)(52536014)(26005)(8936002)(9686003)(53546011)(6666004)(7696005)(66574015)(107886003)(33656002)(186003)(478600001)(71200400001)(41300700001)(966005); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: 7YyyPsht7hPKdjVwKp/BM4USt/K9ljUwFGd5sCADXaNwrXgWHH8OT0GYv0vTWMH9ZPGkQzXaw+JR9vtqsakM4A7XAZnlJM71IbCN/ckTlHJlM0kFvSqKBx5LQxol3ojbDHfgKv+sribkmtfR5DtP0IbSbt9tI8wicY79Qw8toU2z7ikjo/C0qzISFXVVofAVWWiFmlRquxUpImMHu9O/BoVd8kAikb4DG8MFQkTXDv3ro84YKytrCy7XLSlAPnyBbwJAALjNJL/PEqFF7152P5bKMMcLpL17ZgQ9qMcYVPmrSfCRnHJIuwIOWqtbx4caAKTgqwzzIm22pZlB5PhhsA+v8Bq+yNqP3XHcMLhwcDykV89TS/FgXD9pSRjwywSiFLOJEmTwupxmE4m8DWmMsBtvhKXWAZ2O+N1TL9oLMDAX6r9aj0xg/Yrb4EJc8xF2Rpu4B+TzCAAQAAc97cXgVFcGmZ7MP8BhGbwkDDRHs6HpmPHzxvN1cgwdUImRyxo206UNu4goZq9pvH9vVaHimfPn5cuv5Wzcp+X1aBOUXVP3Q85wnu1q5O5Bbrqy9XRcLMaEdiU2suU8m6AFWJfJ6idB/QjeKHArpmvLmzAxPZLJsyM+CU0T9SxBBjqhpg4aK3nWeayFc8U7GK91YTzgnW7S7Nj0q+UjZFM2NelaDe8cAfcUyPEQUDx2xPeJXQ20vZp4lbQk2lx0Ei6JIV1vuTSuLRn2mwOFOE4krwLJ8D9WlnugjJDnAC31gkLokcFRRBjBl++ESwD7knV9Q1hxoDZuhMd4a+W7Vq0dU0WPJ3qSmDwOCE4RQ0SV51JllkliZ59a8kr2FeZsB8ceq2pbCj2a6Uq6wyOndIEKtqOWjfnOysMOA+TGETkiQH9FVm7JV0xQWlH0r8PUU/o9oByGZXDZjjtEGTVJ29Vp2P8ZjeR712qas2G35Lj6Q1DRTCvEfDCNXdzlYQB8buclAlTH07phMi6BoxGa5nPrjkTf/DLFUPqGOD+enmrgJkcsNScf5Xlupfrcd6PSmsRJHo5Gf+MspehuphoEig6qj2kebX77WOBL1VaCdPcTGVsaGkLHJktXxu/iRC3bzOIG4MHvT3LTkw6ck9iTKgOCF40unOKQ7QviFawKd1LqzKLEO6siAtiAjBrPHSszB3BGyb207xGUXJ6NdVSZxbNR5ggleyRmakO+6zwEIDIoAO5TJJLnRP3wD/lF7W1GgchOvSNLCLoas5GTW4+rLNLl+AZ/7y0OQMYjxDBkLkP+hVNHT4nNKhsW/j0GU4oProt25C08G6V+glPx+wCNqjEWrpJyyAXoecXypmwSiPTQJj2m6411dT9lsVWghHNvAVSnzwfBJfnBDtqsBSjOvl2uyfO4Wv6Iwxg8VklYxsps/HKvD3wLYs7rXV77V6NmGESzqIQ8iiqcJbCrXr7ljBjW62MPaZJf+4a3uoq/9EwtVJQUM3vByOw7HyppYoteQRFDfVokqoiNs6smYFJ0lb3mQBTwyQP6TmZOY1vd8bQiMWlYfrFWcmYNl+7gn1Hk7m7r53dZDlC+Sv1V4d2yyIbsugmVQOeJdcPY7hS3EVRrNQtN+fll
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: CO1PR11MB4881.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 7355c6ae-3dc5-4cdc-e3d6-08da716b2a28
X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Jul 2022 14:03:50.8483 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: tVNYu/xXpgcCxHu0rWZAQz7Uxk2ipQX5Gvi1zfArS9rLjQa7nYMBV0op2fPBVf4zL5KxQpkTZsZwYwgse8VPjA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH0PR11MB5610
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 64.101.210.231, xfe-rtp-001.cisco.com
X-Outbound-Node: alln-core-7.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/detnet/eSdLg-WTD9W7sLmSqKkYqwNwZUE>
Subject: Re: [Detnet] on signaling the packet treatment vs. the flow/OAM
X-BeenThere: detnet@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Discussions on Deterministic Networking BoF and Proposed WG <detnet.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/detnet>, <mailto:detnet-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/detnet/>
List-Post: <mailto:detnet@ietf.org>
List-Help: <mailto:detnet-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/detnet>, <mailto:detnet-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 29 Jul 2022 14:04:51 -0000

Hello again Tianran


> If indeed there are requirements for hop by hop processing, I would agree with Pascal, tag over UDP is not a good idea.

Yes; I see it as an architecture issue, and an error at the architecture level is one we pay dearly afterwards, you know that if you ever built a house. SRv6 guys followed the natural architecture paradigm to place the L3 controls in L3 headers; they are quite successful with it and are now extending their design for network functions. 

What we are doing at DetNet and RAW should interwork / be consistent with that, because one day there will be a DetNET+SRv6 packet. The same about IPPM, just sooner. I think that the 5/6 tuple discussion started with a misreading of the DetNet architecture coupled with preconception inherited from other networking experiences. The architecture recognizes the flows based on the 5/6 tuple and then places them on the selected path. It does not mean necessarily that the DetNet network parses the 5/6 tuple all the way through. Actually that's a bad idea because we want to recursively aggregate and disaggregate flows and other things like OAM. 

In my book and out of my pen, the text in the architecture means that an ingress policy attributes a path to one or more application flows, and one or more other types of packet, and will mark the packets to signal the treatment, typically in IPv6 with an EH. E.g., RPL uses an option in the HbH EH whereas SRv6 uses SRH for that.

By nature, a UDP port is like an OSI SAP. It is an upper layer construct and L3 has no control over its semantics. It is fine and relevant to use it as an opaque indication of the flow for ECMP load balancing but twisting it to signal DetNet stuff would be a violation. Which values should we pick? Do we have enough values available to the router?

We need a tag that signals the treatment that all packets with the same tag will go through. That treatment might have parameters that we might want to signal with the tag. E.g., we might want to ensure that of 2 OAM packets, one takes the left path and one the right path. For that we need to own the control fields, not just carry an opaque number.

If the source is DetNet aware, it may place the tag in the packet, and we allow it to be mutable, then the ingress edge may assign it and there's no need of IP in UDP encapsulation at least at the DetNet ingress edge. Encapsulation comes at a cost and is not extensible ad nauseam, e.g., because of MTU or ASIC capabilities to look up the packet down the path. This is a real world problem and SRv6 already works on compression. 

It's important that all the pros and cons are on the table for the WG to make its decision, as opposed to live with the consequences of a unconscious choice.

All the best,

Pascal

From: Tianran Zhou <zhoutianran@huawei.com> 
Sent: vendredi 29 juillet 2022 2:50
To: Greg Mirsky <gregimirsky@gmail.com>; Pascal Thubert (pthubert) <pthubert@cisco.com>
Cc: Black, David <David.Black=40dell.com@dmarc.ietf.org>; detnet@ietf.org; Black, David <David.Black@dell.com>
Subject: RE: [Detnet] on signaling the packet treatment vs. the flow/OAM

We need to see the use cases that hop by hop OAM is applied.
In most cases, active OAM is used edge to edge. So there is no need for intermediate nodes to process. And OAM over UDP has least dependency on the intermediate nodes, hence easy to deploy.
If indeed there are requirements for hop by hop processing, I would agree with Pascal, tag over UDP is not a good idea.
In addition to active OAM, there are also passive and hybrid ways that we can apply. 

Best,
Tianran
From: detnet [mailto:detnet-bounces@ietf.org] On Behalf Of Greg Mirsky
Sent: Friday, July 29, 2022 4:57 AM
To: Pascal Thubert (pthubert) <mailto:pthubert@cisco.com>
Cc: Black, David <mailto:David.Black=40dell.com@dmarc.ietf.org>; mailto:detnet@ietf.org; Black, David <mailto:David.Black@dell.com>
Subject: Re: [Detnet] on signaling the packet treatment vs. the flow/OAM

Hi Pascal and David,
thank you for a great discussion. I fully agree with David that active OAM must share fate with the monitored DetNet flow. Thus, all elements of IPv6 encapsulation that impact the treatment of a packet in the data path MUST be identical across the DetNet flow and corresponding active OAM. Where it gets tricky, in my opinion, is IPv6 HbH EH(s). I think that we need to look closely at which HbH EHs used by the particular DetNet flow MUST also be applied to the OAM test packets. It seems like we can do that analysis in, for example, the OAM Considerations section.

WDYT?

Regards,
Greg

On Thu, Jul 28, 2022 at 4:21 PM Pascal Thubert (pthubert) <mailto:pthubert@cisco.com> wrote:
Great point David,

If one places an ECMP hash in a DetNet network he would better do that consciously because the interaction with the DetNet service plane might be tricky.

The idea along a DetNet path is that there’s no such surprise as an unexpected balancer.

Adding a UDP layer just to obfuscate the inner traffic against such unexpected activity looks like an overkill to me.

The service layer tightly controls its distribution. All nodes comply to DetNet. If DetNet says that the fate will depend on the tag, so it will be.

Regards,

Pascal

> Le 28 juil. 2022 à 22:12, Black, David <David.Black=mailto:40dell.com@dmarc.ietf.org> a écrit :
> 
> Hi Pascal,
> 
> I'm not Greg, but nonetheless ...
> 
> One can certainly tag packets with IPv6 hbh headers, but there's still a concern for active OAM where the OAM traffic is a different flow that needs to fate-share with the traffic flow of interest.  Getting that fate-sharing to work in the presence of flow spreading measures (e.g., ECMP hashes) is possible, but subtle, and dependent on what the data plane is doing for flow spreading (e.g., hash inputs, number of hash buckets).  UDP encapsulating all the traffic that needs to share fate is independent of all that, and hence I'd characterize it as a more robust mechanism to ensure fate sharing ... at the cost of the encapsulation and consequences thereof (another instance of "no free lunch").
> 
> Thanks, --David
> 
> -----Original Message-----
> From: detnet <mailto:detnet-bounces@ietf.org> On Behalf Of Pascal Thubert (pthubert)
> Sent: Thursday, July 28, 2022 3:48 PM
> To: mailto:gregimirsky@gmail.com
> Cc: mailto:detnet@ietf.org
> Subject: [Detnet] on signaling the packet treatment vs. the flow/OAM
> 
> 
> [EXTERNAL EMAIL] 
> 
> Hello Greg:
> 
> My point at the mike was that IPv6 allows you to tag packets with L3 information (e.g., DetNet, but also routing topology / VRF for RPL, and all those things SRv6 does) related to packet treatment without impacting the upper layer information (UDP ports and all above UDP). 
> 
> 
> It's actually cool to leave upper layer do and signal their stuff and have DetNet signal its own stuff independently. 
> This way we can tag all sorts of packets for the same treatment, whether they are UDP or not, whether they are an app flow or OAM, etc... 
> 
> The way to do that in IPv6 is Extension Headers. This is the essence of the proposal in https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-pthubert-detnet-ipv6-hbh-07__;!!LpKI!g764fAu3jINFXJra3JMCgLbYlGpnPnE5hkPRXlDq4G-_KTqxk9KMGMi3dTHijBEertf03WLsnoSG9kuqrjmdT9EpGukcymj4$ [datatracker[.]ietf[.]org] which was done with OAM (and flow aggregation) in mind.
> 
> As it goes, the more we look at enhanced DetNet, the more tagging we will need. DetNet should own and control the tags it operates own. The mapping flow->tag is an ingress edge problem, just like tagging a VLAN is in .1Q... Your OAM packet should be whatever OAM wants IoT to be, and the ingress policy should apply the tag the DetNet network needs.
> 
> Arguable, you could use UDP encaps as a tag. But is that the best tag? It's far in the packet (see the discussion on how far ASICs look in the packets) and heavy with information we do not need (the checksum is a MUST in IPv6, do we have enough ports?, etc...). It's like taking a truck to bring your loved one around the Cuomo lake. Works but maybe not the best idea.
> 
> All the best,
> 
> Pascal
> 
> 
> 
> 
> 
> _______________________________________________
> detnet mailing list
> mailto:detnet@ietf.org
> https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/detnet__;!!LpKI!g764fAu3jINFXJra3JMCgLbYlGpnPnE5hkPRXlDq4G-_KTqxk9KMGMi3dTHijBEertf03WLsnoSG9kuqrjmdT9EpGgoSXTG4$ [ietf[.]org]