Re: [Detnet] Benoit Claise's Block on charter-ietf-detnet-00-00: (with BLOCK)

["Pascal Thubert (pthubert)" <[e-mail]>]

Hi Benoit:

We used to have a part 1 called "Background on deterministic networking" in earlier versions of the charter:
https://bitbucket.org/pthubert/detnet/raw/af7ef7b9f5802aca0816fd1e184e57bff74045dd/detnet%20charter.txt

The section has been elided to focus on the WG itself as opposed to the context. Would you suggest we restore (some of) it?

For reference the text would say:

"
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 in parallel but 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, represents 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 replacements for existing digital control systems, often not packet-based (fieldbus technologies). These replacements are meant to provide similar behavior as the incumbent protocols, and their common focus is to transport a fully characterized flow over a well-controlled environment (i.e., a factory floor), with a bounded latency, extraordinarily low frame loss, and a very narrow jitter. Examples of such protocols include PROFINET, ODVA Ethernet/IP, and EtherCAT.
 
In parallel, the need for determinism in professional and home audio/video markets drove the formation of the Audio/Video Bridging (AVB) standards efforts of IEEE 802.1. With the explosion of demand for connectivity and multimedia in transportation in general, AVB has also become one of the hottest topics in the automotive industry, finding current application in vehicle head units, rear seat entertainment modules, amplifiers, and camera modules, with engine control systems to follow soon. Thus automotive AVB networks share the requirement for extremely low packet loss rates, guaranteed finite latency, and low jitter.

Other instances of in-vehicle deterministic networks have arisen as well for control networks in cars, trains and buses, as well as avionics, with, for instance, the mission-critical Avionics Full-Duplex Switched Ethernet (AFDX) that was designed as part of the ARINC 664 standards. Existing automotive control networks such as the LIN, CAN and FlexRay standards were not designed to cover these increasing demands in terms of bandwidth and scalability that we see with various kinds of Driver Assistance Systems (DAS) and new multiplexing technologies based on Ethernet are now getting traction. 

The generalization of the needs for more deterministic networks have led to the IEEE 802.1 AVB Task Group becoming the Time-Sensitive Networking (TSN) Task Group (TG), with a much-expanded constituency from the industrial and vehicular markets. Along with this expansion, the networks in consideration are becoming larger and structured, requiring deterministic forwarding beyond the 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. The realization is now coming that the convergence of IT and OT networks requires Layer-3, as well as Layer-2, capabilities. 

In order to serve this extended requirement, the IETF and the IEEE must collaborate and define an abstract model that can be applicable both at Layer-2 and Layer-3, and 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 a fully scheduled operation orchestrated by a central controller, as well as a more distributed operation with probably lesser capabilities. In any fashion, the model should not compromise the ability of a network to keep carrying the sorts of traffic that is already carried today. 
 
Once the abstract model is agreed upon, the IETF will need to specify the signaling elements to be used to establish a path and the tagging elements to be used identify the flows that are to be forwarded along that path. The IETF will also need to specify the necessary protocols, or protocol additions, based on relevant IETF technologies such as PCE, MPLS and 6TiSCH, to implement the selected model. As a result of this work, it will be possible to establish a multi-hop path over the IP network, for a particular flow with precise timing and throughput requirements, and carry this particular flow along the multi-hop path with such characteristics as low latency and ultra-low jitter, duplication and elimination of packets over non-congruent paths for a higher delivery ratio, and/or zero congestion loss. Depending on the network capabilities and on the current state, requests to establish a path by an end-node or a network management entity may be granted or rejected, and an existing path may be moved or removed.

"

Cheers,

Pascal

> -----Original Message-----
> From: detnet [mailto:[e-mail]] On Behalf Of Pat (Patricia)
> Thaler
> Sent: jeudi 3 septembre 2015 21:03
> To: Benoit Claise (bclaise) <[e-mail]>; The IESG <[e-mail]>
> Cc: [e-mail]
> Subject: Re: [Detnet] Benoit Claise's Block on charter-ietf-detnet-00-00:
> (with BLOCK)
> 
> Regarding capitalization and acronyms, while I sympathize on capitalization
> in principle and prefer lower case, it is reasonable to use capitalization to
> indicate that a term has a special meaning beyond the dictionary definition
> of the word and to be consistent with common usage.
> 
> Spot checking some other usage in IETF (e.g. some IS-IS and VPN RFCs), I
> find that Layer 2 and Layer 3 were uniformly capitalized. Are there counter
> examples? Lacking those, we should keep the capitalization to be
> consistent.
> 
> IEEE 802.1 defines Bridges and they examined the use of capitalization while
> doing the latest IEEE 802.1Q revision. They decided to capitalize Bridge to
> indicate that it is used with a special meaning, not the dictionary definition
> so we should keep it capitalized to match.
> 
> Regarding acronyms, we should at least spell out acronyms at the first
> occurrence. Replace the first occurrences of the acronyms with Time
> Sensitive Networking (TSN) and Operations, Administration, and
> Maintenance (OAM).
> 
> -----Original Message-----
> From: detnet [mailto:[e-mail]] On Behalf Of Benoit Claise
> Sent: Thursday, September 03, 2015 8:01 AM
> To: The IESG
> Cc: [e-mail]
> Subject: [Detnet] Benoit Claise's Block on charter-ietf-detnet-00-00: (with
> BLOCK)
> 
> Benoit Claise has entered the following ballot position for
> charter-ietf-detnet-00-00: Block
> 
> When responding, please keep the subject line intact and reply to all email
> addresses included in the To and CC lines. (Feel free to cut this introductory
> paragraph, however.)
> 
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/charter-ietf-detnet/
> 
> 
> 
> ----------------------------------------------------------------------
> BLOCK:
> ----------------------------------------------------------------------
> 
> - There is a tendency in our industry to capitalize word, and to overuse
> acronyms:
>     - Layer 2 Bridged and Layer 3
>     - TSN
>     - OAM
> - I find the structure not ideal.
>     Part 1 should express the motivation and high level intend
>     Part 2, more details
>     Part 3, out of scope, if any
>     Part 4, deliverables
>     Part 5, coordination
> 
> For example, the architecture is mentioned in multiple place
> 
> - "Identification of additional YANG augmentations:"
> What does it mean? new YANG models, fine? This could be understood as
> YANG language augmentations, which is a different story.
> 
> - "Any YANG work will be   coordinated with the working groups that
> define the base models."
> What are those base models?
> 
> 
> - "The work will be   independent from the protocol(s) that may be used
> to advertise this   information (e.g. IS-IS or GMPLS extensions)." Well,
> you are in the YANG section, and YANG is bound to NETCONF/RESCONF.
> "independent from the protocol(s) is for the information model
> 
> I have no objection to the work itself, but I believe that the charter text
> should be improved. I started with a list of improvements, and in the end, I
> started editing. There are still improvements to be made. I guess that
> makes it a BLOCK. An 1:1 with Deborah should be the next step.
> 
> ===========================
> 
> The Deterministic Networking (DetNet) Working Group focuses on
> deterministic data paths that operate over layer 2 bridged and layer 3
> routed segments, where such paths can provide bounded latency, loss, and
> packet delay variation (jitter).
> 
> EXPLAIN IN ONE SENTENCE OR TWO THE MOTIVATION Various industries,
> for example, professional audio, electrical utilities, building automation
> systems, wireless for industrial applications require this capability
> because...
> 
> The Working Group will collaborate with IEEE802.1 Time-Sensitive
> Networking (TSN), which is responsible for layer 2 operations, to define a
> common architecture for both layer 2 and layer 3. For this common
> architecture, a number of elements such as the IEEE802.1 TSN host
> operation should be agnostic to the choice of network used for the
> connectivity.
> 
> The work applies to flows that can be characterized in a manner that allows
> the network to 1) reserve the appropriate resources for the flows in
> advance, and
> 2) release/reuse the resources when they are no longer required.
> The work covers the characterization of flows, the encapsulation of frames,
> the required forwarding behaviors, as well as the state that may need to be
> established in intermediate nodes.
> 
> Out of scope is the end-to-end considerations such the transport protocols,
> modification of Operations, Administration, and Maintenance (OAM), L3
> forwarding and encapsulations, or control plane protocols.
> 
> DetNet is chartered to work in the following areas:
> 
>  * Problem statement and requirements: These documents will not
> necessarily
>    be published, but may be maintained in a draft form or on a collaborative
>    Working Group wiki to support the efforts of the Working Group and help
> new comers.
> 
>  * An architecture that encompasses the data plane, OAM, management,
> control,
>    and security aspects required to enable a multi-hop path, and forwarding
>    along that path, with the deterministic properties of controlled latency,
>    low packet loss, low packet delay variation, and high reliability.
>    As part of the overall architecture work, the working group will document
>    which deployment environments and types of topologies that are within
> 
>    (or outside) the scope of the DetNet architecture.
> 
>  * Data plane: This work will document a data plane method of flow
>    identification and packet forwarding over Layer 3. Candidate Layer 3 data
>    plane technologies that may be used, without modification, include:
> IPv4,
>    IPv6, MPLS. The data plane, which must be compatible with the work in
> 
>    IEEE802.1 TSN, is independent from any path setup protocol or
>    mechanism.
> 
>  * Data flow information model: This work will identify the information
>    needed for flow establishment and control and be used by a
>    reservation protocol or by YANG data models. The work will be
>    independent from the protocol(s) used to control the flows
>    (e.g. YANG+NETCONF/RESTCONF, PCEP or GMPLS).
> 
>  * Identification of additional YANG augmentations: This work will
>    document device and link capabilities (feature support) and resources
>    (e.g. buffers, bandwidth) for use in device configuration and status
>    reporting. Such information may also be used when advertising the
>    deterministic network elements to a control plane. The work will be
>    independent from the protocol(s) that may be used to advertise this
>    information (e.g. IS-IS or GMPLS extensions). Any YANG work will be
>    coordinated with the working groups that define the base models.
>    THIS SECTION NEEDS CLARFIFICATION, BUT I NEED TO SPEAK TO DEBORAH
> FIRST
> 
> The WG will coordinate with other relevant IETF Working Groups, including
> CCAMP, PCE, PALS, TEAS, OSPF, IS-IS, TSVWG, LIME, and 6TisSCH.
> As
> the work progresses, requirements may be provided to the responsible
> Working Group, e.g. PCE, TEAS, and CCAMP, with DetNet acting as a focal
> point to maintain the consistency of the overall architecture. The WG will
> liaise with appropriate groups in IEEE and other Standards Development
> Organizations (SDOs), specifically IEEE802.1 TSN.
> 
> 
> 
> 
> _______________________________________________
> detnet mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/detnet
> 
> _______________________________________________
> detnet mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/detnet