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

[Balázs Varga A <[e-mail]>]

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