Subject: Re: [Detnet] proposed revised Charter

From: Kingshuk Mandal <[email-masked]>
Date: Mon, 9 Mar 2020 14:42:13 +0000

Dear Lou and Janos

Great to see this updated charter proposal.

I have a question on the following part of the description.
> Layer 3 data plane technologies that can be used include:
>IP and MPLS, and Layer 2 encapsulations that run over IP
>and/or MPLS, such as pseudowires and GRE.
What is WGs thought about looking into “Segment Routing” and “Segment Routing V6” as additional options for DetNet data plane ? It seems Segment Routing is getting adopted and could be an area for the interested DetNet WG members to explore in this direction for DetNet.

~Regards
  Kingshuk

From: detnet <[email-masked]> on behalf of Janos Farkas <Janos.Farkas=[email-masked]>
Date: Friday, 6 March 2020 at 7:59 PM
To: DetNet WG <[email-masked]>
Cc: DetNet Chairs <[email-masked]>
Subject: [Detnet] proposed revised Charter

[EXTERNAL]
WG,

As discussed at the last IETF, it is time for us to update our charter. We have put together the following proposal:

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 bounds on latency, loss,
and packet delay variation (jitter), and high reliability. The Working
Group addresses Layer 3 aspects in support of applications requiring
deterministic networking. The Working Group collaborates with the IEEE
802.1 Time-Sensitive Networking (TSN) Task Group, which is responsible
for Layer 2 operations, to ensure an aligned architecture for both Layer
2 and Layer 3. Example applications for deterministic networks include
professional and home audio/video, multimedia in transportation, engine
control systems, and industrial automation, as well as other general
industrial and vehicular applications being considered by the IEEE 802.1
TSN Task Group.

The Working Group will initially focus on solutions for networks that
are under a single administrative control or within a closed group of
administrative control; these include not only campus-wide networks but
also can include private WANs. The DetNet WG will not address solutions
for large groups of domains such as the Internet.

The Working Group is responsible for the overall DetNet architecture and
DetNet-specific specifications that encompasses the data plane, OAM
(Operations, Administration, and Maintenance), time synchronization,
management, control, and security aspects which are required to enable a
multi-hop path, and forwarding along the path, with the deterministic
properties of controlled latency, low packet loss, low packet delay
variation, and high reliability. The work applies to point-to-point
(unicast) and point-to-multipoint (multicast) flows which 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. Layer 3 data plane technologies that
can be used include: IP and MPLS, and Layer 2 encapsulations that run
over IP and/or MPLS, such as pseudowires and GRE.

The Working Group will document which deployment environments and types
of topologies are within (or outside) the scope of the DetNet
architecture. This work focuses on the data plane aspects and is
independent from any path setup protocol or mechanism. The working group
will also document DetNet Controller Plane [1] approaches that reuse
existing IETF solutions, such as Path Computation Element (PCE), and
identify the appropriate Working Group for any extensions needed to
support DetNet. Documents produced by the Working Group will be
compatible with the work done in IEEE802.1 TSN and other IETF Working
Groups.  The Working Group's scope explicitly excludes modifications of
transport protocols, OAM, Layer 3 forwarding, encapsulations, and
control plane protocols, but it may define requirements for such
modifications and identify the appropriate Working Group for any needed
modifications.

DetNet is chartered to work in the following areas:

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

Data plane: This work will document how to use IP and/or MPLS to support
a data plane method of flow identification and packet forwarding over
Layer 3. Other IETF defined data plane technologies may also be used.

Controller Plane: This work will document how to use IETF control plane
solutions to support DetNet. This work includes identification of any
gaps in existing solutions and identifying the appropriate Working Group
for any needed extensions..

Data flow information model: This work will identify the information
needed for flow establishment and control and be used by reservation
protocols and 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).

YANG models: 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. Control plane related information will be independent from the
protocol(s) which may be used to advertise this information (e.g. IS-IS
or GMPLS extensions). Any new YANG models will be coordinated with the
Working Groups that define any base models that are to be augmented.

As needed, vertical requirements: This effort will detail the
requirements for deterministic networks in various industries that have
previously not been documented or cannot be supported using defined
DetNet solutions.

To investigate whether existing data plane encryption mechanisms can be
applied, possibly opportunistically, to improve security and privacy.

The Working Group coordinates with other relevant IETF Working Groups,
including CCAMP, PCE, PALS, TEAS, OSPF, IS-IS, TSVWG, RAW, 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
and related solutions. The WG will liaise with appropriate groups in
IEEE and other Standards Development Organizations (SDOs).

[1] The DetNet Controller Plane is defined in RFC 8655 as "the
aggregation of the Control and Management Planes"

The difference compared to the current charter is available at:
https://etherpad.ietf.org:9009/p/detnet-recharter<https://urldefense.com/v3/__https:/etherpad.ietf.org:9009/p/detnet-recharter__;!!I5pVk4LIGAfnvw!wKMrD6eA0k6UstdM5hXJshoOoQrfPgxf6n3r4tOf819DURk_cz0WlAa8Jv4sQt660d44TTw$>

Our plan is to submit revised charter to the IESG after IETF 107. Given the number of remote participants, we are happy to have the discussion fully on the list.

Please submit your comments on the list.

Regards,
Lou and Janos

---

From: Lou Berger <[email-masked]>
Date: Wed, 18 Mar 2020 08:19:46 -0400

Hi Kingshuk,

On 3/9/2020 10:42 AM, Kingshuk Mandal wrote:
> What is WGs thought about looking into “Segment Routing” and “Segment 
> Routing V6” as additional options for DetNet data plane ? It seems 
> Segment Routing is getting adopted and could be an area for the 
> interested DetNet WG members to explore in this direction for DetNet.
>
I think this was also asked by Xuesong, see 
https://mailarchive.ietf.org/arch/msg/detnet/BmtSLCVs9IVPP-GSHmTlTAQv7ow/

In short, we think the revised text already covers this case.

Thanks!

Lou

> *~Regards*
>
> *Kingshuk *
>
> *From: *detnet <[email-masked]> on behalf of Janos Farkas 
> <Janos.Farkas=[email-masked]>
> *Date: *Friday, 6 March 2020 at 7:59 PM
> *To: *DetNet WG <[email-masked]>
> *Cc: *DetNet Chairs <[email-masked]>
> *Subject: *[Detnet] proposed revised Charter
>
> [EXTERNAL]
>
> WG,
>
> As discussed at the last IETF, it is time for us to update our 
> charter. We have put together the following proposal:
>
> https://etherpad.ietf.org:9009/p/detnet-recharter 
> <https://urldefense.com/v3/__https:/etherpad.ietf.org:9009/p/detnet-recharter__;!!I5pVk4LIGAfnvw!wKMrD6eA0k6UstdM5hXJshoOoQrfPgxf6n3r4tOf819DURk_cz0WlAa8Jv4sQt660d44TTw$> 
>
>
> Our plan is to submit revised charter to the IESG after IETF 107. 
> Given the number of remote participants, we are happy to have the 
> discussion fully on the list.
>