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

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

Hello Deborah:

Maybe I misread the last mail from Benoit but it included this:

" 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...
"
That I did not feel was covered so I interpreted as a request to add a bit more intro than Lou's suggestion. I'm fine either way.

All the best,

Pascal

> -----Original Message-----
> From: BRUNGARD, DEBORAH A [mailto:[e-mail]]
> Sent: vendredi 11 septembre 2015 18:09
> To: Pascal Thubert (pthubert) <[e-mail]>; Lou Berger
> <[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)
> 
> 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
> > >
> >
> >