Ballot for charter-ietf-detnet
Yes
No Objection
Note: This ballot was opened for revision 00-00 and is now closed.
Ballot question: "Is this charter ready for external review?"
Thanks for taking my concerns into account and clarifying.
Either there is a word missing here or there is an extraneous "that": 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.
The list of chartered work includes "As needed, problem statement…[and]…vertical requirements.” I thought those items/documents were discussed at the BoF and were really the basis for knowing what the WG would work on. IOW, I don’t think the WG should be chartered to produce problem statement and requirements documents. I liked a lot more the text from the BoF [1] that called them WG sustaining documents and said: "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”. [1] http://trac.tools.ietf.org/bof/trac/wiki/DetNet
A fine charter. I have only one editorial comment. I find the end of the first sentence hard to read, which gets things off to a confusing start: The Deterministic Networking (DetNet) Working Group will focus 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). It's not immediately clear whether "bounded" applies only to latency or to the whole list, and the missing serial comma muddies things more. One can certainly figure it out well enough, but we shouldn't make readers work that hard. I suggest this: NEW The Deterministic Networking (DetNet) Working Group will focus on deterministic data paths that operate over Layer 2 bridged and Layer 3 routed segments, where such paths can provide bounds on latency, loss, and packet delay variation (jitter). END
Let me put this way: I believe the charter text now contains all what it needs (http://trac.tools.ietf.org/bof/trac/wiki/DetNetDraftCharter version 15), but the flow makes it difficult to read. However, I could live with it. Regards, Benoit =========================== 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.
I have no objection to chartering this working group. I agree with Barry's suggested text tweak. If Alvaro's suggestion about problem statement, etc. is accepted, that would be fine with me. I have one question, just for my own background. I'm remembering that early in the charter discussions people thought someone would need to define a new DSCP for packets that should be buffered, if they arrive too early. Is that still a possibility? Perhaps the working group would need to figure that out after being chartered, but I thought I'd ask if this is already known.
Not a comment on the charter but more a (loaded:-) question... I believe, but don't have a citation to hand, that folks have found that higher layer protocol performance is more deterministic when payloads are encrypted. The logic, as I understand it, is ciphertext means middleboxes are less likely to mess about, whereas with plaintext, middlebox messing affects latencies, jitter etc in unpredictable ways. Do we think that this WG might maybe conclude that (perhaps opportunistically) encrypting the data plane may be a fine way to make latency more predictable? If so, count me in to help write that text/draft! If folks liked that idea enough, I guess one could even add a work item to the charter along the lines of: * Investigating the potential for (possibly opportunistic) encryption to increase determinism. (At which point I'd be a yes ballot too:-)