[Raw] The term RAW in RAW Architecture [was Some comments/questions on RAW Architecture]

"Pascal Thubert (pthubert)" <pthubert@cisco.com> Mon, 21 March 2022 14:20 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 AE3673A088F for <raw@ietfa.amsl.com>; Mon, 21 Mar 2022 07:20:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.606
X-Spam-Level:
X-Spam-Status: No, score=-9.606 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=NaRlBqp3; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=SuOP1TOw
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b4BkHaW2fgjC for <raw@ietfa.amsl.com>; Mon, 21 Mar 2022 07:20:19 -0700 (PDT)
Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A54EF3A0105 for <raw@ietf.org>; Mon, 21 Mar 2022 07:20:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9990; q=dns/txt; s=iport; t=1647872419; x=1649082019; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=ZiTFnAaC9IPZqAAfPehd4xg4l6DAS3+8WlH8Dls3Eps=; b=NaRlBqp3zV9Bdj5m11v1FYd8k8YYN1pZj/7Q6PmYzW3nJJX3xtQ68aqx IX/mKAIX8b3D+gxD/JGgQKYR0Lb9iqBi8WIW/0LbhsiAo6Ke3ARPANQgW 5TMCS/DNJ5PAH0CfNtgN9F5jCwOx1Rj4J6tGyO1f0ADQXHMqcjPRwgEf1 E=;
X-IPAS-Result: A0D6AAD9iDhimI0NJK1agQmBWoFSKAYogVg3RIRUg0oDhTmFEF2CJQOWEYUkgS4UgREDVAsBAQENAQFBBAEBhQcCF4QgAiU0CQ4BAgQBAQEBAwIDAQEBAQEBAwEBBQEBAQIBBwQUAQEBAQEBAQEJFAcGDAUOECeFaA2GQgEBFxERDAEBLgoLBgEYAQEDAQEDAiYCBDAVAgYJAQQBEggTB4JigmYDLgGgbwGBOgKBDokReoExgQGCCAEBBgQEhQsYgjcJgRAsgxGEJoc5HIFJRIEVQ3mGNxEBKgUzgmA3gi6YEj4mBDIRXQIBFg0lPwMFUgkDOpIUg0uXYJJtCoNJBY5QkTwVg3STDJE+llsgoSQOgU2DOgIEAgQFAg4BAQaBYYIVcBWDJFEZD445Hm8BBIJHil51OAIGAQoBAQMJjyoBJ4IgAQE
IronPort-PHdr: A9a23:TZfFRB+vKzI5wv9uWCXoyV9kXcBvk7n3PwtA7J0hhvoOd6m45J3tM QTZ4ukll17GW4jXqpcmw+rbuqztQyoMtJCGtn1RfJlFTRRQj8IQkkQpC9KEDkuuKvnsYmQ6E c1OWUUj8Wu8NB1eGd31YBvZpXjhhQM=
IronPort-Data: A9a23:WoCOv6iGvvDl/NIPdZ8qEaxJX161dhAKZh0ujC45NGQN5FlHY01je htvUTyHPaqIYzSgfot0Ooq1oUkCvsPUmoBhTlc6qns3EyhjpJueD7x1DKtf0wB+jyHnZBg6h ynLQoCYdKjYdleF+lH1dOKJQUBUjclkfJKkYAL/En03FFcMpBsJ00o5wbZi2Ncw2LBVPivU0 T/Mi5yHULOa82Yc3lI8s8pvfzs24ZweEBtB1rAPTagjUG32zhH5P7pDTU2FFEYUd6EPdgKMq 0kv+5nilo/R109F5tpICd8XeGVSKlLZFVDmZna7x8FOjzAazhHe3JrXO9I5VVh52yWulelI8 9x068GeZVwwBIHDzbF1vxlwS0mSPIVP/LvBZHO4q8HWnwvNcmDnxLNlC0Re0Y8wo7ksRzoQs 6VDbmlRN3hvhMruqF6/YvFwhtkpIdP3FIgeoXpnizreCJ7KRLiTHPiSvoEBhW5YasZmHNrAd eVGcTlVNAXZT0NAM09GL5Vgk7L97pX4W2QI9A3KzUYt2EDJxRNZ0bXxPpzSYNPibcFfk1yXq 3ju+23zBFccOcD39Nae2nuogumKliThVcdCUra57fVtxlaUwwT/FSH6S3OeneaX2l6ZUetmE EUtpHcAgfMrzmCkG4yVswKDnFaIuRsVWtx1GuI86R2Qxqe83+p/LjVdJtKmQIF63PLaVQDGx XfSxIqwWmIHXKm9DCPDqOjF9FteLABMdTdqWMMScecSDzAPSqkaihbCSL6P+4bq04WsQlkcL 912xRXSap0aicoNkq68512C03Snp4PCSUg+4QC/soOZAuFROd7Ni2+AsAWzARN8wGCxFQHpU J8swJH20Qz2JcvR/BFhuc1UdF1T296LMSfHnXlkFIQ7+jKm9haLJN4Mv2EmdRw3a5dbI1cFh XM/XysMuPe/21P3MsdKj36ZV6zGMIC5T42+D6CIBjawSsEsLVXvEN5Sib64hjCxzxdEfVAXM paAesHkFmcBFali11KLqxQ1j9cWKtQF7TqLH/jTlk3/uZLHPSL9YepVYTOmM7FihIvZ8Vq92 4gEbaOilU4AONASlwGKq+b/23hQcyhibX03wuQKHtO+zv1OQzhwVaWOnet/J+SIXc19z4/1w 510YWcAoHKXuJENAVzihqxLAF83YatCkA==
IronPort-HdrOrdr: A9a23:G4KHRaApq1s9ds/lHegSsceALOsnbusQ8zAXPh9KJyC9I/b2qy nxppgmPEfP+UwssQIb6K290c67MD7hHP9OkMMs1NKZPTUO11HYVb2LY+HZskXd8kHFh4xgPM RbAuRD4b/LfCNHZK/BiWHSebtBsbq6GcuT9IPjJgJWPGdXgtZbnmBE42igYyhLbTgDIaB8OI uX58JBqTblU28QdN6HCn4MWPWGj8HXlbr9CCR2SCIP2U2rt3eF+bT6Gx+X0lM1SDVU24ov9m DDjkjQ+rijifem0RXRvlWjoai+2eGRi+erNvb8yfT9GQ+cyDpAo74RHoFqiQpF4N1HLmxa1O Uk7S1QePiboEmhAl1d6SGdpDUIlgxerUMLDTSj8CPeSQuTfkNiNyMJv/MmTjLJr0Unp91yy6 RNwiaQsIdWFwrJmGDn68HPTAwCrDv8nZMOq59ls5Vka/ppVFaRl/1swGpFVJMbWC7q4oEuF+ djSMna+fZNaFufK3TUpHNmztCgVmk6Wk7ueDlIhuWFlzxN2HxpxUoRw8IS2n8G6ZImUpFBo+ DJKL5hmr1CRtIfKah9GOACS82qDXGle2OFDEuCZVD8UK0XMXPErJD6pL0z+eGxYZQNiIA/nZ zQOWkowVLau3iefPFm8Kc7giwlGl/NLAgF4vsulKREhg==
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.90,198,1643673600"; d="scan'208";a="875036111"
Received: from alln-core-8.cisco.com ([173.36.13.141]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 21 Mar 2022 14:20:18 +0000
Received: from mail.cisco.com (xfe-aln-005.cisco.com [173.37.135.125]) by alln-core-8.cisco.com (8.15.2/8.15.2) with ESMTPS id 22LEKIvX018973 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=OK); Mon, 21 Mar 2022 14:20:18 GMT
Received: from xfe-aln-002.cisco.com (173.37.135.122) by xfe-aln-005.cisco.com (173.37.135.125) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.986.14; Mon, 21 Mar 2022 09:20:17 -0500
Received: from NAM10-BN7-obe.outbound.protection.outlook.com (173.37.151.57) by xfe-aln-002.cisco.com (173.37.135.122) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.986.14 via Frontend Transport; Mon, 21 Mar 2022 09:20:17 -0500
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=MsQasyoa/NBe2+qdsyUKUsuVFZRIMfZmRVuGVY5M94VLE0Ta+1cuaD34CzJhp0hX8YU8kbGV7f8kk7L/3YsYBm8JY+dgq4E5rVOoVTNtsyd67Y3mCVw+CND5L0ODpoQA3TnpBbjYzFu0Mnhwze5a3VnSgXTVR150g8nApFZubSZAz7BEYjCEadXpao1bTtVcGBNt26Kyf964gMG73jChk/ejxnwLfOSOtCQ2H/JqRbYRaOy7dsZkZVigDJOaOl70YXCUKM41Onl2wSC6DKiICjLmCo5Jyzyqpm68fz58rUz+LW90ATFDqrhcuMw9tMtIIyg8dPnO1M+W+7tMwSTJQA==
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=ZiTFnAaC9IPZqAAfPehd4xg4l6DAS3+8WlH8Dls3Eps=; b=NJL1AoML03X0Q/CyCaAhE5Eb93ABYbJLRyN3IhVxsOrtrcdXsIz9LjHpsyj5lV08r63uQgOV3rmbKYDqvPlDUcjwUGQsk6xPZDCrrrVa73XmTOxi6WOyfQKcEqIZYe7sgZA7dLBw5DlHrnNKnCsGQ14MZskcIlhzDnDHJjlc2wg2Ob5ZoRD1Avfygl+e1SffTSxhdE66lJWFwg80RYznWhktlBPDOvt46w89h5Mwu7K5+a/gXacuw6yHREkPMprI+U+UWO7Sj3UFiTadxCa4c4EQGgmfMQOIl9xwtMzdc2Qfjy0G5wGaXQbAYeduBSk9nLrWPc7vidp6NzW75MR6og==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ZiTFnAaC9IPZqAAfPehd4xg4l6DAS3+8WlH8Dls3Eps=; b=SuOP1TOw6h4sBE8UjFliTralb0XwhBPmS+JsHk+RPWXcA23WqeuGJSh3wJbb4tDnz5FbfxYxLGp6ZnIaA79far49+UC51uGdMpaWdtOWRBIE2SLKQ8XTRUYG6pCu+BNXA603QiyeWF9wfs8MSfYkphqyQs/p4PxrrSqb351nhTE=
Received: from CO1PR11MB4881.namprd11.prod.outlook.com (2603:10b6:303:91::20) by DM6PR11MB3289.namprd11.prod.outlook.com (2603:10b6:5:5f::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5081.18; Mon, 21 Mar 2022 14:20:15 +0000
Received: from CO1PR11MB4881.namprd11.prod.outlook.com ([fe80::d4d0:b43e:40e8:d888]) by CO1PR11MB4881.namprd11.prod.outlook.com ([fe80::d4d0:b43e:40e8:d888%5]) with mapi id 15.20.5081.023; Mon, 21 Mar 2022 14:20:15 +0000
From: "Pascal Thubert (pthubert)" <pthubert@cisco.com>
To: "Lou Berger (lberger@labn.net)" <lberger@labn.net>, "raw@ietf.org" <raw@ietf.org>
Thread-Topic: The term RAW in RAW Architecture [was Some comments/questions on RAW Architecture]
Thread-Index: Adg9J3WeYTB7WzdDQnG4yAPvGowLgA==
Date: Mon, 21 Mar 2022 14:20:04 +0000
Deferred-Delivery: Mon, 21 Mar 2022 14:19:52 +0000
Message-ID: <CO1PR11MB4881016A94E2426FE5EE418ED8169@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-office365-filtering-correlation-id: 6b807075-ef1e-4c9f-ca73-08da0b45eb4f
x-ms-traffictypediagnostic: DM6PR11MB3289:EE_
x-microsoft-antispam-prvs: <DM6PR11MB328971EFC491CEB5CD1FB6F3D8169@DM6PR11MB3289.namprd11.prod.outlook.com>
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: ggEd4136mZZ8n7HRhrCQLk3G0thuZdENzdKRh3Om0sYL3Amxm2f+vMRwF8FW3rczK0HlHDQyufcbYGOZSls2SEXWHDF5k3HkDV8gFw4hW9aNaaAd6J8YAmDf2n2E8If/Okbr8eMO4aKV0iur9a7Ose/krq2Qpkf+fQfWr+kJF9soR5lB9cgBqFA+8AE7MsqYNCsbzG/t+MBBl3OXNN+chYo6gE+XulHipEFA2lPoCEAgXUcOpIDQyIrmUFUsCCdqT6ybb1Xjhr+af0q5DQMTLkE0JEBMnX5pDmYZTOnEUitqZ28e7Pfs1euSYAqkkMugg8q0OmOoViYblcRmWW4vv2FWpoAUB2mhvhknBBKQTOxFCDf/OgcteBREpByrT9F4wfscjOMQoYqeucOuwCJHsOVCFh3HVO1MsSsi3hmwJ7HBNAPXYPNiZlpjLvwl+k3DO3GXZKcaiQNqFR8P3n65yBJVQPNzvM1trMoU4JRZ9/j4YmRTRFgNolRvT5PwjMLhDZMBXlpBVFMWzQRqyCimzvcZjgu0Jy1K4sNEQQZC7gFdFuh6o1W0ezBp9pxq8rl97nJC36FANWm+AX2sonv0J5Z7Uqyn+g/uhVN5u5JD2MC4bujM/EZSjUCuvzjoePTKbvhEnohmZHttYvkjYwEMnhfYFXnka6lvf6ncW0QAY1rmlQHVwWM1mFssvtoFcvPZt7RqUSlVkeaMxB2O4xkBCQ==
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:(13230001)(366004)(38070700005)(83380400001)(8676002)(66556008)(66446008)(66946007)(66476007)(8936002)(508600001)(64756008)(6666004)(76116006)(52536014)(122000001)(7696005)(71200400001)(38100700002)(9686003)(2906002)(55016003)(53546011)(316002)(6506007)(186003)(33656002)(26005)(5660300002)(110136005)(86362001); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: UvhLdmMNmqKDGfSG2PEBUUCPmHBHimuu4mYRBGrL5i2FSiubmMoCHU9NIrQcYoH59KHfVXEU084+X3TbhfLDUiX3htuJ/SGmP9+cAEGyZlKBY0kxNLvL0PZNQUOHsvbuijtkCl0wJh6aL+lnoMKNELiUk85VpUiF2id6+F6xmrkp1yWCEQCO3CnCD2Ohsqb+hVkW1FNeyAdhv4fAxo7+682tr7IRD4WZItxnZeRMzUOw2xo6Am3fVWvA1ci7U2g4xYAxu/EBGLWV3mwNWUEVtGoQcTVOOec4vcF+hK5gdEOENudl1uZvXt5CVyOwpr7Ao+dR10ITWckf/tu19C58K3ZzvMacy/ONkHojAwGAvjArTCr0N/sz9jUm7OTzcHHebV25U3c2oChmqzZpebodcpnewlTSFi1o0O9CUy3zdN7VxpLKySl3Au6LyVJw6YTE2fgtnubcEdfMKj5VCdlAMlRzg5/tz4vU+IStLOq5nEugwMwwinEVfEvo8UxWD+Mo72ap3RWO8mtnCJnX0qmizhAw2RbvnuM14Eh68yYZyytIYVQrZvfkk+nFyFvlVLNiQ/CcxwzCyFObzDYKABKhyT/cIbiUIHfPEegcI6bNHxU4LdlvVvIeCss/ZD3qlAxVvXuS+aXEz5N0bfrivEADNsvRKaSIsyzKwZyc9lisJKbJTh/G2/byjb2+g52bqRornwOw3JQlo2GLEP0Y7iuRcjVMP1B+PzflGPc9OHa+Wo7kuDrMGKBQpyJJidQksua4kRfwrsClwVksVz/rbML1t7riJ20A3guwOuixjGE4aQ/0ZaAkzH5K5TNoLkZWOChFbeUBFth74G1BG06aPapRdrF+uUbkQAe3f7GxcvMmFKLkt8L1PQ61v7VuFToQXNS0Nh0k3XJPyBXbQMD/DneeY9cWbs9yNsFIKIHoYXZmtiSe+PyZ/Epl2I2b3aaWfPqbTiU8IM6vNHJZZ00gVh4fSqy/CS4smClHIrL/rRsUebkpDwDEdi9YwGAn5pKT5T+M6muMaM0mYW6VhTRPf8SAASEmdE3URjYGKlF6IzUKv8kjhxFyTfKTzsvbBiPpBXYhCVILCCmnTUVjblbG3dZ6O7QBeEvSkSqwgxW1IsX8Cnu/ncZDe23Z+jWjnmtduidRipGG1ifYD5W+zl0aL0Km2iCvIa21c5WkiaDvvBxuT90eaI9nAyg7ttojyeH1e33hquZ0yB0UOZOMlrVruCNdkU+tuDJEy7HMad02cKmxHuR2u4FPe13duzhbzl4z4zmq+ItWqOsEJbX7ve0vZ8vfDORlQkJ5zI7R6yRWFcT7OUD5L5MN59Rpr5k13zVsFiseo12Cb0inMTY7t/hpFsQCF1wAca5dSQndg6AwK4Y3l+eh4I1OpO91aZLYNrk6TbZ/1JLJk2kzxkPZH922DkaQ5e5y7irEuzQiASDMQccp7vn4KidJ/iZqNtmois32KlMU
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
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: 6b807075-ef1e-4c9f-ca73-08da0b45eb4f
X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Mar 2022 14:20:15.3776 (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: jL8tIXygaQ/MQFfXZLFeFzfYdBhdt71BHqmHRmP35zfjC7iq0lVxzDqmQuCyPCO5X6Djne2UFI1N+o5cSZtmjg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR11MB3289
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.37.135.125, xfe-aln-005.cisco.com
X-Outbound-Node: alln-core-8.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/raw/8r3uMgjiLd6zatIXhVRK0EPWEGg>
Subject: [Raw] The term RAW in RAW Architecture [was Some comments/questions on RAW Architecture]
X-BeenThere: raw@ietf.org
X-Mailman-Version: 2.1.29
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: Mon, 21 Mar 2022 14:20:25 -0000

Dear Lou and all:

Lou asked (more below): "1) What does the term "RAW" refer to in the context of the architecture? 
Is it a new/standalone set of mechanisms or is it an addition or an extension, or a usage of IETF defined technologies?"

<Pascal>

Effectively we use "RAW Architecture" a but like if what we do here is the alpha and omega to make wireless near deterministic when we're just providing a set DetNet extensions for OODA loop, and functions more may come in the future. Should we call it "RAW OODA Architecture" or something?

</Pascal>

Lou also points out that the text staring at " It builds on the DetNet Architecture" sounds evolutionary. 

<Pascal>
Evolution is key to survival, ask Covid. More seriously, we may be hitting my non-native limits. I wish this architecture to be foldable into the DetNet family, even though it means that the family will extend, which is neat in my book. So:
1) how bad is evolutionary? Does that contradict the charter ?
2) Should we use, e.g., "extends" as opposed to "builds on"?

<Pascal>

Finally Lou Proposes the following change:

OLD 

    It builds on the DetNet Architecture and
    discusses specific challenges and technology considerations needed to
    deliver DetNet service utilizing scheduled wireless segments and
    other media, e.g., frequency/time-sharing physical media resources
    with stochastic traffic.

Lou's PROPOSAL

     The RAW Architecture builds on the DetNet Architecture and
     standard IETF Traffic Engineering concepts and mechanisms to
    deliver service across any combination of wired and wireless
    network segments. ...

<Pascal>

My 2 cents: 
*   Our charter builds on DetNet and MANET-DLEP, but not TEAS.
*   We have not decided to extend TEAS but be inheritance from DetNet. 
*   I'm probably both biased and ill-informed, but I do believe that the work at 6TiSCH - which explicitly considered deterministic flows over one of our selected technologies (see RFC 9030 which BTW also defines the concept of a Track) - may be as good a base to build upon for RAW as other IETF work that roots in MPLS, fiber optics, and/or SP networks.
*  Whether we do use TEAS work, to which extent, or we do not, will be documented in the framework once the WG settles on that, and we certainly hope for your help doing that.
*  At the level of this document (architecture), I believe that the core qualification is not how we'll do it but the fact that it will have to support wireless segments and possibly non wireless segments as well, with as a corollary that we selected wireless techs that can be scheduled to offer the expected guarantees.

All in all, I might have missed your point but I'd rather keep that text as is.

</Pascal> 

What do you all think?

Pascal

-----Original Message-----
From: Lou Berger <lberger@labn.net> 
Sent: lundi 21 mars 2022 2:25
To: draft-ietf-raw-architecture@ietf.org
Cc: RAW WG <raw@ietf.org>
Subject: Some comments/questions on RAW Architecture

Pascal, Georgios,

In looking to provide input on the framework document I realized I had some basic questions on the architecture document. While I also have more detailed comments/questions on the Architecture document, I'll stick to the high level comments/questions here. Also, my apologies for not getting them out sooner, but I figured it was still better to document here than just "at the mic" in tomorrow's session.

1) What does the term "RAW" refer to in the context of the architecture? 
Is it a new/standalone set of mechanisms or is it an addition or an extension, or a usage of IETF defined technologies?

I find that reading the architecture, I'm really  unsure.  The current working is a bit mixed, e.g.,

    Reliable and Available Wireless (RAW) provides for high reliability
    and availability for IP connectivity over a wireless medium.

this sounds like something new/independent

    It builds on the DetNet Architecture and
    discusses specific challenges and technology considerations needed to
    deliver DetNet service utilizing scheduled wireless segments and
    other media, e.g., frequency/time-sharing physical media resources
    with stochastic traffic.

this sounds evolutionary.

I was expecting the RAW WG to build on DetNet and other IETF Traffic Engineering (TE)  bodies of work. In other works something along the lines of:

     The RAW Architecture builds on the DetNet Architecture and
     standard IETF Traffic Engineering concepts and mechanisms to
    deliver service across any combination of wired and wireless
    network segments. ...

I think the document and the used terminology must be clear even we're
(understandably) loose in the usage of the "RAW" term in our discussions.

2) Are RAW solutions limited to IPv6 and a limited set of wireless technologies?  I think the framework says/implies no, but the architecture is less inclusive. e.g.,
    RAW provides DetNet elements that are specialized for IPv6 flows
    [IPv6] over selected deterministic radios technologies [RAW-TECHNOS].

I would expect that at least at the Architecture level that there would be no exclusion of IETF networking technologies (including v4 and MPLS) and any SDO-defined wireless technology.  I certainly understand needing to focus and prioritize work on specific technologies, but that is practical choice not a limitation that should be codified in the architecture.

Somewhat related, but of less importance, it's probably worth mentioning that RAW forwards/switches at the IP, not link layer.

3) How do tracks differ from TE protection paths?

In reading the definition of the tracks, the term seems quite aligned/similar to TE protection paths and segments.  Keep in mind that DetNet PREOF is just one form of service restoration supported in IETF TE, i.e., the 1+1 form.  A track reads to me to be something that can be composed or combine 1:1, 1:N and even 1+N, and have interesting
(uncoordinated) protection switching based on actual network/link
(channel) state.  I suspect we can accomplish the same objectives as Tracks and stay consistent with existing DetNet and TE(AS) terminology.

4) Is RAW limited to PCE-based centralized solutions?

DetNet introduced the term Controller Plane to cover all types of control supported by the IETF TE architecture, i.e., fully centralized, fully distributed, or any hybrid combination of centralized/distributed control.  The Architecture reads as supporting only one combination of - PCE for paths, PSEs for tracks (aka protection segments) .   PSEs read as also doing the actual protection switching, but this is outside the scope of this comment.

Hereto, I see no reason for the architecture to limit the scope of the Controller Plan solutions that could be standardized as part of RAW. (Yes PCE-based approaches are likely the first to be standardized, but that's not an architecture level decision.)


Those are my top comments.  While substantive, I suspect addressing these comments will result in some refactoring and rewording -- but not a major change to the document.

Thank you, and speak to you soon. (Unfortunately, just virtually this
meeting...)

Lou