Re: [Detnet] Éric Vyncke's No Objection on draft-ietf-detnet-bounded-latency-09: (with COMMENT)

"Eric Vyncke (evyncke)" <evyncke@cisco.com> Tue, 12 April 2022 15:46 UTC

Return-Path: <evyncke@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 6FEEF3A043E; Tue, 12 Apr 2022 08:46:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.605
X-Spam-Level:
X-Spam-Status: No, score=-9.605 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_H5=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01, 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=MmhfYInk; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=yWJtsaSd
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 p4bYe9HQscST; Tue, 12 Apr 2022 08:46:35 -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 B18323A2183; Tue, 12 Apr 2022 08:46:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=56351; q=dns/txt; s=iport; t=1649778394; x=1650987994; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=yjGZPeYb9xUm2gRU6hQQL/kFxCZZ4SeNC/2j+IRvtbI=; b=MmhfYInk9+eh3nejI3gAm2UJsOvLZbPBoh41DoTRByYbtjG1sqbbTtrV Kmfgq2zch88pFOTTVZZXavwjp3zHlE1Z/1rCp1JWuh9rJ3SDgLJwm7KZc Wp2/w1om5vksAcMHkInAPPGHzsCRsVC7k5m0pDP2Td17yJfYabWI5RgW/ M=;
X-IPAS-Result: A0D5AAB5nlVimI0NJK1aHgEBCxIMgg8LgSExKC58Alo4RIRUg0oDhTmFEIMCA4EpmhOBLhSBEQNUCwEBAQ0BATkKBAEBhQcCF4RfAiU0CQ4BAgQBAQEBAwIDAQEBAQEBAwEBBQEBAQIBBwQUAQEBAQEBAQEJFAcGDAUOECeFaA2GQgEBAQEDEggJHQEBKQ4BDwIBCBEBAgECFgsBBgMCAgIwFAMDAwgCBA4FFgyCYgGCDlcDMQEOomYBgT4CgQ6JEXqBMYEBgggBAQYEBIE7AgENQYJ/GII4AwaBPIMRgwRYSwEBgl6EPSccgUlEgRUnHIFmgQE+gmMBAQIBgRYNBQESAUENCQmDFzeCLpo0JkwjPgMEIQEZCAgGAglHByQEWw8ZBQwZEToDkWkUEAYHgwZGiWuOApJ1CoNJixeOcYV4BS6DdIw5hl6RR4VUkQqNHZQ8BASFCQIEAgQFAg4BAQY1gSyBJXBwFTsqAYIKAQEBMVEZD44gCRAJFYMTKIUUhUp1AjYCBgEKAQEDCQGCOoosAQE
IronPort-PHdr: A9a23:h//tERavwDqJLoyy9AI9C/T/LTAphN3EVzX9orIriLNLJ6Kk+Zmqf EnS/u5kg1KBW4LHo+lFhOzbv+GFOyQA7J+NvWpEfMlKUBkI2skTlhYrVciCD0CzJfX2bis8S cJFUlIt/3yyPUVPXsjkYFiHqXyp5jlUERL6ZmJI
IronPort-Data: A9a23:qSlYh6vgnGUj7VTyLrg+dmPx1efnVMFeMUV32f8akzHdYApBsoF/q tZmKW6Bb/feMDD3L911b97ko0wOuMTTzoBkSQplryAyRCwUgMeUXt7xwmUckM+xwmwvaGo9s q3yv/GZdJhcokf0/0vrav67xZVF/fngqoDUUIYoAQgsA148IMsdoUg7wbRh3tcy2YLR7z6l4 LseneWOYDdJ5BYsWo4kw/rrRMRH5amaVJsw5zTSVNgT1LPsvyB94KE3ecldG0DFrrx8RYZWc QpsIIaRpQs19z91Yj+sfy2SnkciGtY+NiDW4pZatjTLbhVq/kQPPqgH2PU0YHVtoDSQtf5Il otT7MbuURkGHZ32h7FIO/VYO3kW0axu8bvDJz20ttaeih2AeHr3yPIoB0YzVWEa0r8oWicVq 7pBc3ZUMknra+GemNpXTsFhmNUlJ8rmFIgeoXpnizreCJ7KRLiTGP2btYYHg2lYasZmDO+Ge shEZwNVNw2eIDdUEHYtDaJ5g7L97pX4W2QI9A3KzUYt2EDfyhdZ3ry0P9fPPNCHLe1RlEuCq W/c12DwCBdcMtGDoRKJ/26qi/PnnC7nVsQVDrLQ3vJnnFue2ikYCBQXT0CToPSlhAi5Qd03A 0AO8yQy6Kk/6ELuQtThWRCk5XSDoxgQVtYVF+Qm5QeG24LV7hqXQG8eQVZpadE9u+c3SCAkk FiTkLvBCDx0ubvTTHWd/7KRpD+qPjUPBWIaaytCRgtt3jX4iIg3ihSKRdF5HevlyNb0Ajr3h TuNqUDSmon/k+YC5Z+Q/EntrQvy+IaQFFAt+Cr0bli6u1YRiJGeW6Sk7l3S7PBlJYmfT0Wcs HVspyR4xL1VZX1qvHHRKNjhDI1F9N7ea2SF3gAH840JsmXzpSHyJOi89RknfB8BDyoSRdP+j KY/Uyt44JteOhNGhocoPtroUKzGIUUcfOkJu9jdat5IJ5N2bgLCrGdlZFWb2Cbml01EfUAD1 XWzLJjE4ZUyUPkPIN+KqwE1iuVDKscWnji7eHwD5077uYdynVbMIVv/DHOAb/oi8ISPqxjP/ tBUOqOikksDAbKmM3SNqtFCfDjmyETX47ir9aS7kcbefGJb9J0JV5c9PJt4IdU+xvQJ/gs21 ijmBRMwJKXDaY3vcFXWNS8LhELHVpdkpnVzJj03IVutwBAejXWHss8im28MVeB/roRLlKcsJ 9FcIpnoKqkfG1zvpmVGBbGg/dMKXErw32qmYXH6CAXTirY9HWQlDPe+IFu2nMTPZwLq3fYDT 0qIiluAEcVeHVw7ZCsUAdr2p26MUbEmsLoadyP1zhN7IS0ALKACx/TNs8IK
IronPort-HdrOrdr: A9a23:A2+2Malv2/xftnQZTc7S6EIw1U3pDfNpiWdD5ihNYBxZY6Wkfp +V8sjzhCWatN9OYh0dcIi7SdW9qXO1z+8Q3WBjB8bcYOCGghrnEGgG1+rfKlLbalXDH4JmpM Vdmu1FeaDN5DtB/IfHCWuDYq0dKbC8mcjC74q/vhRQpENRGttdBmxCe2Gm+zhNNXB77O0CZf yhD6R81l+dUEVSSv7+KmgOXuDFqdGOvonhewQ6Cxku7xTLpS+06ZbheiLonis2Yndq+/MP4G LFmwv26uGIqPeg0CLR0GfV8tB/hMbh8N1eH8aB4/JlaQkEyzzYJriJaYfy+Azdk9vfr2rCV+ O85SvICv4Drk85uFvF+CcFlTOQiArGoEWSt2NwyUGT0PARAghKUPaoQeliA0bkA41KhqAn7E sD5RPri3IcZymw7BjV9pzGUQpnmVGzpmdnmekPj2ZHWY9bc7NJq5cDlXklWqvoMRiKoLzPKt MeR/00JcwmBm+yfjTcpC1i0dasVnM8ElOPRVUDoNWc13xTkGpix0UVycQDljNYnahNB6Vs9q DBKOBlhbtORsgZYeZ0A/oAW9K+DijITQjXOGyfLFz7HOVeUki95KLf8fEw/qWnaZYIxJw9lN DIV05Zr3c7fwbrBdeV1JNG/xjRSCG2XCjryMtZ+59l04eMCYbDIGmGUhQjgsGgq/IQDonSXO uyIotfB7v5IW7nCe9yrkTDsllpWA8jueEuy6MGsgi107D2w6XRx5jmTMo=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.90,254,1643673600"; d="scan'208,217";a="830981776"
Received: from alln-core-8.cisco.com ([173.36.13.141]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 12 Apr 2022 15:46:32 +0000
Received: from mail.cisco.com (xfe-aln-001.cisco.com [173.37.135.121]) by alln-core-8.cisco.com (8.15.2/8.15.2) with ESMTPS id 23CFkWPv018587 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=OK); Tue, 12 Apr 2022 15:46:32 GMT
Received: from xfe-aln-002.cisco.com (173.37.135.122) by xfe-aln-001.cisco.com (173.37.135.121) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.986.14; Tue, 12 Apr 2022 10:46:31 -0500
Received: from NAM12-BN8-obe.outbound.protection.outlook.com (173.37.151.57) by xfe-aln-002.cisco.com (173.37.135.122) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.986.14 via Frontend Transport; Tue, 12 Apr 2022 10:46:31 -0500
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=NMaMLHIhUF7GwuNiazWyk6/HC/DgXkUZVP0DRENCpcA05crHqruGPL7lQakbqpFbA6q9C5ociS65FdKYDVhU8nSoJoUGYPf9eooFjnMbdzKkaEUnNLehOjN0AKu6znvHHPZvVx9PVEtNRAJ2EAvxSq9Q549XM6LVpxgOUvj1YS6qQ4gkdqWudS7BVawds5nuPOVBaQPYrZ3wJTx6eU38YZsD9gNo+IRRKY4diLPlOlvILfN4zyhvYTayG8Tat5sX+LiYtqmJsjSXZ+zkmxB/4syDiXjWob/1T5K8pM8ZGOX6OT+FrpTFzwcRykZ1LQjCLdklEVZu/uDiqIdLKsSjLg==
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=yjGZPeYb9xUm2gRU6hQQL/kFxCZZ4SeNC/2j+IRvtbI=; b=eOXlHXwWcgW+8a/45Hu0BqK1ebvouTsMUjr28s0mFc3eLzTuYoVJcYYY44by/fGrcmbld+9S7sQKh+dazD64YL95PBygGfHaWJmIrzgkTPXrkI80ycI91ZKczkYrcYwZk58CZVm0u69xZFm7Oxy/JU1G5W/4eWn+/e8/k4Eh16i7MwxnmvIbSPs3Iq5iIFpxo6wpl0HXmSd1A0Em6+1uEIvNiz0ybct1/Zgm5X4Ia0+LP2gNpuj+anoKYwJB6H9EXTo0lY4jPlyYvYMkiUPujWd2FJpzsJvihZlx3eudUAT9ReEdK1nL+u5o2MCdmmPGBLwOyWVS8IiYVr4CEmFHOQ==
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=yjGZPeYb9xUm2gRU6hQQL/kFxCZZ4SeNC/2j+IRvtbI=; b=yWJtsaSddwSnnhqttaDB7er1NuPWN+VDYELqkOsLX0wCD9PflFP6hV8CLruqCytrjmal44Yp+1+eMq4Qs9iAitFhMTXmewhYL2dbuby60/daDQWno6WwB8fDKd7qLLIjh+tKA7ASiYLOvEAonV/wytMfstAed7HU+xxfosy0UdE=
Received: from PH0PR11MB4966.namprd11.prod.outlook.com (2603:10b6:510:42::21) by BYAPR11MB3702.namprd11.prod.outlook.com (2603:10b6:a03:f7::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5144.29; Tue, 12 Apr 2022 15:46:29 +0000
Received: from PH0PR11MB4966.namprd11.prod.outlook.com ([fe80::145e:1c80:538f:43d5]) by PH0PR11MB4966.namprd11.prod.outlook.com ([fe80::145e:1c80:538f:43d5%3]) with mapi id 15.20.5164.018; Tue, 12 Apr 2022 15:46:29 +0000
From: "Eric Vyncke (evyncke)" <evyncke@cisco.com>
To: Mohammadpour Ehsan <ehsan.mohammadpour@epfl.ch>
CC: The IESG <iesg@ietf.org>, "draft-ietf-detnet-bounded-latency@ietf.org" <draft-ietf-detnet-bounded-latency@ietf.org>, DetNet Chairs <detnet-chairs@ietf.org>, DetNet WG <detnet@ietf.org>, Lou Berger <lberger@labn.net>, "dns@fl1ger.de" <dns@fl1ger.de>
Thread-Topic: Éric Vyncke's No Objection on draft-ietf-detnet-bounded-latency-09: (with COMMENT)
Thread-Index: AQHYSNKvvzmFVfXbiUanMzS+N9diQazjSwKAgAlN0QA=
Date: Tue, 12 Apr 2022 15:46:29 +0000
Message-ID: <1E0B2764-2FE9-430F-A89D-0CA7EA0D5405@cisco.com>
References: <164915226660.10923.7596112393710360471@ietfa.amsl.com> <4301F711-D9EC-44EA-AF3F-6234E6A51F6B@epfl.ch>
In-Reply-To: <4301F711-D9EC-44EA-AF3F-6234E6A51F6B@epfl.ch>
Accept-Language: fr-BE, en-US
Content-Language: en-GB
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/16.59.22031300
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: f74a7f30-3747-427e-2a80-08da1c9b9c51
x-ms-traffictypediagnostic: BYAPR11MB3702:EE_
x-microsoft-antispam-prvs: <BYAPR11MB3702939F818E673A44C753B7A9ED9@BYAPR11MB3702.namprd11.prod.outlook.com>
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: Jgjq+tdmNsk2lI9K3kcJaUvcNQ1SEt7vQZeZsPBEp9MhDPAUF8KgLOVtGh+RFHfXurjp7ZCfNrZe9z46qRoF51nAA2ccCl1Ya39R3p26u/LM2zOVWA/WETyPlQdu1j+Fl/0ndJhh50K61qVbvEvYJz+AtqV7ApLqxourqif+8+RuTi7Tr5odp6L2B4cRj41TkujCD3FyN2RaoI/qY5ggjSHjFWl7G9mWp/DiRkzwxY5prg9Hux11AoKoRFx6IvOeiMSJsL9oDU/D1mTjieeJB2NgL3n3vAXoXcajiPuEbv+dWeXjfUWvX1B6knaU1VB8nU691Q4AQGp2e2leZMjWP5K3Lu9/caqa7ALsGGi7XtjDR1vPxzU1S74z3KCGewPZk/dJLPOCe7M00/SSu3E4xE6sb0EjL07IzSD4ibAsknaKAE7OMFTm2vQwylUVB7OZMKgvsrIFJosTv51AUVIoytzMZnsEcLFTvhqx5/9i6qTvnkXO9O/02VEXSalm6NYVIcbw0HAOkZHsZRJtbOw6BW1tUyHbx7PVkSFG5+y5JAHsYFumz34gkORM/1JGQ/MJhkZMpxAJHG/wCYnvnjdRMRgNSnkjKV+LraX40ZpZ2+XVXiKDEe9hjo/ASKcekNMMDOXBjvUZ+PgzFvpcvSYN0fr6bXxiOI+xvks0kLRsFXtXRAblVz/d2vKTVEc9qSBdmAzG4VTc+nP6FXWVEnWGWZW6xGcsv6ts7YMXDwbz7A2RvSmwumzWxDM4dozfqoQUH8J+oFwyFnNBXG0wdLEa69AR6NFwyEg8vU8zKLsgsZ7G+3j5leUQAqlCWgOaHTPkX1SQ+wtPmDCrUDCDJKdEpMggZPdgQ3gutqZVPeGNn6s=
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:PH0PR11MB4966.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230001)(366004)(122000001)(38100700002)(6486002)(2616005)(5660300002)(30864003)(54906003)(6916009)(2906002)(38070700005)(6512007)(508600001)(316002)(53546011)(33656002)(966005)(166002)(224303003)(6506007)(186003)(91956017)(66574015)(64756008)(71200400001)(66556008)(66946007)(4326008)(66476007)(66446008)(8936002)(83380400001)(86362001)(76116006)(36756003)(45980500001); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 2
x-ms-exchange-antispam-messagedata-0: REMippsfl/jpkhT7Pqu6jDvXcCVs4hitroqfjyIIC4yARq91RTjcuZmhqPntHzX6s/tsvMrpKS8mTv8m18ZnVJAKj5Eobn3F6Mclby0XJ8kVdHzBV6onDZS17vGdYPIRuTjLbl46sgWYS+wr/zrbkUKFRUFgBbPOgVr+aWslTcPOs3F5NQdWgIsoOga1yrR9kdz+3qlWHNlSLqc11CSXk/0/Rk6A8BhArx/b+vhWjvjL43ulOKrBR+x1S23NHoYkA3P/ktD9U6dvY+vU2/Va45EfmDfCIBiT5GF5xBRy3+m2pGVBmNY2dyUfOTCotdiZ4y8KL21Ppk7HcxIMYfoxDAnXChvmdQadIpdQfE9rlwmFMK/TnvlVCuBqdRZxkdJvjLn34xOUw7Ruy3CitdOtsYvyD2FGDd3oZPKf/lGj4gefXuXmKwANDv8oGq9AdYsWletRL3UyXFa6nVuWxMR0c+3oy189e6Oh0gkfk5DfIJCPN6KmUzT7gTvSPH7xvRaK+HrrZRgsXsl7lPg6/yHe/1Pi70xb4OAMuLXg40WO6cbEWqteVNTSyE1KCPXxHIdSEuqdCEyyqjkphCx/f6WGM6QvDnSmeEUwrv/xSUyNOChvrwIcjmdeXxZc688hfLt5H2HomLiFBI6bM3T6tkqnomWCVwAA7p3KbGEKQ8F4wo5HKENOqCc85huU8gpEHLdyHUXZk98ypLAF6FGTjJqLBLefQAHE7DsXZZkchHqkJxpwkoAhSnYArQIfoNf3bfhofj6IlhTQuJ+/PHcCHUTRwnrK5NAc4kKX0yrWDWlzEI6HpDFWl66Ha+7f70Tk7pp65TTdZBzCaZKTTg7RjsjaOOs+TieqNF23FRt6Vhzi4GffdSpcbjexuxPX9hllvB2mVjgLnL5KALyado1Ak0QMHB2sVuXO8jJ3CufBFkTBULTp3Ss4POkhymzQC++8yZbCEsYWLoHYWeXOlvSQyK45iIeDv3yR4OZAr3TLoiTouh9PIdWAKKF9H/6A7dM2PPXmiY0BFn+/RTMZPHJc9em8CMCnH2JKOCFzad9AjOKVDkD8/oZyZVOQBwr5YnLKvz0r7fgi5BVGg17PGHWOTeSiMbVg592nD84e+deDDYOSeS985mfw4wrNTy6aZhyFr2fQBDmEiT/WzdB9/67shMdarLmzQf85J6FZKIH2HQeAi8rcZhvGnyVrNX8A/eoJ8b4KSqjwu8mVl5L+kiNWHCC5A7JiBHXo/s8WIMOEgnm+qvaNFSCPgTe2etDSJmx/hPls8dbQHnajg5oWHFQrebUIYaXHgw4u0iEy+649ihxKJmO9dOzyaRfCLPjANyq1h9ZuEuMg16nJb2OTCumI5RHbE0Tbt5H1QRiIMs7wIGZDhCBvWKYO/EOgLVAfYKioRfO5xoSz7dPXhAvqC/NETbPxsCYKJ3yi4axQa1rHfeqSNpGv1xz5daD0ClXkxYNtZo99hLgFo96mEOz6Kdz3HZDcMNU+qK4CH7c9CRir3V0vhikZznuvsClJp8TUIuiZ6GbsRLic0GePAloHS/iEQ8G7vzQtlMn+AGdS93mnYUQl+U64Nmd0Z/vEA1zATWsNcUfxwgPp6sjVIseLxRRmJ0VM4t211h23Bhl0hOPqkX9HHG+L99SCpEjoPz1BlqVskAFv5FDBmmE6ipIIZSpuwM5+nTYXTFLw32MHdF4AIgv5dV7oe8OMU+JIzGMlo1MKDhwRf0lqYNxA3Na1hIuHoJZeLSCWF3q8u+CYmhkJ7RI0bzs0RWeL/vB6q0RBWSyxowzRn/V93hZI
x-ms-exchange-antispam-messagedata-1: 9u+GFiGrb1uUAw==
Content-Type: multipart/alternative; boundary="_000_1E0B27642FE9430FA89D0CA7EA0D5405ciscocom_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: PH0PR11MB4966.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: f74a7f30-3747-427e-2a80-08da1c9b9c51
X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Apr 2022 15:46:29.3483 (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: R9o94fD1NdPMfGT8KCPAj+IkMHYq7Kif3fElylfvyaxis9tgUBA61+uMmaGMCjvmy+t5k0xoOBBkWAe6h87dLQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR11MB3702
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.37.135.121, xfe-aln-001.cisco.com
X-Outbound-Node: alln-core-8.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/detnet/vOZjU-tqisGpE4hj0UPGiYXAT-I>
Subject: Re: [Detnet] Éric Vyncke's No Objection on draft-ietf-detnet-bounded-latency-09: (with COMMENT)
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: Tue, 12 Apr 2022 15:46:41 -0000

Hello Ehsan,

Thank you for your reply, my previous email was mainly about non-blocking points but I appreciate that you took time to reply.

Additional comments indicated by EV> (else all the rest is fine)

Regards

-éric


From: Mohammadpour Ehsan <ehsan.mohammadpour@epfl.ch>
Date: Wednesday, 6 April 2022 at 23:42
To: Eric Vyncke <evyncke@cisco.com>
Cc: The IESG <iesg@ietf.org>, "draft-ietf-detnet-bounded-latency@ietf.org" <draft-ietf-detnet-bounded-latency@ietf.org>, DetNet Chairs <detnet-chairs@ietf.org>, DetNet WG <detnet@ietf.org>, Lou Berger <lberger@labn.net>, "dns@fl1ger.de" <dns@fl1ger.de>
Subject: Re: Éric Vyncke's No Objection on draft-ietf-detnet-bounded-latency-09: (with COMMENT)

Dear Éric,

Thank you very much for your comments. Please find below my responses.




Please note that I am not a DetNet expert, hence some comments are possibly not
relevant. The use of "regulator" instead of "shaper" was also surprising to me
;-) There may even be a semantic difference between a shaper and a regulator
that I have to learn.

"regulator" is the "shaper" defined in RFC2475. In time-sensitive networks, a common referred mechanisms is “credit-based shaper”, which does not perform as a shaper defined in RFC2475. Moreover, the term "regulator” has been used frequently in the literature especially with the emergence of "interleaved regulators”. Hence to avoid possible confusion regarding the term “shaper", we decided to use “regulator”,

EV> Thank you


More generally, the document is about a bound on the latency, but would it be
possible to compute an aggregate latency curve, which could also be interesting?

I am not sure that I understand the term “aggregate latency curve”. Do you mean latency bounds on an aggregate of flows sharing a queue?

EV> rather than a single point (the top bound), I was alluding to have more like a probability distribution of the latency



## Abstract

The document goes beyond "it provides a methodology to compute end-to-end
latency" as it describes how admission control is important and gives formulas
to compute the latency bounds in many technologies. The content is great but
the abstract should reflect the actual content.

As mentioned in the last line of the abstract:
"The methodology can be used by the management and control planes and by resource reservation algorithms to provide bounded latency and zero congestion loss for the DetNet service”,
the focus of Bounded Latency I.D. is not admission control; however, it gives some guidelines on how it can be used in the admission control without jumping into details. Section 6.4.2 gives an example on this for a specific mechanism.




## Section 1

"DetNet flows are characterized by" is followed by only 2 characteristics of
DetNet and does not mention low packet loss. Even if this I-D is about latency,
why not adding "notably" in the text ?

In the new version, we change the sentence to:

"As explained in [RFC8655<https://www.ietf.org/archive/id/draft-ietf-detnet-bounded-latency-09.html#RFC8655>], DetNet flows are notably characterized by…"

EV> sounds better ;-)

## Section 2

As noted by other ADs, either the acronym "PROEF" or its expansion is wrong ;-)

It is typo and should have been “PREOF”. It is corrected in the new version.



## Section 3.1.1

Perhaps some examples of "static latency" could be added to ease the reading ?
E.g., does it include serialisation and propagation times ?
Have the authors considered the use of "constant" rather than "static" ?

Here, “static” refers to “latency calculation”, meaning that the latency calculation is done statically. We believe that a hyphen is necessary. In the new version, we change it “static latency-calculation”. The same has applied in “dynamic latency-calculation”.

EV> up to the authors

## Section 3.2

Does DetNet support some link having some flow control / congestion at layer-2
or layer-1 ?

Are there any DetNet relay able to start forwarding packet after receiving just
a couple of bytes of the frame w/o having to wait for the full frame reception
? Similarly, should the deserialisation delay be taken into account ? Or any
congestion inside a relay node (e.g., contention to a backplane bus)

In this document, a DetNet relay node is characterized as a service curve, which is used for delay bound computation. Therefore, any implementation-specific detail, e.g., fast-forwarding, serialization, deserialization, is included in the service curve. The methodology presented in this document holds independent of such implementation-specific details.

EV> ack

## Section 4.1

Is "end-to-end delay" defined in DetNet architecture ? I.e., is it from first
bit out from the source to the last bit received by the destination ? Or other
variation ? Or the difference is so small that it does not care ?

To the best of our knowledge, the exact definition of “end-to-end delay” is not present in the DetNet architecture RFC8655. In our document, we refer to the “end-to-end delay” as start of transmission of a packet from source (or DetNet ingress node) until its full reception at destination (or DetNet egress node), i.e., from first bit out from the source (or DetNet ingress node) to the last bit received by the destination (or DetNet egress node).



## Section 4.4

Sorry couldn't resist in suggesting to rename "DetNet-unaware island" into
"DetNet-unaware swamp" ;-) (comment to be ignored of course)

The term “island” has been used in some other RFCs within a similar context:

RFC9055 (Deterministic Networking Security Considerations): “DetNet islands”
RFC8578 (Deterministic Networking Use Cases): "Layer 2 Islands"



## Section 5

Should some assumptions be listed ? E.g., no packet
replication/generation/encapsulation/discard by the relay node ?

In the new version, we made the assumptions clear for the computed bound.

EV> thanks

## Section 6.1

Is the list at the end of this section exhaustive ? If so, then why not adding
"IP protocol (e.g., UDP or TCP)" ? Else, please let's be clear that it is not
exhaustive.
No, it is not an exhaustive list. It is corrected in the new version.



# NITS

AFAIK, XML2RFCv3 has features for mathematical formulas that could be used for
this document to increase readability.
Thanks for the suggestion. Are you referring to RFC7991?

EV> or using UTF-8 for unicode characters


Usually, "e.g." is followed by a coma. Same for "i.e.".

It is corrected in the new version.



## Section 1

Multiple lists in the section would benefit from a correct markup to put one
bullet per line.

It is modified in the new version.


In "It disregards the in-band packets", and accept all my apologies for not
being a native English speaker, but "disregards" sounds really negative.
Corrected in the new version!


## Section 6.3

s/Time Aware Shaper/Time-Aware Shaper/ ?
Corrected!






Best,
Ehsan



--
Ehsan Mohammadpour
PhD candidate at Swiss Federal Institute of Technology (EPFL)
EPFL EDIC PhD student representative
IC IINFCOM, LCA2, INF 011, Station 14, 1015 Lausanne, Switzerland
https://people.epfl.ch/ehsan.mohammadpour




On 5 Apr 2022, at 14:21, Éric Vyncke via Datatracker <noreply@ietf.org<mailto:noreply@ietf.org>> wrote:

Éric Vyncke has entered the following ballot position for
draft-ietf-detnet-bounded-latency-09: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-detnet-bounded-latency/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thank you for the work put into this document. It was a fascinating read and
most of the text is easy to understand. Good job ! Could even end up as
educational material ;-)

Please find below some non-blocking COMMENT points (but replies would be
appreciated even if only for my own education), and some nits.

Special thanks to:

- Lou Berger for the shepherd's write-up including the absence of
implementations

- Ralf Weber for his IETF last call INT directorate review at:
https://datatracker.ietf.org/doc/review-ietf-detnet-bounded-latency-08-intdir-lc-weber-2022-02-06/.
Ralf's review was acted upon by Mohammadpour Ehsan ;-)

I hope that this helps to improve the document,

Regards,

-éric

Please note that I am not a DetNet expert, hence some comments are possibly not
relevant. The use of "regulator" instead of "shaper" was also surprising to me
;-) There may even be a semantic difference between a shaper and a regulator
that I have to learn.

More generally, the document is about a bound on the latency, but would it be
possible to compute an aggregate latency curve, which could also be interesting?

## Abstract

The document goes beyond "it provides a methodology to compute end-to-end
latency" as it describes how admission control is important and gives formulas
to compute the latency bounds in many technologies. The content is great but
the abstract should reflect the actual content.

## Section 1

"DetNet flows are characterized by" is followed by only 2 characteristics of
DetNet and does not mention low packet loss. Even if this I-D is about latency,
why not adding "notably" in the text ?

## Section 2

As noted by other ADs, either the acronym "PROEF" or its expansion is wrong ;-)

## Section 3.1.1

Perhaps some examples of "static latency" could be added to ease the reading ?
E.g., does it include serialisation and propagation times ?

Have the authors considered the use of "constant" rather than "static" ?

## Section 3.2

Does DetNet support some link having some flow control / congestion at layer-2
or layer-1 ?

Are there any DetNet relay able to start forwarding packet after receiving just
a couple of bytes of the frame w/o having to wait for the full frame reception
? Similarly, should the deserialisation delay be taken into account ? Or any
congestion inside a relay node (e.g., contention to a backplane bus)

## Section 4.1

Is "end-to-end delay" defined in DetNet architecture ? I.e., is it from first
bit out from the source to the last bit received by the destination ? Or other
variation ? Or the difference is so small that it does not care ?

## Section 4.4

Sorry couldn't resist in suggesting to rename "DetNet-unaware island" into
"DetNet-unaware swamp" ;-) (comment to be ignored of course)

## Section 5

Should some assumptions be listed ? E.g., no packet
replication/generation/encapsulation/discard by the relay node ?

## Section 6.1

Is the list at the end of this section exhaustive ? If so, then why not adding
"IP protocol (e.g., UDP or TCP)" ? Else, please let's be clear that it is not
exhaustive.

# NITS

AFAIK, XML2RFCv3 has features for mathematical formulas that could be used for
this document to increase readability.

Usually, "e.g." is followed by a coma. Same for "i.e.".

## Section 1

Multiple lists in the section would benefit from a correct markup to put one
bullet per line.

In "It disregards the in-band packets", and accept all my apologies for not
being a native English speaker, but "disregards" sounds really negative.

## Section 6.3

s/Time Aware Shaper/Time-Aware Shaper/ ?