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

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

Hello Benoit and Lou:

I agree with Benoit's point that we need more background. I condensed the original text into the below. What do you think?


Operational Technology (OT) refers to industrial-grade networks that are typically deployed to monitor and control critical installations and automated systems for such applications as industrial automation, professional and home audio/video, and control networks in vehicles. 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, and requires the internet technology to achieve similar deterministic behaviors as the incumbent OT serial (TDM) links and field buses which guarantee a bounded latency, an extraordinarily low frame loss, and a very narrow jitter. 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. At the same time, the model should not compromise the ability of a network to keep carrying best effort and traditional QoS-based traffic that is already carried today. 
 
All the best,

Pascal

> -----Original Message-----
> From: Lou Berger [mailto:[e-mail]]
> Sent: vendredi 4 septembre 2015 15:13
> To: Pascal Thubert (pthubert) <[e-mail]>; Benoit Claise
> (bclaise) <[e-mail]>
> Cc: Pat (Patricia) Thaler <[e-mail]>; [e-mail]; The
> IESG <[e-mail]>
> Subject: Re: [Detnet] Benoit Claise's Block on charter-ietf-detnet-00-00:
> (with BLOCK)
> 
> Pascal,
>     How about proposing a 1-3 sentence version?
> 
> Thanks,
> Lou
> 
> On 9/4/2015 8:54 AM, Pascal Thubert (pthubert) wrote:
> > 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/af7ef7b9f5802aca0816fd1e18
> 4e
> > 57bff74045dd/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 pat  h 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
> > _______________________________________________
> > detnet mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/detnet
> >
> 
>