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

["Andrew G. Malis" <[e-mail]>]

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