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

[Janos Farkas <[e-mail]>]

Hi Andy,

Thank you for the updates! I think the draft has become better.

I have some further comments, thoughts.

I’m afraid the term “hybrid” is used in an unclear way. Well, like many other terms, hybrid may be an overloaded one, which may cause some confusion.
Part of the confusion may be that some call one of the TSN configuration models hybrid, which may have influenced the draft given that CNC and CUC are mentioned in the draft.
Note that IEEE Std 802.1Qcc-2018 specifies three TSN configuration models:

  *   Fully centralized model
  *   Fully distributed model
  *   Centralized network / distributed user model
See e.g., page 18 in www.ieee802.org/1/files/public/docs2018/detnet-tsn-farkas-tsn-basic-concepts-1118-v01.pdf#page=18.
None of them is called hybrid.
But, parking TSN away.

“Hybrid” and “Hybrid SDN” are terms that have been already used for years since the introduction of the term SDN. This is purely about network control, without user control. “Hybrid SDN” is the term used for cases when both distributed and centralized approaches are used together for the control of a network. For instance, ONF used to had a WG chartered to this subject: it was called “Hybrid WG”, see, e.g.,: “Hybrid Approaches” in
https://books.google.hu/books?id=Bc1qAAAAQBAJ&pg=PT107&lpg=PT107&dq=onf+hybrid+sdn+working+group&source=bl&ots=nmIkd0Y7A7&sig=ACfU3U0IX0mvRwIB0e357ej6lXliMgUMmA&hl=hu&sa=X&ved=2ahUKEwiGlqCv1b3nAhURuaQKHc2BD_MQ6AEwB3oECAsQAQ#v=onepage&q=onf%20hybrid%20sdn%20working%20group&f=false,
https://www.opennetworking.org/wp-content/uploads/2014/10/Framework_for_SDN_-Scope_and_Requirements.pdf,  or
https://www.opennetworking.org/wp-content/uploads/2014/10/sb-sdn-migration-use-cases.pdf.
Hybrid SDN has been also explained, e.g., in:
https://searchnetworking.techtarget.com/definition/hybrid-SDN,
https://www.researchgate.net/publication/283824941_Hybrid-SDN_for_packet_transport_The_horizontal_split,
https://www.semanticscholar.org/paper/A-survey%3A-Hybrid-SDN-Sandhya-Sinha/56b620f886478d2fd46395e17cea52bab10f7bd8, and
https://arxiv.org/ftp/arxiv/papers/1405/1405.6953.pdf

So, I’d suggest using the term “hybrid” only for the control (plane) of the network and for cases when both distributed and centralized approaches are used together for the control of a network.


Perhaps, more importantly, I found confusing the distinction of “traditional” and “segment routing”. I’m afraid this is not a lucky split. For instance, this implies that SDN is traditional. Nonetheless, for some, fully distributed control plane is traditional.

Even more importantly, this means that the draft choses a solution: segment routing. In my opinion, a framework document should not choose a solution, especially, as we have not done the control plane evaluation work yet.

Furthermore, segment routing is just one of the possible solutions to one of the mechanisms DetNet requires: explicit routes (https://www.rfc-editor.org/rfc/rfc8655.html#name-explicit-routes).

Perhaps it may be good to make a step back.

At this stage, it may be better to only list possible solutions for explicit routing; or even not to list but state that a solution is needed for explicit routing. There are multiple possible solutions. Please do not misunderstand me; segment routing is clearly one of the possibilities. But, we have not made any evaluation yet.

For instance, the draft states “Segment Routing is a scalable approach”. Has this been evaluated? Are there trade-offs in some cases? For instance, I mean, DetNet may require strict explicit routes. If the explicit route is encoded in the packet header, then the overhead may be large in case of a large network and small packets of periodic CBR flow. Is it worth it? Note that I’m not debating, just asking some questions as I haven’t seen analysis.

There are explicit routing techniques that are not mentioned in the draft. For instance, MRT, see RFC 7812 and RFC 7811, which is a standardized algorithm to compute maximally disjoint trees. (Note that MRT can be used in fully distributed, fully centralized, and hybrid ways, as described, e.g., in RFC 7813, which actually specifies an explicit routing extension to IS-IS.) I think MRT should be on the table as a possible technique.

The statement “interactions between DetNet Control and Management planes with Segment Routing Control and Management planes” also confuses me.
I thought that there is only one control plane and one management plane in a DetNet domain. If segment routing is used, then the single control plane supports segment routing aspects as well as DetNet aspects. (The single control plane may include centralized and distributed elements, but it is still a single control plane. If segment routing is used, then it is a hybrid control plane, but still a single control plane.)

I think, similarly to data plane, the distinction of MPLS and IP is good. However, a separate section on segment routing (following the MPLS and IP sections in Section 4) looks strange to me, especially as segment routing is somewhat different for MPLS and IP. I’d suggest listing MPLS segment routing in the MPLS section as one of the possible explicit routing techniques for MPLS, and do the same for IP.

My 2 cents,
Janos





From: detnet <[e-mail]> On Behalf Of Andrew G. Malis
Sent: Tuesday, January 14, 2020 11:16 PM
To: Balázs Varga A <[e-mail]>
Cc: [e-mail]; [e-mail]
Subject: Re: [Detnet] Comments regarding draft-malis-detnet-controller-plane-framework

Balázs,

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

On Sun, Jan 12, 2020 at 5:48 AM Balázs Varga A <[e-mail]<mailto:[e-mail]>> wrote:
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.

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


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

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.

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

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.


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

This can be moved to a separate draft that goes into more detail on the solution options.

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”

We can reword this.

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

Agreed.

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

Agreed.

- 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?

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.

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

Got it.

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

Of course!

Cheers
Bala’zs

Thanks again,
Andy