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

["BRUNGARD, DEBORAH A" <[e-mail]>]

Hi Pascal,

As Lou noted, we discussed with Benoit and added this sentence:
"Example applications for deterministic networks include professional and home audio/video, multimedia in transportation, engine control systems, and other general industrial and vehicular applications being consider by the IEEE 802.1 TSN Task Group."

Benoit has removed his objection (what you are seeing below (===) is his original objection). So all ok. We now only have Alia's block to address.

Thanks,
Deborah

-----Original Message-----
From: iesg [mailto:[e-mail]] On Behalf Of Pascal Thubert (pthubert)
Sent: Friday, September 11, 2015 11:54 AM
To: Lou Berger; Benoit Claise (bclaise)
Cc: Pat (Patricia) Thaler; [e-mail]; The IESG
Subject: RE: [Detnet] Benoit Claise's Block on charter-ietf-detnet-00-00: (with BLOCK)

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