Subject: [Detnet] draft charter skeleton - with some meat on it

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 18 Sep 2014 09:10:31 +0000

Hello Norm:

What do you think of :

Background text

Explaining the use cases and the work at IEEE, I'm sure you have text?
That would be 3-4 paragraphs, introducing the concepts behind zero congestion loss and PRP

WG description

The Working Group will focus on enabling  end-to-end path with Deterministic Properties and High Reliability.

The extent of the problem space for the WG includes multihop paths which include Layer-2 Bridging and Layer-3 routing though only Layer-3 operations are specific.

A focus will be on maintaining consistency and compatibility with the concurrent work that is happening at IEEE for the Layer-2 operations.

Initially, the WG will limit its scope to a Campus or a Small/Home office Network and excludes Wide Area Networks.

The WG will interface with other appropriate groups in the IETF in the Internet, Transport, Operations and Management, Routing and Security areas.

Work Items

- Deliverables for the first round could be/include :

  * an analysis of the requirements in a number of environments (3-4 drafts which would include process control, factory automation, planes and video studios)

  * a status of the work at IEEE with the general problem statement as perceived there, and the directions that is being taken. Potential solutions will be explored.

  * and a requirement draft for the definition of a PhB at the transport area.

  ->  all informational track

  * a generic format for flow identification that works across layers.

  * a study of scoping, including the definition of Realm-Local scope and Admin-Local scope (pre RFC 7346) where for instance the deterministic technology is consistent over a Realm and achievable across technologies and layers over an Admin local scope

  -> those would be standard track

Milstones

TBD, probably all drafts to IESG one year after chartering

What do you think?

Pascal

---

From: "Norman Finn (nfinn)" <[email-masked]>
Date: Fri, 19 Sep 2014 16:49:12 +0000

This looks like a good start.  Detailed comments in a later message.  I’m getting on an airplane, soon, also.

— Norm

From: Pascal Thubert <[email-masked]<mailto:[email-masked]>>
Date: Thursday, September 18, 2014 at 02:10 AM
To: Norman Finn <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: draft charter skeleton - with some meat on it

Hello Norm:

What do you think of :

Background text

Explaining the use cases and the work at IEEE, I’m sure you have text?
That would be 3-4 paragraphs, introducing the concepts behind zero congestion loss and PRP

WG description

Work Items

Milstones

What do you think?

Pascal

---

From: "Anca Zamfir (ancaz)" <[email-masked]>
Date: Fri, 19 Sep 2014 17:09:06 +0000

Hi,
A few questions inline.

thanks,
-anca

From: "Pascal Thubert (pthubert)" <[email-masked]<mailto:[email-masked]>>
Date: Thursday, September 18, 2014 11:10 AM
To: "Norman Finn (nfinn)" <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: [Detnet] draft charter skeleton - with some meat on it

Hello Norm:

What do you think of :

Background text

WG description

[AZ] Could you please clarify what you mean by "only Layer-3 operations are specific"?

Work Items

[AZ] In this bullet, do you mean the IEEE solutions will be explored? Or new proposals?

[AZ] Is this for an IPv6 problem space only?

[AZ] What about solution and architecture documents?

Milstones

What do you think?

Pascal

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 19 Sep 2014 17:19:41 +0000

Hello Anca:

Please see inline

...

Background text

WG description

[PT] Typo + autocorrect... I meant specified. The group will not enter IEEE-land but complete the work in a consistent fashion.

Work Items

  * a status of the work at IEEE with the general problem statement as perceived there, and the directions that is being taken. Potential solutions will be explored.
[AZ] In this bullet, do you mean the IEEE solutions will be explored? Or new proposals?
[PT] Well, I meant to cover the list that Norm indicated at the beginning of this thread. The solution space in its abstract form does not depend on L2 vs. L3. The gory details of encoding will, but then that is not the scope of that document. How would you suggest to reword it?

  * a study of scoping, including the definition of Realm-Local scope and Admin-Local scope (pre RFC 7346) where for instance the deterministic technology is consistent over a Realm and achievable across technologies and layers over an Admin local scope
[AZ] Is this for an IPv6 problem space only?
[PT] Certainly not, we must make that more generic/abstract to encompass v4.

  -> those would be standard track
[AZ] What about solution and architecture documents?
[PT] solution exploration and architecture provide information but no interop rules and MUSTs. Informational is fine...

Cheers,

Pascal

Milstones

What do you think?

Pascal

---

From: "Anca Zamfir (ancaz)" <[email-masked]>
Date: Fri, 19 Sep 2014 18:04:33 +0000

Hi Pascal,
Thanks for the response. Please see inline for [AZ2].

cheers,
-anca

Background text

WG description

[PT] Typo + autocorrect… I meant specified. The group will not enter IEEE-land but complete the work in a consistent fashion.

[AZ2] Is the expectation that L2 devices will mainly be able to operate as specified today? And where not, any required extensions must be specified in IEEE? Will IETF be driving the overall architecture? Or is it somehow a joint effort?

Work Items

[AZ2] Thanks for the clarification. Not sure on the wording, maybe: "Analysis of the IEEE related work, its solutions and limitations." and a separate bullet for "Potential solutions will be explored".

  * a study of scoping, including the definition of Realm-Local scope and Admin-Local scope (pre RFC 7346) where for instance the deterministic technology is consistent over a Realm and achievable across technologies and layers over an Admin local scope
[AZ] Is this for an IPv6 problem space only?
[PT] Certainly not, we must make that more generic/abstract to encompass v4.
[AZ2] Maybe clarify..since RFC7346 is for IPv6 only? Something like "a study of generic scoping, including the definition of … "?

  -> those would be standard track
[AZ] What about solution and architecture documents?
[PT] solution exploration and architecture provide information but no interop rules and MUSTs. Informational is fine…
[AZ2] Is this then covered under "Potential solutions will be explored" above under informational?

Cheers,

Pascal

Milstones

What do you think?

Pascal

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 19 Sep 2014 18:11:13 +0000

Hello Anca:

Background text

WG description

[PT] My understanding from the 802.1 work is that we have to live with the existing silicon, which excludes, like, MPLS switching in the bridges. I think that IEEE is already driving the architecture, but in a fashion that has great care and concern to protect the converging interests of both sides.

Work Items

  * a study of scoping, including the definition of Realm-Local scope and Admin-Local scope (pre RFC 7346) where for instance the deterministic technology is consistent over a Realm and achievable across technologies and layers over an Admin local scope
[AZ] Is this for an IPv6 problem space only?
[PT] Certainly not, we must make that more generic/abstract to encompass v4.
[AZ2] Maybe clarify..since RFC7346 is for IPv6 only? Something like "a study of generic scoping, including the definition of ... "?
[PT] Agreed, I'll look into it and propose an update.

[PT] Yes, it is. It's proposing a taxonomy not defining the final solution.

Cheers,

Pascal

Milstones

What do you think?

Pascal

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 22 Sep 2014 13:48:26 +0000

Dear all:

Please find below my latest and the txt version attached. I included (my understanding of) Anca's point (Thanks Anca!) as well as a multilayer/segment discussion as stirred by George. I stole and adapted text from various places, the original authors will recognize themselves : )

Background on deterministic networking

Operational Technology (OT) refers to industrial networks that are typically used for monitoring systems and supporting control loops, as well as movement detection systems for use in Process Control (i.e., process manufacturing) and Factory Automation (i.e., discrete manufacturing). Due to its different goals, OT has evolved totally in parallel and in a manner that is radically different from IT/ICT, focusing on highly secure, reliable and deterministic networks, with limited scalability over a bounded area.

The convergence of IT and OT technologies, also called the Industrial Internet, will represent a major evolution for both sides. The work has already started; in particular, the Industrial Automation space has been developing a number of Ethernet-based "fieldbus" replacements, meant to provide "determinism", with the focus to transport a fully characterized flow over a very controlled environment (i.e., a "well regulated" factory floor), with a bounded latency, a low frame loss, and a very narrow jitter.

In parallel, a high demand for a standard format drove the formation of the Audio/Video Bridging (AVB) standards effort of IEEE 802.1, destined to the professional and home audio/video markets. While aimed at less critical applications, AVB networks share very similar characteristics. Other instances of deterministic networks have arisen as well, for instance in the context of vehicles and avionics, with the mission-critical "Avionics Full-Duplex Switched Ethernet" (AFDX) that was designed as part of the ARIC 664 standards. The work started at the IEEE802.1 to provide deterministic Ethernet A/V Bridging has now generalized and was renamed "Time Sensitive Networking" (TSN).

The IETF and the IEEE need now to collaborate and define an abstract model that can be applicable at Layer-2 and Layer-3 along segments of different technologies, for instance across a (limited) number of 802.1 bridges and then a (limited) number of IP routers, such as 6TiSCH nodes which, by the way, operate on a different MAC/PHY. The model should enable fully scheduled operations by a central controller, with capabilities such as zero congestion loss and live-live parallel transmission for increased reliability, as well as a more distributed model similar to Intserv, though bounded in reach and possibilities.

WG description

The Working Group will focus on the signaling and forwarding models that are required to enable an end-to-end path with the Deterministic properties of controlled latency, low packet loss, ultra-low jitter, and High Reliability, over a moderate-sized mixed Layer 2 / Layer 3 network composed of IEEE802.1 bridges, routers, and hosts, within a single administrative domain such as a campus or a Small/Home office Network.
The extent of the problem space for the WG includes the establishment and maintenance of multi-hop paths over Layer-2 bridged and Layer-3 routed segments, and though only Layer-3 operations will be specified in Standard Track documents, the group will maintain consistency and compatibility with the concurrent work that is happening at IEEE802.1 TSN for the Layer-2 operations.
The work will include the characterization and the marking of flows. It will apply to flows that can be well-characterized in a manner that allows to tightly reserve the appropriate network resources for the flows in advance, and release/reuse the resources when they are not required.

The WG will interface with other appropriate groups in the IETF in the Internet (e.g. 6TiSCH), Transport (e.g. TSVWG), Operations and Management, Routing and Security areas.
Work Items

- Deliverables:
  * an analysis of the requirements in a number of environments (3-4 drafts which would include process control, factory automation, planes and video studios)
  * A general problem statement including an analysis of the proposed solutions of the related work at IEEE802.1TSN, with a status of the work done and left to be achieved, and the directions that are being taken.
  * A solution taxonomy, where potential solution paradigms will be explored, such as Peer-to-peer protocols (along the lines of MSRP or RSVP), Central controller (along the lines of SDN or PCE), Connection to Operations (Application) Controllers, and Mixed scenarios.
  * requirement drafts will be produced for other WGs as deemed necessary, with for instance a requirement draft for the definition of a PHsB at the transport area.
  * a study of generic scoping. For IPv6, the study will include the definition of Link-Local, Realm-Local and Admin-Local scoped operation (per RFC 7346) where for instance the deterministic technology is consistent over a Link or a Realm Local Scope and achievable across technologies and layers over an Admin-Local scope. Similar scoping will be studied for IPv4.

  ->  all those documents planned for informational track

  * a data model for flow characterization for use in flow reservation,
  * a flow identification for use in packet forwarding, with declination on 6TiSCH and MPLS.

Milestones

Cheers,

Pascal

---

From: Rodney Cummings <[email-masked]>
Date: Mon, 22 Sep 2014 09:31:47 -0500

Thanks Pascal,

This looks great. I have a couple of minor comments, shown in context 
below.

----------------------------
Rodney Cummings
Principal Software Architect, Industrial/Embedded Networks
National Instruments
Tel: (512) 683-8544
Fax: (512) 683-8661
Email: [email-masked]

From:   "Pascal Thubert (pthubert)" <[email-masked]>
To:     "Anca Zamfir (ancaz)" <[email-masked]>, "Norman Finn (nfinn)" 
<[email-masked]>, "Erik Nordmark ([email-masked])" 
<[email-masked]>, "Alia Atlas ([email-masked])" 
<[email-masked]>, 
Cc:     "[email-masked]" <[email-masked]>
Date:   09/22/2014 09:04 AM
Subject:        Re: [Detnet] draft charter skeleton - with some meat on it
Sent by:        "detnet" <[email-masked]>

Dear all:
 
Please find below my latest and the txt version attached. I included (my 
understanding of) Anca’s point (Thanks Anca!) as well as a 
multilayer/segment discussion as stirred by George. I stole and adapted 
text from various places, the original authors will recognize themselves : 
)

Operational Technology (OT) refers to industrial networks that are 
typically used for monitoring systems and supporting control loops, as 
well as movement detection systems for use in Process Control (i.e., 
process manufacturing) and Factory Automation (i.e., discrete 
manufacturing). Due to its different goals, OT has evolved totally in 
parallel and in a manner that is radically different from IT/ICT, focusing 
on highly secure, reliable and deterministic networks, with limited 
scalability over a bounded area.
 
The convergence of IT and OT technologies, also called the Industrial 
Internet, will represent a major evolution for both sides. The work has 
already started; in particular, the Industrial Automation space has been 
developing a number of Ethernet-based “fieldbus” replacements, meant to 
provide “determinism”, with the focus to transport a fully characterized 
flow over a very controlled environment (i.e., a “well regulated” factory 
floor), with a bounded latency, a low frame loss, and a very narrow 
jitter.
 
In parallel, a high demand for a standard format drove the formation of 
the Audio/Video Bridging (AVB) standards effort of IEEE 802.1, destined to 
the professional and home audio/video markets. While aimed at less 
critical applications, AVB networks share very similar characteristics. 
Other instances of deterministic networks have arisen as well, for 
instance in the context of vehicles and avionics, with the 
mission-critical “Avionics Full-Duplex Switched Ethernet” (AFDX) that was 
designed as part of the ARIC 664 standards. 

[RC] There are a large number of Ethernet-based standards for industrial 
and in-vehicle applications that predate the 802.1 AVB/TSN work. If we 
mention only one of those as an example, that might lead to an impression 
that we are limiting our scope to AFDX. In order to communicate the same 
point, I tend to say something like "for example, ARINC 664 AFDX, 
PROFINET, ODVA Ethernet/IP, and EtherCAT".

The work started at the IEEE802.1 to provide deterministic Ethernet A/V 
Bridging has now generalized and was renamed "Time Sensitive Networking" 
(TSN).
 
The IETF and the IEEE need now to collaborate and define an abstract model 
that can be applicable at Layer-2 and Layer-3 along segments of different 
technologies, for instance across a (limited) number of 802.1 bridges and 
then a (limited) number of IP routers, such as 6TiSCH nodes which, by the 
way, operate on a different MAC/PHY. 

[RC] This may need some clarification. This makes it sounds like 6TiSCH is 
not an 802 MAC/PHY. You may be referring to the fact that 802.1 AVB/TSN 
currently does not specifically reference 802.15.4e as a supported 
MAC/PHY. If that is a concern, I think we could get consensus to address 
that in 802.1. I don't think that work would have an impact on the IETF 
work, but I could be wrong.

The model should enable fully scheduled operations by a central 
controller, with capabilities such as zero congestion loss and live-live 
parallel transmission for increased reliability, as well as a more 
distributed model similar to Intserv, though bounded in reach and 
possibilities.

WG description
 
The Working Group will focus on the signaling and forwarding models that 
are required to enable an end-to-end path with the Deterministic 
properties of controlled latency, low packet loss, ultra-low jitter, and 
High Reliability, over a moderate-sized mixed Layer 2 / Layer 3 network 
composed of IEEE802.1 bridges, routers, and hosts, within a single 
administrative domain such as a campus or a Small/Home office Network.
The extent of the problem space for the WG includes the establishment and 
maintenance of multi-hop paths over Layer-2 bridged and Layer-3 routed 
segments, and though only Layer-3 operations will be specified in Standard 
Track documents, the group will maintain consistency and compatibility 
with the concurrent work that is happening at IEEE802.1 TSN for the 
Layer-2 operations.
The work will include the characterization and the marking of flows. It 
will apply to flows that can be well-characterized in a manner that allows 
to tightly reserve the appropriate network resources for the flows in 
advance, and release/reuse the resources when they are not required. 
 
The WG will interface with other appropriate groups in the IETF in the 
Internet (e.g. 6TiSCH), Transport (e.g. TSVWG), Operations and Management, 
Routing and Security areas.
Work Items
 
- Deliverables:
  * an analysis of the requirements in a number of environments (3-4 
drafts which would include process control, factory automation, planes and 
video studios)
  * A general problem statement including an analysis of the proposed 
solutions of the related work at IEEE802.1TSN, with a status of the work 
done and left to be achieved, and the directions that are being taken.
  * A solution taxonomy, where potential solution paradigms will be 
explored, such as Peer-to-peer protocols (along the lines of MSRP or 
RSVP), Central controller (along the lines of SDN or PCE), Connection to 
Operations (Application) Controllers, and Mixed scenarios.
  * requirement drafts will be produced for other WGs as deemed necessary, 
with for instance a requirement draft for the definition of a PHsB at the 
transport area.
  * a study of generic scoping. For IPv6, the study will include the 
definition of Link-Local, Realm-Local and Admin-Local scoped operation 
(per RFC 7346) where for instance the deterministic technology is 
consistent over a Link or a Realm Local Scope and achievable across 
technologies and layers over an Admin-Local scope. Similar scoping will be 
studied for IPv4.

  * a data model for flow characterization for use in flow reservation, 
  * a flow identification for use in packet forwarding, with declination 
on 6TiSCH and MPLS. 

Cheers,
 
Pascal[attachment "detnet charter.txt" deleted by Rodney Cummings/AUS/NIC] 
_______________________________________________
detnet mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/detnet

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 22 Sep 2014 14:46:04 +0000

Ack, Rodney, thanks a bunch!

For the references, we’d then move the industrial standards to the industrial paragraph, shouldn’t we? I agree it is good to give some sense that there are multiple protocols out there, though they are focused on a usage and do not necessarily provide the whole functional coverage in an open fashion.

The 6TiSCH sentence is too complex, let me split. What about:

The convergence of IT and OT technologies, also called the Industrial Internet, will represent a major evolution for both sides. The work has already started; in particular, the Industrial Automation space has been developing a number of Ethernet-based “fieldbus” replacements, meant to provide “determinism”, with the focus to transport a fully characterized flow over a very controlled environment (i.e., a “well regulated” factory floor), with a bounded latency, a low frame loss, and a very narrow jitter. Examples of such protocols include PROFINET, ODVA Ethernet/IP, and EtherCAT.

In parallel, a high demand for a standard format drove the formation of the Audio/Video Bridging (AVB) standards effort of IEEE 802.1, destined to the professional and home audio/video markets. While aimed at less critical applications, AVB networks share very similar characteristics. Other instances of deterministic networks have arisen as well, for instance in the context of vehicles and avionics, with the mission-critical “Avionics Full-Duplex Switched Ethernet” (AFDX) that was designed as part of the ARIC 664 standards. The work started at the IEEE802.1 to provide deterministic Ethernet A/V Bridging has now generalized to all these use cases and was renamed "Time Sensitive Networking" (TSN).

The IETF and the IEEE need now to collaborate and define an abstract model that can be applicable at Layer-2 and Layer-3 along segments of different technologies. With this new work, a path may span for instance across a (limited) number of 802.1 bridges and then a (limited) number of IP routers. In that example, the IEEE802.1 bridges may be operating at Layer-2 over Ethernet whereas the IP routers may be 6TiSCH nodes operating at Layer-2 and/or Layer-3 over the IEEE802.15.4e MAC.

The model should enable fully scheduled operations by a central controller, with capabilities such as zero congestion loss and live-live parallel transmission for increased reliability, as well as a more distributed model similar to Intserv, though bounded in reach and possibilities.

WG description

The Working Group will focus on the signaling and forwarding models that are required to enable an end-to-end path with the deterministic properties of controlled latency, low packet loss, ultra-low jitter, and High Reliability, over a moderate-sized mixed Layer 2 / Layer 3 network composed of IEEE802.1 bridges, routers, and hosts, within a single administrative domain such as a campus or a Small/Home office Network.
The extent of the problem space for the WG includes the establishment and maintenance of multi-hop paths over Layer-2 Bridged and Layer-3 routed segments, and though only Layer-3 operations will be specified in Standard Track documents, the group will maintain consistency and compatibility with the concurrent work that is happening at IEEE802.1 TSN for the Layer-2 operations.
The work will include the characterization and the marking of flows. It will apply to flows that can be well-characterized in a manner that allows to tightly reserve the appropriate network resources for the flows in advance, and release/reuse the resources when they are not required.

- Deliverables:
  * requirement drafts will be produced for other WGs as deemed necessary, with for instance a requirement draft for the definition of a PHB at the transport area.

Cheers,

Pascal

From: Rodney Cummings [mailto:[email-masked]]
Sent: lundi 22 septembre 2014 16:32
To: Pascal Thubert (pthubert)
Cc: Alia Atlas ([email-masked]); Anca Zamfir (ancaz); [email-masked]; Norman Finn (nfinn); Erik Nordmark ([email-masked])
Subject: Re: [Detnet] draft charter skeleton - with some meat on it

Thanks Pascal,

This looks great. I have a couple of minor comments, shown in context below.

----------------------------
Rodney Cummings
Principal Software Architect, Industrial/Embedded Networks
National Instruments
Tel: (512) 683-8544
Fax: (512) 683-8661
Email: [email-masked]<mailto:[email-masked]>

From:        "Pascal Thubert (pthubert)" <[email-masked]<mailto:[email-masked]>>
To:        "Anca Zamfir (ancaz)" <[email-masked]<mailto:[email-masked]>>, "Norman Finn (nfinn)" <[email-masked]<mailto:[email-masked]>>, "Erik Nordmark ([email-masked]<mailto:[email-masked]>)" <[email-masked]<mailto:[email-masked]>>, "Alia Atlas ([email-masked]<mailto:[email-masked]>)" <[email-masked]<mailto:[email-masked]>>,
Cc:        "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Date:        09/22/2014 09:04 AM
Subject:        Re: [Detnet] draft charter skeleton - with some meat on it
Sent by:        "detnet" <[email-masked]<mailto:[email-masked]>>
________________________________

Dear all:

Please find below my latest and the txt version attached. I included (my understanding of) Anca’s point (Thanks Anca!) as well as a multilayer/segment discussion as stirred by George. I stole and adapted text from various places, the original authors will recognize themselves : )

The convergence of IT and OT technologies, also called the Industrial Internet, will represent a major evolution for both sides. The work has already started; in particular, the Industrial Automation space has been developing a number of Ethernet-based “fieldbus” replacements, meant to provide “determinism”, with the focus to transport a fully characterized flow over a very controlled environment (i.e., a “well regulated” factory floor), with a bounded latency, a low frame loss, and a very narrow jitter.

In parallel, a high demand for a standard format drove the formation of the Audio/Video Bridging (AVB) standards effort of IEEE 802.1, destined to the professional and home audio/video markets. While aimed at less critical applications, AVB networks share very similar characteristics. Other instances of deterministic networks have arisen as well, for instance in the context of vehicles and avionics, with the mission-critical “Avionics Full-Duplex Switched Ethernet” (AFDX) that was designed as part of the ARIC 664 standards.

[RC] There are a large number of Ethernet-based standards for industrial and in-vehicle applications that predate the 802.1 AVB/TSN work. If we mention only one of those as an example, that might lead to an impression that we are limiting our scope to AFDX. In order to communicate the same point, I tend to say something like "for example, ARINC 664 AFDX, PROFINET, ODVA Ethernet/IP, and EtherCAT".

The work started at the IEEE802.1 to provide deterministic Ethernet A/V Bridging has now generalized and was renamed "Time Sensitive Networking" (TSN).

The IETF and the IEEE need now to collaborate and define an abstract model that can be applicable at Layer-2 and Layer-3 along segments of different technologies, for instance across a (limited) number of 802.1 bridges and then a (limited) number of IP routers, such as 6TiSCH nodes which, by the way, operate on a different MAC/PHY.

[RC] This may need some clarification. This makes it sounds like 6TiSCH is not an 802 MAC/PHY. You may be referring to the fact that 802.1 AVB/TSN currently does not specifically reference 802.15.4e as a supported MAC/PHY. If that is a concern, I think we could get consensus to address that in 802.1. I don't think that work would have an impact on the IETF work, but I could be wrong.

The model should enable fully scheduled operations by a central controller, with capabilities such as zero congestion loss and live-live parallel transmission for increased reliability, as well as a more distributed model similar to Intserv, though bounded in reach and possibilities.

WG description

- Deliverables:

Cheers,

Pascal[attachment "detnet charter.txt" deleted by Rodney Cummings/AUS/NIC] _______________________________________________
detnet mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/detnet

---

From: Rodney Cummings <[email-masked]>
Date: Mon, 22 Sep 2014 10:13:29 -0500

Looks great.

From:   "Pascal Thubert (pthubert)" <[email-masked]>
To:     Rodney Cummings <[email-masked]>, 
Cc:     "Erik Nordmark \([email-masked]\)" <[email-masked]>, 
"[email-masked]" <[email-masked]>, "Norman Finn \(nfinn\)" 
<[email-masked]>, "Anca Zamfir \(ancaz\)" <[email-masked]>, "Alia Atlas 
\([email-masked]\)" <[email-masked]>
Date:   09/22/2014 09:46 AM
Subject:        Re: [Detnet] draft charter skeleton - with some meat on it
Sent by:        "detnet" <[email-masked]>

For the references, we’d then move the industrial standards to the 
industrial paragraph, shouldn’t we? I agree it is good to give some sense 
that there are multiple protocols out there, though they are focused on a 
usage and do not necessarily provide the whole functional coverage in an 
open fashion.

 
jitter. Examples of such protocols include PROFINET, ODVA Ethernet/IP, and 
EtherCAT.
 
In parallel, a high demand for a standard format drove the formation of 
the Audio/Video Bridging (AVB) standards effort of IEEE 802.1, destined to 
the professional and home audio/video markets. While aimed at less 
critical applications, AVB networks share very similar characteristics. 
Other instances of deterministic networks have arisen as well, for 
instance in the context of vehicles and avionics, with the 
mission-critical “Avionics Full-Duplex Switched Ethernet” (AFDX) that was 
designed as part of the ARIC 664 standards. The work started at the 
IEEE802.1 to provide deterministic Ethernet A/V Bridging has now 
generalized to all these use cases and was renamed "Time Sensitive 
Networking" (TSN).
 
The IETF and the IEEE need now to collaborate and define an abstract model 
that can be applicable at Layer-2 and Layer-3 along segments of different 
technologies. With this new work, a path may span for instance across a 
(limited) number of 802.1 bridges and then a (limited) number of IP 
routers. In that example, the IEEE802.1 bridges may be operating at 
Layer-2 over Ethernet whereas the IP routers may be 6TiSCH nodes operating 
at Layer-2 and/or Layer-3 over the IEEE802.15.4e MAC. 

WG description
 
are required to enable an end-to-end path with the deterministic 
maintenance of multi-hop paths over Layer-2 Bridged and Layer-3 routed 

- Deliverables:
with for instance a requirement draft for the definition of a PHB at the 

 

Cheers,
 
Pascal
 
From: Rodney Cummings [mailto:[email-masked]] 
Sent: lundi 22 septembre 2014 16:32
To: Pascal Thubert (pthubert)
Cc: Alia Atlas ([email-masked]); Anca Zamfir (ancaz); [email-masked]; 
Norman Finn (nfinn); Erik Nordmark ([email-masked])
Subject: Re: [Detnet] draft charter skeleton - with some meat on it
 
Thanks Pascal, 

From:        "Pascal Thubert (pthubert)" <[email-masked]> 
To:        "Anca Zamfir (ancaz)" <[email-masked]>, "Norman Finn (nfinn)" 
<[email-masked]>, "Erik Nordmark ([email-masked])" <
[email-masked]>, "Alia Atlas ([email-masked])" <[email-masked]>, 

Dear all: 

  

  

  

WG description 

  
- Deliverables: 

  

Cheers, 
  
Pascal[attachment "detnet charter.txt" deleted by Rodney Cummings/AUS/NIC] 
_______________________________________________
detnet mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/detnet[attachment "detnet 
charter.txt" deleted by Rodney Cummings/AUS/NIC] 
_______________________________________________
detnet mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/detnet

---

From: "Black, David" <[email-masked]>
Date: Mon, 22 Sep 2014 11:51:40 -0400

Pascal,

This text looks promising.  Here are a few things to consider.

(1) How does this relate to IETF's focus on the public (capital-I) Internet?

- Would it be reasonable to envision deterministic networking running
over (suitably provisioned) Internet paths in a network, e.g.,
to connect related industrial sites?
- I'm reacting to "very controlled environment" at the end of the
      second paragraph in Background and suggesting some text to
      address the broader possibilities.

(2) I see a disconnect between the charter text's focus on "models"
and the two specific standards track protocol deliverables.

- This starts at the end of the background that seems to scope the
      work solely to models.  The proposed work is not just to
      produce models, but also protocol support for deterministic
      IP-based networking (some of which might take place in other
      WGs).

(3) Please add a sentence or two on how coordination with the IEEE
is envisioned to work.

- How do we ensure (or at least make it highly likely) that the IEEE
      and IETF develop and work with common models and requirements?
- This is about heading off divergence in advance, and might be as
      simple as key people participating in both organizations.

(4) For deliverables:

- I would combine the first two, so that the use cases support both
      the problem statement and high-level requirements.
- The IP scoping work feels like it's related to the solution taxonomy,
      but I'm not sure whether those should be combined.  At a minimum,
      the solution taxonomy should discuss the role of IP scope.
- There's probably some sequencing in the dates with the requirements
      and problem statement coming before the two standards-track
      documents.

(5) Flow characterization - between the third paragraph in the WG
description and the deliverable, I'm missing something about how the
"data model for flow characterization" is intended to be used.

- Suggestion: list reservation protocols with which the model could
be used (e.g., RSVP) as examples, making it clear that the WG
decides which ones are relevant.
- What is IEEE doing for flow reservation?  That should be mentioned.

(6) I wonder about committing this proposed WG to produce requirements
for work in other WGs.

- Some flexibility and lazy evaluation of where to do work may be
      better.
- I would suggest softening this language to talk about requirements
as deliverables, and discuss the possibility of work being
done in other WGs up in the main charter text.

Thanks,
--David

From: detnet [mailto:[email-masked]] On Behalf Of Pascal Thubert (pthubert)
Sent: Monday, September 22, 2014 9:48 AM
To: Anca Zamfir (ancaz); Norman Finn (nfinn); Erik Nordmark ([email-masked]); Alia Atlas ([email-masked])
Cc: [email-masked]
Subject: Re: [Detnet] draft charter skeleton - with some meat on it

Dear all:

WG description

Work Items

- Deliverables:

Milestones

Cheers,

Pascal

---

From: Karl Weber <[email-masked]>
Date: Mon, 22 Sep 2014 16:37:36 +0000

David,

A few cents regarding (1)
Industrial control is structured in several hierarchical levels.
It would be difficult to put everything in a single LAN - thus, a structured system would be fine and IETF may be a good choice to structure a machinery park.

The most important area is the infrastructuring area: water, waste, electricity and transposrt.
Especially electricity requires a highly deterministic network and it is definitely a WAN.
Wind parks/Virtual power plants are other examples in this areas.

And electricity is a very important factor for the quality of production seamless interaction between infrastructure and production will be a key success factor in the future ...

Motors and other equipment may be used in infrastructure and industry - a common approach is highly welcome.

And cars would require a common deterministic link to run in an convoy each of them a few centimeters distance to use the slipstream effect.

-        - Karl

Beckhoff Automation GmbH | Managing Director: Dipl. Phys. Hans Beckhoff, Arnold Beckhoff
Registered office: Verl, Germany | Register court: G?tersloh HRB 1803

From: detnet [mailto:[email-masked]] On Behalf Of Black, David
Sent: Montag, 22. September 2014 17:52
To: Pascal Thubert (pthubert); Anca Zamfir (ancaz); Norman Finn (nfinn); Erik Nordmark ([email-masked]); Alia Atlas ([email-masked])
Cc: [email-masked]
Subject: Re: [Detnet] draft charter skeleton - with some meat on it

Pascal,

(4) For deliverables:

Thanks,
--David

From: detnet [mailto:[email-masked]] On Behalf Of Pascal Thubert (pthubert)
Sent: Monday, September 22, 2014 9:48 AM
To: Anca Zamfir (ancaz); Norman Finn (nfinn); Erik Nordmark ([email-masked]<mailto:[email-masked]>); Alia Atlas ([email-masked]<mailto:[email-masked]>)
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [Detnet] draft charter skeleton - with some meat on it

Dear all:

WG description

Work Items

- Deliverables:

Milestones

Cheers,

Pascal

---

From: "Black, David" <[email-masked]>
Date: Mon, 22 Sep 2014 17:06:55 -0400

Karl,

Nice explanation - I think it'd be good for the charter to include that sort of hierarchy discussion.  The possibility of using the Internet to interconnect the local networks would definitely help to connect this proposed work to the IETF's mission.

Thanks,
--David

From: Karl Weber [mailto:[email-masked]]
Sent: Monday, September 22, 2014 12:38 PM
To: Black, David; Pascal Thubert (pthubert); Anca Zamfir (ancaz); Norman Finn (nfinn); Erik Nordmark ([email-masked]); Alia Atlas ([email-masked])
Cc: [email-masked]
Subject: RE: [Detnet] draft charter skeleton - with some meat on it

David,

-          - Karl

Beckhoff Automation GmbH | Managing Director: Dipl. Phys. Hans Beckhoff, Arnold Beckhoff
Registered office: Verl, Germany | Register court: Gütersloh HRB 1803
From: detnet [mailto:[email-masked]] On Behalf Of Black, David
Sent: Montag, 22. September 2014 17:52
To: Pascal Thubert (pthubert); Anca Zamfir (ancaz); Norman Finn (nfinn); Erik Nordmark ([email-masked]<mailto:[email-masked]>); Alia Atlas ([email-masked]<mailto:[email-masked]>)
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [Detnet] draft charter skeleton - with some meat on it

Pascal,

(4) For deliverables:

Thanks,
--David

Dear all:

WG description

Work Items

- Deliverables:

Milestones

Cheers,

Pascal

---

From: Erik Nordmark <[email-masked]>
Date: Mon, 22 Sep 2014 16:40:00 -0700

Pascal,

There is useful information in this charter. But when I look at the 
deliverables it reads as if the WG will work for a few years and produce 
various documents, but not much in terms of standards and associated 
creation of interoperable implementations.

A key question for me is how do we see the network operating differently 
as a result of DETNET; I assume some protocols need to be changed in 
some ways. Understanding how we see it working differently is key in 
understanding the architectural impact as well.
Thus I'd definitely would like some more concrete details and a clear 
path towards useful things being standardized and implemented.

Norm's slides had more specifics. For example the need to be able to say 
"no" i.e. some form of admission control. The proposed text talks about 
that in the form of a solutions taxonomy. But if we want to accomplish 
something more than documents, I think the path needs to include the WG 
choosing a protocol (or possibly choosing a separate protocol for a 
distributed vs. a centralized approach); keep in mind that we get 
interoperability by making decisions that lead to a small set of 
mandatory to implement protocols and options.

The ADs might want to manage the charter in a step-wise way with some 
initial set of documents before a WG can work on picking a solution. But 
I would strive to make that initial set of documents small with crisp 
content.

My 2 cents,
    Erik

On 9/22/14 6:48 AM, Pascal Thubert (pthubert) wrote:
>
> Dear all:
>
> Please find below my latest and the txt version attached. I included 
> (my understanding of) Anca’s point (Thanks Anca!) as well as a 
> multilayer/segment discussion as stirred by George. I stole and 
> adapted text from various places, the original authors will recognize 
> themselves : )
>
> parallel and in a manner that is radically different from IT/ICT, 
> focusing on highly secure, reliable and deterministic networks, with 
> limited scalability over a bounded area.
>
> Internet, will represent a major evolution for both sides. The work 
> has already started; in particular, the Industrial Automation space 
> has been developing a number of Ethernet-based “fieldbus” 
> replacements, meant to provide “determinism”, with the focus to 
> transport a fully characterized flow over a very controlled 
> environment (i.e., a “well regulated” factory floor), with a bounded 
> latency, a low frame loss, and a very narrow jitter.
>
> In parallel, a high demand for a standard format drove the formation 
> of the Audio/Video Bridging (AVB) standards effort of IEEE 802.1, 
> destined to the professional and home audio/video markets. While aimed 
> at less critical applications, AVB networks share very similar 
> characteristics. Other instances of deterministic networks have arisen 
> as well, for instance in the context of vehicles and avionics, with 
> the mission-critical “Avionics Full-Duplex Switched Ethernet” (AFDX) 
> that was designed as part of the ARIC 664 standards. The work started 
> at the IEEE802.1 to provide deterministic Ethernet A/V Bridging has 
> now generalized and was renamed "Time Sensitive Networking" (TSN).
>
> The IETF and the IEEE need now to collaborate and define an abstract 
> model that can be applicable at Layer-2 and Layer-3 along segments of 
> different technologies, for instance across a (limited) number of 
> 802.1 bridges and then a (limited) number of IP routers, such as 
> 6TiSCH nodes which, by the way, operate on a different MAC/PHY. The 
> model should enable fully scheduled operations by a central 
> controller, with capabilities such as zero congestion loss and 
> live-live parallel transmission for increased reliability, as well as 
> a more distributed model similar to Intserv, though bounded in reach 
> and possibilities.
>
> WG description
>
> The Working Group will focus on the signaling and forwarding models 
> that are required to enable an end-to-end path with the Deterministic 
> properties of controlled latency, low packet loss, ultra-low jitter, 
> and High Reliability, over a moderate-sized mixed Layer 2 / Layer 3 
> network composed of IEEE802.1 bridges, routers, and hosts, within a 
> single administrative domain such as a campus or a Small/Home office 
> Network.
>
> The extent of the problem space for the WG includes the establishment 
> and maintenance of multi-hop paths over Layer-2 bridged and Layer-3 
> routed segments, and though only Layer-3 operations will be specified 
> in Standard Track documents, the group will maintain consistency and 
> compatibility with the concurrent work that is happening at IEEE802.1 
> TSN for the Layer-2 operations.
>
> The work will include the characterization and the marking of flows. 
> It will apply to flows that can be well-characterized in a manner that 
> allows to tightly reserve the appropriate network resources for the 
> flows in advance, and release/reuse the resources when they are not 
> required.
>
> Internet (e.g. 6TiSCH), Transport (e.g. TSVWG), Operations and 
> Management, Routing and Security areas.
>
> Work Items
>
> - Deliverables:
>
> drafts which would include process control, factory automation, planes 
> and video studios)
>
> solutions of the related work at IEEE802.1TSN, with a status of the 
> work done and left to be achieved, and the directions that are being 
> taken.
>
> RSVP), Central controller (along the lines of SDN or PCE), Connection 
> to Operations (Application) Controllers, and Mixed scenarios.
>
>   * requirement drafts will be produced for other WGs as deemed 
> necessary, with for instance a requirement draft for the definition of 
> a PHsB at the transport area.
>
> technologies and layers over an Admin-Local scope. Similar scoping 
> will be studied for IPv4.
>

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 23 Sep 2014 12:55:49 +0000

So much content here!

Many thanks to both of you. Addressing this and Karl's point:

I'm a bit concerned about knee jerks on complexity in particular related to interdomain, IOW I'd rather stay closer to a diffserv scope than an intserv where the whole network needs to understand the tags in a consistent fashion. What about adding in the background something like:

"The integration of determinism in Internet Technology becomes a necessity as deterministic networks become structured, and require forwarding beyond LAN boundaries. For instance, Industrial Automation segregates the network along the broad lines of the Purdue Enterprise Reference Architecture (PERA), using different technologies at each level, and public infrastructures such as Electricity Automation require deterministic properties over the Wide Area. "

In the WG descrition, we could also modify the first sentence to:
"
The Working Group will initially focus on the signaling and packet tagging that are required to enable and forward along an end-to-end path with the deterministic properties of controlled latency, low packet loss, ultra-low jitter, and High Reliability. The network will initially be of moderate size, composed of mixed Layer 2 / Layer 3 sub-networks of IEEE802.1 bridges, routers, and hosts. A single administrative domain such as a campus, a Small/Home office Network, or a controlled Wide Area Network will be assumed to start with, and approaches that can be applied to the Internet at large will be favored.
"

Yes, I think I see what you're saying. My point is that the work on the data model for signaling elements and a study of state and tagging can start before the architectural model is fully understood. For one thing, the work on deterministic PHB has already started at TSVWG, and a study on generalizing MLPS labels can also start now. What about changing the last paragraph to:

"
In order to serve those needs, the IETF and the IEEE need to collaborate and define an abstract model that can be applicable at Layer-2 and Layer-3 along segments of different technologies. With this new work, a path may span for instance across a (limited) number of 802.1 bridges and then a (limited) number of IP routers. In that example, the IEEE802.1 bridges may be operating at Layer-2 over Ethernet whereas the IP routers may be 6TiSCH nodes operating at Layer-2 and/or Layer-3 over the IEEE802.15.4e MAC. The proposed model should enable fully scheduled operations by a central controller, with capabilities such as zero congestion loss and live-live parallel transmission for increased reliability, as well as a more distributed model similar to Intserv, though bounded in reach and possibilities.
In parallel to the definition of the abstract model, the IETF needs also to define tagging and signaling elements to be used to establish a path and identify the flows, and how they can be instantiated on relevant technologies such as PCE, MPLS and 6TiSCH.
"

In practice, we already have Pat Thaler participating, and a number of members who participate to both. So I'm not too anxious there.
Still, yes, this needs to be clarified. What about updating the second sentence to:
"
The extent of the problem space for the WG includes the establishment and maintenance of multi-hop paths over Layer-2 Bridged and Layer-3 routed segments. Though only Layer-3 operations will be specified in Standard Track documents, the group will maintain consistency and compatibility with the concurrent work that is happening at IEEE802.1 TSN for the Layer-2 operations, leveraging cross-participation and liaison work.
"

I'm still working on the last 3 items, but I wanted to share this already. Following up later in the day.

Cheers,

Pascal

From: Black, David [mailto:[email-masked]]
Sent: lundi 22 septembre 2014 23:07
To: Karl Weber; Pascal Thubert (pthubert); Anca Zamfir (ancaz); Norman Finn (nfinn); Erik Nordmark ([email-masked]); Alia Atlas ([email-masked])
Cc: [email-masked]
Subject: RE: [Detnet] draft charter skeleton - with some meat on it

Karl,

Thanks,
--David

To: Black, David; Pascal Thubert (pthubert); Anca Zamfir (ancaz); Norman Finn (nfinn); Erik Nordmark ([email-masked]<mailto:[email-masked]>); Alia Atlas ([email-masked]<mailto:[email-masked]>)

David,

-        - Karl

Pascal,

(4) For deliverables:

Thanks,
--David

Dear all:

WG description

Work Items

- Deliverables:

Milestones

Cheers,

Pascal

---

From: "Norman Finn (nfinn)" <[email-masked]>
Date: Tue, 23 Sep 2014 22:27:33 +0000

WOW!  Just what we needed.

Attached is a PDF of my suggestions for improvement.  I’m sending your the Word separately.

— Norm

From: Pascal Thubert <[email-masked]<mailto:[email-masked]>>
Date: Monday, September 22, 2014 at 03:48 AM
To: "Anca Zamfir (ancaz)" <[email-masked]<mailto:[email-masked]>>, Norman Finn <[email-masked]<mailto:[email-masked]>>, "Erik Nordmark ([email-masked]<mailto:[email-masked]>)" <[email-masked]<mailto:[email-masked]>>, "Alia Atlas ([email-masked]<mailto:[email-masked]>)" <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: RE: [Detnet] draft charter skeleton - with some meat on it

Dear all:

In parallel, a high demand for a standard format drove the formation of the Audio/Video Bridging (AVB) standards effort of IEEE 802.1, destined to the professional and home audio/video markets. While aimed at less critical applications, AVB networks share very similar characteristics. Other instances of deterministic networks have arisen as well, for instance in the context of vehicles and avionics, with the mission-critical “Avionics Full-Duplex Switched Ethernet” (AFDX) that was designed as part of the ARIC 664 standards. The work started at the IEEE802.1 to provide deterministic Ethernet A/V Bridging has now generalized and was renamed "Time Sensitive Networking" (TSN).

WG description

- Deliverables:

Cheers,

Pascal

---

From: "Norman Finn (nfinn)" <[email-masked]>
Date: Tue, 23 Sep 2014 22:40:41 +0000

David,

I’m on vacation this week; but this is important, so let me take a swing at your questions.  I find them very useful — thank you!  See in-line.  (My answers may differ from Pascal’s, but hopefully not in a big way.)

— Norm

From: <Black>, David <[email-masked]<mailto:[email-masked]>>
Date: Monday, September 22, 2014 at 05:51 AM
To: Pascal Thubert <[email-masked]<mailto:[email-masked]>>, "Anca Zamfir (ancaz)" <[email-masked]<mailto:[email-masked]>>, Norman Finn <[email-masked]<mailto:[email-masked]>>, "Erik Nordmark ([email-masked]<mailto:[email-masked]>)" <[email-masked]<mailto:[email-masked]>>, "Alia Atlas ([email-masked]<mailto:[email-masked]>)" <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: RE: [Detnet] draft charter skeleton - with some meat on it

Pascal,

(1) How does this relate to IETF’s focus on the public (capital-I) Internet?

IMO, the core of deterministic networking is absolute zero congestion loss.  In the absence of gross overprovisioning, that requires per-hop reservation and dedicated resources.  The “0” in zero congestion loss is what justifies this expense, certainly up to the size of an enterprise network.  I know of no way to scale these reservations up except by bundling.  I would think that the easy way to interconnect industrial sites would be to use a technology that can dedicate some bandwidth, e.g. DWM.  I have doubts about using the known low-level techniques to provision bundles over the Big-I best-effort infrastructure.

- I’m reacting to “very controlled environment” at the end of the
      second paragraph in Background and suggesting some text to
      address the broader possibilities.

(2) I see a disconnect between the charter text’s focus on “models”
and the two specific standards track protocol deliverables.

Point taken.  Models and protocols both needed.

The short answer is common membership with liaison backup and broad supervision by the IETF/IEEE coordination committee to head off divergence.

(4) For deliverables:

- I would combine the first two, so that the use cases support both
      the problem statement and high-level requirements.
- The IP scoping work feels like it’s related to the solution taxonomy,
      but I’m not sure whether those should be combined.  At a minimum,
      the solution taxonomy should discuss the role of IP scope.
- There’s probably some sequencing in the dates with the requirements
      and problem statement coming before the two standards-track
      documents.

(5) Flow characterization - between the third paragraph in the WG
description and the deliverable, I’m missing something about how the
“data model for flow characterization” is intended to be used.

An answer (that should be somehow captured in the charter):  Having reserved resources for a flow, we need to recognize which packets get to use a given resource.  Also, we may be “nailing up” (or “pinning down”, if you prefer) paths for specific flows.  For bridges, the distinguishing feature psretty much have to be the destination MAC address, the VLAN, and the L2 priority.  I have not heard an obvious solution to the problem for L3 flows.  The 5-tuple and DSCP have issues in this regard.  There are questions about whether bridges should look at the IP 5-tuple/DSCP for flow recognitions (as opposed to forwarding decisions).  That’s the subject for these drafts.

The name of the 802.1 reservation protocol — MSRP — is mentioned along with RSVP, but this should be expanded.

I’ll leave this to the IETFers.

Thanks,
--David

Dear all:

WG description

Work Items

- Deliverables:

Milestones

Cheers,

Pascal

---

From: "Black, David" <[email-masked]>
Date: Tue, 23 Sep 2014 20:26:57 -0400

Pascal,

-- (1) --
I agree with your concerns about interdomain and favoring Diffserv over Intserv.

I like the proposed addition to background text.  In the WG description edits:

A single administrative domain such as a campus, a Small/Home office Network, or a controlled Wide Area Network will be assumed to start with, and approaches that can be applied to the Internet at large will be favored.

I think ending the sentence at "a controlled Wide Area Network will be assumed to start with" suffices - I would admit "and approaches that can be applied to the Internet at large will be favored."

-- (2) --
The new sentence is a significant improvement.

-- (3) --
The additional words look fine.

Thanks,
--David

From: Pascal Thubert (pthubert) [mailto:[email-masked]]
Sent: Tuesday, September 23, 2014 8:56 AM
To: Black, David; Karl Weber; Anca Zamfir (ancaz); Norman Finn (nfinn); Erik Nordmark ([email-masked]); Alia Atlas ([email-masked])
Cc: [email-masked]
Subject: RE: [Detnet] draft charter skeleton - with some meat on it

So much content here!

"

Cheers,

Pascal

To: Karl Weber; Pascal Thubert (pthubert); Anca Zamfir (ancaz); Norman Finn (nfinn); Erik Nordmark ([email-masked]<mailto:[email-masked]>); Alia Atlas ([email-masked]<mailto:[email-masked]>)

Karl,

Thanks,
--David

David,

-          - Karl

Pascal,

(4) For deliverables:

Thanks,
--David

Dear all:

WG description

Work Items

- Deliverables:

Milestones

Cheers,

Pascal

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 24 Sep 2014 15:10:06 +0000

Thanks a bunch David!

Continuing...

(4) For deliverables:

I expected multiple req drafts, like avionics, A/V, factory automation and/or process control, grid automation. This is for instance what we did at ROLL, with draft-ietf-roll-applicability-home-building draft-ietf-roll-applicability-ami and draft-ietf-roll-rpl-industrial-applicability. From there we'd derive requirements. Is that OK?

I changed the order to place the scoping higher on the list, and added ", in relation to the IP generic scoping." in the end of the taxonomy draft description.

Added "those would be standard track, and the work would progress once dependencies are resolved."

"a data model for flow characterization for use in flow reservation by the protocol(s) selected by the WG from the solution taxonomy (e.g. an evolution of PCEP or RSVP). "

- What is IEEE doing for flow reservation?  That should be mentioned.
"
  -> those would be standard track, and the work would progress once dependencies are resolved. The data models and flow tagging should be compatible with the similar work done at IEEE801.1TSN so they could be either directly usable at both layers, or mappable in an unambiguous fashion."

We can change "requirements" into "needs"?

"The WG will interface with other appropriate groups in the IETF in the Internet (e.g. 6TiSCH), Transport (e.g. TSVWG), Operations and Management, Routing and Security areas. As the work progresses, some of the items initially considered at detnet may be transferred to those working groups as deemed appropriate by all parties."

Cheers,

Pascal

From: Black, David [mailto:[email-masked]]
Sent: mercredi 24 septembre 2014 02:27
To: Pascal Thubert (pthubert); Karl Weber; Anca Zamfir (ancaz); Norman Finn (nfinn); Erik Nordmark ([email-masked]); Alia Atlas ([email-masked])
Cc: [email-masked]; Black, David
Subject: RE: [Detnet] draft charter skeleton - with some meat on it

Pascal,

-- (1) --

-- (2) --

-- (3) --

Thanks,
--David

To: Black, David; Karl Weber; Anca Zamfir (ancaz); Norman Finn (nfinn); Erik Nordmark ([email-masked]<mailto:[email-masked]>); Alia Atlas ([email-masked]<mailto:[email-masked]>)

So much content here!

"

Cheers,

Pascal

Karl,

Thanks,
--David

David,

-        - Karl

Pascal,

(4) For deliverables:

Thanks,
--David

Dear all:

WG description

Work Items

- Deliverables:

Milestones

Cheers,

Pascal

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 24 Sep 2014 16:36:18 +0000

Hello Erik:

Thanks for all this.

In the last sentence of the background, we could show more clearly where we're going:

"
Once the abstract model is agreed upon, the IETF needs also to define which protocol(s) will be applied or extended, and to produce tagging and signaling elements to be used to establish a path and identify the flows, and how they can be instantiated on relevant technologies such as PCE, MPLS and 6TiSCH. As a result of this work, it will be possible to establish an end-to-end path for a particular flow with precise timing and throughput requirements, and transport this flow over the IP network with such characteristics as precise timing, duplication and elimination over non-congruent paths, and/or zero congestion loss. Depending on the network capabilities and on the current state, requests may be granted or rejected, and the associated reservation may be moved or cancelled.  
"

I would rather commit for a limited standard deliverable in this round and then recharter for the full blown commitment when we know better what we are after. But then, if you can propose alternate text/updates to the attached v3 draft, you are more than welcome!

Cheers,

Pascal

> -----Original Message-----
> From: Erik Nordmark [mailto:[email-masked]]
> Sent: mardi 23 septembre 2014 01:40
> To: Pascal Thubert (pthubert); Anca Zamfir (ancaz); Norman Finn (nfinn); Alia
> Atlas ([email-masked])
> Cc: [email-masked]
> A key question for me is how do we see the network operating differently as
> a result of DETNET; I assume some protocols need to be changed in some
> ways. Understanding how we see it working differently is key in
> Thus I'd definitely would like some more concrete details and a clear path
> towards useful things being standardized and implemented.
> 
> "no" i.e. some form of admission control. The proposed text talks about that
> in the form of a solutions taxonomy. But if we want to accomplish
> interoperability by making decisions that lead to a small set of mandatory to
> implement protocols and options.
> 
> initial set of documents before a WG can work on picking a solution. But I
> would strive to make that initial set of documents small with crisp content.
> 
> My 2 cents,
>     Erik
> 
> > (my understanding of) Anca's point (Thanks Anca!) as well as a
> > has been developing a number of Ethernet-based "fieldbus"
> > replacements, meant to provide "determinism", with the focus to
> > environment (i.e., a "well regulated" factory floor), with a bounded
> > the mission-critical "Avionics Full-Duplex Switched Ethernet" (AFDX)

---

From: "Shitanshu Shah (svshah)" <[email-masked]>
Date: Thu, 25 Sep 2014 05:28:19 +0000

Hi Pascal,

Just got into this mailing list. Since don¹t have original e-mail with
charter skeleton, picking this e-mail to respond to your original proposed
text..

Few comments/questions

(1) last sentence of last paragraph in the Background section,
  "as well as a more distributed model similar to Intserv²

  Is there any reason/need to highlight ³Intserv²? You have background
covered well that highlights requirement of determinism. I am not clear
what Intserv signifies here.

(2) In the WG description

  Use of term ³consistency² between L2 and L3 is too loose and practically
difficult to decide where to draw a line. Like IP can support 64
code-points, L2 supports only 8. Like flow specification may differ L3 vs
L2. Trying to achieve consistency in some of such places may mean limiting
proposed solution for IP or even vice-versa.

 I think compatibility and Inter-operability makes sense. IMO
³consistency² should not be mentioned here for those reasons.

(3) In the WG description

  "The work will include the characterization and the marking of flows.²

  Suggest modification of this statement to,

  ³The work will include the characterization and marking of flows, Per
hop behavior². If ³Per hop behavior² seems to be more inclined to
specifics, may be we state ³packet forwarding behavior² or something
similar. Is it not important to have WG define such behavior in its
charter?

(4) I understand that WG to work on proposing signaling mechanism and use
of it to establish a path. That seems perfectly fine for WG to produce.
  However, in overall solution, there still should be an option to enable
determinism through traditional style command line interface. Thus
hopefully WG charter does not focus on a solution that can not accommodate
such. I am thinking about smaller scale networks with few L3 hops
requiring determinism, where command line interface to provision flow
definition and deterministic parameters may be much more simpler and
convenient than heavy weight signaling (central or distributed) mechanism.

  This comment relates to one of the paragraphs from the WG description,

"A solution taxonomy, where potential solution paradigms will be explored,
such as Peer-to-peer protocols (along the lines of MSRP or RSVP), Central
controller (along the lines of SDN or PCE), Connection to Operations
(Application) Controllers, and Mixed scenarios"

Regards,
Shitanshu

On 9/24/14, 9:36 AM, "Pascal Thubert (pthubert)" <[email-masked]>
wrote:

>Once the abstract model is agreed upon, the IETF needs also to define
>which protocol(s) will be applied or extended, and to produce tagging and
>signaling elements to be used to establish a path and identify the flows,
>and how they can be instantiated on relevant technologies such as PCE,
>MPLS and 6TiSCH. As a result of this work, it will be possible to
>establish an end-to-end path for a particular flow with precise timing
>and throughput requirements, and transport this flow over the IP network
>with such characteristics as precise timing, duplication and elimination
>over non-congruent paths, and/or zero congestion loss. Depending on the
>network capabilities and on the current state, requests may be granted or
>rejected, and the associated reservation may be moved or cancelled.
>"
>
>I would rather commit for a limited standard deliverable in this round
>and then recharter for the full blown commitment when we know better what
>we are after. But then, if you can propose alternate text/updates to the
>attached v3 draft, you are more than welcome!
>
>Cheers,
>
>Pascal
>
>
>>path
>>that

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 25 Sep 2014 13:32:22 +0000

[PT] Thanks for them!!! Please find below my proposed resolution:

> covered well that highlights requirement of determinism. I am not clear what
> Intserv signifies here.
> 

[PT] I got rid of that text

> difficult to decide where to draw a line. Like IP can support 64 code-points,
> L2 supports only 8. Like flow specification may differ L3 vs L2. Trying to
> achieve consistency in some of such places may mean limiting proposed
> solution for IP or even vice-versa.
> 
>  I think compatibility and Inter-operability makes sense. IMO ³consistency²
> should not be mentioned here for those reasons.

[PT]  Here we want more consistency than what we could do with QoS. The data model, the signaling flows, and the packet tagging should be the same or unambiguously mappable. Do you still think the text is too strong?

>   ³The work will include the characterization and marking of flows, Per hop
> behavior². If ³Per hop behavior² seems to be more inclined to specifics, may
> be we state ³packet forwarding behavior² or something similar. Is it not
> important to have WG define such behavior in its charter?
> 
> 

[PT] It is. I had trouble parsing the above but changed the text to accommodate this and added a deliverable.

" 
  * A data model for the state to be installed in the forwarding device and the associated packet forwarding behavior. 
 "

> hopefully WG charter does not focus on a solution that can not
> accommodate such. I am thinking about smaller scale networks with few L3
> hops requiring determinism, where command line interface to provision flow

[PT] added Manual Configuration

> >which protocol(s) will be applied or extended, and to produce tagging
> >and signaling elements to be used to establish a path and identify the
> >flows, and how they can be instantiated on relevant technologies such
> >as PCE, MPLS and 6TiSCH. As a result of this work, it will be possible
> >to establish an end-to-end path for a particular flow with precise
> >timing and throughput requirements, and transport this flow over the IP
> >network with such characteristics as precise timing, duplication and
> >elimination over non-congruent paths, and/or zero congestion loss.
> >Depending on the network capabilities and on the current state,
> >requests may be granted or rejected, and the associated reservation may
> be moved or cancelled.
> >"
> >
> >and then recharter for the full blown commitment when we know better
> >what we are after. But then, if you can propose alternate text/updates
> >to the attached v3 draft, you are more than welcome!
> >
> >Cheers,
> >
> >Pascal
> >
> >
> >> To: Pascal Thubert (pthubert); Anca Zamfir (ancaz); Norman Finn
> >>(nfinn); Alia  Atlas ([email-masked])
> >> Cc: [email-masked]
> >> deliverables it reads as if the WG will work for a few years and
> >> produce various documents, but not much in terms of standards and
> >> associated creation of interoperable implementations.
> >>
> >> A key question for me is how do we see the network operating
> >>differently as  a result of DETNET; I assume some protocols need to be
> >>changed in some  ways. Understanding how we see it working differently
> >>is key in  understanding the architectural impact as well.
> >> Norm's slides had more specifics. For example the need to be able to
> >>say  "no" i.e. some form of admission control. The proposed text talks
> >>about that  in the form of a solutions taxonomy. But if we want to
> >>accomplish  something more than documents, I think the path needs to
> >>include the WG  choosing a protocol (or possibly choosing a separate
> >>protocol for a  distributed vs. a centralized approach); keep in mind
> >>that we get  interoperability by making decisions that lead to a small
> >>set of mandatory to  implement protocols and options.
> >>
> >> > Please find below my latest and the txt version attached. I
> >> > included (my understanding of) Anca's point (Thanks Anca!) as well
> >> > as a multilayer/segment discussion as stirred by George. I stole
> >> > and adapted text from various places, the original authors will
> >> > recognize themselves : )
> >> >
> >> > typically used for monitoring systems and supporting control loops,
> >> > as well as movement detection systems for use in Process Control
> >> > (i.e., process manufacturing) and Factory Automation (i.e.,
> >> > discrete manufacturing). Due to its different goals, OT has evolved
> >> > totally in parallel and in a manner that is radically different
> >> > from IT/ICT, focusing on highly secure, reliable and deterministic
> >> > networks, with limited scalability over a bounded area.
> >> >
> >> > The convergence of IT and OT technologies, also called the
> >> > Industrial Internet, will represent a major evolution for both
> >> > sides. The work has already started; in particular, the Industrial
> >> > Automation space has been developing a number of Ethernet-based
> "fieldbus"
> >> > environment (i.e., a "well regulated" factory floor), with a
> >> > bounded latency, a low frame loss, and a very narrow jitter.
> >> >
> >> > In parallel, a high demand for a standard format drove the
> >> > formation of the Audio/Video Bridging (AVB) standards effort of
> >> > IEEE 802.1, destined to the professional and home audio/video
> >> > markets. While aimed at less critical applications, AVB networks
> >> > share very similar characteristics. Other instances of
> >> > deterministic networks have arisen as well, for instance in the
> >> > context of vehicles and avionics, with the mission-critical
> >> > "Avionics Full-Duplex Switched Ethernet" (AFDX) that was designed
> >> > as part of the ARIC 664 standards. The work started at the
> generalized and was renamed "Time Sensitive Networking" (TSN).
> >> >
> >> > The IETF and the IEEE need now to collaborate and define an
> >> > abstract model that can be applicable at Layer-2 and Layer-3 along
> >> > segments of different technologies, for instance across a (limited)
> >> > number of
> >> > live-live parallel transmission for increased reliability, as well
> >> > as a more distributed model similar to Intserv, though bounded in
> >> > reach and possibilities.
> >> >
> >> > WG description
> >> >
> >> > that are required to enable an end-to-end path with the
> >> > Deterministic properties of controlled latency, low packet loss,
> >> > ultra-low jitter, and High Reliability, over a moderate-sized mixed
> >> > Layer 2 / Layer 3 network composed of IEEE802.1 bridges, routers,
> >> > and hosts, within a single administrative domain such as a campus
> >> > or a Small/Home office Network.
> >> >
> >> > The extent of the problem space for the WG includes the
> >> > establishment and maintenance of multi-hop paths over Layer-2
> >> > bridged and Layer-3 routed segments, and though only Layer-3
> >> > operations will be specified in Standard Track documents, the group
> >> > will maintain consistency and compatibility with the concurrent
> >> > work that is happening at IEEE802.1 TSN for the Layer-2 operations.
> >> >
> >> > It will apply to flows that can be well-characterized in a manner
> >> > that allows to tightly reserve the appropriate network resources
> >> > for the flows in advance, and release/reuse the resources when they
> >> > are not required.
> >> >
> >> > The WG will interface with other appropriate groups in the IETF in
> >> > the Internet (e.g. 6TiSCH), Transport (e.g. TSVWG), Operations and
> >> >   * an analysis of the requirements in a number of environments
> >> > (3-4 drafts which would include process control, factory
> >> > automation, planes and video studios)
> >> >
> >> >   * A general problem statement including an analysis of the
> >> > proposed solutions of the related work at IEEE802.1TSN, with a
> >> > status of the work done and left to be achieved, and the directions
> >> > that are being taken.
> >> >
> >> > explored, such as Peer-to-peer protocols (along the lines of MSRP
> >> > or RSVP), Central controller (along the lines of SDN or PCE),
> >> > Connection to Operations (Application) Controllers, and Mixed
> scenarios.
> >> >
> >> > necessary, with for instance a requirement draft for the definition
> >> > of a PHsB at the transport area.
> >> >
> >> >   * a study of generic scoping. For IPv6, the study will include
> >> > the definition of Link-Local, Realm-Local and Admin-Local scoped
> >> > operation (per RFC 7346) where for instance the deterministic
> >> > technology is consistent over a Link or a Realm Local Scope and
> >> > achievable across technologies and layers over an Admin-Local
> >> > scope. Similar scoping will be studied for IPv4.
> >> >

---

From: "Shitanshu Shah (svshah)" <[email-masked]>
Date: Thu, 25 Sep 2014 18:01:13 +0000

Hi Pascal,

On 9/25/14, 6:32 AM, "Pascal Thubert (pthubert)" <[email-masked]>
wrote:

>>code-points,
>>³consistency²
>[PT]  Here we want more consistency than what we could do with QoS. The
>data model, the signaling flows, and the packet tagging should be the
>same or unambiguously mappable. Do you still think the text is too strong?

##svshah, I understand the intention and they are valid intention to make
sure IEEE/IETF works are in harmony. I just think that granularity of
“consistency” can be interpreted differently and when so may  limit the
outcome from the wg. Anyway, I wouldn’t make myself overly concerned with
it.

Thanks
Shitanshu

>>hop
>[PT] It is. I had trouble parsing the above but changed the text to
>accommodate this and added a deliverable.
>
>" 
>  * A data model for the state to be installed in the forwarding device
>and the associated packet forwarding behavior.
> "
>