Subject: Re: [Detnet] proposed revised Charter

From: <[email-masked]>
Date: Wed, 11 Mar 2020 16:32:44 +0800 (CST)

Hi Janos and Lou,

It looks good to me. I think there are three main changes as following:

a, increase the solutions of Control and Management Planes, 

b, increase the types of Data plane, such as SRv6,

c, increase the requirements of the deterministic networks in all industries.

I think these are useful and I will contribute as the revised Charter.

A question I am confused is that what the Management Planes cover, such as OAM,PM?

Thanks,

Quan

<<[Detnet] proposed revised Charter
Janos Farkas <[email-masked]> Fri, 06 March 2020 14:29 UTCShow header

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"

---

From: "Gengxuesong (Geng Xuesong)" <[email-masked]>
Date: Wed, 11 Mar 2020 09:53:38 +0000

Hi Chairs & Quan,

A brief question based on Quan’s previous email: Whether New Data Plane Solution(e.g. SRv6) is included in the new charter?
This seems different from the conclusion in IETF 106: SRv6 based data plane solution is supposed to be promoted in other WG, e.g., SPRING.
Thank you for raising this, and this is important to find a proper home for our SRv6 based drafts.

Best Regards
Xuesong

From: detnet [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Wednesday, March 11, 2020 4:33 PM
To: [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: [Detnet] proposed revised Charter

Hi Janos and Lou,

Thanks,

Quan

Janos Farkas <[email-masked]<mailto:[email-masked]>> Fri, 06 March 2020 14:29 UTCShow header<https://mailarchive.ietf.org/arch/msg/detnet/GcBVsW-_AeC6G1ryWpc_N5LuXIs/>

WG,

TSN Task Group.

modifications.

or GMPLS).

DetNet solutions.

---

From: Lou Berger <[email-masked]>
Date: Sun, 15 Mar 2020 17:05:14 -0400

Hi Quan,

See below.

> A question I am confused is that what the Management Planes cover, 
This is a fair question.  Generally "Management Plane" refers to 
configuration and provisioning related activities, while OAM and PM 
generally refers to in-band mechanisms used to measure/evaluate what is 
happening in the data plane.  This is certainly terminology overload 
related to the word "management".   The charter's usage of these terms 
have not really changed from the original text, but they are intended to 
be consistent with https://tools.ietf.org/html/rfc8655

Please let me know if this helps.  If not, can you suggest a specific 
change that you think would?

Thank you,

Lou

> <https://mailarchive.ietf.org/arch/msg/detnet/GcBVsW-_AeC6G1ryWpc_N5LuXIs/#>
>
> WG,
>

---

From: Lou Berger <[email-masked]>
Date: Sun, 15 Mar 2020 17:10:18 -0400

Hi Xuesong,

On 3/11/2020 5:53 AM, Gengxuesong (Geng Xuesong) wrote:
>
> Hi Chairs & Quan,
>
> A brief question based on Quan’s previous email: Whether New Data 
> Plane Solution(e.g. SRv6) is included in the new charter?
>
> This seems different from the conclusion in IETF 106: SRv6 based data 
> plane solution is supposed to be promoted in other WG, e.g., SPRING.
>
I don't think this revision of the charter has change anything WRT Data 
plane solutions. We don't define forwarding plane technologies, but we 
may define how existing technologies may be used to support detnets.  We 
also can coordinate with other working groups to ensure that their 
forwarding technologies support detnet requirements. For SRv6 we need to 
continue coordinating with the SRv6 chairs (and working group) as 
previously discussed.

Thanks,

Lou

> Best Regards
> Xuesong
>
> *From:*detnet [mailto:[email-masked]] *On Behalf Of 
> [email-masked]
> *Sent:* Wednesday, March 11, 2020 4:33 PM
> *To:* [email-masked]; [email-masked]
> *Cc:* [email-masked]; [email-masked]
> *Subject:* Re: [Detnet] proposed revised Charter
>
>
> Hi Janos and Lou,
>
> Janos Farkas <[email-masked] 
> <mailto:[email-masked]>>Fri, 06 March 2020 14:29 UTCShow 
> header 
> <https://mailarchive.ietf.org/arch/msg/detnet/GcBVsW-_AeC6G1ryWpc_N5LuXIs/>
>
> WG,
> As discussed at the last IETF, it is time for us to update our 
> charter. We have put together the following proposal: