Re: [Raw] New Version Notification for draft-pthubert-raw-architecture-00.txt

Lou Berger <lberger@labn.net> Fri, 10 April 2020 21:01 UTC

Return-Path: <lberger@labn.net>
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 A34663A0D43 for <raw@ietfa.amsl.com>; Fri, 10 Apr 2020 14:01:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=labn.net
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 eEihe6YDlo29 for <raw@ietfa.amsl.com>; Fri, 10 Apr 2020 14:01:44 -0700 (PDT)
Received: from gproxy5-pub.mail.unifiedlayer.com (gproxy5-pub.mail.unifiedlayer.com [67.222.38.55]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A341A3A0D44 for <raw@ietf.org>; Fri, 10 Apr 2020 14:01:44 -0700 (PDT)
Received: from CMGW (unknown [10.9.0.13]) by gproxy5.mail.unifiedlayer.com (Postfix) with ESMTP id C06031404D7 for <raw@ietf.org>; Fri, 10 Apr 2020 15:01:36 -0600 (MDT)
Received: from box313.bluehost.com ([69.89.31.113]) by cmsmtp with ESMTP id N0mOjWioUtoKZN0mOjAwqv; Fri, 10 Apr 2020 15:01:36 -0600
X-Authority-Reason: nr=8
X-Authority-Analysis: v=2.2 cv=AaTBJzfG c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=dLZJa+xiwSxG16/P+YVxDGlgEgI=:19 a=jpOVt7BSZ2e4Z31A5e1TngXxSK0=:19 a=xqWC_Br6kY4A:10 a=IkcTkHD0fZMA:10 a=cl8xLZFz6L8A:10 a=Vy_oeq2dmq0A:10 a=wU2YTnxGAAAA:8 a=48vgC7mUAAAA:8 a=0FD05c-RAAAA:8 a=AUd_NHdVAAAA:8 a=4F-7qsevL8f6DA26lhkA:9 a=FhV9urUwfnEwVuO4:21 a=epgBk59bdtQ5LpL1:21 a=QEXdDO2ut3YA:10 a=Yz9wTY_ffGCQnEDHKrcv:22 a=w1C3t2QeGrPiZgrLijVG:22 a=l1rpMCqCXRGZwUSuRcM3:22
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version :Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=qpL6fHlJP5/HeAP19ahndXxtcIlJVpWUz70HQ49gYZg=; b=CDj+jFU0hf3CCoIfk2lLuxYIH0 mHecrp8nkQySmsaPF8p8sMxjyQmsarWUUHduJnxQtHfO1GExARi8m2kG3TbgN02R6cmbJsOUiA7ZH uvrk0lhx9hXsilE0KOUGRF60U;
Received: from [127.0.0.1] (port=55545 helo=[IPv6:::1]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.92) (envelope-from <lberger@labn.net>) id 1jN0mO-001Vie-A9; Fri, 10 Apr 2020 15:01:36 -0600
To: "Pascal Thubert (pthubert)" <pthubert=40cisco.com@dmarc.ietf.org>
Cc: "raw-chairs@ietf.org" <raw-chairs@ietf.org>, "raw@ietf.org" <raw@ietf.org>, Rute Sofia <sofia@fortiss.org>, Janos Farkas <Janos.Farkas@ericsson.com>
References: <158574681247.30890.2068130938683129843@ietfa.amsl.com> <MN2PR11MB3565B230F566803AC2AF8F4BD8C90@MN2PR11MB3565.namprd11.prod.outlook.com> <VI1PR07MB441539331E0F7C1FE12D4176F2C90@VI1PR07MB4415.eurprd07.prod.outlook.com> <MN2PR11MB3565D605AFD85EB5839EBBE3D8C60@MN2PR11MB3565.namprd11.prod.outlook.com> <bd11fb5f886b4fc7bded0bc4ce2b728b@fortiss.org> <4270f53f-0ef6-8a08-b7a9-7899e689132b@labn.net> <D61A3F7C-B265-4DF5-A5BE-2C90BD0E0336@cisco.com>
From: Lou Berger <lberger@labn.net>
Message-ID: <a4b524ea-0d16-a12c-587a-33fc038fc180@labn.net>
Date: Fri, 10 Apr 2020 17:01:34 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.3.1
MIME-Version: 1.0
In-Reply-To: <D61A3F7C-B265-4DF5-A5BE-2C90BD0E0336@cisco.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Content-Language: en-US
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - box313.bluehost.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - labn.net
X-BWhitelist: no
X-Source-IP: 127.0.0.1
X-Source-L: Yes
X-Exim-ID: 1jN0mO-001Vie-A9
X-Source:
X-Source-Args:
X-Source-Dir:
X-Source-Sender: ([IPv6:::1]) [127.0.0.1]:55545
X-Source-Auth: lberger@labn.net
X-Email-Count: 3
X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ==
X-Local-Domain: yes
Archived-At: <https://mailarchive.ietf.org/arch/msg/raw/lKYpFjnQ5iDu-yUtpUYEYD2zsbQ>
Subject: Re: [Raw] New Version Notification for draft-pthubert-raw-architecture-00.txt
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: Fri, 10 Apr 2020 21:01:48 -0000

Hi Pascal,

On 4/7/2020 4:24 PM, Pascal Thubert (pthubert) wrote:
> Hello Lou
>
> We did not ask for adoption yet

sorry, my mistake.  I was going through Rick's calls and assumed there 
was a call for adoption on this one too.

>   and are well aware that the architecture piece is missing. We are composing the framework based on the existing RAW documents since there is a mismatch between the pre-WG work and the chartered work.
>
> When that is done (soon) we’ll work on the (new) architecture text; in the current shape it is way too early to judge if the document is adoptable or not. Note that some of what you are rightfully asking already exists partially in the 6TiSCH and DetNet architectures, and there will be some fusion work to do. As co author of both I believe it is quite doable. A matter of time...

Fair enough - thanks for the response and my apologies for the adoption 
comment.

Lou

>
> Keep safe!
>
> Pascal
>
>> Le 7 avr. 2020 à 21:27, Lou Berger <lberger@labn.net> a écrit :
>>
>> Hi,
>>
>>      I just (re)red this draft -- I agree that it doesn't seem to be an architecture.  It does raise some good points related to requirements and possible tools for a DetNet wireless solution.
>>
>> The main points I'd look for from a RAW (DetNet over Wireless) architecture, or framework, document  are how the Data plane (including OAM) and controller planes at the DetNet Layer interact with those same functions at the Wireless layer.  For example, how is a DetNet flow mapped into a wireless track/flow/stream, and how control information from the wireless layer makes it to the DetNet control(ler) plane and how is it used (https://tools.ietf.org/html/rfc5623 provides an example of a generic approach to this).
>>
>> I think the best way forward for the material in this document is for it to be integrated into other existing a future documents -- and for the WG to not adopt it as a foundation for a RAW architecture document.
>>
>> Lou
>>
>>> On 4/2/20 10:53 AM, Rute Sofia wrote:
>>> Hello
>>>
>>> After reading the draft, and being one of the "wireless" as well as "IP people" :), IMO:
>>>
>>> - this is not an architecture, so the term framework is possibly better.
>>> - there would be benefits in merging the content of this draft and the OAM requirements draft.
>>>
>>> Relevant to the research towards industrial environments (e.g., industrial IoT) is that determinism needs to be addressed both on the MAC and IP layer. Ideally working together.
>>>
>>> The terminology, namely, reliability and availability, are somewhat confusing...perhaps state that reliability is in this draft defined based on two specific indicators, namely, latency (MTBF) and packet loss (MCF).  Similarly to availability, how is a "path" defined here? E2E path? 1 hop?
>>>
>>> Best Regards,
>>> Rute Sofia
>>>
>>>
>>> -----Original Message-----
>>> From: RAW <raw-bounces@ietf.org> On Behalf Of Pascal Thubert (pthubert)
>>> Sent: 02 April 2020 14:29
>>> To: Janos Farkas <Janos.Farkas@ericsson.com>
>>> Cc: raw-chairs@ietf.org; raw@ietf.org
>>> Subject: Re: [Raw] New Version Notification for draft-pthubert-raw-architecture-00.txt
>>>
>>> Hello Janos:
>>>
>>> I'll change the title to add /Framework in 01, no worries.
>>>
>>> I have seen a lot of cross participation with DetNet, including you, so I'm reasonably sure that we have that side covered. RAW also attracts wireless experts that did not participate to DetNet. I do not take it as a requirement that what this resulting team produces is a subset of DetNet and is contained in the DetNet Architecture. I actually expect new approaches that are specific to RAW in addition to those inherited from DetNet and possibly extended.
>>>
>>> If that's correct we'll need a new architecture, and we want the wireless experts to help us produce it. I agree that the architecture is the beginning of a solution, which is composed of many components that the architecture outlines. That's the reason why it must come the best informed party, and hopefully RAW is the group that has formed for that at the IETF.
>>>
>>> All in all I believe that the charter makes  a lot of sense.
>>>
>>> Keep safe,
>>>
>>> Pascal
>>>> -----Original Message-----
>>>> From: Janos Farkas <Janos.Farkas@ericsson.com>
>>>> Sent: mercredi 1 avril 2020 22:10
>>>> To: Pascal Thubert (pthubert) <pthubert@cisco.com>
>>>> Cc: raw@ietf.org; raw-chairs@ietf.org
>>>> Subject: RE: New Version Notification for
>>>> draft-pthubert-raw-architecture- 00.txt
>>>>
>>>> Hi Pascal,
>>>>
>>>> I like the approach reflected in the first two milestones in the RAW
>>>> charter. I found this multiple times a good way of working; namely, to
>>>> collect use cases and then collect the requirements out of the use
>>>> cases. I think this helps understanding the problem we are about to
>>>> solve. Perhaps requirements is close to problem statement. I'd be glad
>>>> to see then what can we do with current IETF technology to meet the
>>>> requirements / solve the problem and what are the gaps. This may help
>>>> seeing clearer what could be useful to include in a framework/architecture.
>>>> I understand that these work items are not completely sequential but
>>>> run with some overlaps.
>>>>
>>>>
>>>> Since you brought up the BoF, the consensus reached on the BoF:
>>>> https://datatracker.ietf.org/doc/minutes-106-raw/
>>>> " If do WG for only first 2 work items, informational, do poll again:
>>>> For/against was maybe 80 vs 20."
>>>> where the work items were:
>>>> "1) Produce informational documents describing deterministic wireless
>>>> use cases, in continuation to the DetNet Use Cases document
>>>>   2) Produce informational documents describing the technologies that
>>>> the group will cover (e.g., URLLC, TSCH, 802.11ax/be and possibly LDACS)"
>>>>
>>>>
>>>> As you asked feedback about architecture; honestly, I prefer framework
>>>> to architecture. Architecture for me is kind of a solution. I'm most
>>>> familiar with DetNet, so I'll take it as example. I think RFC 8655
>>>> DetNet Architecture outlines at a high level the DetNet solution to
>>>> the problem coming from RFC 8578 DetNet Use Cases and RFC 8577 DetNet
>>>> Problem Statement. Of course, RFC
>>>> 8655 does not provide the solution details, they are provided by
>>>> individual drafts like the data plane drafts; but still RFC 8655 is a solution at high level.
>>>>
>>>> The RAW charter says: "RAW is not chartered to work on a solution."
>>>>
>>>> So, a framework seems to be better to me than architecture in order to
>>>> remain in the scope of the charter.
>>>>
>>>> As for framework, the DetNet Controller Plane Framework draft comes to
>>>> my mind. In the DetNet WG we discussed with regards to this draft that
>>>> it is good, but it should not specify solution details.
>>>>
>>>> I know, the charter uses "architecture/framework".
>>>> I'm just expressing an opinion on which one I'd suggest out of the two
>>>> options for the reasons explained above.
>>>>
>>>> Best regards,
>>>> Janos
>>>>
>>>>
>>>> -----Original Message-----
>>>> From: RAW <raw-bounces@ietf.org> On Behalf Of Pascal Thubert
>>>> (pthubert)
>>>> Sent: Wednesday, April 1, 2020 3:27 PM
>>>> To: raw@ietf.org
>>>> Cc: raw-chairs@ietf.org
>>>> Subject: [Raw] FW: New Version Notification for draft-pthubert-raw-
>>>> architecture-00.txt
>>>>
>>>> Dear all:
>>>>
>>>> The collection of documents that we built for the BoF does not match
>>>> the list of deliverables that we have now committed with the RAW
>>>> charter. In particular, the charter expects a requirement draft and an
>>>> architecture draft but does not require a problem statement.
>>>>
>>>> Georgios and I picked and restructured text from the PAREO
>>>> requirements and the PS draft, and started an architecture document. I
>>>> just pushed the first version to hint the group of where we wish to go and solicit early feedback.
>>>> Please expect revisions soon to add more architecture text.
>>>>
>>>> Comments welcome!
>>>>
>>>> Keep safe...
>>>>
>>>> Pascal
>>>>
>>>>
>>>> -----Original Message-----
>>>> From: internet-drafts@ietf.org <internet-drafts@ietf.org>
>>>> Sent: mercredi 1 avril 2020 15:14
>>>> To: Georgios Z. Papadopoulos
>>>> <georgios.papadopoulos@imt-atlantique.fr>;
>>>> Georgios Papadopoulos <georgios.papadopoulos@imt-atlantique.fr>;
>>>> Pascal Thubert (pthubert) <pthubert@cisco.com>
>>>> Subject: New Version Notification for
>>>> draft-pthubert-raw-architecture-00.txt
>>>>
>>>>
>>>> A new version of I-D, draft-pthubert-raw-architecture-00.txt
>>>> has been successfully submitted by Pascal Thubert and posted to the
>>>> IETF repository.
>>>>
>>>> Name:        draft-pthubert-raw-architecture
>>>> Revision:    00
>>>> Title:        Reliable and Available Wireless Architecture
>>>> Document date:    2020-04-01
>>>> Group:        Individual Submission
>>>> Pages:        16
>>>> URL:            https://www.ietf.org/internet-drafts/draft-pthubert-raw-
>>>> architecture-00.txt
>>>> Status:         https://datatracker.ietf.org/doc/draft-pthubert-raw-architecture/
>>>> Htmlized:       https://tools.ietf.org/html/draft-pthubert-raw-architecture-00
>>>> Htmlized:       https://datatracker.ietf.org/doc/html/draft-pthubert-raw-
>>>> architecture
>>>>
>>>>
>>>> Abstract:
>>>>     Due to uncontrolled interferences, including the self-induced
>>>>     multipath fading, deterministic networking can only be approached on
>>>>     wireless links.  The radio conditions may change -way- faster than a
>>>>     centralized routing can adapt and reprogram, in particular when the
>>>>     controller is distant and connectivity is slow and limited.  RAW
>>>>     separates the routing time scale at which a complex path is
>>>>     recomputed from the forwarding time scale at which the forwarding
>>>>     decision is taken for an individual packet.  RAW operates at the
>>>>     forwarding time scale.  The RAW problem is to decide, within the
>>>>     redundant solutions that are proposed by the routing, which will be
>>>>     used for each individual packet to provide a DetNet service while
>>>>     minimizing the waste of resources.
>>>>
>>>>
>>>>
>>>>
>>>> Please note that it may take a couple of minutes from the time of
>>>> submission until the htmlized version and diff are available at tools.ietf.org.
>>>>
>>>> The IETF Secretariat
>>>>
>>>>
>>>> --
>>>> RAW mailing list
>>>> RAW@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/raw
>>> --
>>> RAW mailing list
>>> RAW@ietf.org
>>> https://www.ietf.org/mailman/listinfo/raw
>> -- 
>> RAW mailing list
>> RAW@ietf.org
>> https://www.ietf.org/mailman/listinfo/raw