Re: [Detnet] review DetNet OAM framework draft

"Pascal Thubert (pthubert)" <pthubert@cisco.com> Thu, 29 April 2021 13:07 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 C9EE83A3E45; Thu, 29 Apr 2021 06:07:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.617
X-Spam-Level:
X-Spam-Status: No, score=-9.617 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_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_NONE=0.001, URIBL_BLOCKED=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=SlchKvZm; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=CIZhTOmX
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xH23bmCqaL_l; Thu, 29 Apr 2021 06:07:15 -0700 (PDT)
Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D95E3A3E03; Thu, 29 Apr 2021 06:07:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=30416; q=dns/txt; s=iport; t=1619701635; x=1620911235; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=cbJfTweGO1WFw8OQgGwESISQ48G85QS5lrhJ9Ji2yh0=; b=SlchKvZmhsT10MoaJmmqAxGVuI9/jpxjWMGw69KKougPQfkgPgXJQ+G6 2oapDPcW6zv22w7WnTW4WwfeD+fVRJnRr9u47+HqycewdghcVjNJiS8AD E1rbvET0GcE2hpiAmFZsQMoy1Rw3bAkg4d2us5n0neFd6d3uHbOvB8X6Z A=;
X-IPAS-Result: =?us-ascii?q?A0AmAACvropgmIUNJK0+HB0BAQEBCQESAQUFAUCBQwgBC?= =?us-ascii?q?wGBIjBRflo2MQuIAQOEWWCIcQOZTYEuFIERA1QLAQEBDQEBKggCBAEBhFACg?= =?us-ascii?q?XsCJTQJDgIEAQEBAwIDAQEBAQEFAQEBAgEGBBQBAQEBAQEBAWiFUAEMhkQBA?= =?us-ascii?q?QEEJwYTAQE3AQ8CAQgRBAEBIQENMh0IAQEEDgUIgmkBgX5XAy8BDkCdYAKKH?= =?us-ascii?q?3iBATOBAYIEAQEGBASBNAETQYMhGIITAwaBOgGCeIQJhlUnHIFJQoEVQ4Ffg?= =?us-ascii?q?QA+gmACAgEXgQMJPCuDIIIrgU8aW2oEDSIUEFANCUgWGQYEEAUKDB80D5BTG?= =?us-ascii?q?ossjQmRagqDEIl2hk9VjCYQg1SLCYYbjUeCXZUqi36Scw+EWwIEAgQFAg4BA?= =?us-ascii?q?QaBVDiBW3AVGiGCNQEBMlAXAg6OHwwNCYNOhRSFSXMCNgIGCgEBAwl8iwMBg?= =?us-ascii?q?Q8BAQ?=
IronPort-PHdr: A9a23:EjiX4xWUHws0LuKw0ffpfZvq5OXV8K0MAWYlgqEPgq9Scqml45XpN VDe4vMollLSQIHH8JpsiufKvebnQ2NTqZqCsXVXdptKWldFjMgNhAUvDYaDDlGzN//laSE2X aEgHF9o9n22Kw5ZTcD5YVCBo3Cu43gVABqsfQZwL/7+T4jVicn/3uuu+prVNgNPgjf1Yb57I Bis6wvLscxDiop5IaF3wRzM8RN1
IronPort-HdrOrdr: A9a23:6zYxJ6HYVONI+psppLqFkZXXdLJzesId70hD6mlYcjYQWtCEls yogfQQ3QL1jjFUY307hdWcIsC7IE/03aVepa0cJ62rUgWjgmunK4l+8ZDvqgePJwTXzcQY76 tpdsFFZ+HYJVJxgd/mpCyxFNg9yNeKmZrY+9v25V0Fd3AMV4hL6QBlBgGHVmh/QwdbDZQ0fa Dsl/ZvjTymZHgRc4CHFmAINtKz5uHjubDHRVo9BxAh4BSTlj/A0t7HOjWRwxt2aUI1/Z4O/W fIiBf06+GPv/S61RPGxwbonu5rsfT7zN8rPr3otuE0LXHWhh+sdMBdXdS5zU8IicWOzHpvr9 XWuRcnOK1ImjPsV0W4uwHk1QWl8BtG0Q6e9XaijXHuodP0SVsBYqIr7+80A3ipiXYIh91y3L lG2GiUrfNsfG/9tR7g7NvFXQwCrDvTnVMekPUeh3EacYwSZK45l/1mwGppEYwNFC+/1YY/EO MGNrCk2N9qdzqhHhTkl1gq5ObpcmU4Hx+ATERHkNeSySJqkHdwyFZd7NADn18bnahNCKVs1q DhCOBFhbtORsgZYeZWH+EaW/a6DWTLXFblLH+SG1L6D6sKUki96aLf0fEQ3qWHaZYIxJw9lN DqS1VDr1M/fEroFImo0IBU9AvOBEGwRy7kxM0bx5URgMy4eJPbdQm4DHw+mcqppPsSRufBXe yoBZ5QC/j/aWT0H4JE2BD/RolSJXESXNZ9gKd9Z3u+5ubwbqH6vO3Sd/jeYJD3Fyw/Z2/5Cn wfGDj/Tf8wqHyDazvdulz8Snntckvw8dZbC67B5dUez4ALK8lJuggRglKp+9GTJVR5w/ULVX o7BImivrKwpGGw82qNxX5uIABhAkFc56ilVWhLqw8MO0b9aq0CpN2bZGBX0BK8V1tCZvKTND Qai0V8+KqxIZDV7zslEcibPmWTiGZWuGiHVI4GmqqI5d7sf5QxCppOYt0oKSz7UzhO3Sp6om ZKbwEJAnLFHjT1kKO/kdg/H+fEbeRxhw+tPO9ZoX/Srl+nuMkqX3cXNgTeCvK/sEILfX50jk c027IDiLCA8AzfWVcXsaAdChlwT0i5RJhBFx+IYY1InKuDQnACcU66wRqAix8yfWL28V41nW KJF1zPRdj7RnxAp3tfzqHmtHRze2n1RTMtVllK9atgCG/BpnF/ldWuW5P2+W6QZlweq9ttbQ 3taScOIw9o2tC83AOUnjHHDnk92pAyJIXmfcYeWqCW1XW3JIKSk6YaW/dS4ZZ+Ldjr9vQGSO SFZmauXX/FIvJs3wyevXA+PiZo7HEijPPzwRXghVLIlkIXEL7XIF58QascLMzZ52/4R+yQ2J E8id4up+O/PiHwbdGBoJunIgJrO1fWoWSsSfsvpo0RtaUutKFrF52eSCDWzhh8rVwDBdaxkF lbTLVw4bjHNIMqd8sOezhB9l5skNiUNkMkvgH/H+dWRyBjs1bLe9eSp7bYo7smBUOM4BH9Pl SS6CVR9fbIVSnr789QN4sgZWBNLEQs4nVr++2PM5DKAAKxbudZ4R60NGS+fLI1ctnKJZwA6h Jhp9eGkO+ce3CmhETevT5nLrlP9GjiS8WoGw6IEfNJ9dv/OVnkuNrc3OejyDPsDT28YAAEgI cAc0oaZMFKkCMjg406yTLacN2+nms1119FpSh6nVvs0JW86GjVHUtaIRTU668mKQV7IzyNl4 DZ6uCW23T2/Shd1ZTCHElWeMtSG9J4dPmAEw5+bc4KvLCp+KIzgiNMJBc2ZlRM/QzA4w==
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.82,259,1613433600"; d="scan'208,217";a="677740982"
Received: from alln-core-11.cisco.com ([173.36.13.133]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 29 Apr 2021 13:07:13 +0000
Received: from mail.cisco.com (xbe-rcd-004.cisco.com [173.37.102.19]) by alln-core-11.cisco.com (8.15.2/8.15.2) with ESMTPS id 13TD7D0u018897 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=OK); Thu, 29 Apr 2021 13:07:13 GMT
Received: from xfe-rcd-002.cisco.com (173.37.227.250) by xbe-rcd-004.cisco.com (173.37.102.19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.3; Thu, 29 Apr 2021 08:07:06 -0500
Received: from xfe-rcd-002.cisco.com (173.37.227.250) by xfe-rcd-002.cisco.com (173.37.227.250) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.3; Thu, 29 Apr 2021 08:07:05 -0500
Received: from NAM12-MW2-obe.outbound.protection.outlook.com (72.163.14.9) by xfe-rcd-002.cisco.com (173.37.227.250) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.3 via Frontend Transport; Thu, 29 Apr 2021 08:07:05 -0500
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=mH6FVaJxYG91niGP8mbkf4Kqd4I7yRkXUleyPbEmycz2IVDoyNSLAa1rT2HksZHiEr8fb8PIGxYYBnBUcnMxNKH5H4Pa3CvsBok2hkY9sA3N3Ve4lQItM568wNiLUZzH8thHmMSRoYeLm+sSF9Owu6FZ09wUuZRl6zXhbn+d2gLdoJVOVFCYj/U/A9URTB6rcoGXkt5nxQZhiEbfJ7R+/fPEIwLZqISVHPxLfU9Ftt5jFgdy00K2g5kK5E2lzAuzYBubRn6Sj6PbUeKlJytZfU4NHOS7xXPp9vNSLWFcnmrtPIvjZIffwMVJUdUMJ5ptY8eK59M3yCLj+oFCZCssjA==
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-SenderADCheck; bh=hNY58hoTALfObZ810/WpX1ovbCxFSM36xdAErD1mbWA=; b=necS9RG+TzAbdwwi9Kc1WVGsnxItayBWY6WJJJqBdomjc9JmBO35kuSu8mEEu4HcPGObMG4t0l4YBEoAbpXwC6lIalEUWq+ml+QHjOC6o1rEVpZlrNj3DAcJICP5zDQFk1Vn0L0LMuulIoLCxPb0HnRRKF5GEScFfGkaHpKSEjEmS4aYl0awM1IHxXU6sMkhzs0u6NoIhffBrGr1+8BnzuiiB/j7LfWbNbByb5dZqOPooZfpAAyHjS3YIZ1gOlcfLUnF9QaHsNL7Eb5eCFZudYrn76yRYEShruCwTO8Hc6DjVKnKb4Tx6PgPERsTg+bnnz2ly5oZLdnr6f1KebxEYQ==
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=hNY58hoTALfObZ810/WpX1ovbCxFSM36xdAErD1mbWA=; b=CIZhTOmXSzkjql5NtElK8bk5AJkosjsOpNKp/OcSAc6xMDaXpkgUvOWbkTEfAuFJDGshsZEJaKKK3KRxhrq2f6ENxqT09dZG+KYw06/NaKGUQwN7IGuJJAIOvu3PRFptgnY5OLKUhdXH8lHOmIXLSmMVWI6+6w4fQzghuOWiMws=
Received: from CO1PR11MB4881.namprd11.prod.outlook.com (2603:10b6:303:91::20) by MWHPR11MB1776.namprd11.prod.outlook.com (2603:10b6:300:110::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4065.23; Thu, 29 Apr 2021 13:05:50 +0000
Received: from CO1PR11MB4881.namprd11.prod.outlook.com ([fe80::cd01:ffc9:6592:b1d5]) by CO1PR11MB4881.namprd11.prod.outlook.com ([fe80::cd01:ffc9:6592:b1d5%6]) with mapi id 15.20.4065.027; Thu, 29 Apr 2021 13:05:50 +0000
From: "Pascal Thubert (pthubert)" <pthubert@cisco.com>
To: "draft-ietf-detnet-oam-framework@ietf.org" <draft-ietf-detnet-oam-framework@ietf.org>
CC: "detnet@ietf.org" <detnet@ietf.org>
Thread-Topic: review DetNet OAM framework draft
Thread-Index: Adc8fXs1emXJ6R6aQlWuJ6hcKk0iFAASE9Gg
Date: Thu, 29 Apr 2021 13:05:27 +0000
Deferred-Delivery: Thu, 29 Apr 2021 13:04:55 +0000
Message-ID: <CO1PR11MB488199682C35E517C0E2A444D85F9@CO1PR11MB4881.namprd11.prod.outlook.com>
References: <AM9PR07MB7204DF42315052CE9C620692F2409@AM9PR07MB7204.eurprd07.prod.outlook.com>
In-Reply-To: <AM9PR07MB7204DF42315052CE9C620692F2409@AM9PR07MB7204.eurprd07.prod.outlook.com>
Accept-Language: fr-FR, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=cisco.com;
x-originating-ip: [173.38.220.52]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 80de6d74-72b6-496b-3f50-08d90b0f832d
x-ms-traffictypediagnostic: MWHPR11MB1776:
x-microsoft-antispam-prvs: <MWHPR11MB1776F61F2641362EE23479D9D85F9@MWHPR11MB1776.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: zAKUtG2Te5FDBRIOPfQ7f9gZmbPHSXqanXosWnioBMPIyk1INxwK8OzKbhWBOpvgt+vBLrFnD5OpRSfaqBRWfWR9gPWFISCxoZF87HGHlPdROctpNYUfkzCEdEtYABiIn5P9R/wAox6+2nM7Rgv4/5M3Ha4PuRr8rSnsp04be2bFjpqGGhAUhVrpl5eD39zsSo0KY70vgcNE9HTQywXFBtvLekZrl1JQliOknoF1ifj+AUoAm+EAwQjX1uQiFWNkOKCOf8WIHTsoPYg8LagwhcV8JXpJBZ+qgkENG7JwDN4jgCfUd2beS04OaXBAQO/wHQTs05jGIdjnvEYh5dqhMbp+mq+i8Q+Mw30Ed2v3+TeT/mOMQhqeNn8GtxiZj4U6Jgs0uUePwfoTYO8mneOt6QJ7Z8xYlrgTVOYAsomZpim7LFvpzI1+sCOOyQ07z/f9+UqehEg4diSkXWCOZwE960zNYf2os5RW42nVR+dPH/6zH9FBOa7WS1n0ALOBEI1STKjItexyW864UMjxS0zRXPdyhJW5Z/J1eM5mAZYikR+z2HzTUH5uN7iw6B77WsAJsSAVj/s+crFj46INOLZpGIxNz0SUOYMGQVPLwMfyAs/hbb5rm54csmggVFIaJTfOFOqlliliLEND/jgAkexXm5nk7GOOZ6Jbu6lGR/DgmK7Kipi+ddrT5/Af6ZUGY6mu
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:(39860400002)(366004)(376002)(396003)(346002)(136003)(5660300002)(38100700002)(2906002)(122000001)(6666004)(66446008)(86362001)(52536014)(8676002)(8936002)(6916009)(66946007)(966005)(26005)(166002)(6506007)(186003)(53546011)(64756008)(83380400001)(33656002)(478600001)(16799955002)(316002)(55016002)(76116006)(7696005)(66476007)(66556008)(450100002)(9686003)(4326008)(71200400001); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: =?us-ascii?Q?TZNDBYfgLskmY4g7FhPOHNPk0aZcjyftKdrViFg7bE/Op/yA1j7BXyhDYRue?= =?us-ascii?Q?KwpphYjGCu5pT/Ea1XGx9m+Tr2Y+4zlpIMyoUKnWLjkVNVJqkMysGXKNhKDC?= =?us-ascii?Q?HGtadfAX1zleKeC+wPUmv0VG5Jcwy5H4P4o76djeDUfjfRspuCore6L2lC4j?= =?us-ascii?Q?fAhTfH3zNIqlmQlORs2mfav2o7ojFuFlOF8ftqxyNsdgHLci3BJc4/RR8O0S?= =?us-ascii?Q?EPKl9XfbIGOVv+Zem3JQmMx1BJ1uVGsp4SBfB3fUbqIe7Kx3b2VZcQSwbPI0?= =?us-ascii?Q?iNynN3JBwuqBNLzmDWQ+ljOFfl3F3qBm36PedSQ3Df0apK25389v8GN5I0sR?= =?us-ascii?Q?lqxXprHobVhYcFmbJC+J+yWXQgdf073c5nrVV1JLz6pZhFpC0M+lfqS+5/h/?= =?us-ascii?Q?KoPXd2U3ExsbYv01kScSPnyRWPPOQg/r9q7RNX9rUpdw6hUkKIvGXFvngs+6?= =?us-ascii?Q?OUj3apvXVcTFT4/3pwWt7DysNrNfeWrA8NjVEAspnpLPA1Whmu9A2E2Gb+yi?= =?us-ascii?Q?+IpgrXEjThnFkBktyJwgPwcihlJDDDr4g7w0hBwfluVP82O3SNvL3/VRaYPB?= =?us-ascii?Q?/nR5hleyE5HiPtG4vOFfE82ceeLNR5DUGGtU27HiF2h2lCN9wbMmOeMxM66q?= =?us-ascii?Q?nHntSVCVzLA6JbpPD3FG9yR32MD7LxCEZp9vRXco/Nbt1v35WHXdorcsVTIr?= =?us-ascii?Q?ftGKqZTsxN51jWTaXKKQG0DtHbnrTvwOjuTETmEMvPxN2FL4KqqLJRzA/O14?= =?us-ascii?Q?SRyt1ULLKGBSGpMANJx2MLKYELexVPaSU058ZjPGOeyUWmecC7ausynWki8o?= =?us-ascii?Q?skrm0povOmVwjjYjcQDknYBNMgQucgLWmH907hyYa5Xx3Pop4YYygCn9VQVk?= =?us-ascii?Q?EXE9XzkT3/Rv1f47Te3DxTEM+ZtYmPj0H5aAVuF8T9dQTmjAHfJ3ajJktQKB?= =?us-ascii?Q?FPWYV3RU7ZzD1knLXKApRZBQn5cepJgK4/Oa9gbQdkkNpQalbY5ly6LW1ai3?= =?us-ascii?Q?H5rBxH/0QtFeT3spNdU5kKcdgnoRbPeGlIf8XIvzt5xj8B9NV/0b+LtsQEeA?= =?us-ascii?Q?hIZLKN+NSF+NBBXAogXeMIkKGbGe5foiMvRZOWKOZ5wqZ57HP/j8+Vf5CRvv?= =?us-ascii?Q?F9f2Wdaqf5b74th3xyw989+dDAGg3OFgdV7YB+AjXTg0KKGdsH7emcXAp/CB?= =?us-ascii?Q?vG8OtHbgiaCLIwTtaveLSVs3CFrxUtp6l/cVhjAerv4oJS238611bpW3a5j8?= =?us-ascii?Q?cwwGZ1KSPcckKlz8uLyB+q0716yL6MZt8l3/fIjo4HpMIO35JuESx5Cwze76?= =?us-ascii?Q?bVOPI5n/j+qIS6qMYIu4vZlV?=
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_CO1PR11MB488199682C35E517C0E2A444D85F9CO1PR11MB4881namp_"
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: 80de6d74-72b6-496b-3f50-08d90b0f832d
X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Apr 2021 13:05:50.2044 (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: rWr0bzdoIjgbniSaJFPnnqwr03/ZaO79xy0NlmUSp9ude2+KqkHFgazZ4fROOTVitscklwpFFwJHF2JyIFCg5w==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR11MB1776
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.37.102.19, xbe-rcd-004.cisco.com
X-Outbound-Node: alln-core-11.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/detnet/TSzTadO_iGjoINjWafhobU8sdvs>
Subject: Re: [Detnet] review DetNet OAM framework draft
X-BeenThere: detnet@ietf.org
X-Mailman-Version: 2.1.29
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: Thu, 29 Apr 2021 13:07:28 -0000

Dear authors and all

I do support this document but do not see that in its present shape it is ready for WGLC. Please find some review comments below.

- Sadly RFC 8655 does not define either "latency" or "delay". Reading this draft, I now see it as an oversight. I'd suggest that we define them in the terminology section. it is my sense that RFC 8655 uses "delay"  with the meaning of incremental flight duration, and uses "latency" for the total time end-to-end time across the network, IOW, minimal_latency + delay <= bounded_latency.



- Their work -> that work ?



- the abstract and the introduction indicate that the document is a problem statement / functional requirement draft, and indeed the text reads like a requirement document. But the title says framework. Which is it?



- same question about the intended status (std track). Is that really what we want here?



- "It is critical for the

      quality of information obtained using an active method that

      generated test packets are in-band with the monitored data flow.

". this duplicates text in 3.3 and does not belong in a terminology. Remove?



- "                                                                                                         OAM represents the

   essential elements of the network operation and necessary for OAM

   resources that need to be accounted for to maintain the network

   operational.

" does not parse too well



- "information about the state of the network being

   collected

" is being? Maybe remove that text ? it seems to repeat the first sentence of the paragraph.



- "   Also, we can characterize methods of transporting OAM information

   relative to the path of data.  For instance, OAM information may be

   transported out-of-band or in-band with the data flow.

" this deserves its own subsection with some more explanation and possibly some references to relevant IETF work



"   Similarly, the destination does not receive packets from different

   flows through its interface.

" sorry I do not get the intended meaning



- section 3.3 -"It is worth noting that the test and data packets MUST follow the

   same path, i.e., the connectivity verification has to be conducted

   in-band without impacting the data traffic."

 there appears to be a tension between the bandwidth that is reserved for the flow and the extra bandwidth that the OAM needs .

Do we need to know in advance how much OAM there will be? Must that be included in the reservation?





- section 3.4. What do we do for PREOF?



- "The network has isolated and identified the cause of the fault."

Again I fail to understand the intention.



-"                                  One of the advantages of the use of

   AMM in a DetNet domain with the IP data plane is that the marking is

   applied to a data flow, thus ensuring that measured metrics are

   directly applicable to the DetNet flow.

" isn't this the case for IPPM in general? Isn't the benefit of AMM more related to conciseness?



- Maybe we should discuss the tension between RFC 8939 and the capability to use separate packets for OAM, since the flow is routed on the 5/6 tuple. Does that mean that only in-situ is feasible with RFC 8939 (ref draft-ietf-ippm-ioam-ipv6-options)?



Section 4. This section needs more thoughts. For instance there are packets like PTP packets for which it is important to know the transit duration in each hop. Isn't that true for DetNet as well? Radio links have numerous metrics that can be reported (think RFC 8175), we need to know that information per hop as opposed to per path/circuit. We need to know if the hop does store-and-forward or passthrough - e.g., in the former case using smaller frames / packets / segments / fragments and/or network coding may improve the latency. Maybe we could dump the WG collective mind with a dedicated thread?



- "   DetNet needs to implement a self-healing and self-optimization

   approach."

Though I agree with the intention and the next sentences, I'm not sure this is the best wording. Those words are classical for routing protocols that (re)compute a path, which is disruptive or consecutive to a disruption. We do not want disruptions in DetNet. There must be enough PREOF to ensure the SLO without repairing. The RAW problem is actually NOT to use all the redundancy at all times in order to save battery and spectrum. I'd rather say that

" in the face of events that impact the network operation (e.g., link up/down, node crash/reboot, flows starting and ending) the DetNet Controller need to perform repair and re-optimization actions in order to permanently ensure the SLO of all active flows with minimal waste of resources".



- section 5.2: Is it the intention to include the repair action in OAM work?



- section 6. Why only MPLS data plane? It seems that the requirement are not dependent on the underlying technology.



- I'm not sure about requirement 5, 6, 10, 11, and of the use of "excellent" in 16.



- I read requirement 16 as the only service assurance requirement. A very important requirement in my view, and I think we want more. We also want to ensure that a scheduled transmission happens as scheduled/when, that the guaranteed resources like buffers are available per reservation..



Many thanks to the authors for all the great work!



Pascal



From: detnet <detnet-bounces@ietf.org> On Behalf Of Janos Farkas
Sent: jeudi 29 avril 2021 0:28
To: detnet@ietf.org
Subject: [Detnet] review DetNet OAM framework draft

WG,

Please review the DetNet OAM framework draft: https://datatracker.ietf.org/doc/draft-ietf-detnet-oam-framework/.

The authors consider the draft in a pretty good shape, do not see any major piece missing.

WG review and comments would be great in order to develop the draft towards WG Last Call.

Please send your comments to the list before the next informal OAM discussion on May 11 or bring it to the informal meeting: https://ietf.webex.com/ietf/j.php?MTID=m27bb8ee31f025670e4071bfdfcd47432. (More details on the OAM informal meetings: https://mailarchive.ietf.org/arch/msg/detnet/4ik3tI-E3uhOFNaKhpkZiWwyiZc/.)

Regards,
Janos