Subject: [Detnet] Comments regarding draft-malis-detnet-controller-plane-framework

From: Balázs Varga A <[email-masked]>
Date: Sun, 12 Jan 2020 10:48:03 +0000

Hi,

Please, find below some comments / proposed improvements regarding
draft-malis-detnet-controller-plane-framework.

General comments:
- List of topics:
I think the controller plane framework related topics are well summarized. Good start. :--)

- Role of control plane and management plane
Data plane drafts have listed the requirements for the controller plane and have not
discussed what is implemented in a solution by control and what by management plane.
Here it would be great to have a section dedicated to provide possible separation the
requirements to control / management plane.

- Hybrid control plane (chapter 3.3)
I have found the examples unclear and confusing. Is the CNC same entity as the controller?
How the controller receives "flow establishment request from a UNI"? Does it have a UNI?
To what entity? Examples should be improved or removed.

- P2MP2P path (chapter 4.3)
What is a P2MP2P path? We need a clear definition for this term. DetNet flows are P2P or P2MP.
Single ingress endpoint/interface to the DetNet domain and one or more egress endpoints/interfaces.
(See e.g., 5.6.  Endpoints of the DetNet Flow or 6.4.  Connectivity Type of the DetNet Service in
[draft-ietf-detnet-flow-information-model])
I think what we need here from the controller plane is being able to setup/maintain a structure of
LSP segments what is in-line with the location of PREOF elements serving a compound flow. These
LSP segments are used by the member flows (segments of the DetNet flow).
We may need a term for "structure of LSP segments", like "LSP graph" or something similar.
I think this topic is an _essential part_ of the controller plane framework and need much more details.
We have to define what we expect from the controller plane. For example: (1) setting up a set of
P2P LSPs, or (2) setting up a single advanced P2MP++ "LSP graph" or (3) something else.

- too much solution related details (chapter 4.6)
In my view the framework document should summarize the requirements and major solution options,
but should not go into details. For example chapter 4.6 refers to several individual drafts being under
discussion and in early phases. Current text also says "This is not the only possible approach.".
Text starting with "One possible architecture is ..." should be considered to be removed.

Detailed comments:
- chapter 2, aggregation related terminology
"Support DetNet flow aggregation and de-aggregation via the ability
to dynamically create and delete flow aggregates (FAs), and be
able to modify existing FAs by adding or deleting members."
We may need new terminology here. PREOF uses "compound flow" and "member flow".
It would be good to distinguish flows participating in aggregation from "member flows"
related to PREOF. E.g., replace in the text "members" -> "participating flows"

- chapter 2, label management
"In the case of the DetNet MPLS data plane, manage DetNet S-Label
and F-Label allocation and distribution."
A-labels should be mentioned here as well. It has some special characteristics.

- chapter 2, DetNet service sub-layer
"Also in the case of the DetNet MPLS data plane, support packet
replication, duplicate elimination, and packet ordering functions
(PREOF), and to be able to place these functions at appropriate
places in the network."
We should refer here to DetNet service sub-layer and refer to PREOF as an example.

- chapter 2, synchronization
"Support applications that require the ability to synchronize the
clocks in end systems to the extent supported by the DetNet data
plane."
It is not clear what we intend to say here. Synch solution is expected to exists and
is not DetNet Controller Plane specific. Or You are proposing special signaling to setup
synch configuration/relationships between nodes?

- chapter 4.5, path merging
In my view path merging is a wrong term here. Related to previous L2MP2P path comment.

Minor/editorial comments:
- references need update (e.g., draft-architecture -> rfc8655, etc.)

Cheers
Bala'zs

---

From: Lou Berger <[email-masked]>
Date: Mon, 13 Jan 2020 08:00:25 -0500

Balázs,

Thanks for these comments!

WG,

We (the chairs) are really hoping for wider contribution on this 
document as we move to WG adoption -- such contribution will help 
demonstrate that the WG as a whole is interested in progressing this 
work as we move to the rechartering mentioned in our last meeting.

Cheers,

Lou

On 1/12/2020 5:48 AM, Balázs Varga A wrote:
> *General comments:*
> How the controller receives “flow establishment request from a UNI”? 
> Does it have a UNI?
>
> We may need a term for “structure of LSP segments”, like “LSP graph” 
> or something similar.
>
> I think this topic is an _/essential part/_ of the controller plane 
> framework and need much more details.
>
> P2P LSPs, or (2) setting up a single advanced P2MP++ “LSP graph” or 
> (3) something else.
>
> discussion and in early phases. Current text also says “This is not 
> the only possible approach.”.
>
> Text starting with “One possible architecture is …” should be 
> considered to be removed.
>
> *Detailed comments:*
>
> “Support DetNet flow aggregation and de-aggregation via the ability
>
> able to modify existing FAs by adding or deleting members.”
>
> related to PREOF. E.g., replace in the text “members” -> 
> “participating flows”
>
> “In the case of the DetNet MPLS data plane, manage DetNet S-Label
>
> and F-Label allocation and distribution.”
>
> “Also in the case of the DetNet MPLS data plane, support packet
>
> places in the network.”
> “Support applications that require the ability to synchronize the
>
> plane.”
> *Minor/editorial comments:*
>
> Bala’zs
> _______________________________________________
> detnet mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/detnet

---

From: "Andrew G. Malis" <[email-masked]>
Date: Tue, 14 Jan 2020 17:16:07 -0500

Balázs,

Many thanks for your detailed review and comments. Replies inline .....

> requirements to control / management plane.

Andy: In Section 2, we could identify, for each requirement, to which plane
it primarily applies. Would that satisfy your comment?

> How the controller receives “flow establishment request from a UNI”? Does
> it have a UNI?
>

We'll take a look at the examples (which are just that, not meant to be
exhaustive) and see how they can be improved. Any suggested improvements
would also be greatly appreciated.

> We may need a term for “structure of LSP segments”, like “LSP graph” or
> something similar.
>
> I think this topic is an _*essential part*_ of the controller plane
> P2P LSPs, or (2) setting up a single advanced P2MP++ “LSP graph” or (3)
> something else.
>

P2MP2P was meant to refer not to the DetNet service, but the means to
implement PREOF in order to support a DETNET P2P or P2MP service. As you
know, when using PREOF to implement a DetNet P2P service, packets are
replicated and then later merged, at a conceptual "lower layer" than the
DetNet service. It is at this conceptual lower layer that the "P2MP2P"
happens. We can reword this along the lines that you suggest to make it
more clear.

> discussion and in early phases. Current text also says “This is not the
> only possible approach.”.
>
> Text starting with “One possible architecture is …” should be considered
> to be removed.
>
>
>
This can be moved to a separate draft that goes into more detail on the
solution options.

> related to PREOF. E.g., replace in the text “members” -> “participating
> flows”
>

We can reword this.

> A-labels should be mentioned here as well. It has some special

Agreed.

> We should refer here to DetNet service sub-layer and refer to PREOF as an

Agreed.

> synch configuration/relationships between nodes?

This originated from several of the use cases in RFC 8578. But you're
right, it's not clear that this is DetNet controller plane specific. We'll
remove it.

> In my view path merging is a wrong term here. Related to previous L2MP2P

Got it.

> - references need update (e.g., draft-architecture -> rfc8655, etc.)

Of course!

> Bala’zs

Thanks again,
Andy