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

[Lou Berger <[e-mail]>]

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:
>
> 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
>
>
> _______________________________________________
> detnet mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/detnet