Subject: [Detnet] Draft charter discussion

From: Lou Berger <[email-masked]>
Date: Wed, 26 Aug 2015 14:41:27 -0400

So a few of us have been having an offline discussion to get the ball
rolling on a draft WG charter discussion.  Here's what we have so far. 
I think we all recognize it isn't perfect, but it's a starting point for
the discussion.

Please comment / provide specific proposals for modification...

Proposed DetNet Charter

The Deterministic Networking Working Group (DetNet) 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
jitter. The Working Group will address Layer 3 aspects in support of
deterministic applications. The group will collaborate with
IEEE802.1TSN, which is responsible for Layer-2 operations, to define a
common architecture to support IEEE802.1TSN applications. For the common
architecture, a number of elements such as the IEEE802.1TSN host
operation should be agnostic to the choice of network used for the
connectivity.

The Working Group will specify an overall architecture that encompasses
the data plane, OAM, management, control, and security aspects that are
required to enable a multi-hop path, and forwarding along that path,
with the deterministic properties of controlled latency, low packet
loss, low jitter, and high reliability. The work will apply 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 more required.  The work
will cover 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; it will not include end-to-end
considerations such as transport protocols, modification of OAM, L3
forwarding and encapsulations, or control plane protocols. Candidate
Layer 3 data plane technologies that may be used, without modification,
include: IPv4, IPv6, MPLS. 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.  This work focuses on the data plane and is independent
from any path setup protocol or mechanism.  The data plane will be
compatible with the work done in IEEE801.1TSN.

DetNet is chartered to work in the following areas:

 o Overall architecture: This work encompasses the data plane, OAM,
   management, control, and security aspects.

 o Data plane: This work will document a data plane method of flow
   identification and packet forwarding over Layer 3.

 o 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, PCEP or GMPLS).

 o 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. ISIS or GMPLS extensions). Any YANG work will be
   coordinated with the working groups that define the base models.

 o As needed, problem statement: This effort will establish the
   deployment environment and deterministic network requirements which
   is supported.

 o As needed, vertical requirements: This effort will detail the
   requirements for deterministic networks in various industries, for
   example, professional audio, electrical utilities, building
   automation systems, wireless for industrial applications.

The WG will coordinate with other relevant IETF Working Groups,
including CCAMP, PCE, PALS, TEAS, TSVWG, 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).

---

From: János Farkas <[email-masked]>
Date: Thu, 27 Aug 2015 14:10:03 +0200

Hi,

I think that the charter is pretty good. (noting is perfect)
Please find some comments below on the charter text.

1st paragraph:
- I think "Deterministic Networking (DetNet) Working Group" looks better 
than "Deterministic Networking Working Group (DetNet)".
- "Layer-3" vs "Layer 3" are not used consequently (same for L2)
- I'd use "packet delay variation" instead of "jitter" in all occurrences.
- I think "The Working Group will address Layer 3 aspects in support of 
applications requiring deterministic networking." would be better than 
"The Working Group will address Layer 3 aspects in support of 
deterministic applications." (I'm not sure whether "deterministic 
application" is defined.)

2nd paragraph:
- I think it is quite important that we are often going below 
milliseconds. I'd extend "controlled latency" with "controlled low 
latency (even sub-milliseconds)" or sg like that.
- I'd extend the last sentence with "aspects": "This work focuses on the 
data plane aspects and ..."
- typo: IEEE801.1TSN -> IEEE802.1TSN
- (use of "IEEE 802.1 TSN" with the spaces could be considered)

Data flow information model:
- PCEP and GMPLS are protocols at the end in the parentheses. Instead of 
YANG, I'd add NetConf or sg similar here.

Identification of additional YANG augmentations:
- "IS-IS" looks better to me than "ISIS".

problem statement:
- I think "which is supported" is unnecessary at the end, I'd delete it.

Last paragraph:
- I think the IS-IS WG and the OSPF WG are missing from the list of WGs 
DetNet WG will coordinate with. The TE extensions of these protocols can 
be useful for DetNet.

Best regards,
Janos

On 8/26/2015 8:41 PM, Lou Berger wrote:
> _______________________________________________
> detnet mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/detnet
>
>

---

From: Lou Berger <[email-masked]>
Date: Thu, 27 Aug 2015 18:22:24 -0400

János,

Really good comments.  I've put the draft text on a Wiki:
http://trac.tools.ietf.org/bof/trac/wiki/DetNetDraftCharter

It's available for editing -- but please discuss changes on list before
making them.

I'll update it per your comments, and send a message once done. 
Although, probably tomorrow...

Lou 

On 8/27/2015 8:10 AM, János Farkas wrote:
> - I think "Deterministic Networking (DetNet) Working Group" looks
> better than "Deterministic Networking Working Group (DetNet)".
> - I think "The Working Group will address Layer 3 aspects in support
> of applications requiring deterministic networking." would be better
> than "The Working Group will address Layer 3 aspects in support of
> - I'd extend the last sentence with "aspects": "This work focuses on
> the data plane aspects and ..."
> - PCEP and GMPLS are protocols at the end in the parentheses. Instead
> of YANG, I'd add NetConf or sg similar here.
>
> - I think the IS-IS WG and the OSPF WG are missing from the list of
> WGs DetNet WG will coordinate with. The TE extensions of these
> protocols can be useful for DetNet.
>
> Best regards,
> Janos
>
>

---

From: Lou Berger <[email-masked]>
Date: Fri, 28 Aug 2015 08:26:09 -0400

János, (All)

I've updated the wiki based on your comments, take a look.  See below
for specific response/open points.

>> application" is defined.)
All done.

>> latency (even sub-milliseconds)" or sg like that.
While I don't disagree with the technical point, and I think it's
particularly important WRT PDV/jitter, I'm not sure this level of detail
really belongs in the charter. 

What do others think?

>> - (use of "IEEE 802.1 TSN" with the spaces could be considered)
done.

>> of YANG, I'd add NetConf or sg similar here.
fair enough.  Changed to YANG+NETCONF/RESTCONF.

>> - I think "which is supported" is unnecessary at the end, I'd delete it.
Done.

>> protocols can be useful for DetNet.
100% agree.

Thanks again for the comments,
Lou

---

From: Balázs Varga A <[email-masked]>
Date: Mon, 31 Aug 2015 12:25:57 +0000

Hi,
 
I would argue for explicitly highlighting sub-millisecond requirement as many current protocols do not deal with such a timescale.
 
Cheers
Bala'zs

-----Original Message-----
From: detnet [mailto:[email-masked]] On Behalf Of Lou Berger
Sent: Friday, August 28, 2015 2:26 PM
To: [email-masked]; Janos Farkas
Subject: Re: [Detnet] Draft charter discussion

János, (All)

I've updated the wiki based on your comments, take a look.  See below for specific response/open points.

>  snips

>> latency (even sub-milliseconds)" or sg like that.
While I don't disagree with the technical point, and I think it's particularly important WRT PDV/jitter, I'm not sure this level of detail really belongs in the charter. 

What do others think?

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 31 Aug 2015 13:53:49 +0000

Hello Bala'zs 

... But then, some do not need to, and for some others, the critically is a time sync in usecs, a low jitter, or a guarantee of no more than 3 losses in a row. I'm afraid that exhibiting one property may make it appear like more important than another. I find the charter balanced, but then, maybe we could use the word "extreme" or some equivalent to reflect that " paths can provide bounded latency, loss and packet delay variation (jitter)" in ways that are beyond the traditional expectations of IP protocols.

What do you think?

Pascal

> From: detnet [mailto:[email-masked]] On Behalf Of Balázs Varga A
> Sent: lundi 31 août 2015 14:26
> To: [email-masked]
> I would argue for explicitly highlighting sub-millisecond requirement as
> many current protocols do not deal with such a timescale.
> 
> Cheers
> Bala'zs
> 
> While I don't disagree with the technical point, and I think it's particularly
> important WRT PDV/jitter, I'm not sure this level of detail really belongs in
> the charter.
> 
> What do others think?
> 
>

---

From: Jouni Korhonen <[email-masked]>
Date: Mon, 31 Aug 2015 14:42:17 +0000

I tend to agree with Pascal. No issue from my side having "sub-milliseconds" mentioned as an example in the text. On the other hand we could say: "..with the deterministic properties of controlled low latency, low packet loss, low packet delay variation, and high reliability that are likely to greatly exceed the current expectations for IP protocols."

- Jouni

> From: detnet [mailto:[email-masked]] On Behalf Of Pascal Thubert
> (pthubert)
> Sent: Monday, August 31, 2015 6:54 AM
> To: Balázs Varga A; [email-masked]
> ... But then, some do not need to, and for some others, the critically is a time
> sync in usecs, a low jitter, or a guarantee of no more than 3 losses in a row. I'm
> afraid that exhibiting one property may make it appear like more important than
> another. I find the charter balanced, but then, maybe we could use the word
> "extreme" or some equivalent to reflect that " paths can provide bounded
> latency, loss and packet delay variation (jitter)" in ways that are beyond the
> traditional expectations of IP protocols.
> 
> What do you think?
> 
> Pascal
>

---

From: Balázs Varga A <[email-masked]>
Date: Mon, 31 Aug 2015 15:22:03 +0000

Hi Pascal,

The comment on delay was not against any other parameters, just to highlight that "low delay" can mean even micro-sec requirements.
I like your formulation " beyond the traditional expectations of IP protocols " (it is valid for other parameters as well like loss, jitter, etc.).

Cheers 
Bala'zs

-----Original Message-----
From: Pascal Thubert (pthubert) [mailto:[email-masked]] 
Sent: Monday, August 31, 2015 3:54 PM
To: Balázs Varga A; [email-masked]
Subject: RE: [Detnet] Draft charter discussion

Hello Bala'zs 

What do you think?

Pascal

> I would argue for explicitly highlighting sub-millisecond requirement 
> as many current protocols do not deal with such a timescale.
> 
> Cheers
> Bala'zs
> 
> particularly important WRT PDV/jitter, I'm not sure this level of 
> detail really belongs in the charter.
> 
> What do others think?
> 
>