Re: [Raw] RAW notes

"Pascal Thubert (pthubert)" <pthubert@cisco.com> Tue, 30 July 2019 14:59 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 B063F120130 for <raw@ietfa.amsl.com>; Tue, 30 Jul 2019 07:59:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.499
X-Spam-Level:
X-Spam-Status: No, score=-14.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, 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=OxLmQQPp; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=OhRZOMyE
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 awZfWJHQDnPC for <raw@ietfa.amsl.com>; Tue, 30 Jul 2019 07:59:38 -0700 (PDT)
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 D62771200F8 for <raw@ietf.org>; Tue, 30 Jul 2019 07:59:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=54563; q=dns/txt; s=iport; t=1564498777; x=1565708377; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=DeqPhERR92s0MjHTdRC4vt39/Vdcwm4E2o1KSi9DDKY=; b=OxLmQQPp/eOi6fTlL/KJHf0ux9+FPkCqYHd4yGJXQ30Ct5tl7ctZS+XF h8Cl1ERIc577BuC0rmtI7nLGVHy6RAjwMvfQEZvChISiJPytmZgaIytbP A8B2Ky9Lkt0abJ4nu7yMydFBgyy6WkvIPYnlvhvU9LyMUMnVgPipMKLb1 k=;
IronPort-PHdr: 9a23:FtcqcRBVSMJXTvu5Nv09UyQJPHJ1sqjoPgMT9pssgq5PdaLm5Zn5IUjD/qs03kTRU9Dd7PRJw6rNvqbsVHZIwK7JsWtKMfkuHwQAld1QmgUhBMCfDkiuNOLqciY3BthqX15+9Hb9Ok9QS47z
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0AzAABpWkBd/4UNJK1lGgEBAQEBAgEBAQEHAgEBAQGBVgIBAQEBCwGBFC8kLANtVSAECyqHZQONBYJbiVSGJoVbgX+BQoEQA1AECQEBAQwBARgBDgYCAQGEQAKCQSM3Bg4BAwEBBAEBAgEGbYUeDIVKAQEBAQECAREIExMBATcBDwIBCBEBAwEBIQEGByEHChQDBggBAQQBDQUIEweDAYEdTQMdAQIMoR0CgTiIYIIjgnoBAQWBMgEDAwGDVA0LghMDBoE0AYRxhm4XgUA/gRABRoFOfj6CGiIlAgEBAYEmBQERAgEgDBgHCQKDBYImjBcPAy+HJohxjVJACQKCGoZbhwCBMIEUhBKCLocliiuEE409h0uBdo4ZAgQCBAUCDgEBBYFmImdxcBU7DQyCU4JCDBeDToUUhT9yAYEojVABAQ
X-IronPort-AV: E=Sophos;i="5.64,327,1559520000"; d="scan'208,217";a="302971483"
Received: from alln-core-11.cisco.com ([173.36.13.133]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 30 Jul 2019 14:59:35 +0000
Received: from XCH-RCD-004.cisco.com (xch-rcd-004.cisco.com [173.37.102.14]) by alln-core-11.cisco.com (8.15.2/8.15.2) with ESMTPS id x6UExZqE000709 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 30 Jul 2019 14:59:35 GMT
Received: from xhs-rtp-003.cisco.com (64.101.210.230) by XCH-RCD-004.cisco.com (173.37.102.14) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 30 Jul 2019 09:59:34 -0500
Received: from xhs-rtp-002.cisco.com (64.101.210.229) by xhs-rtp-003.cisco.com (64.101.210.230) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 30 Jul 2019 10:59:33 -0400
Received: from NAM03-DM3-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-002.cisco.com (64.101.210.229) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Tue, 30 Jul 2019 10:59:33 -0400
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=iZ8m9AAqMsj4ila1g4uM846GS2grYL7WNik3MmxAqOCy6jAH8YnFZpseK/jV7hV//MXXSFQcUDhdU+U7XWfJrnIGPl3r2OMpw3jPraWL0s/1oqcIjWqSewrpaOJi0s0JlwTd0cYUG4e4Kpc6yqJbNXUUAU6aANGnh+iYyuhuACDfYICYlfQXKQ1o6lJ/lj8pAIYdnVj9t8EPBEXTIaNm+Ve92zNOepxuSUKc17baBm+xto1P+1/Vn0hLvraUobc0/t+chAeBEgK7gZkhVmXUe9b7YgvN0EyRfHWLFfD+MEc5wVRL6G3MQvxj9hMLmmQzNpT/fTGHLr3uk/JwGwrDqQ==
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-SenderADCheck; bh=tNJ0LtfbUl4dgpurJviyVdg3HUOegSH1QqyVZUOfpSI=; b=JR2TSDw0/qCTPCmDECKNGdoiwPvhCSfy52Df2Aw4E1mfZlmHCkOfoLQ7NtsILuVBJsghov8FEaM2LBFhuZ9SZjYUfxG+fLHq8465ZbCXbCowHaqUa+rlA1J1Ys40u0JZvGEaQ4eTdB+Y2l2FyAZmWVu8UbxEV9e9TrkqYZxSe9T25BsIwk2ZVJ2Pit21m03I3sQF0MWeCHG27YTxyIlxCxrCZahjZt4ulZlnmTN8ZiNKuxctOGpwifwkputfbEXRqHYO3WrtMb6Urd+VKTlL29ilLqxZdzXUG8izA8ZSDSa2b/VrTdU8tIkM2OckPdiYHGK39K0A3O72pp5go7BGTA==
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=tNJ0LtfbUl4dgpurJviyVdg3HUOegSH1QqyVZUOfpSI=; b=OhRZOMyEXLfkxKuEb65+cVn3hGWT+XVT0VHgehoUlAl7dilxLOqTy1XJgNR3lOvrThvAZF2mEqSYN97NpEJ/SXnwxMopxxW02T3SF2gy73GpMz36rEg49uHdmBm4r/itRjAIEKPYmHXrjdTDUVFRPaTe8QjRo0B0DmHuBkG23Pc=
Received: from MN2PR11MB3565.namprd11.prod.outlook.com (20.178.250.159) by MN2PR11MB4159.namprd11.prod.outlook.com (20.179.150.225) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2115.14; Tue, 30 Jul 2019 14:59:31 +0000
Received: from MN2PR11MB3565.namprd11.prod.outlook.com ([fe80::1ce9:1582:146c:c50a]) by MN2PR11MB3565.namprd11.prod.outlook.com ([fe80::1ce9:1582:146c:c50a%6]) with mapi id 15.20.2094.017; Tue, 30 Jul 2019 14:59:31 +0000
From: "Pascal Thubert (pthubert)" <pthubert@cisco.com>
To: Janos Farkas <Janos.Farkas@ericsson.com>, "raw@ietf.org" <raw@ietf.org>
CC: "'Lou Berger (lberger@labn.net)'" <lberger@labn.net>, Randal Atkinson <rja.lists@gmail.com>
Thread-Topic: RAW notes
Thread-Index: AdVF8GiXcLOvKXhMTUGrdfDzH7wdJgAXs9CgACRMVTA=
Date: Tue, 30 Jul 2019 14:59:25 +0000
Deferred-Delivery: Tue, 30 Jul 2019 14:59:18 +0000
Message-ID: <MN2PR11MB3565005372C48E260DCF2BEFD8DC0@MN2PR11MB3565.namprd11.prod.outlook.com>
References: <MN2PR11MB3565FB5ED19710FC11F14D7FD8DD0@MN2PR11MB3565.namprd11.prod.outlook.com> <VI1PR07MB5213FFBEA6DB663EE3B4902FF2DD0@VI1PR07MB5213.eurprd07.prod.outlook.com>
In-Reply-To: <VI1PR07MB5213FFBEA6DB663EE3B4902FF2DD0@VI1PR07MB5213.eurprd07.prod.outlook.com>
Accept-Language: fr-FR, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=pthubert@cisco.com;
x-originating-ip: [2001:420:44f3:1300:e0e5:db44:51c1:b69]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 0472749e-88b9-41d3-5975-08d714fe8720
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:MN2PR11MB4159;
x-ms-traffictypediagnostic: MN2PR11MB4159:
x-ms-exchange-purlcount: 5
x-microsoft-antispam-prvs: <MN2PR11MB415949C195B9F0961D8F7368D8DC0@MN2PR11MB4159.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 0114FF88F6
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(136003)(366004)(346002)(376002)(39860400002)(396003)(189003)(199004)(51914003)(221733001)(54896002)(6306002)(55016002)(76116006)(9686003)(30864003)(7116003)(6436002)(66946007)(4326008)(229853002)(66476007)(64756008)(6246003)(316002)(66446008)(81156014)(53936002)(53946003)(8936002)(25786009)(236005)(8676002)(2501003)(66556008)(33656002)(54906003)(110136005)(966005)(102836004)(186003)(3480700005)(446003)(46003)(76176011)(68736007)(606006)(790700001)(6116002)(81166006)(6666004)(11346002)(71200400001)(2906002)(71190400001)(53546011)(14454004)(74316002)(7736002)(86362001)(5660300002)(99286004)(14444005)(486006)(256004)(476003)(6506007)(7696005)(478600001)(52536014); DIR:OUT; SFP:1101; SCL:1; SRVR:MN2PR11MB4159; H:MN2PR11MB3565.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: gR8jyM0brJ6gYINfc/epKrj8A/+eIxSUFB4NJtznhZ70Eq2ejzImAHcAybMoDESD3Jyhm0PH+XCZYBPrYfOkSsxL8/jQrfFTblPWmrVWBVEsG9NLIM6opg1gieCY4w7v90TxlA/3DAtZNfmY86PWvDmNT6gaKFR9gC2b4e8kOXwOf1/jadS+6r44k//ol68qRZCDrEQ6cVJJBvXgPfdHX0/HPJLZJvIsZo5RSmILfWySZvNag8x2ZdUBRTnYfLBhkvumM2zMsbvZe0uN8CSScpt/BiMcCDvHplGvVkmWtX1d8nW3c/ZjynCt0zW4xgx932bOENOBm0t4OL36rAs/7ljrUf098+0+mxPQRqMVwnWips5FEK7dEilDUIdDsxiSkFRH5sAF3JTgxQ9h2kUE+0dVzduO2EfU2g7PC6AJ3bw=
Content-Type: multipart/alternative; boundary="_000_MN2PR11MB3565005372C48E260DCF2BEFD8DC0MN2PR11MB3565namp_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 0472749e-88b9-41d3-5975-08d714fe8720
X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Jul 2019 14:59:31.6008 (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: pthubert@cisco.com
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB4159
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.37.102.14, xch-rcd-004.cisco.com
X-Outbound-Node: alln-core-11.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/raw/Y0dsdoTbDxVKf2chmZ3yCQqb9s0>
Subject: Re: [Raw] RAW notes
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: Tue, 30 Jul 2019 14:59:42 -0000

Hello Janos



Many thanks for the long email, demonstrates great care and that's really appreciated.

Please see below


All the best,

Pascal

From: Janos Farkas <Janos.Farkas@ericsson.com>
Sent: lundi 29 juillet 2019 18:00
To: Pascal Thubert (pthubert) <pthubert@cisco.com>; raw@ietf.org
Cc: 'Lou Berger (lberger@labn.net)' <lberger@labn.net>; Randal Atkinson <rja.lists@gmail.com>
Subject: RE: RAW notes

Hi Pascal,

Thank you for the notes!

Frankly speaking, I understand that work needs to be done as we cannot yet claim having all the details of Layer 3 deterministic wireless networking addressed; however, the details of the work to be done are not clear for me at all. Based on the discussions so far, it is even less clear whether or not a new WG is needed. Actually, I think it would be better to conduct the work to address missing pieces in the relevant existing Working Groups.

I agree that a problem statement draft would be a great next step. It would be even better if gap analysis could be included.


?    We are on it

Having the draft, it could be submitted to and discussed at the relevant WGs, so we could see what they say to the problem and the gaps, what they could do. In addition to DetNet, MANET, CCAMP, which were brought up at the session, further relevant WGs are listed on page 4 in https://datatracker.ietf.org/meeting/104/materials/slides-104-paw-03-detnet-overview-00.pdf.

My view on DetNet includes that DetNet is the WG of the IETF that is overall responsible for the architecture to provide Deterministic Networking on Layer 3 and specify corresponding details as necessary keeping in mind to leverage existing work as much as possible.

"RAW extends DetNet" reads to me that DetNet extensions necessary for wireless should be done in DetNet. For instance, if additional parameters would be needed for a DetNet flow supported by wireless segments, then that could be contributed to the DetNet flow information model draft. Actually, I'd be glad to see it contributed to DetNet what is missing and needed for wireless, and address those needs in DetNet.


?    Well, 6man is responsible for IPv6, but the many "IPv6 over foo" are handled elsewhere, e.g., 6lo, and we've been successful at forming WGs like that one that specialize on a certain aspect.

?    I think we agree that a WG should not attempt to boil the ocean. Seems that the mainstream DetNet has been pretty busy so far with mostly Wired / SP concerns with MPLS and pseudowire, and the group is far from being finished on that. Things evolved positively for wireless, but initially PREOD did not have a O, the model was replicate at ingress and eliminate at egress, great on wires but largely inadequate for wireless. Still today, there is no concern about optimizing the usage of the DetNet path for energy or spectrum, and simple techniques like ARQ and overhearing do not seem to exist at all.

?    If the argument for not forming RAW is that DetNet is handling the topic in house, then DetNet should add RAW's items in its charter. I'm not against it at all, I helped start DetNet with that in mind, and so far was disappointed. But say it does, then should DetNet meet 3-4 times per IETF? This is not our model, we prefer more specialized / smaller groups.

?    I think the most important aspect we achieve with a specialized WG is to attract a more specific crowd that may not show up at the IETF otherwise and can really talk to one another on their particular domain. Merging all work items dilutes the value of the WG for each participants and drives them away.

?    IOW People who do not care about the specialized topic do not need to show up, like DetNet people with only an SP interest will not visit RAW and may attend another group scheduled at the same time. I like that way of the IETF work when we have the right people in the right room, with smaller rooms, though agreeably collisions that sometimes hurt.

?   In the case of wireless I tried since inception of the WG to get Wireless topics in. You know and I know that wireless was always a thing at the edge. DetNet does not look at the problems that I am now facing for our next deployments and I need a place to work on them, else we'll ship proprietary stuff and no one wants that.
As you captured in the notes, DLEP was brought up as potentially very useful. Furthermore, CCAMP was brought up multiple times as CCAMP has addressed various technologies that may have a lot of similarities, e.g., microwave recently.


?

?    Another analog case I'm well aware of is 6TiSCH. 6TiSCH did a lot of work on putting solutions together and pushing the needed RFC work in the relevant WGs. It did quite little on new standard specs, mostly the glue that had no home either at IETF or IEEE. I can list more RFCs from ROLL and 6lo that help accomplish the 6TiSCH architecture than from 6TiSCH itself. But we needed 6TiSCH to maintain the overall picture of what was going on.

?    I expect RAW to generate work for the WGs you indicate, and ask for DetNet reviews for some specs just like the IPv6-oevr-Foo ask for review from 6man occasionally.


I agree that radio layer details should remain abstract from Layer 3 perspective.


?    To a point. Some needs come from the radio  layers and people who do not work on radios are not motivated to solve radio-specific issues. Models that do not understand scheduled radios cannot program the forms of diversity that enable DetNet services. OTOH, the abstraction that we want for RAW should be abstract enough to represent OFDMA as well as TSCH, both capable of injecting diversity in time and frequency.



Actually, my layered view is:

.
.
.
----------------------
DetNet
-----------------------
optionally: TSN
-----------------------
Radio Technology
-----------------------


I do not see the need for a new WG in this layered view.


?    There's more than one DetNet functionality, TSN is probably not everything we'll ever need in particular with radios, and there are many radio technologies. We'll keep forming groups in all layers. Think IEEE 802.11be, aren't they needed?


It is good that we discussed RAW details at the side meeting and did not spend time on the two information item I thought to share. I can share it now. It is just background information, but still may be somewhat relevant.

There are efforts happening at Layer 2 for deterministic wireless. For instance:

3GPP SA2 is working on 5G System support for integration with IEEE 802.1 TSN networks. The architectural extensions to support integration of IEEE 802..1 TSN networks are documented in 3GPP TS 23.501. For lack of better further reference, let me point to the one I have at hand; the liaison exchange on the subject:
https://1.ieee802.org/july-2019-plenary-meeting-in-vienna-austria-tsn-tg-agenda/#Monday_TSN

IEEE P802.11be (TGbe) and IEEE 802.1 TSN TG had a joint session to see where we are with WLAN - TSN integration and what could be done:
https://1.ieee802.org/july-2019-plenary-meeting-in-vienna-austria-tsn-tg-agenda/#Tuesday_80211_TGbe_8211_8021_TSN
 (An analogy to my view on DetNet responsibilities mentioned above: It is the IEEE 802.1 WG who is responsible for the overall IEEE 802 LAN/MAN architecture.)

The reason I added TSN as an option to the layer view is that in case of a wireless - TSN integrated subnet, DetNet may leverage such a subnet.


?    Suer. EHT (.11be) enables .11 extensions to support TSN-like feature. Note that it cannot be the plain application of TSN as is, e.g., the concept of preemption is revisited.

?    RAW actually enables DetNet extensions to optimize resources at forwarding time over a IP-multihop network. All good, and you never see one-WG-does-it-all at any layer.


I'm looking forward to see the problem statement and gap analysis to see what is missing for Layer 3 deterministic wireless networking.


?    Sure, and then again, the group that builds the solution is not necessarily the group that builds the individual tools. As soon as you need a collection of tools or tools extensions, its good to have a WG that centralizes the requests and monitors the progress overall.

Many thanks!

Pascal


Ps:
I'm sorry for sending this mail from vacation; which may imply delayed response on my part. Nonetheless, I thought it may be better to share these thoughts earlier than later.




From: Raw <raw-bounces@ietf.org<mailto:raw-bounces@ietf.org>> On Behalf Of Pascal Thubert (pthubert)
Sent: Monday, July 29, 2019 3:07 PM
To: raw@ietf.org<mailto:raw@ietf.org>
Cc: 'Lou Berger (lberger@labn.net<mailto:lberger@labn.net>)' <lberger@labn.net<mailto:lberger@labn.net>>; Randal Atkinson <rja.lists@gmail.com<mailto:rja.lists@gmail.com>>
Subject: [Raw] RAW notes

Dear all

Many thanks for all those who attended the side meeting last Thursday morning in Ste Catherine., and those who joined the ad-hoc webex. Sorry for the issues starting it, my mistake, not Webex. Also, special thanks to Rand, Lou and Ronald for coming and for their useful inputs.

Below are my RAW notes ; please come back to the list for anything I missed or that I might have misunderstood.

Summary:


  *   RAW extends DetNet to focus on issues that are mostly radio-specific and relate to less consistent transmissions, energy constraints and shared spectrum efficiency. As a technique to optimize forwarding, RAW naturally belongs to RTG Area.
  *   The group needs to write a problem statement that separates the routing time scale and the forwarding time scale, and focuses on forwarding time operations on a given routing construct.
  *   RAW should stay abstract to the radio layer (keep a layered approach). How the PHY is programmed, and whether the radio is single-hop or meshed, are unknown at the IP layer and not part of the RAW abstraction. E.g., programming TSCH slots is out of scope - it may be an item to either recharter 6TiSCH or form a new WG in INT Area.
  *   The RAW charter should present the work as generic (IP layer), the 4 technologies being not limitative but examples against which we assert our generic solution
  *   There may be overlaps with MANET (e.g., use of DLEP), and MANET is well-observed by radio vendors. On the other hand, as an approach towards deterministic networking, RAW is neither mobile not ad-hoc, pretty much the very opposite.


In more details:


  *   A prerequisite to the RAW work is that an end-to-end routing function computes a complex path (we can use the 6TISCH definition of a Track) with a high degree of redundancy and diversity (DetNet PREOF, end-to-end network coding, and possibly radio-specific abstracted techniques such as ARQ, overhearing, frequency diversity, time slotting, and possibly others). How the  routing operation computes the Track is out of scope for RAW. The scope of the RAW operation is one Track, and the goal of the RAW operation is to optimize the use of the Track at the forwarding timescale to maintain the expected service while optimizing the usage of constrained resources such as energy and spectrum.
  *   Another prerequisite is that an IP link can be established over the radio with some guarantees in terms of service reliability, e.g., it can be relied upon to transmit a packet within a bounded latency and provides a guaranteed BER/PDR outside rare but existing transient outage windows that can last from split seconds to minutes. The radio layer can be programmed with abstract parameters, and can return an abstract view of the state of the Link to help forwarding decision (think MANET's DLEP). In the layered approach, how the radio manages its PHY layer is out of control and out of scope. Whether it is single hop or meshed is also unknown and out of scope.
  *   The end-to-end routing can be centralized and can reside outside the network. Reaching to the routing computation can be slow in regards to the speed of events that affect the forwarding operation at the radio layer. Due to the cost and latency to perform a route computation, routing is not expected to be sensitive/reactive to transient changes. The abstraction of a link at the routing level is expected to use statistical operational metrics that aggregate the behavior of a link over long periods of time, and represent its availability as a shade of gray as opposed to either up or down. We distinguish the time scale at which routes are computed that we qualify as slow from the forwarding time scale where per-packet decisions are made. RAW operates at the forwarding time scale on one DetNet flow over one Track.
  *   RAW observes the whole Track in quasi real time. It will consider existing tools such as L2-triggers, DLEP, BFD and inband-OAM to observe the Track, and BIER-TE and SR to control the use of the Track on individual packets.
  *   RAW decisions may be made at the ingress and signaled in-band. Alternatively, they may be made at intermediate hops and depend on the current state of the next hop and local policies. In either case, a per-flow state is installed in all intermediate nodes to recognize the flow and determine the forwarding policy to be applied.


Next steps:


  *   Revise the proposed charter
  *   Send the charter to RTG, request formation a WG
  *   Publish a problem statement draft

All the best

Pascal