Re: [Raw] FW: I-D Action: draft-ietf-raw-architecture-10.txt

"Pascal Thubert (pthubert)" <pthubert@cisco.com> Tue, 06 December 2022 08:25 UTC

Return-Path: <pthubert@cisco.com>
X-Original-To: raw@ietfa.amsl.com
Delivered-To: raw@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F45AC157B5B; Tue, 6 Dec 2022 00:25:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -11.898
X-Spam-Level:
X-Spam-Status: No, score=-11.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_NONE=0.001, 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=VsPpw68R; dkim=pass (1024-bit key) header.d=cisco.com header.b=DPrHsyME
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 DwxZWHbCP6A3; Tue, 6 Dec 2022 00:24:59 -0800 (PST)
Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DB5DFC14CE2E; Tue, 6 Dec 2022 00:24:58 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=16171; q=dns/txt; s=iport; t=1670315099; x=1671524699; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=lbE8mWqFxo772lVfUlVVrEpSVmDg+lSZK1LkFpaH/vI=; b=VsPpw68RxWPItwFfVjzJA1shp50B1aDmqU6h9WniMbYXALrKcDVgnnhV L3R8L4GZbox/XizbR3n272WyF1Syaomr9yChr0ebZvmNS+EEDF8dbxfU6 DtgoOfSw3DI59TOqRSC7sh40jPELumljlzo/P5eoshZ/0Sbrx+wYpH6oX 0=;
X-IPAS-Result: A0AZAADy+45jmIgNJK1aHAEBAQEBAQcBARIBAQQEAQFAgTsHAQELAYFaKiiBBAJZOkWIGgOEUF+IHgOBE49viweBLBSBEQNWDwEBAQ0BATsJBAEBgVIBgzIChQ4CJTQJDgECBAEBAQEDAgMBAQEBAQEDAQEFAQEBAgEHBBQBAQEBAQEBAR4ZBQ4QJ4VoDYZVAQEBAQIBEhUTBgEBNwEECwIBCA4EJBAyFw4BAQQBDQ0TAwSCXAGCfyMDAQ+geAGBPwKKH3iBATOBAYIIAQEGBASBOAEDAgIOQZ0OAwaBQAGHNHWIbiccgUlEgRQBQ4FmSjc+gkAiAQEBAQGBJwEBCwQDASOEDoIuj3MBhyUOgQg3A0QdQAMLOzIKRTUGBRFMEBscGweBDCoJHxUDBAQDAgYTAyACDSgxFAQpEw0rJm0JAgMhYQUDAwQoLAMJIAQcBxURJjwHVhImBAMCDyA4BgMJAwIfVH4lJgUDCxUlCAVJBAg3BQZTEgIKERIPBQEmRQ5IPjkWBidBATAODhMDXYFpBDNIgSkKAi0umBNfgSQEFhVMASJBBC8CEg4CBBwvAQcGCRUKGBMdCgcfLwsXKZIGFBoKArAMCoNpi1GVJhaDeYxWl29el0AggiuKepRiFhMNAYR0AgQCBAUCDgEBBoFiOmtwcBWDIlIZD44gDA0JgQQBB4JEhRSFSnUCOQIHCwEBAwmGTHqCWQEB
IronPort-PHdr: A9a23:6DQRdxzOuyrmR7bXCzPZngc9DxPP8534PQ8Qv5wgjb8GMqGu5I/rM 0GX4/JxxETIUoPW57Mh6aLWvqnsVHZG7cOHt3YPI5BJXgUO3MMRmQFoCcWZCEr9efjtaSFyH MlLWFJ/uX+hNk0AE8flbFqUqXq3vlYv
IronPort-Data: A9a23:CgnUGqrGQM7FMYgHBv7+0bVFvGdeBmIzZRIvgKrLsJaIsI4StFCzt garIBmDaK6Iajf0fIpwbIi29ElT65WEyYRiGlY9rCtnFCJD9uPIVI+TRqvS04x+DSFioGZPt Zh2hgzodZhsJpPkjk7xdOCn9xGQ7InQLlbGILas1htZGEk1Fk/NtTo5w7Rj29Qw34Dga++wk YqaT/P3aQfNNwFcagr424rbwP+4lK2v0N+wlgVWicFj5DcypVFMZH4sDf3Zw0/Df2VhNrXSq 9AvY12O1jixEx8FUrtJm1tgG6EAaua60QOm0hK6V0U+6/RPjnRa70o1CBYTQUANh2mbvI9w9 NYOv82tUDsKJZHyqM1IBnG0EwkmVUFH0LbDJX76usuJwgidNXDt2P5pSkoxOOX0+M4uXjoIr qJecWtLN0vd7w616OrTpu1EntgjMcPmJp83sXB7xjafBvEjKXzGa/+Qu4MHjWdr7ixINcvQW fgCYxB2V03vRCB/JlxPLs4fkc790xETdBUB+A7K+sLb+VP7wAFt1rXxddHVc92QXu1Uk1qW4 GXc8AzRGBgFcdefwDuf6Vqti/PB2yThV+o6DrSn3v9nnFPVwXYcYDUaW1a3sPqRjke0XZRZJ lB8x8Y1haE28EruRd7nUljj5nWFpRUbHdFXFoXW9T1h1ILTuQrFFEtbTwJCK9Z3qdYKZicW6 G+gyoaB6SNUjJWZTneU97GxpDy0ODQIIWJqWcPiZVZeizUEiNxu5i8jXuqPA4bu1YSsRm+YL ySi6Xlg2epC1Kbnwo3hpTj6bySQSo8lp+LfzizTWm+jhu+STNH4P9XzgbQ3AAopEWp0ZlCFu H5BkM+E4aVVS5qMjyeKBu4KGdlFBspp0hWC2TaD/LF4qFxBHkJPm6gLuVmSw28yaK45lcfBO hO7hO+ozMY70IGWRaF2eZmtLM8h0LLtE9/oPtiNMIUWOMYsLFTdp3w+DaJ144wLuBVz+U3YE crLGftA8V5BYUia5GPsHrxEgeNDKt4WnDqPHPgXMChLIZLHNCLKFt/pwXOFb/sy6+ufsR7J/ tNEX/ZmOD0BONASlhL/qNZJRXhTdCBTLcmv96R/KLXZSiI4Qz5JNhMk6e57E2CTt/4Lxr6gE 7DUchIw9WcTclWeeFvQMSo9Mu6/NXu9xFpiVRER0Z+T8yBLSe6SAG03LfPboZFPGDRf8MNJ
IronPort-HdrOrdr: A9a23:iwqaraoMFucNZJo7nK+aahwaV5uAL9V00zEX/kB9WHVpm5Oj+f xGzc516farslossSkb6K+90KnpewK5yXcH2/huAV7EZniohILIFvAv0WKG+Vzd8kLFh5ZgPS kLSdkENDSdNykZsS++2njFLz9C+qjIzEnLv5al854Fd2gDAMsMj3YbNu/YKDwKeOAsP+tfKH Po3Ls/m9PWQwVwUi3UPAhhY8Hz4/nw0L72ax8PABAqrCOUiymz1bL8Gx+Emj8DTjJm294ZgC n4uj28wp/mn+Cwyxfa2WOWxY9RgsHdxtxKA9HJotQJKw/rlh2jaO1aKv2/VXEO0aKSAWQR4Z zxSiQbToBOArTqDyaISC7WqkvdOfAVmjnfIBGj8CLeSIfCNUMH4oJ69PJkm13imhIdVBUW6t MQ44pf3KAnVi8o1R6NlOTgRlVkkFG5rmEllvNWh3tDUZEGYLsUtoAH+lhJea1wVx4SxbpXWd WGNvusrMp+YBefdTTUr2NvyNujUjA6GQqHWFELvoiQ3yJNlH50wkMEzIhH901wua4VWt1B/a DJI65onLZBQosfar98Hv4IRY+yBnbWSRzBPWqOKRDsFb0BOXjKt5nriY9Frt2CadgN1t8/iZ 7BWFRXuSo7fF/vE9SH2NlR/hXEUAyGLELQIwFllu9EU5HHNc7W2He4OSITeuOb0oAiPvE=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.96,220,1665446400"; d="scan'208";a="22647983"
Received: from alln-core-3.cisco.com ([173.36.13.136]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 06 Dec 2022 08:24:56 +0000
Received: from mail.cisco.com (xfe-rtp-005.cisco.com [64.101.210.235]) by alln-core-3.cisco.com (8.15.2/8.15.2) with ESMTPS id 2B68OuGx015733 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=OK); Tue, 6 Dec 2022 08:24:56 GMT
Received: from xfe-rcd-001.cisco.com (173.37.227.249) by xfe-rtp-005.cisco.com (64.101.210.235) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1118.9; Tue, 6 Dec 2022 03:24:55 -0500
Received: from NAM10-MW2-obe.outbound.protection.outlook.com (72.163.14.9) by xfe-rcd-001.cisco.com (173.37.227.249) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1118.9 via Frontend Transport; Tue, 6 Dec 2022 02:24:55 -0600
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=AI6BReHSlLh/ubsiQ9zxiuKMMY8lLbvjLw1HfIVCPx2eVJqaRBBoQ9S/nkzrZmBpD513jv0gKdQK3wVgOKoii355FsyCEBkPURCudbc+fJklJmqer8OnbhHi4wYD9BaThBbC7FMXujD+7jfySy0Zigxwdav5FpvnokgTpE0h33ooXGeiFxMtv1FwYZogBu1+Liac9UNuaYxX549hi1xRGSJERUm2qxP9CCokhv8oEYn6wYeMwXxo93L5lNeTPogxxUNHD/smCcFCjJJ21fE/o/f55pHp0LnhIfDSRAIqXv6zdc0rt/T93lBzo3aPMt5Kge0ZlW+aXyUOrFSKvFoORQ==
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=Yuwl+2hdrIQbbItl36Q3qYGQHub44ZgOg/6XcJoFQlw=; b=Djn3ImVux+y3q77Rbe3gTTl7MFnJ6NLcLXzd+MLI0iM11dmR1H7x0grZgW0px1ZvT7Xe6Sl43yRnwVO6R6/ADR3Msopvf1As7lBiNPboLl0ldaeFguoTerkgvCGHH3dJJB7AFR9Sj7x0Sto4ceJg/61EA/qvJwz13unYcuMu8MaUucBExT6EuQaGyJidHnedoNH4Cg4W464fbLefJ/jhj8lzph36weLONmR2eUSNaTXkztC206lxs9poNKyYMEfHBRNaSo4fGrPXw1E3AXFOU4SgpOtM7O0D90WAvSqLKQ0GcXkeuzzvKo9W9E8jXq5Pz2j//6aEBFWxaXr1v4aVsQ==
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.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Yuwl+2hdrIQbbItl36Q3qYGQHub44ZgOg/6XcJoFQlw=; b=DPrHsyMEFnz0fLPXVhof1V2s4CNi9tpXrSkw2w/PoOF18xXjsniPGx0C3o0M96faLAc3yGIpGdrCs6MfHoesxw+L20asZcTqiWdt5VHwNoPsu4bzTSYtFsZHRr1CD6Z0iXtO829dcxG5ZmzN0oV+2Xk6QCEjt2RBk6mzNd1eJu8=
Received: from CO1PR11MB4881.namprd11.prod.outlook.com (2603:10b6:303:91::20) by DS0PR11MB6471.namprd11.prod.outlook.com (2603:10b6:8:c1::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5880.14; Tue, 6 Dec 2022 08:24:53 +0000
Received: from CO1PR11MB4881.namprd11.prod.outlook.com ([fe80::20d9:5c5:9e71:961]) by CO1PR11MB4881.namprd11.prod.outlook.com ([fe80::20d9:5c5:9e71:961%5]) with mapi id 15.20.5880.014; Tue, 6 Dec 2022 08:24:53 +0000
From: "Pascal Thubert (pthubert)" <pthubert@cisco.com>
To: Don Fedyk <dfedyk@labn.net>, "raw@ietf.org" <raw@ietf.org>
CC: "raw-chairs@ietf.org" <raw-chairs@ietf.org>, DetNet Chairs <detnet-chairs@ietf.org>
Thread-Topic: [Raw] FW: I-D Action: draft-ietf-raw-architecture-10.txt
Thread-Index: AdkEItll7BSqIYXSTzSZRt2iSLPriQBY4mwAACFtu4AAzMQL4A==
Date: Tue, 06 Dec 2022 08:24:37 +0000
Deferred-Delivery: Tue, 6 Dec 2022 08:24:29 +0000
Message-ID: <CO1PR11MB488152BC4C60D7CC46BCD2D0D81B9@CO1PR11MB4881.namprd11.prod.outlook.com>
References: <PH7PR14MB5368821B6264F94D957C4C3DBB129@PH7PR14MB5368.namprd14.prod.outlook.com> <CO1PR11MB488180EC042045C886385915D8149@CO1PR11MB4881.namprd11.prod.outlook.com> <PH7PR14MB536823D28FBA120DEBE9A4F7BB179@PH7PR14MB5368.namprd14.prod.outlook.com>
In-Reply-To: <PH7PR14MB536823D28FBA120DEBE9A4F7BB179@PH7PR14MB5368.namprd14.prod.outlook.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-traffictypediagnostic: CO1PR11MB4881:EE_|DS0PR11MB6471:EE_
x-ms-office365-filtering-correlation-id: 2e8bac45-a2fd-4267-53a9-08dad763598e
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: X25gXjebutjKOZSlXkrRVxZA1gzCzEM7gVWNm2c/DOMpFO+RzTCLBeAPIH9Vp9FiM9RRN1SgjGwaswPzalD1cNJrhJLRnsq7WDCqaDutzrh1R73p8piK5rY8pkeP9HUmHINefs9U/lY+w4v6cKk/v/RGKwwi7mEIqTtVRp2PzsuTf8WIHTDSiDc3lNuo40R3OCH0V5LHN5NcvZP+E6yWUhyQV3BL8HyGbLr365m5dRt9Ah+3n+KKVjkSyOwjpBAjDe9OMuL3kK0PACNbDRbW6L9Qov6GBgPfFAJIFC/atw/5lpCtEC1h6xrTWNQlldGJMli7/cQnX1+pJV/pKmpAp5csty1dQT9rxLqNUuiE2jOutKNof8A0/tdS51IxmKzOHwTf9Bayu2UU1jsmvKpdKABIBbbm/tRE1QsrmFsfxmciLkp8CGois85ViXeCf7LKEILaVnFcQhKMDKzcRl2yhKaiew8FIGA2Z2GbRL5nyiMj5dwrQxETAdcVD1P9D5hta2G7/WWdJxJrw5uhIy9ZMtBeev4idpRw2EG/5PNoj8m1y1TNNUWonKKjJAFX8CuCs+T6aM/pD0ljmbVSR+1UKQF8aRe1kIX6RinBIdlGJyb9w2BHYGtzizmHabi63ghmeaViGGA2/Ir2gbfR0EDpx6OQ5f/i46164mC9zD1JGW9EPqsqhNtawb8w/shrVChLHN8tzfozMCG5H41ujS4RzrOg0I+NZJU3IEfpqjF30D6pnevKtfwps9LYBt76qv0BHcEaJRhv2gvSXVpikynXiA==
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:(13230022)(4636009)(366004)(136003)(376002)(396003)(346002)(39860400002)(451199015)(83380400001)(2906002)(66899015)(33656002)(55016003)(76116006)(41300700001)(86362001)(38100700002)(110136005)(26005)(186003)(9686003)(38070700005)(71200400001)(8936002)(8676002)(66556008)(5660300002)(4326008)(64756008)(66946007)(122000001)(66476007)(66446008)(30864003)(6666004)(316002)(6506007)(966005)(7696005)(52536014)(54906003)(478600001); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: DFEX3loziMdpz1u9DW8YJk8XTpY8IDXBOILX9aN4L56n1qC/KRIytTeiU2LYgUL0N7sYsYwoYpfWB/K2UkpfkiCRnSRiWhDBmrxhs1xyGgzoRwoQ4LK/D3HzD2w/lnOF1KztiHlPfnygB4cbM8VSy4nGdEAh680Nf2swskrIwDARkYNSxzegM5qFZnxqZKtpDTg7Is/KgwYc40nLQmvegelI4BACbCDFAt1cxPlw63hWYhGxad6k2lL7chbWIQmCspMbG+Nl8BW0BBLybmNeGpDA2pCIPNAIQvhFhyboGKXXGRm0/CFgLzaRfcYymkWZSX0Mk+NlndNCSuBWSYHC3NTpNMQZH1iu9mWhjJZNyCN5atrGVTYCWP+jNi3Sl/JgWufnGNQR5ud/egdEd9yGMv5Au2R3+Wo8/FFhdIVzSrqFL44vd/fdq4hD9eDBoCeqgoL+XF/ykmPaWWUeGFVy22IK8zsa6/QoVoxCqZ+MQ0J1N0YSjy4JPrkXitm0RlPVylgwQoLXUxpZvzdqlfMwH8ae9lQA23HWT6oDMrtMBq/QK1RUPtpkn90mwu6H9DTR/Nq0C5FT2Q1T4ZrIsCqjy2fuYfxRs4KIgfjNB8cMR88Xf4b4NF0xcxsBJaVswLmbIcWYGiXNRkwXnUiQjAqtwoZgIn7VDcCrrHx+vJiI2hivF9K79LAILNqkd2gZ23FF1kTOFwdFjdyfzVyAkQHeuy6+ONOQYpRnFE6DQh71Y3MaxsxVsGPn9bhYAZzeJ1pHKD6zasJr190i3/yI2d9gym/AIfUDO2MN2eI54S1Djxdy5GC4gn0FiNkY2OCUXeB7mNDp+siAxl4iqipdzi7QjLckeB6XQz5zLU29OfyBgSR/GGWDKPE+N+QE9/KpYKnGhAaFn9xMALxb+sBDZpB/yGHnsZjT82L/xKG7x098DtXV2Xi8pO3Hvj+nZ5kpdvz1VUGPf/O65dEK4OomiIVMzDMogMHbeNcrncyW1yVFiAOfKPtp9SEjwL2Fal8VC6szXFsm2sCz3P/Oz3ysKWG78woOht7nDhnw5mFqeKiSpGZ01ja8V0286cgdHySipKq8xLkzIoIxn1W1VC5oqdgv8oEnIzzBRLGycqPAcfrYtN1VFlgLEP/1Cpnno/GHLmoDg3B4N7GwzQq1FVrJ+gTwMny3lXp4m7Ud2K3/0BQwRLYn7WjppysiJZ/Ja+3uwTtsVAcq0m5cjoL1Hq3PkSLgkZ1IyV7jATfSPHD8lWrAmvMaMXMvyArax9Qw789MW5W+GP8KGEifZ+vneWDQchLZasl4k/vCac7Y9ukd9EBGDKlEgEMXgAbtKAHByemWMT6SwmTItD7d7cbivNqVMYbwZa24XaRztt/SQGDEg05kt1O0ptmuYErSp5RZqzeJIxuq4ro2EnCfYawiTPvJ0AxGZ426gSLnHplJVYRVfRdFFDIqW6QLNuCu7jW3yI/upT7SYhSvhdOyMVGeesqHGbuthqZq/k7g1pHwDGpj1ccqrQCRILkt+/kklsKUWKMA1xC0cMe7UELwUXvKnsj9nwlWTB032MZYG+Kbzr701O0rTON1iVkKTyMbO73z9h316odM
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
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: 2e8bac45-a2fd-4267-53a9-08dad763598e
X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Dec 2022 08:24:53.0267 (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: YGySRA3OVJ5GNuPfz2/B8p8xpDEyTmM27H1YMV+UL3CI7YQ+Hd/we41KO592FE45pqLoUrVY9wGc5zd82kvKOw==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS0PR11MB6471
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 64.101.210.235, xfe-rtp-005.cisco.com
X-Outbound-Node: alln-core-3.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/raw/LB7KSeWYDt7u1NIxcmNoXCqycfI>
Subject: Re: [Raw] FW: I-D Action: draft-ietf-raw-architecture-10.txt
X-BeenThere: raw@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: reliable and available wireless <raw.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/raw>, <mailto:raw-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/raw/>
List-Post: <mailto:raw@ietf.org>
List-Help: <mailto:raw-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/raw>, <mailto:raw-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 06 Dec 2022 08:25:04 -0000

Hello Don

> >I'm good with "protection" and I agree with the history you point out.
> >The way we use the Track appears consistent with that term to me too.
> 
> My point was "Track" is new to me - not been following Roll perhaps my
> bad but what I offered to do was define Track without using the term
> and see if the WG agreed Track was what to call it.

"Deterministic" Wireless has been an IETF topic for 10 years now. And Track is the term that was used all that time, see RFC 9030. There are a number of 6TiSCH people at RAW, including draft authors.

Think about the gnu track analogy: all the gnus follow the track but you do not know in advance where a particular gnu will leave the marks of its hooves. Once the herd has passed, one can see from above the track where the herd was, and observe the density of the marks on the ground. Similarly, when you do something like overhearing, the packet may be relayed by a node that is not the most intended next hop, so you do not really know where a packet passes until it did it. What we call a path is that observed experience after the fact, while the track is the a priori knowledge of the overall area where all the marks will be for the whole herd, the gnus ancestral knowledge if you like.

> I caught my self saying "protection path" then realized when
> talking with Lou that "Protection" embodies the whole concept.
> >

Happy to use that term

> >I'm not good with "RAW" since though RAW is using the concept, it did
> >not create it and is not the end of it.
> 
> I only used the term to mean the RAW flavor of protection.
> I'm fine dropping that.

Cool

> >We cannot ignore how much work has taken place at ROLL and 6TiSCH,
> >which contribute to the work on reliable and available Wireless by
> >providing the route installation and the forwarding over TSCH,
> >respectively.
> >
> >Just look at
> >https://datatracker.ietf.org/doc/html/draft-ietf-roll-dao-projection.
> >I cannot easily go and tell ROLL that the term they have been using
> >forever must now change because of RAW. And This draft is the only way
> >I'm aware of to build the Tracks in a centralized fashion - unless we
> >argue that PCEP is a valid contender in a wireless mesh?
> 
> Well, it points to RAW as the defining place for Track yes I see.

ROLL did not publish an architecture but ROLL and RAW do. Conversely, RAW and ROLL (mostly) do not define standards, 6TiSCH only designed the missing pieces that did not have a home, but for the most part, worked with other groups (to the point of helping start some). So far, ROLL has provided routing solutions for 6TiSCH and then RAW. Keeping those groups in tight sync is useful and necessary. This is not an IETF process, this is us. It is a mark of respect from RAW that we do not change the words that ROLL has been using to work with and for us. 


> 
> >
> >I suggest we settle for "Protection Track".
> 
> Again, not my decision but the WGs. Perhaps
> - Protection as the superset
> - Protection Track is then the active set of paths in that
>   protection scheme?
> - And Protection Tracks are the active set of paths for
>   separate services?
> 
> Googling images of track I realize that I like "lanes".
> Protection lanes?  Was lanes considered? Lanes are a subset of track.

ROLL has the term leg, though it is never used in conversation (as opposed to Track), and does not come from 6TiSCH but from the need to construct east west protection paths. I agree that lane is better. I'm OK to ask ROLL to change. Can you please look at the definition there:

>From https://www.ietf.org/archive/id/draft-ietf-roll-dao-projection-29.html
"
2.4.5.7. Leg

An end-to-end East-West serial path. A leg can be a Serial Track by itself or a subTrack of a complex Track with the same Ingress and Egress Nodes. With this specification, a Leg is installed by the Root of the main DODAG using a Non-Storing Mode P-DAO message, and it is expressed as a loose sequence of nodes that are joined by Track Segments.

As the Non-Storing Mode Via Information option (NSM-VIO) can only signal sequences of nodes, it takes one Non-Storing Mode P-DAO message per Leg to signal the structure of a complex Track.
Each NSM-VIO for the same TrackId but with a different Segment ID signals a different leg that the Track Ingress adds to the topology.
"

Also happy to import the resulting definition of "lane" in this architecture and refer from the ROLL document like we do for Track for consistency.
I sent a separate email on that to RAW 'n' ROLL.

> >
> >
> >> Remove Network Plane - It is a Data plane or a control plane.
> >> Rational Network plane is not a common term.
> >>
> >
> >See section   "4.4.3.  The Network Plane" of RFC 8655
> 
> I see it is a composite plane and still _rarely_ referenced in DetNet.
> I'm familiar with data plane, control plane, management plane and
> Network.  So OK my bad.  If the WG thinks it brings clarity then it is
> an established term.
> 
> 
> >> Remove OODA. - Rational the OODA loop is one type of feedback loop
> >> common in cybersecurity.  In RAW there are multiple feedback loops.
> >
> >It's a very abstract model and that's the only one we have defined a
> >mapping for. It fits very well the detnet network plane roles of PCE,
> >PSE, OAM and PAREO, respectively.
> >Do you have something in mind that does not match that model? Should
> we
> >describe it in the architecture?
> 
> It is the "orient" part I think is being forced.
> OODA looks to me like a larger system of multiple feedbacks.
> It is a general system and can be fitted to many situations.

It's a critical piece actually. Probably the hardest to do right. "orient" turns the history into prediction and prediction into recommendation (this link will fail occasionally, and here's the response to this situation). That's the process by which all the statistics/ML activities (e.g., about link reliability and availability) at the PCE are transformed into actionable rules/policies in the PSE (which is deterministic not statistical).


> 
> There are multiple feedback loops.
> 
> In control loops you have a system with an operating goal, a
> measurement function and feedback to maintain the goal.
> There is no orienting measurement is implicit in the feedback loop
> design.  Since we deal with packets and paths we have discrete steps
> thresholds and actions.

It is always there and it's typically called a PLC. The transforms the measurement into a decision action. "Orient" is the intelligence in that process; even if it is a plain mechanism, some intelligence designed that mechanism and that's the orient piece. See it as a transducer between sensing and actuating. In the example you give the PLC activity is not visible on the wire, only the resulting action decision is; with RAW, the PLC is split between PCE and PSE, and there will be a time where the "orientation" will be signaled.

> 
> There is also in theory a network manager role that tries to optimize
> over all service - maximizing network utility however when services are
> equal priority established services win over not yet established
> services. When
> priority is involved higher priority services win.
> I  contend this higher level does not exist and you either have equal
> services FIFO or priority services or both.

And the netAdmin (via NME) does the "orient" part by providing the policy to tag flows and the QoS engine does the "action" part.
 
> Again, a question for WG. Does OODA bring clarity over a simple feedback?

Waiting on a response. 

Note that the OODA loop was discussed many times at the RAW WG. The term has been there since the first publication as a WG document (01, since 00 is a republish of the personal submission as is). It was in every architecture presentation at least since IETF 111, see for instance the slide 1 (#2) of https://datatracker.ietf.org/meeting/111/materials/slides-111-raw-draft-ietf-raw-architecture-01


The actions I agreed upon and saw no objection:
- use the term "protection" 
- define lane in the RAW architecture and rename ROLL's leg to lane, provided ROLL does not oppose. The lanes are individual east west paths. Note: A protection path may use several lanes and join them (so a car can move from a lane to the other) using PAREO capabilities. 

Please let me know you still see a need for more changes;

All the best,

Pascal


> 
> 
> >
> >
> >>
> >> Details:
> >> Reading over the RAW architecture I would remove Track and refer to
> >> places where Track is used as as RAW protection and active RAW
> >> protection paths
> >> - This reuses IETF terminology.
> >> RFC 9030 defined a Track but it is not common use outside that
> group.
> >
> >It is used in the IETF wireless / IoT groups in INT area and RTG Area.
> >
> >
> >> The WG should then decide if a single term such is Track (or other)
> >> can be used.  My issue with the term Track is it is singular in
> >> nature and the usage here varies from singular to multiple.
> >
> >Agreed
> >
> >
> >> There are two fundamental concepts:
> >> a protection set and
> >> the active protection set.
> >
> >True. I figured from the discussion with Lou that the "active
> >protection set" is a TE path, so I changed the terminology to that in
> >the latest publication. Was that wrong? Note that as I insisted at the
> >WG meeting in London, the 2 sets are not of the same nature. The
> former
> >is a potential, the latter is an actual. Using "protection set"
> >for both hides that subtlety under the carpet.
> 
> I agree.
> >
> >
> >> Currently, the RAW Architecture talks about a Network plane.
> >> I think it means a data plane.  Network plane is not widely used.
> >>
> >> I would remove OODA loop.   There is not much reference to
> >> it in the IETF and I think it is more a security feedback loop than
> a
> >> run time operational feedback loop. We have feedback loops. I think
> >> the PAREO loop stays largely as as you have defined it.
> >
> >We do not have a PAREO loop. PAREO is the action in OODA.
> 
> Yes I agree I used the wrong wording for PAREO.
> >
> >> RAW (and other networks) have multiple feedback loops.
> >> Link state with statistics (comprises a topology feedback loop). RAW
> >> active protection path set and service statistics is another
> feedback
> >> loop.
> >
> >I'm not aware of feedback loop in the data plane though. The closest
> >I'm aware of would be FRR/LFA but that's not really a control loop,
> >more a reflex action to avoid a broken path.A
> 
> The feedback loop for QoS is RFC2386. Generally considered not a good
> idea. This is why I questioned the use of PAREO actions and why I
> suggest they should be limited.
> 
> >
> >> Currently the architecture allows RAW to ask for a path to be
> >> computed (one or several protection paths).
> >> Then RAW uses local decisions locally decide if it needs to refine
> >> the active path out of the set.  To maintain stability over all
> >> paths, path allocations of capacity should be sized to the fullest
> >> use of the protection path set assigned although locally RAW can
> >> decide not to use all paths.
> >
> >True. Do we need more words in the document on that?
> 
> I think so to alleviate the instability concerns.
> >
> >> I think for path computation RAW should assume it uses all resource
> >> allocated in "active RAW protection". When less resources are used
> >> over time
> >> - then it should relinquish the resources.
> >> This slow adjustment of the actual usage is another feedback loop.
> >>
> >> Here is what I think this looks like.
> >>
> >>                    +--------------+
> >>         +--------->+ Compute RAW  +-----------+
> >>         |          | Protection   |           |
> >>         |          | Paths        |           |
> >>         |          +--------+-----+           |
> >>         |                   ^                 |
> >>         |                   | Network         V
> >>  +------+---------+         | Link      +-----+-----+
> >>  |Request RAW     |         | State     |           |
> >>  |Service  Path   |         +-----------+Deploy and |
> >>  |                |                     |Monitor    |
> >>  |Traffic Request |         +-----------+RAW        |
> >>  |[Add or delete  |         | Service   |protection |
> >>  | Resources]     |         V State     |           |
> >>  +------+---------+   +-----+-------+   +-----+-----+
> >>         ^             |RAW actions  |         ^
> >>         |             |PAREO        +---------+
> >>         |             +-----+-------+  Local
> >>         |                   |          Change
> >>         |     Service       |
> >>         |     Change        |
> >>         +-------------------+
> >
> >I like this drawing, many thanks. The "Network Link State"
> >is not really correct though. More like "Network Link Stats", one
> >letter, very different meaning. Or both if we consider a permanent
> stat
> >of 0 to be a link down information.
> 
> Yes full link capacity to degraded to zero. I think you have better
> wording.
> 
> >
> >Just like there's async and periodic OAM-based "state"
> >information on links (passing, not passing, assumed reliability / PDR)
> >to the PSE, there must be periodic and async stats to the PCE. When
> the
> >stats differ to widely from those used to compute the Track, the PCE
> >may update or rebuild the protection Track. OTOH, if the stats remain
> >in an acceptable range, the PCE will rely on the PSE to adapt and
> >refrain from impacting the Track.
> >
> >This is the big difference between what the PSE and the PCE see. The
> >PSE sees links as usable or not at one instant. The PCE sees quality
> >stats over long periods. As opposed to classical IGPs the model in
> >radio networks has to accommodate link flapping smoothly. E.g., RPL is
> >built for that, that's why it builds DODAGs as opposed to trees.
> >
> >> There are three possibilities:
> >> - The quality is poor, and more resources need to be
> >>   requested.  If a RAW service determines that the service
> >>   is not getting sufficient packets through it should ask
> >>   for a better RAW protection (set of paths) .
> >>
> >> -The quality meets it targets and allocation of resources  stays
> >> constant.
> >>
> >> - The quality meets it target but the connection is
> >>   consuming excessive bandwidth/capacity.  Currently RAW
> >>   makes this determination locally.  I think that RAW
> >>   should release resources within
> >>   some bounds.
> >>
> >> This scheme should be set up to reduce the chance that RAW services
> >> will compete by over allocating (blocking) or under allocating
> >> (congesting).
> >
> >
> >True. Then again as a DetNet Extension, RAW uses provisioned resources
> >so on paper congesting is not part of the game. On paper, there should
> >be enough resources for all RAW flows using all the PCE allocated
> >resources. The game is to save
> >1) energy and 2) spectrum which can then be used by non-deterministic
> >flows.
> 
> >
> >Arguably, the link rate may vary (with MCF). OAM must capture that,
> and
> >the PSE of some flows will have to react and stop using that link,
> >while for other flows the link will remain usable. Maybe a sentence or
> >2 to clarify that is in order?
> 
> Yes, Even if you over allocate bandwidth there are cases where a loss
> will cause congestion. You can argue for queuing that sacrifices other
> flows before RAW flows but ultimately you may not be satisfying.
> Some environments/wireless links may be bandwidth starved.
> >
> >All the best,
> >
> >Pascal
> 
> And I apologize for not having given input earlier.
> 
> Cheers
> Don
> >
> >