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 > > > > > >
- [Raw] I-D Action: draft-ietf-raw-architecture-10.… internet-drafts
- [Raw] FW: I-D Action: draft-ietf-raw-architecture… Pascal Thubert (pthubert)
- Re: [Raw] FW: I-D Action: draft-ietf-raw-architec… Pascal Thubert (pthubert)
- Re: [Raw] FW: I-D Action: draft-ietf-raw-architec… Don Fedyk
- Re: [Raw] FW: I-D Action: draft-ietf-raw-architec… Pascal Thubert (pthubert)
- Re: [Raw] FW: I-D Action: draft-ietf-raw-architec… Don Fedyk
- Re: [Raw] FW: I-D Action: draft-ietf-raw-architec… Pascal Thubert (pthubert)
- Re: [Raw] FW: I-D Action: draft-ietf-raw-architec… Don Fedyk
- Re: [Raw] FW: I-D Action: draft-ietf-raw-architec… Pascal Thubert (pthubert)
- Re: [Raw] FW: I-D Action: draft-ietf-raw-architec… Pascal Thubert (pthubert)
- Re: [Raw] FW: I-D Action: draft-ietf-raw-architec… Pascal Thubert (pthubert)