Subject: [Detnet] Alvaro Retana's No Objection on charter-ietf-detnet-01-00: (with COMMENT)

From: Alvaro Retana via Datatracker <[email-masked]>
Date: Mon, 06 Apr 2020 06:03:48 -0700

Alvaro Retana has entered the following ballot position for
charter-ietf-detnet-01-00: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/charter-ietf-detnet/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

(1) Given the close relationship with IEEE, I think we need external review.

(2) "identify the appropriate Working Group"

This phrase shows up a couple of times.  I was first worried that it was meant
as a means for the WG to simply decide which WG (including itself) would do the
work, but now I think it is meant as a dispatch-like function: "we need this
work done, WG x seems like the right place."  Is my interpretation correct? 
Please try to clarify so that there is no confusion later...maybe something
along the lines of "the work will be done in the WG responsible for the
technology".

(3) Is the intent to publish the "vertical requirements" documents as RFCs? 
Just wondering because it sounds like an open-ended effort.  Suggestion: if
appropriate, scope the documents to industries that have new requirements which
have not been addressed already.

(4) s/OSPF, IS-IS/LSR

(5) Milestones would be nice.

---

From: Janos Farkas <[email-masked]>
Date: Wed, 8 Apr 2020 17:53:27 +0000

Hi Alvaro,

Thank you for your review!

Please note that the actually the change compared to the original charter is relatively small. Diff is shown here: https://etherpad.ietf.org:9009/p/detnet-recharter. Actually, the most important change is adding the Controller Plane. The rest are just smaller tweaks to enable extensions as/if needed.

Please see more in-line marked with [Janos Farkas].

-----Original Message-----
From: Alvaro Retana via Datatracker <[email-masked]> 
Sent: Monday, April 6, 2020 3:04 PM
To: The IESG <[email-masked]>
Cc: [email-masked]; [email-masked]
Subject: Alvaro Retana's No Objection on charter-ietf-detnet-01-00: (with COMMENT)

When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.)

[Janos Farkas] 
The changes in the charter are within the scope of IETF and do not affect the relationship with IEEE 802.1. In particular, the work is limited documenting how to use IETF control planes and identifying gaps.

This phrase shows up a couple of times.  I was first worried that it was meant as a means for the WG to simply decide which WG (including itself) would do the work, but now I think it is meant as a dispatch-like function: "we need this work done, WG x seems like the right place."  Is my interpretation correct? 
Please try to clarify so that there is no confusion later...maybe something along the lines of "the work will be done in the WG responsible for the technology".

[Janos Farkas] 
The intention is along the lines you wrote: "the work will be done in the WG responsible for the technology". 
In order to capture, I suggest the following changes. This also includes the change to address the comment from Magnus.

OLD:
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.

NEW:
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 Working Group responsible 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 discuss requirements for such modifications and the work will be done in the WG responsible for the technology.

OLD:
     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.

NEW:
     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 responsible for any needed extensions.

(3) Is the intent to publish the "vertical requirements" documents as RFCs? 
Just wondering because it sounds like an open-ended effort.  Suggestion: if appropriate, scope the documents to industries that have new requirements which have not been addressed already.

 [Janos Farkas] 
"As needed, vertical requirements" comes from the original charter.
The WG developed RFC 8578 Deterministic Networking Use Cases.
This part is intended to be an enabler to be able to extend if needed.

(4) s/OSPF, IS-IS/LSR

 [Janos Farkas] 
Replace as suggested.

 [Janos Farkas] 
Milestones are being updated accordingly at: https://datatracker.ietf.org/wg/detnet/about/.

Thank you!
Best regards,
Janos

---

From: Alvaro Retana <[email-masked]>
Date: Wed, 8 Apr 2020 11:41:47 -0700

On April 8, 2020 at 1:53:28 PM, Janos Farkas wrote:

Janos:

Hi!

I have a couple of replies below.  I defer to the responsible AD
decide on the other points.

Thanks!!

Alvaro.

...
> (2) "identify the appropriate Working Group"
...
> In order to capture, I suggest the following changes. This also includes the
> change to address the comment from Magnus.
>
...
> Working Group responsible for any needed extensions.

This change still says the same thing.

Suggestion>
   Controller Plane: This work will document how to use IETF control
   plane solutions to support DetNet, including the identification
   of any gaps in existing solutions.  Any resulting work will be done
   in the WG responsible for the technology.

> appropriate, scope the documents to industries that have new requirements
> which have not been addressed already.
>
> [Janos Farkas]

The original charter was written when the use cases, architecture,
etc. had not been defined.

My concern is not about extending the architecture or the solutions.
It is about publishing requirements that have already been addressed.
Here's a suggestion:

OLD>
     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.

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

---

From: Lou Berger <[email-masked]>
Date: Wed, 8 Apr 2020 14:44:48 -0400

On addition minor comment, see below.

> https://datatracker.ietf.org/doc/charter-ietf-detnet/

The WG has also published an architecture document 
https://tools.ietf.org/html/rfc8655

Lou

> _______________________________________________
> detnet mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/detnet
>

---

From: "Grossman, Ethan A." <[email-masked]>
Date: Wed, 8 Apr 2020 18:46:44 +0000

Hi Alvaro,
I agree with your two wording changes below, I feel they are both clearer. 
Ethan.

-----Original Message-----
From: Alvaro Retana <[email-masked]> 
Sent: Wednesday, April 8, 2020 11:42 AM
To: Janos Farkas <[email-masked]>; The IESG <[email-masked]>
Cc: [email-masked]; [email-masked]
Subject: RE: Alvaro Retana's No Objection on charter-ietf-detnet-01-00: (with COMMENT)

Janos:

Hi!

I have a couple of replies below.  I defer to the responsible AD decide on the other points.

Thanks!!

Alvaro.

...
...
> In order to capture, I suggest the following changes. This also 
> includes the change to address the comment from Magnus.
>
...

Suggestion>

> Just wondering because it sounds like an open-ended effort. 
> Suggestion: if appropriate, scope the documents to industries that 
> have new requirements which have not been addressed already.
>
> [Janos Farkas]

The original charter was written when the use cases, architecture, etc. had not been defined.

OLD>

NEW>

---

From: Lou Berger <[email-masked]>
Date: Wed, 8 Apr 2020 14:51:18 -0400

Hi Alvaro,

See below.

>     in the WG responsible for the technology.

While I don't feel strongly about this and certainly can live with the 
suggested phrasing, I feel like this might be overly constrictive.  
Let's say for an extension is needed to a yang model defined in TEAS and 
the chairs of both groups, in consultation with the AD, decided that the 
work should be done in DetNet.  Would this be permitted?  I think TEAS 
would not want to transfer the responsibility of the larger work even 
though the specific gap would be filled by DetNet.  So, I'm left with a 
slight preference for the original text.

>       defined DetNet solutions.

This works for me.

Thanks!

Lou

---

From: Alvaro Retana <[email-masked]>
Date: Wed, 8 Apr 2020 12:18:08 -0700

On April 8, 2020 at 2:51:20 PM, Lou Berger wrote:

Lou:

Hi!

...
> slight preference for the original text.

That original text talks about detnet identifying who will do the
work.  As you point out, that could also be coordinated between the
chairs, AD, etc.

In spring, for example, we used this text, which could be reused here
(the last part):

   Any modification of -or extension to- existing architectures, data planes,
   or control or management plane protocols should be carried out in the WGs
   responsible for the architecture, data plane, or control or management plane
   protocol being modified and in coordination with the SPRING WG, but may be
   done in SPRING WG after agreement with all the relevant WG chairs and
   responsible Area Directors.

Alvaro.

---

From: "Grossman, Ethan A." <[email-masked]>
Date: Wed, 8 Apr 2020 19:27:01 +0000

Hmm, now that I look closer, the proposed text also brings back the term "control plane" vs "controller plane" (union of management and control planes), so some revision is needed. I took a swing at it below, #4, combining the SPRING text with our existing text. 
Ethan.

1, previous original) This work includes identification of any gaps in existing solutions and identifying the appropriate Working Group for any needed extensions.

2, next original ) This work includes identification of any gaps in existing solutions and identifying the appropriate Working Group responsible for any needed extensions.

3, Alvaro proposal) This work will document how to use IETF control plane solutions to support DetNet, including the identification of any gaps in existing solutions.  Any resulting work will be  done in the WG responsible for the technology.

4) (Incorporating SPRING text, adapted)    This work will document how to use IETF controller plane solutions to support DetNet, including the identification of any gaps in existing solutions.  Any modification to controller plane protocols to address identified gaps should be carried out in their associated WGs, but may be done in DetNet if agreed to by the relevant WG chairs and responsible Area Directors.

-----------------------------------

-----Original Message-----
From: Alvaro Retana <[email-masked]> 
Sent: Wednesday, April 8, 2020 12:18 PM
To: The IESG <[email-masked]>; Lou Berger <[email-masked]>; Janos Farkas <[email-masked]>
Cc: [email-masked]; [email-masked]
Subject: Re: Alvaro Retana's No Objection on charter-ietf-detnet-01-00: (with COMMENT)

Lou:

Hi!

...
> >> plane solutions to support DetNet. This work includes 
> >> identification of any gaps in existing solutions and identifying 
> >> the appropriate Working Group responsible for any needed extensions.
> > plane solutions to support DetNet, including the identification of 
> > any gaps in existing solutions. Any resulting work will be done in 
> > the WG responsible for the technology.
>
> Let's say for an extension is needed to a yang model defined in TEAS 
> and the chairs of both groups, in consultation with the AD, decided 
> that the work should be done in DetNet. Would this be permitted? I 
> think TEAS would not want to transfer the responsibility of the larger 
> work even though the specific gap would be filled by DetNet. So, I'm 
> left with a slight preference for the original text.

That original text talks about detnet identifying who will do the work.  As you point out, that could also be coordinated between the chairs, AD, etc.

In spring, for example, we used this text, which could be reused here (the last part):

Alvaro.

---

From: Alvaro Retana <[email-masked]>
Date: Wed, 8 Apr 2020 12:29:41 -0700

FWIW, #4 works for me.

Thanks!

Alvaro.

On April 8, 2020 at 3:27:03 PM, Grossman, Ethan A. ([email-masked]) wrote:

Hmm, now that I look closer, the proposed text also brings back the term
"control plane" vs "controller plane" (union of management and control
planes), so some revision is needed. I took a swing at it below, #4,
combining the SPRING text with our existing text.
Ethan.

1, previous original) This work includes identification of any gaps in
existing solutions and identifying the appropriate Working Group for any
needed extensions.

2, next original ) This work includes identification of any gaps in
existing solutions and identifying the appropriate Working Group
responsible for any needed extensions.

3, Alvaro proposal) This work will document how to use IETF control plane
solutions to support DetNet, including the identification of any gaps in
existing solutions. Any resulting work will be done in the WG responsible
for the technology.

4) (Incorporating SPRING text, adapted) This work will document how to use
IETF controller plane solutions to support DetNet, including the
identification of any gaps in existing solutions. Any modification to
controller plane protocols to address identified gaps should be carried out
in their associated WGs, but may be done in DetNet if agreed to by the
relevant WG chairs and responsible Area Directors.

-----Original Message-----
From: Alvaro Retana <[email-masked]>
Sent: Wednesday, April 8, 2020 12:18 PM
To: The IESG <[email-masked]>; Lou Berger <[email-masked]>; Janos Farkas <
[email-masked]>
Cc: [email-masked]; [email-masked]
Subject: Re: Alvaro Retana's No Objection on charter-ietf-detnet-01-00:
(with COMMENT)

Lou:

Hi!

...
> left with a slight preference for the original text.

That original text talks about detnet identifying who will do the work.  As
you point out, that could also be coordinated between the chairs, AD, etc.

In spring, for example, we used this text, which could be reused here (the
last part):

   Any modification of -or extension to- existing architectures, data
planes,
   or control or management plane protocols should be carried out in the
WGs
   responsible for the architecture, data plane, or control or management
plane
   protocol being modified and in coordination with the SPRING WG, but may
be
   done in SPRING WG after agreement with all the relevant WG chairs and
   responsible Area Directors.

Alvaro.

---

From: Lou Berger <[email-masked]>
Date: Wed, 8 Apr 2020 18:04:33 -0400

Hi Alvaro,

The spring phrasing would address my reservation.

Thanks,

Lou

Lou

---

From: Janos Farkas <[email-masked]>
Date: Thu, 9 Apr 2020 12:27:15 +0000

Hi,

I tried to capture the changes in the updated charter text:

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 Working Group responsible 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 discuss requirements for such
modifications and the work will be done in the WG responsible for the
technology.

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, and
     related OAM, 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 Controller
     Plane solutions to support DetNet, including the identification
     of any gaps in existing solutions. Any modification to Controller
     Plane protocols to address identified gaps should be carried out
     in their associated WGs, but may be done in DetNet if agreed to by
     the relevant WG chairs and responsible Area Directors.

     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.

     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, LSR, TSVWG, RAW, and 6TiSCH. 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"

Thank you!
Best regards,
Janos

-----Original Message-----
From: Lou Berger <[email-masked]>
Sent: Thursday, April 9, 2020 12:05 AM
To: Alvaro Retana <[email-masked]>; The IESG <[email-masked]>; Janos Farkas <[email-masked]>
Cc: [email-masked]; [email-masked]
Subject: Re: Alvaro Retana's No Objection on charter-ietf-detnet-01-00: (with COMMENT)

Hi Alvaro,

Thanks,

Lou

Lou

>> While I don't feel strongly about this and certainly can live with

>> the suggested phrasing, I feel like this might be overly constrictive.

>> think TEAS would not want to transfer the responsibility of the

>> larger work even though the specific gap would be filled by DetNet.

>> So, I'm left with a slight preference for the original text.

>     or control or management plane protocols should be carried out in

> the WGs

>     responsible for the architecture, data plane, or control or

> management plane

>     protocol being modified and in coordination with the SPRING WG,

> but may be

>     done in SPRING WG after agreement with all the relevant WG chairs

> and

---

From: Alvaro Retana <[email-masked]>
Date: Thu, 9 Apr 2020 07:01:09 -0700

On April 9, 2020 at 8:27:16 AM, Janos Farkas wrote:

Janos:

Hi!

This looks good to me..there's just a small inconsistency:

...
...
> the relevant WG chairs and responsible Area Directors.

The first piece of text says that control plane (and other) work will
be done somewhere else...the second piece says that modifications to
controller plane (which includes the control plane) may be done in
detnet, if agreed...

Just a small nit.

Thanks!!

Alvaro.

---

From: "Grossman, Ethan A." <[email-masked]>
Date: Thu, 9 Apr 2020 18:47:25 +0000

Hi Janos, 
Here is some proposed text for re-using the controller plane text to address Alvaro's observation: 

1 - Janos current proposed) 
The Working Group's scope explicitly excludes modifications of
transport protocols, OAM, Layer 3 forwarding, encapsulations, and
control plane protocols, but it may discuss requirements for such
modifications and the work will be done in the WG responsible for the
technology.

2 - Incorporating "adapted SPRING" wording as used for controller plane paragraph) 
The Working Group's scope explicitly excludes modifications of
transport protocols, OAM, Layer 3 forwarding, encapsulations, and
controller plane protocols, but it may discuss requirements for such
modifications; any identified requirements should be carried out in their associated WGs, but may be done in DetNet if agreed to by the relevant WG chairs and responsible Area Directors.

Ethan.

-----Original Message-----
From: Alvaro Retana <[email-masked]> 
Sent: Thursday, April 9, 2020 7:01 AM
To: Janos Farkas <[email-masked]>; Lou Berger <[email-masked]>; Grossman, Ethan A. <[email-masked]>; The IESG <[email-masked]>
Cc: [email-masked]; [email-masked]
Subject: RE: Alvaro Retana's No Objection on charter-ietf-detnet-01-00: (with COMMENT)

Janos:

Hi!

...
...
> Plane solutions to support DetNet, including the identification of any 
> gaps in existing solutions. Any modification to Controller Plane 
> protocols to address identified gaps should be carried out in their 
> associated WGs, but may be done in DetNet if agreed to by the relevant 
> WG chairs and responsible Area Directors.

The first piece of text says that control plane (and other) work will be done somewhere else...the second piece says that modifications to controller plane (which includes the control plane) may be done in detnet, if agreed...

Just a small nit.

Thanks!!

Alvaro.