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

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

Janos,

Many thanks for your review and detailed comments, they're greatly
appreciated. I'll update the draft accordingly.

Cheers,
Andy


On Fri, Feb 7, 2020 at 6:17 AM Janos Farkas <[e-mail]>
wrote:

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