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

"Pascal Thubert (pthubert)" <pthubert@cisco.com> Tue, 06 December 2022 11:44 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 B1B44C14CE2B; Tue, 6 Dec 2022 03:44:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.597
X-Spam-Level:
X-Spam-Status: No, score=-9.597 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_BLOCKED=0.001, 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=MZ4WicMy; dkim=pass (1024-bit key) header.d=cisco.com header.b=fOd6Rb9X
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 4bEYzbdHTbbn; Tue, 6 Dec 2022 03:44:27 -0800 (PST)
Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E9FFC14CE23; Tue, 6 Dec 2022 03:44:27 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=17799; q=dns/txt; s=iport; t=1670327067; x=1671536667; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=5dTpoV5xIiXyNkrEdA112Z4V18kD/3s4Vun0NAbMFds=; b=MZ4WicMyj1/QZYA+oCFiR44b5ExmVAnhXopKvFvoyMKzJRRebUvWT52d xWADNf2zEpBbI0IAJSt76CUXXUEv540u3Q2V2MLFe3GU5/Im7fe2rh9kC cELlgu+2x+oatBk3xNRLFOLIuYDKWaTQcUZSNYySZIhul3KgPbcsNZvOn Y=;
X-IPAS-Result: A0AZAACWKY9jmIoNJK1aHAEBAQEBAQcBARIBAQQEAQFAgTsHAQELAYFaKiiBBAJZOkWIGgOEUF+IHgOBE49viweBLBSBEQNWDwEBAQ0BATsJBAEBgVIBgzIChQ4CJTQJDgECBAEBAQEDAgMBAQEBAQEDAQEFAQEBAgEHBBQBAQEBAQEBAR4ZBQ4QJ4VoDYZVAQEBAQMSFRkBATcBCwQCAQgOAwEDAQEvMhcGCAEBBAENBQgTAwSCXAGDIgMBD6BqAYE/AoofeIEBM4EBgggBAQYEBIE4AQMEDkGdDgMGgUABhzR1iG4nHIFJRIEUAUOBZko3PoJiAQECAYEnAQELBAMBIySDaoIuj3MBE4cSDoEMNwNEHUADCzsyCkU1BgURTBAbHBsHgQwqCR8VAwQEAwIGEwMgAg0oMRQEKRMNKyZtCQIDIWEFAwMEKCwDCSAEHAcVESY8B1YSJgQDAg8gOAYDCQMCH1R+JSYFAwsVJQgFSQQINwUGUxICChESDwUBJkUOSD45FgYnQQEwDg4TA12BaQQzSIEpCgItLpgVX4EkBBYVTAEiQQQvAhIOAgQcLwEHBgkVChMFEx0KBx8vCxcpkgYUGgoCj3GgGwqDaYtRlSYWg3mMVpdvXpdAIIIrinqUYhYTDQGEdAIEAgQFAg4BAQaBYjprcHAVgyJSGQ+OIAwNCYEEAQeCRIUUhUp1CzACBwEKAQEDCYZMeoJZAQE
IronPort-PHdr: A9a23:y4ca7h1Ns76EirSssmDPr1BlVkEcU/3cMg0U788hjLRDOuSm8o/5N UPSrfNqkBfSXIrd5v4F7oies63pVWEap5rUtncEfc9AUhYfgpAQmAotSMeOFUz8KqvsaCo3V MRPXVNo5Te1K09QTc3/fFbV5Ha16G16Jw==
IronPort-Data: A9a23:hGdkS6giE8HwGl4d74oETxdwX161SxAKZh0ujC45NGQN5FlHY01je htvCGjSP6nYajbwLogjOY7joEIPvJeBydJkSlZkrC49ESxjpJueD7x1DKtf0wB+jyHnZBg6h ynLQoCYdKjYdleF+lH1dOKJQUBUjclkfJKkYAL/En03FFEMpBsJ00o5wbdj2tAw27BVPivU0 T/Mi5yHULOa82Yc3lI8s8pvfzs24ZweEBtB1rAPTagjUG32zhH5P7pDTU2FFEYUd6EPdgKMq 0kv+5nilo/R109F5tpICd8XeGVSKlLZFVDmZna7x8FOjzAazhHe3JrXO9I6YmgJlDOQpOx+5 95AmcygTFoiGJ3DzbF1vxlwS0mSPIVP/LvBZHO4q8HWkgvNcmDnxLNlC0Re0Y8wo7ksRzoQs 6VDbmlWPnhvhMruqF6/YvFwhtkpIdP3FIgeoXpnizreCJ7KRLiZGvWWuoIFgF/cgOhsE+v8e 8UeRgZ0S1eQRD5wY2kzDcIHybLAan7XKm0E9w39SbAMy2Te0Ap8zP3mMNPUYMeiRMhJkACfv G2u137wHVQRNNWe0yGt83+wiKnIhyyTcJgbC5W5++JkxlqJyQQ7BBMbWUq4if2wgEj4Xd9DQ 3H44QInqaw0sUesVNS4AluzoWWPuVgXXN84//AGBB+l7KH7vRmfH1M4QRFKZfB2pMprThoa2 Qrc9z/2PgBHvLqQQHOb076bqzKuJCQYRVPugwdZFmPpBPG+/ekOYgLzosVLS/Xs14Krcd3k6 3Xb8nZh1ux7Ydsjjf3TwLzRv967SnElpCYc4gHaWApJBSsmOdb8POREBbUnhMuswa6QSl2H+ XMDgcXbsaYFDIqGk2qGR+Bl8FCVCxStbmW0bb1HRsZJG9GRF5iLJtk4DNZWfx4BDyr8UWW1C HI/QCsIjHOpAFOkbLVsf6W6ANkwwK7rGLzND66LNoAQP8AqLlTarEmCgHJ8OUiwzyDAdolia f+mnTqEVh729Iw+lmPtHrdBuVPV7nlnmTq7qW/HI+SPiOrCOyH9pUYtO1qVZedx97KfvAjQ6 L5i2ziilX1ivBnFSnCPq+Y7dAlSRVBiXMyeg5IMLIarfFE5cFzN/teMm9vNjaQ/wfQM/goJl 1ngMnJlJK3X3iOfd13WNio9MtsCn/9X9BoGAMDlBn7ws1BLXGplxP53m0cfFVX/yNFe8A==
IronPort-HdrOrdr: A9a23:oCcu/KOm4c76EMBcT2r155DYdb4zR+YMi2TDiHoedfUFSKOlfp 6V8MjzjSWE9wr4WBkb6LS90dq7MA3hHPlOkMYs1NaZLUXbUQ6TTb2KgrGSuwEJlUfFh5VgPM tbAspD4ZjLfCRHZKXBkUeF+rQbsaO6GcmT7I+0pRoMPGJXguNbnnpE422gYypLrXx9dOME/e 2nl6x6TlSbCBEqR/X+IkNAc/nIptXNmp6jSwUBHQQb5A6Hii7twKLmEjCDty1uEg9n8PMHyy zoggb57qKsv7WQ0RnHzVLe6JxQhZ/I1sZDPsqRkcIYQw+cyjpAJb4RGIFqjgpF5d1H22xa1O UkZC1QePib3kmhPF1dZyGdnTUIngxeskMKgmXo8EcL6faJNA7STfAx3b6wtnDimhAdVBYW6t MR44vRjeslMTrQ2Cv6/NTGTBdsiw69pmcji/caizhFXZIZc6I5l/1VwKp5KuZIIMvB0vFuLM B+SMXHoPpGe1KTaH7U+mFp3dy3R3w2WhOLWFILtMCZ2yVf2CkR9TpU+OUP2nMbsJ4tQZhN4O rJdqxuibFVV8cTKaZwHv0IT8e7AnHEBRjMLGWRK1L6E7xvAQOGl7fnpLEuoO26cp0By5U/3J zHTVNDrGY3P1njDMWftac7hCwlgF/NKggF5vsuk6SR4IeMNoYDGRfzPWwTrw==
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.96,222,1665446400"; d="scan'208";a="21847554"
Received: from alln-core-5.cisco.com ([173.36.13.138]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 06 Dec 2022 11:44:25 +0000
Received: from mail.cisco.com (xfe-aln-003.cisco.com [173.37.135.123]) by alln-core-5.cisco.com (8.15.2/8.15.2) with ESMTPS id 2B6BiPXo031393 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=OK); Tue, 6 Dec 2022 11:44:25 GMT
Received: from xfe-rtp-003.cisco.com (64.101.210.233) by xfe-aln-003.cisco.com (173.37.135.123) 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 05:44:25 -0600
Received: from NAM10-BN7-obe.outbound.protection.outlook.com (64.101.32.56) by xfe-rtp-003.cisco.com (64.101.210.233) 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 06:44:25 -0500
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=j0p7g0d5EyCNiKYSb6I2KqiunEtAGTuDjj/FYcy097lcUu12k4kRhv4ftQ6ev9cePXpsdP7cqvJC132jifq99JNM+NrLw+glhaxM+X4QrteCps29lpZakH01qn8zwOljjEjQq+iibB0IIGPvbYq7YkuBk2NQ7jgRO3fkatBSKXYuaeJ7hWGieLxVYWPWNZdIla3nY67MTsLJedwjxvq/vcRzYd/ap+1lm0/5TcHpj1F+jvbyBksrE5sFxQ1pF/uLAclDILotKsyCq1jWMczN0BsXNpO+IjSq0QUVvzlMUXL+RqorMg6gdIhY9fpeXX89FmcCkQoMB/96YVHd/3PFrA==
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=+8T6otx1PdKsXcJZHBu8sRbBicH5ZE1OcRET+umFeCI=; b=A4MQsAq5oOA54weED4GZLaz/7nOpwM5C9kqKQBQBnK0a9bFJtX+c/lCZhF9H0HJ2amRspHRtUkH4X8zg3spdxSmgJF0rIGnH6+SYp4K1ZfXNttgOpxT9VXr2AMZpSQbPLTOaMm3htVL/GlST1+rJvA2mwfmwuRW/AH9/eT/W7Bxk0gQtHxVF0yK6E401B5Hapz6mufKom7SSY4a+fGFkXZr03ck0Tm1eWcwT4yTA//6D9xuzz2I+9Zb4jf76CjXwijGKdetlAXf+39pSrkDP+pBC9khQXx658jggxt5IzZYQS91Io+iwPBvQ0pZedVXAEX9t0k59uS1lhrMugQLUwA==
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=+8T6otx1PdKsXcJZHBu8sRbBicH5ZE1OcRET+umFeCI=; b=fOd6Rb9XuANWKYp/x9RNSkUxqbsAo16x3mDM6g9WUiC4DkmXy4+2ZrJpSK+uQUOezqXxBivSXB/kbTnEIn7LOqqdAcpBZqqSA1doRzvz2VM1UpwhWw4AUyaNdXCACIl1qPgBmGc0H8OuO+QH5IylHBreT0XMcOH2lDuHJa/Gk6k=
Received: from CO1PR11MB4881.namprd11.prod.outlook.com (2603:10b6:303:91::20) by DM4PR11MB6383.namprd11.prod.outlook.com (2603:10b6:8:bf::11) 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 11:44:23 +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 11:44:23 +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: AdkEItll7BSqIYXSTzSZRt2iSLPriQBY4mwAACFtu4AAzMQL4AAKBGVA
Date: Tue, 06 Dec 2022 11:44:08 +0000
Deferred-Delivery: Tue, 6 Dec 2022 11:43:30 +0000
Message-ID: <CO1PR11MB48814B28601F41086EB4DCCCD81B9@CO1PR11MB4881.namprd11.prod.outlook.com>
References: <PH7PR14MB5368821B6264F94D957C4C3DBB129@PH7PR14MB5368.namprd14.prod.outlook.com> <CO1PR11MB488180EC042045C886385915D8149@CO1PR11MB4881.namprd11.prod.outlook.com> <PH7PR14MB536823D28FBA120DEBE9A4F7BB179@PH7PR14MB5368.namprd14.prod.outlook.com> <CO1PR11MB488152BC4C60D7CC46BCD2D0D81B9@CO1PR11MB4881.namprd11.prod.outlook.com>
In-Reply-To: <CO1PR11MB488152BC4C60D7CC46BCD2D0D81B9@CO1PR11MB4881.namprd11.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_|DM4PR11MB6383:EE_
x-ms-office365-filtering-correlation-id: e9f97581-e5f3-4cf3-9a52-08dad77f3864
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: 0p7/sL8hGOPO/+v689h/PnsMtrMqs8AxFx0QCo7mIxSu0tbcmL1BkVF2/g1v/lIZREuMqzVK3g/KQPvv6M8JVJY8zk18a0L10CmqgjRWW1V1D7DX4eH5u/ZqENUQADGll7ZKJX4oEB50Pm+nyNBmf30fYIDoMzBO4Av68Kq1cijSvn4xGzcYFCtSkNyZqS2gFX7nr7U1ySjJ55uXHij8KyxoytAXf/gMlxWE6FucrgeXtbSr0eDw4LS53ZHEO4sA0yQgIWwsRczHLvi735H/HBXvk44+v4VGStckS1nl0jY6bog5P3DkIGynYNrXgwwStLhKG180AzOjmtBqrE02/uOpUs8bES5K961c3oNJ3tR2oaUuvRsuQWlEbxhKa+V519npVRV4Oa654zDab+MK/XaX1TKyrH8teuxWx/2dr5yLhn23kXzrnj7IZYlYfTxxzcpcdqIcDdWjuYGmTWzRVoMCsX4cR236BwBSdvWSZKFft316unlSagXKCgJaZmy360uJzOWaW1foRELmqAk5NsD28U5863HhjEJNNhidKcPNhI1yaJ8U6K/YVVcHFMhWPiybWFx3PO/YCPxLaozsbq+3g4UKZhXT6khkFCoUv7rOx/eex6t6MHD7R1wtzPmI1CqNbXNfKanXpWeQJU/AtBi6zEqsTjFh2+kIGszpJjl6hv/EAH5QhZbn1bAfpBsjymleRHeKbE6PP7crntm5BrzPpXKo5vTMLiLXkx8926nbhcaZ1HRLP2dBMJiis+CFXRvP8VvObqxi/AnDZXtSlQ==
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)(346002)(376002)(136003)(39860400002)(396003)(366004)(451199015)(66446008)(76116006)(66556008)(8676002)(66476007)(4326008)(64756008)(30864003)(66946007)(5660300002)(8936002)(66899015)(52536014)(41300700001)(2906002)(478600001)(966005)(6506007)(53546011)(7696005)(33656002)(9686003)(2940100002)(54906003)(110136005)(71200400001)(26005)(316002)(6666004)(186003)(66574015)(86362001)(83380400001)(55016003)(122000001)(38070700005)(38100700002); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: qinXRvwC5rUJVfxyz7dMArtpqfL9tuBrAIJCVMvWsZsY3ANICnMnW26UY/fEnC2E1S6P0FcwczgbX0/q8vJ+bUQUNufWLOimvEvKalpnZw4osL4doFJRIafTTW3mzJ3Ze3kE4q/qFZqdw3Y8pvksNJIknr01ylCIfmmPM/SVz5aouk+UzUxUQ9i00meIMrwr9RPrDsLaYwFW93LqttGfh2lwGLvg+0ErKJRhZIs+Lb2mdC8YrYlNbTn863K+oaEuLEGBfmLWZsBfjwxXjx3Wj2oMbsSxgdoq6i3WzKJegZn9ce93zJslLqYADQzloGEiM9m2XR04dQDP1//yhaPBkDX7Ki7IfyBITzFWMfwbpr64OKHDy0anYrczvnFSlsPHQTsMrHhQIMOSnQWMB8SsfmOjKTkbi+JXh59NDbQuDtmPMdL4omO/f7+0EzBORWpjpnIWrMRbYl8Q9OjYa2yP6htOGtCX0oq+3oA9KVx+2NY1x/Z/Bt2tIVIlxDnPpY2t4JSQBSHbElW6IkQ+paQiXTI/ntzN/vQGi6pnsV88bL1vRray/rW1vDfTbfDzj3KNomROMuD6P0E6pIfXXHFtjkHx7ETQOBXaeXoVm5aswcpRj5EzNaDLkkHeXUEBEJcAaD7NYS0aausGlnp4eFjGT8qhA/Hiaw4Sa8n4InIxrTpFQnMEVfi8zSdxtJZc4/jCeUqTpzun6pR1kmzJs3Yd18XECAAKmQG0j/UnE4Bar432pDjvlJTpkhTwZNyJzIh8DZM0cFJDpWntqzZAbriJcptYCwmcoG9cc4sFcsO+mDBwcB9Xt/tg3H7vPU5VA0k2Bvw/QcPHNTFYLpDRVPZSgwZ10YteHZ1DwNRSN520++XCbPXhj0ncwLzTIETbyMsgDStFbU5DvuGs4A963xdPpDU09XWlK1UP/gfJxSxUsc4+Tyfm8MfcCmtB6jnNGRJg7ENPT2AXvbYMBUkMD06rNXWeDlSu0zlUOEN5zGviG9Wiuca1rHA0qusptvlnbCqvwKuk6MstnYW1BnwIfhnIfD1L6hNuxfYM1f8ecpLV3VamkdZ+uEoBkHi1I5Ic0y+RNqRxo4s4glRfFDVWTOYyK6WpdOhpQj35g4K0Sdl5GbKR1Oe+x//RmXRHSHybsTmOYMBkyT5/cnDSVzhU4S5/xBIEh7bgpFkZ0V/bWbo0taf1BLtNbajo4HwQfsZBgI/0urk13v5OIfdr8EgDnFapJnw9tAP7XRP58sqAtljMx+ykJw+TffvHN2dRu5s5LrWIyWrPV8CFPkNmaBrV/A0shYC75s4GuesTZd7ETSd3I4Vxb3XWMAzvIBe1wEZmO2vdnQTm4TPs91Pbfx2NKRiGj/qZnnZy2+Yw/6S0ROds0acAsT1xnMzLqt0KXtGeIJGCdOHM7t88htja7qQscvkEBevPOf2BBATzpNQ3Enrc30bSbU26kO7r0CdPR4vtrmcDvfJ0DQV/5Uw/NiZsY1IXyrZdQUp7nGf93SCOx62EkCntnYgYDP1caGrnnqPaaMTi/61JB0J4Bp5N6sG/uh5qUWqtNKU10a4PeyZmhlBgqtvKXgcdL53k6EidmkASR0DC
Content-Type: text/plain; charset="iso-8859-1"
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: e9f97581-e5f3-4cf3-9a52-08dad77f3864
X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Dec 2022 11:44:23.2656 (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: UXlpuQFdKSv8YmI+sIWfF3W0GI1B7WMQXeTvxyRpIud3bLpE8db1rwquQy3c/B7ojdXBVAW4w4wFD6lladKHOQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM4PR11MB6383
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.37.135.123, xfe-aln-003.cisco.com
X-Outbound-Node: alln-core-5.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/raw/Mq5p3kIRRaRqCNKqfcFGTUEePxg>
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 11:44:31 -0000

Hello again Don

The proposed changes are visible in https://github.com/raw-wg/raw-architecture/commit/ad9525dd399cfe11da645ccc591272cc2b97d75e

Major:

- Added at beginning of terminology:
"
                                               RAW inherits and augments
    the IETF art of Protection as seen in DetNet and Traffic Engineering.
"

- New Figure of a Track
- Definition of East, West, North, and South
- Definition of Lane

In parallel I'm moving the ROLL draft to use lane as well. Waiting for WG approval (or lack of disapproval) to publish.

All the best

Pascal






> -----Original Message-----
> From: Pascal Thubert (pthubert)
> Sent: mardi 6 décembre 2022 9:25
> To: Don Fedyk <dfedyk@labn.net>; raw@ietf.org
> Cc: raw-chairs@ietf.org; DetNet Chairs <detnet-chairs@ietf.org>
> Subject: RE: [Raw] FW: I-D Action: draft-ietf-raw-architecture-10.txt
> 
> 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
> > >
> > >