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

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 1 Apr 2020 13:26:57 +0000

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: [email-masked] <[email-masked]> 
Sent: mercredi 1 avril 2020 15:14
To: Georgios Z. Papadopoulos <[email-masked]>; Georgios Papadopoulos <[email-masked]>; Pascal Thubert (pthubert) <[email-masked]>
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

---

From: Janos Farkas <[email-masked]>
Date: Wed, 1 Apr 2020 20:09:55 +0000

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 <[email-masked]> On Behalf Of Pascal Thubert (pthubert)
Sent: Wednesday, April 1, 2020 3:27 PM
To: [email-masked]
Cc: [email-masked]
Subject: [Raw] FW: New Version Notification for draft-pthubert-raw-architecture-00.txt

Dear all:

Comments welcome!

Keep safe...

Pascal

-----Original Message-----
From: [email-masked] <[email-masked]> 
Sent: mercredi 1 avril 2020 15:14
To: Georgios Z. Papadopoulos <[email-masked]>; Georgios Papadopoulos <[email-masked]>; Pascal Thubert (pthubert) <[email-masked]>
Subject: New Version Notification for draft-pthubert-raw-architecture-00.txt

Abstract:

The IETF Secretariat

-- 
RAW mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/raw

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 2 Apr 2020 12:29:06 +0000

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
> From: Janos Farkas <[email-masked]>
> Sent: mercredi 1 avril 2020 22:10
> To: Pascal Thubert (pthubert) <[email-masked]>
> Cc: [email-masked]; [email-masked]
> 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.
> "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.
> 
> 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.
> 
> 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
> 
> 
> To: Georgios Z. Papadopoulos <[email-masked]>;
> Georgios Papadopoulos <[email-masked]>; Pascal
> Thubert (pthubert) <[email-masked]>
> 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
> [email-masked]

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 2 Apr 2020 14:03:50 +0000

Dear RAWers,

The Industrial people I've been discussing with tell me that they want 5 nines of reliability (PDR=99.999%) because if the faults are independent, then there are 10 nines that we have 2 faults in a row, and 15 nines that you get three.

What they really want is to avoid faults in a row. Because after 4 packet losses, the control loop is unstable and the production line is emergency halted. Once a year you get a bad look. Twice and your equipment is on the curb.

You see that the nines of reliability actually translate in an unscheduled loss of availability that is less than 4 loops. Because we cannot repair that fast, we need redundancy is a requirement.

In the architecture I used the following definition:

   Reliability:  Reliability is a measure of the probability that an
      item will perform its intended function for a specified interval
      under stated conditions.  For RAW, the service that is expected is
      delivery within a bounded latency and a failure is when the packet
      is either lost or delivered too late.  RAW expresses reliability
      in terms of Mean Time Between Failure (MTBF) and Maximum
      Consecutive Failures (MCF).

   Availability:  Availability is a measure of the relative amount of
      time where a path operates in stated condition, in other words
      (uptime)/(uptime+downtime).  Because a serial wireless path may
      not be good enough to provide the required availability, and even
      2 parallel paths may not be over a longer period of time, the RAW
      availability implies a path that is a lot more complex than what
      DetNet typically envisages (a Track).

(feedback welcome!)

Certainly the ratio of usable time is of interest. If it's scheduled and you can coordinate other maintenance activities then it can last longer. But the losses in a row are the real criterion on which automation operates; the reliable cross-over that Rex tells us about must happen within that time.

Keep safe,

Pascal

---

From: Rute Sofia <[email-masked]>
Date: Thu, 2 Apr 2020 14:53:10 +0000

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 <[email-masked]> On Behalf Of Pascal Thubert (pthubert)
Sent: 02 April 2020 14:29
To: Janos Farkas <[email-masked]>
Cc: [email-masked]; [email-masked]
Subject: Re: [Raw] New Version Notification for draft-pthubert-raw-architecture-00.txt

Hello Janos:

Keep safe,

Pascal
> 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.
> "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.
> 
> 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.
> 
> 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.
> To: Georgios Z. Papadopoulos 
> <[email-masked]>;
> Georgios Papadopoulos <[email-masked]>; 
> Pascal Thubert (pthubert) <[email-masked]>
> 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
> [email-masked]

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 2 Apr 2020 17:21:34 +0000

Hello Rute
> - this is not an architecture, so the term framework is possibly better.

I added .framework to the title as suggested in the 01 that I just posted. I expect to keep on working to add more text that's actually architecture.

> - there would be benefits in merging the content of this draft and the OAM

We had a certain organization in the RAW docs and the charter came out differently, so we are reshuffling text between docs, this your impression on the architecture. The architecture deliverable is new with the charter and we are just starting to publish text for it, using text from the problem statement as context since there will not be a problem statement published .

> 
> 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.

Great point. 

> 
> 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?

A path is a very generic term and usually allows A to reach B, so at least it is not a hop between A and B.
In DetNet, the term covers a complex graph with PRE. At 6TiSCH, the decision was to form a term (Track) to cover the complex graph towards B (almost a DODAG but not exactly) on which we apply PAREO functions. 
This doc inherits from 6TISCH for that terminology.

MTBF is not latency but the time between packets that fail to achieve their contract, the contract being for instance in-order delivery within bounded time, to echo DetNet. Or something else, Reliability is abstract to the SLA.

MCF is not packet loss but losses in a row. If you lose exactly every other packet you have a PDR of only 50% but the MCF is 1.  You need both to express that you never lose more than X packets in a row and that this event (of losing >X packets in a row) is really rare.

I put some more text on reliability in -1. Now we need text on architecture as you point out.

Keep safe!

Pascal
> 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.
>

---

From: Janos Farkas <[email-masked]>
Date: Thu, 2 Apr 2020 20:12:13 +0000

Hi Pascal,

Please see few notes in-line  as [Janos Farkas].

-----Original Message-----
From: Pascal Thubert (pthubert) <[email-masked]> 
Sent: Thursday, April 2, 2020 2:29 PM
To: Janos Farkas <[email-masked]>
Cc: [email-masked]; [email-masked]
Subject: RE: New Version Notification for draft-pthubert-raw-architecture-00.txt

Hello Janos:

If that's correct we'll need a new architecture, and we want the wireless experts to help us produce it. 

[Janos Farkas] 
I fully agree that it is absolutely great to have expertise attracted to IETF and involved in our work, and get people with various expertise  work together.

I agree that the architecture is the beginning of a solution, 

[Janos Farkas] 
This is my concern. By developing solution we go beyond the charter.
I think we would rather fit in the charter if we develop a framework, not an architecture. So, I'd suggest to remove architecture and only keep framework.

All the best,
Janos

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. 

Keep safe,

Pascal

---

From: Janos Farkas <[email-masked]>
Date: Thu, 2 Apr 2020 20:33:33 +0000

Hi Pascal,

Reliability and Availability are unfortunately controversial terms as different industries, or even sub-groups of industries have defined them independently of each other, hence, very much unfortunately differently. A lot of discussion is now happening on it in multiple fora with the convergence of Operations Technology, Information Technology, and Telecommunications networking. I would not try to redefine them in RAW. We may consider taking one of the existing or converged definitions.

When it comes to packet loss, I have the same information as you: there is no tolerance of n consecutive packets in industrial automation for the reasons you described. The numbers I heard is no 2 or 3 consecutive packets are allowed to be lost.
This is also captured in the DetNet use cases:
https://tools.ietf.org/html/rfc8578#section-7.4
In DetNet, we did not try to convert this requirement to X nines, but introduced new parameter for it:
https://tools.ietf.org/html/draft-ietf-detnet-flow-information-model-07#section-5.9.5

As it was also pointed out on the DetNet list, it actually often means zero packet loss requirement:
https://mailarchive.ietf.org/arch/msg/detnet/nkoqM-cBlmIhBoyvs4u6nv-q-t0/

So, we need service protection to meet this requirement as described in DetNet Architecture: https://www.rfc-editor.org/rfc/rfc8655.html#name-service-protection.

Stay safe,
Janos

-----Original Message-----
From: RAW <[email-masked]> On Behalf Of Pascal Thubert (pthubert)
Sent: Thursday, April 2, 2020 4:04 PM
To: Rex Buddenberg <[email-masked]>; [email-masked]
Cc: Fabrice Theoleyre <[email-masked]>; CARLOS JESUS BERNARDOS CANO <[email-masked]>
Subject: Re: [Raw] FW: New Version Notification for draft-pthubert-raw-architecture-00.txt

Dear RAWers,

(feedback welcome!)

Keep safe,

Pascal

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 2 Apr 2020 20:51:26 +0000

All good pointers János, many thanks.
Note that for the definitions I did exactly as you suggested. And then provided an interpretation on the RAW angle. That interpretation is what needs attention from the group.

Stay safe !

Pascal

> Le 2 avr. 2020 à 22:33, Janos Farkas <Janos.Farkas=[email-masked]> a écrit :
> 
> Hi Pascal,
>

---

From: Abdussalam Baryun <[email-masked]>
Date: Fri, 3 Apr 2020 21:23:24 +0200

On Wed, Apr 1, 2020 at 3:27 PM Pascal Thubert (pthubert) <pthubert=
[email-masked]> wrote:

> 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.
>

I don't agree that this WG is not required to do a problem statement, in my
opinion any new WG is required to do so.

AB

---

From: Abdussalam Baryun <[email-masked]>
Date: Fri, 3 Apr 2020 21:32:49 +0200

On Thu, Apr 2, 2020 at 4:08 PM Pascal Thubert (pthubert) <pthubert=
[email-masked]> wrote:

> Dear RAWers,
>
> The Industrial people I've been discussing with tell me that they want 5
> nines of reliability (PDR=99.999%) because if the faults are independent,
> then there are 10 nines that we have 2 faults in a row, and 15 nines that
> you get three.
>
> What they really want is to avoid faults in a row. Because after 4 packet
> losses, the control loop is unstable and the production line is emergency
> halted. Once a year you get a bad look. Twice and your equipment is on the
> curb.
>
> You see that the nines of reliability actually translate in an unscheduled
> loss of availability that is less than 4 loops. Because we cannot repair
> that fast, we need redundancy is a requirement.
>

I think the reliability definition in RAW depends on the use case, and IMHO
we cannot define for All RAW technologies or use cases,
furthermore, in wireless cases the packet loss is not correct to measure
reliability, I recommend bit error rate in wireless.

AB

---

From: Janos Farkas <[email-masked]>
Date: Fri, 3 Apr 2020 19:39:08 +0000

Hi Pascal,

The problem statement could be part of the Gap Analysis Document, which is there in the Charter.
The Existing IETF Technologies and Gap Analysis Document could include:
- problem statement
- existing IETF technologies to address the problem
- gaps

Regards,
Janos

-----Original Message-----
From: Pascal Thubert (pthubert) <[email-masked]> 
Sent: Thursday, April 2, 2020 7:22 PM
To: Rute Sofia <[email-masked]>; Pascal Thubert (pthubert) <pthubert=[email-masked]>; Janos Farkas <[email-masked]>
Cc: [email-masked]; [email-masked]
Subject: RE: New Version Notification for draft-pthubert-raw-architecture-00.txt

Hello Rute

> 
> 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..

Great point. 

> 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?

Keep safe!

Pascal
> 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.
> 
> > 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.
> > "1) Produce informational documents describing deterministic 
> > wireless use cases, in continuation to the DetNet Use Cases document
> > 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
> > individual drafts like the data plane drafts; but still RFC 8655 is 
> > a solution at
> high level.
> >
> > 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'm just expressing an opinion on which one I'd suggest out of the 
> > two options for the reasons explained above.
> >
> > Best regards,
> > Janos
> >
> >
> > charter. In particular, the charter expects a requirement draft and 
> > an architecture draft but does not require a problem statement.
> >
> > 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.

---

From: Abdussalam Baryun <[email-masked]>
Date: Fri, 3 Apr 2020 21:49:18 +0200

Hi Janos,

On Thu, Apr 2, 2020 at 10:33 PM Janos Farkas <Janos.Farkas=
[email-masked]> wrote:

> Hi Pascal,
>
> Reliability and Availability are unfortunately controversial terms as
> different industries, or even sub-groups of industries have defined them
> independently of each other, hence, very much unfortunately differently. A
> lot of discussion is now happening on it in multiple fora with the
> convergence of Operations Technology, Information Technology, and
> Telecommunications networking. I would not try to redefine them in RAW. We
> may consider taking one of the existing or converged definitions.
>

I think it is better to define them for each technology.

>
> When it comes to packet loss, I have the same information as you: there is
> no tolerance of n consecutive packets in industrial automation for the
> reasons you described. The numbers I heard is no 2 or 3 consecutive packets
> are allowed to be lost.
>

IMO packet lost is not measure for reliability because we still can repeat
is any protocol, the most important issue is packet error rate, receiving
packets with error is a problem, because in wireless there is possibilities
of packet errors and bit errors per packet which could not be corrected. So
we need packet error rate most likely.

> https://mailarchive.ietf.org/arch/msg/detnet/nkoqM-cBlmIhBoyvs4u6nv-q-t0/

I agree that the packet loss should not be an issue, we need all packets to
be received on time even it was re-sent.

>
>
> So, we need service protection to meet this requirement as described in
> DetNet Architecture:
> https://www.rfc-editor.org/rfc/rfc8655.html#name-service-protection.
>

agree

AB

---

From: Lou Berger <[email-masked]>
Date: Tue, 7 Apr 2020 15:27:29 -0400

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

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 7 Apr 2020 20:24:04 +0000

Hello Lou

We did not ask for adoption yet 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...

Keep safe!

Pascal

> Le 7 avr. 2020 à 21:27, Lou Berger <[email-masked]> 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
>

---

From: Lou Berger <[email-masked]>
Date: Fri, 10 Apr 2020 17:01:34 -0400

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.
>

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

Lou