Deterministic Networking
charter-ietf-detnet-04

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