Subject: [Actn] Comments on draft-ceccarelli-actn-framework-04

From: Dave Hood <[email-masked]>
Date: Tue, 21 Oct 2014 22:44:09 +0000

I shared several comments on the new draft with the editors, but a few of them are more than editorial, so I'm posting them for wider discussion.

Operators have been trying to break silos for decades. It is okay to specialize the SDN architecture into a unique transport view, but we ought not create separate concepts, interfaces, or terminology unless there are strong justifications to depart from other domains. We should make best efforts to integrate transport SDN views seamlessly into the rest of the SDN space. We do not want to re-create silos in the SDN world.

Having said that, it is of course always the operator's option to deploy SDN in separate technology silos according to its own practices. The architecture is general, but can be specialized in any number of particular ways.

An example of specialization is the proposed 3-tier model, in which hierarchy or recursion appears to be restricted to the VNC layer. Architecturally, stacking is valid in any layer, and even the layer classification is to some extent pragmatic for each given instance. In the transport network, suppose we have a PNC, some of whose endpoints are tunneled ports provided by a yet lower layer of SDN. In such a case, the same controller would act as a PNC toward some of its resources, and a VNC toward others. (Necessarily VNC because I'm told offline that only a VNC can span admin domains.) These distinctions do not seem like a useful rathole to enter. The controllers at different levels differ in granularity and scope, but not in fundamentals; better just to call them all SDN controllers.

The framework suggests that the PCE lives in the PNC. Even if we assume a single well-defined PNC layer, this denies the more abstract layers the ability to compute paths in their virtual networks. Note that paths in VNs are constrained by the VN definition, and the PNC PCE has no way of knowing what those constraints are. This is especially true if the VN is exported across a business boundary to a customer whose VN may be complex enough to justify its own PCE. I believe PCE is intended to be available at multiple levels of virtualization: let it be available to anyone who needs it.

Arguably the major issue with the draft is that it does not recognize the importance of the manager actor in the provider-customer relationship. The SDN architecture explains that the provider's manager is necessarily responsible for creating a virtual network environment for the customer and for installing policy in its SDN controller (at whatever hierarchical level) to both protect the customer from other customers (privacy and QoS) and to protect the provider's own resources from customer misbehaviour, whether intentional or otherwise. In particular, the draft refers to the customer app creating VNs, whereas a customer cannot be trusted to create its own VN except perhaps as a mere subnet of the "real" VN created under the auspices of a business negotiation by the provider's manager. (And yes, the SDN architecture also describes how all of this can be done flexibly, for example if the customer invokes a service provisioning portal with credentials that permit billing.)

Completeness, common concepts, interfaces and terminology could all be facilitated by starting with the umbrella SDN architecture available at https://www.opennetworking.org/images/stories/downloads/sdn-resources/technical-reports/TR_SDN_ARCH_1.0_06062014.pdf, and then specializing it.

Dave

---

From: Leeyoung <[email-masked]>
Date: Thu, 23 Oct 2014 02:33:52 +0000

Hi Dave,

Thanks for providing your perspective. Please see in-line for my comment.

Best regards,
Young

From: ACTN [mailto:[email-masked]] On Behalf Of Dave Hood
Sent: Tuesday, October 21, 2014 5:44 PM
To: [email-masked]
Subject: [Actn] Comments on draft-ceccarelli-actn-framework-04

YOUNG>> I think you are talking about SDN from a green field perspective. T-SDN could mean different things to different set of people including different SDOs. It seems to me that you are prescribing ONF SDN view as the basis of discussion here. I respect ONF view, especially your SDN architecture document produced mid this year. On the other hand, there are different views of what T-SDN means in other parts of the world. Therefore I think it would be a bit over bearing to demand other views to be subjected to one view.

YOUNG>> Agree. Operators want to build on top of what they have deployed while pursuing new green field. One of the drivers for ACTN is to enable legacy control/management domains while allowing new domain control like ONF SDN (openflow) control.

YOUNG>> I think there was a misunderstanding. In your particular example, if a PNC is in charge of some networks, say, it is GMPLS/PCE. There may be another hierarchy below that PNC. PNC may have several domains in itself and indeed that PNC might function as a multi-domain coordination underneath its control domain. So here we are not restricting what PNC does in its network control. This does not simply need not be known to what is above the PNC. Each PNC represents a control of some network comprising an end to end network. It can be a single domain control or control multi domain. SDN controller is one of the PNC in ACTN architecture. There may be other controllers such as GMPLS/PCE, PNNI. ASON, etc. including NMS/EMS based control.

YOUNG>> Actually there is always PCE function in each of CNC, VNC and PNC. Perhaps, there needs more clarification in the document. We used PCE means to what PCE does in TE network control (as part of PNC), but in VNC we have resource manager (which needs to compute paths based on virtual networks), likewise CNC where customers want to compute their paths within the confines of VNs allocated to them.

YOUNG>> Good point. This is one of the areas where ACTN needs to work on more. Your contribution is welcome for this.

YOUNG>> Good reference, I have to say, which the latest version included as one of the references.

Dave

---

From: Daniele Ceccarelli <[email-masked]>
Date: Thu, 23 Oct 2014 08:14:24 +0000

Hi Dave,

Adding some further comments in line.

Thank a lot for the detailed review, much appreciated.

BR
Daniele

From: ACTN [mailto:[email-masked]] On Behalf Of Dave Hood
Sent: mercoledì 22 ottobre 2014 00:44
To: [email-masked]
Subject: [Actn] Comments on draft-ceccarelli-actn-framework-04

Operators have been trying to break silos for decades. It is okay to specialize the SDN architecture into a unique transport view, but we ought not create separate concepts, interfaces, or terminology unless there are strong justifications to depart from other domains. We should make best efforts to integrate transport SDN views seamlessly into the rest of the SDN space. We do not want to re-create silos in the SDN world.
[[DanCe]] I think what is missing here is that ACTN is not only SDN...it is also SDN. I start to think that the PNC term is misleading. The PNC is not necessarily an SDN controller, it is "something" that controls a network, it can be an SDN controller, can be an NMS, can be a PCE+ on top of a GMPLS network. The idea is to use the VNC as the enabler to put all of these silos together. I fully agree that the idea of the SDN is to break the silos, but in my opinion the goal of ACTN is the one of take the existing silos and make them interwork.

An example of specialization is the proposed 3-tier model, in which hierarchy or recursion appears to be restricted to the VNC layer. Architecturally, stacking is valid in any layer, and even the layer classification is to some extent pragmatic for each given instance. In the transport network, suppose we have a PNC, some of whose endpoints are tunneled ports provided by a yet lower layer of SDN. In such a case, the same controller would act as a PNC toward some of its resources, and a VNC toward others. (Necessarily VNC because I'm told offline that only a VNC can span admin domains.) These distinctions do not seem like a useful rathole to enter. The controllers at different levels differ in granularity and scope, but not in fundamentals; better just to call them all SDN controllers.
[[DanCe]] there is parallel thread on that and we'll see the different approaches being presented and discussed at the BoF. It will be interesting. Per my previous comment I see the recursion between VNCs as the PNC could or could not be an SDN controller. Maybe you could argue that in case the PNC is an SDN controller it is not different from the VNC. The other thread on the list regards interfaces (whether interfaces B and C are the same of different ones). I think sorting that out could also help understand what are the differences between the PNC SDN controller and the VNC...if any.

Regarding domain boundaries I think the definition of boundary includes all the nodes under the control of the same PNC (I could be also multiple GMPLS domains, but all of them controlled by the same PNC). This is based on the assumption that  a node can't be under the control of multiple PNC. It is a strong assumption but I think reasonable, isn't it?

The framework suggests that the PCE lives in the PNC. Even if we assume a single well-defined PNC layer, this denies the more abstract layers the ability to compute paths in their virtual networks. Note that paths in VNs are constrained by the VN definition, and the PNC PCE has no way of knowing what those constraints are. This is especially true if the VN is exported across a business boundary to a customer whose VN may be complex enough to justify its own PCE. I believe PCE is intended to be available at multiple levels of virtualization: let it be available to anyone who needs it.
[[DanCe]]IMHO there is one PCE at PNC layer and a PCE at VNC layer. I've always assumed the PCE inside the SDN controller but it is correct to assume that is could also be outside. I see this architecture much alike the H-PCE one.

Arguably the major issue with the draft is that it does not recognize the importance of the manager actor in the provider-customer relationship. The SDN architecture explains that the provider's manager is necessarily responsible for creating a virtual network environment for the customer and for installing policy in its SDN controller (at whatever hierarchical level) to both protect the customer from other customers (privacy and QoS) and to protect the provider's own resources from customer misbehaviour, whether intentional or otherwise. In particular, the draft refers to the customer app creating VNs, whereas a customer cannot be trusted to create its own VN except perhaps as a mere subnet of the "real" VN created under the auspices of a business negotiation by the provider's manager. (And yes, the SDN architecture also describes how all of this can be done flexibly, for example if the customer invokes a service provisioning portal with credentials that permit billing.)
[[DanCe]] This is what is assumed to be done by the VNC proxy in both the PNC and VNC. We can rename it manger to get aligned with the ONF-ARCH.

Dave

---

From: Dave Hood <[email-masked]>
Date: Thu, 23 Oct 2014 15:14:29 +0000

Thanks, Young. A couple of responses:

The suggested SDN architecture that was developed in ONF includes the possibility that layers at either the top or bottom of the stack can be non-SDN environments. An EMS or an NMS could equally support a classical environment, supporting SDN interfaces on their north sides. Incremental deployment is certainly necessary, no question about it.

As to the ONF SDN architecture suggestion, be clear that there is no question of demanding that anyone accept any particular input. The point was to call attention to existing work that can help avoid reinvention of wheels, to the purpose of adding new value to the discussion.

Dave

From: Leeyoung [mailto:[email-masked]]
Sent: Wednesday, October 22, 2014 7:34 PM
To: Dave Hood; [email-masked]
Subject: RE: Comments on draft-ceccarelli-actn-framework-04

Hi Dave,

Best regards,
Young

From: ACTN [mailto:[email-masked]] On Behalf Of Dave Hood
Sent: Tuesday, October 21, 2014 5:44 PM
To: [email-masked]<mailto:[email-masked]>
Subject: [Actn] Comments on draft-ceccarelli-actn-framework-04

Dave

---

From: Leeyoung <[email-masked]>
Date: Fri, 24 Oct 2014 15:57:48 +0000

Hi Dave,

Thanks for your further comments. I found this thread very helpful to clarify different perspectives and some misunderstanding.

The three-tier control hierarchy discussed in the ACTN framework is "zooming" on the relationships across three entities (CNC, VNC, PNC). This does not necessarily limit that is above and below these entities. There may be other hierarchy especially under PNCs. From this, I see neither contradiction with nor reinventing the wheel of the notion of  "recursive" relationships among the controllers, which is one of the main points in your SDN architecture document. We used the term "hierarchy" (instead of "recursion") noting that there is a certain recursive nature in modeling abstraction while specifying some functional differences among the three-tier controllers.

Your SDN architecture specifies a PCE function in each control layer, which is also very consistent with ACTN framework. We might need further terminology alignment to avoid misunderstanding.

In regards to controller name, as Daniele suggested we are open to rename them if necessary. Igor has some idea as well on this. CNC, VNC and PNC are tied with some control functions. We can continue to work on this. Perhaps for IETF 91, we would stay with these terms and later if the work is warranted, we can revisit this issue.

Please see inline for my responses.

Thanks,
Young

From: Dave Hood [mailto:[email-masked]]
Sent: Thursday, October 23, 2014 10:14 AM
To: Leeyoung; [email-masked]
Subject: RE: Comments on draft-ceccarelli-actn-framework-04

YOUNG>> Yes, this is important. In ACTN, we regard NMS/EMS as the domain control/management entity and with an added function to support "interface C", NMS/EMS can be empowered to participate in virtualization regime. 80% of transport networks are controlled/managed by NMS/EMS today and enabling them with network virtualization layer/function is one of the key requirements from operators.

YOUNG>> Thanks for this clarification. I think ACTN can complement ONF SDN architecture. I think by now many issues we discussed (e.g., hierarchy vs. recursiveness; pce function in each control layer, etc) are more or less aligned rather than being contradictory or re-inventing.

Dave

Hi Dave,

Best regards,
Young

Dave

---

From: Dave Hood <[email-masked]>
Date: Fri, 24 Oct 2014 16:18:22 +0000

Thanks, Young. Try the following proposal to see if it aligns our perspectives:

For either hierarchy or recursion, as used here, we need each successive layer to be fundamentally of the same type as the one above/below it, likewise for the interfaces. That's why the SDN architecture calls all of them SDN controllers, and all of the interfaces CPIs (controller plane interfaces).

I think we can align our views by introducing roles. The SDN architecture imagines that we take the perspective of some given SDN controller, from which we see a (virtual) data plane to our south and a (virtual) applications plane to our north.

>From the discussion on this thread, I think the ACTN framework steps outside one particular SDN controller, and instead stands on the boundary between a pair of adjacent SDN controllers, one of which plays the role PNC, the other of which plays the role VNC. If we think of it as a boundary or an interface view, we have reduced visibility, maybe no visibility, of what happens further down or further up. We already omit discussion of applications north of the VNC; would it make sense to minimize the discussion of physical functions further south of the PNC?

After all, if we really insist that the PNC talk to iron, we necessarily care about boxes and circuit packs, redundant cooling shelves and power feeds, hardware failure and repair, software upgrade.... If these are out of scope for ACTN, and I believe they are, then we shouldn't really care whether there is iron down there or a virtual network.

What do you think?
Dave

From: Leeyoung [mailto:[email-masked]]
Sent: Friday, October 24, 2014 8:58 AM
To: Dave Hood; [email-masked]
Subject: RE: Comments on draft-ceccarelli-actn-framework-04

Hi Dave,

Thanks,
Young

From: Dave Hood [mailto:[email-masked]]
Sent: Thursday, October 23, 2014 10:14 AM
To: Leeyoung; [email-masked]<mailto:[email-masked]>
Subject: RE: Comments on draft-ceccarelli-actn-framework-04

Dave

From: Leeyoung [mailto:[email-masked]]
Sent: Wednesday, October 22, 2014 7:34 PM
To: Dave Hood; [email-masked]<mailto:[email-masked]>
Subject: RE: Comments on draft-ceccarelli-actn-framework-04

Hi Dave,

Best regards,
Young

Dave

---

From: Igor Bryskin <[email-masked]>
Date: Fri, 24 Oct 2014 17:38:05 +0000

Hi Dave,

I completely agree with you on the requirement that from the hierarchical SDN point of view each provider layer must be fundamentally the same as its client layer, so that the client can serve its own clients, and the server can be a client of its own providers, etc.
With this in mind would you agree with me that there is no fundamental difference between the VNC and PNC, and between the interfaces B and C in the current ACTN architecture?

Thanks,
Igor

From: ACTN [mailto:[email-masked]] On Behalf Of Dave Hood
Sent: Friday, October 24, 2014 12:18 PM
To: Leeyoung; [email-masked]
Subject: Re: [Actn] Comments on draft-ceccarelli-actn-framework-04

What do you think?
Dave

Hi Dave,

Thanks,
Young

Dave

Hi Dave,

Best regards,
Young

Dave

---

From: Dave Hood <[email-masked]>
Date: Fri, 24 Oct 2014 17:40:11 +0000

Yes, I would, Igor. They differ in granularity, probably in security considerations, but not fundamentally.

Thanks,
Dave

From: Igor Bryskin [mailto:[email-masked]]
Sent: Friday, October 24, 2014 10:38 AM
To: Dave Hood; Leeyoung; [email-masked]
Subject: RE: Comments on draft-ceccarelli-actn-framework-04

Hi Dave,

Thanks,
Igor

What do you think?
Dave

Hi Dave,

Thanks,
Young

Dave

Hi Dave,

Best regards,
Young

Dave

---

From: Leeyoung <[email-masked]>
Date: Fri, 24 Oct 2014 19:07:33 +0000

Hi Dave,

Thanks. I think we are getting there.

Please see inline for my comment. This is my personal view and other folks (especially the co-authors of the framework draft) may address their views.

Thanks,
Young

From: Dave Hood [mailto:[email-masked]]
Sent: Friday, October 24, 2014 11:18 AM
To: Leeyoung; [email-masked]
Subject: RE: Comments on draft-ceccarelli-actn-framework-04

YOUNG>> I agree with you on this in principle, but with a caveat that when we associate roles/functions with the type of controller, there are differences we begin to observe. I think devil are in the details. As I elaborated before and also in the later point, there are two main functions that need to be performed by VNC: (i) virtualizer; (ii) multi-domain coordination/orchestration. For (i), we can agree that the hierarchy of controllers (CNC, VNC, PNC) all share this in different degrees. For (ii), if we were to assume this would happen in VNC, then this particular role has to be defined which is different than virtualizer function. If we can agree on this, that is great.

>From the discussion on this thread, I think the ACTN framework steps outside one particular SDN controller, and instead stands on the boundary between a pair of adjacent SDN controllers, one of whic…

YOUNG>> Yes, we are only considering an interface view between VNC and PNC. We concerns not what PNC does for its domain technology control. I can envision the following needs to be supported in this interface so that the VNC would perform the following (Interface C in the current framework).

i.                     Creating an end-to-end virtual network topology based on the feed of each domain controllers input south of the VNC (i.e., PNCs).

ii.                   It computes an end-to-end path (virtual path)

iii.                 It signals to each domain controller (PNCs) and there might be some signaling interaction (e.g., likes of crankbacks to reroute due to network condition changes associated with domain networks)

YOUNG>> I agree.  What "PNC" does underneath (interface D) is out of the scope of ACTN, this includes GMPLS/PCE, PNNI, OF, Qx, Netconf, SNMP, etc, or anything else.  Only thing in scope is the interface between PNC and VNC (and interface CNC and VNC, which I still think a difference interface from PNC-VNC interface although sharing some "virtualizer" functionality) and the protocols on those interfaces, which is TDB by the solution works down the road. Is this what you are saying, then we are in agreement on this point.

What do you think?
Dave

Hi Dave,

Thanks,
Young

Dave

Hi Dave,

Best regards,
Young

Dave

---

From: Igor Bryskin <[email-masked]>
Date: Fri, 24 Oct 2014 19:54:22 +0000

Hi Young,
Consider the following use case: a provider of abstract topology (PNC as you call) does it the following way:

a)     For a part of said topology (a subset of abstract nodes and links) it provides underlay directly, that is, talks to the actual network control (NMS, Control Plane, PCE, etc.)

b)     For another part it uses abstract topologies presented by its own child domain providers

In this case, when a segment of service is provisioned over the domain owned by said PNC, it will have to perform both the PNC function and the VNC multi-domain coordination for the child domains. Note that such situation can recur at each level of the transport SDN hierarchy.
This is just another indication as to why there is no difference between VNV and PNC.

Cheers,
Igor

From: ACTN [mailto:[email-masked]] On Behalf Of Leeyoung
Sent: Friday, October 24, 2014 3:08 PM
To: Dave Hood; [email-masked]
Subject: Re: [Actn] Comments on draft-ceccarelli-actn-framework-04

Hi Dave,

Thanks,
Young

What do you think?
Dave

Hi Dave,

Thanks,
Young

Dave

Hi Dave,

Best regards,
Young

Dave

---

From: Leeyoung <[email-masked]>
Date: Fri, 24 Oct 2014 20:16:09 +0000

Hi Igor,

I would say we need to associate the role of the controller. I can see from your example multi-domain coordination (let say the function is called 'md') can take place either VNC or PNC, or both.

-          If we were to place the 'md' funtion at VNC (which is a typical case in the framework), we need to say it as VNC-md;

-          if we were to place this at PNC (in your example), we need to say the PNC has two roles: for the direct controlled network control, it is PNC; for child VNs' control, it is VNC-md.

I think as Dave suggested, once we attach the role of the controller with its name, then things begin to shed more light.

Regards,
Young

From: Igor Bryskin [mailto:[email-masked]]
Sent: Friday, October 24, 2014 2:54 PM
To: Leeyoung; Dave Hood; [email-masked]
Subject: RE: Comments on draft-ceccarelli-actn-framework-04

Hi Young,

Cheers,
Igor

Hi Dave,

Thanks,
Young

What do you think?
Dave

Hi Dave,

Thanks,
Young

Dave

Hi Dave,

Best regards,
Young

Dave

---

From: Dave Hood <[email-masked]>
Date: Fri, 24 Oct 2014 20:42:05 +0000

Well, yes, we can multiply the granularity of the designations as much as we care to; the question is whether it is productive.

In a previous exchange, I pointed out that domain is not well-defined; I believe you use the term in the sense of network ownership/control. In that sense, I agree that the final lowest controller before the iron needs to be in the same admin domain as the iron itself. But the SDN architecture just regards same-domain as a special case of multi-domain.

Dave

From: Leeyoung [mailto:[email-masked]]
Sent: Friday, October 24, 2014 1:16 PM
To: Igor Bryskin; Dave Hood; [email-masked]
Subject: RE: Comments on draft-ceccarelli-actn-framework-04

Hi Igor,

Regards,
Young

From: Igor Bryskin [mailto:[email-masked]]
Sent: Friday, October 24, 2014 2:54 PM
To: Leeyoung; Dave Hood; [email-masked]<mailto:[email-masked]>
Subject: RE: Comments on draft-ceccarelli-actn-framework-04

Hi Young,

Cheers,
Igor

Hi Dave,

Thanks,
Young

What do you think?
Dave

Hi Dave,

Thanks,
Young

Dave

Hi Dave,

Best regards,
Young

Dave

---

From: Leeyoung <[email-masked]>
Date: Fri, 24 Oct 2014 20:54:56 +0000

Hi Dave,

Thanks for your time to iron out many items in this thread.  Well, I think we have reached an agreement. We can always start with a base model to produce something useful quickly, then think about variations later.

It looks  like terms need to be defined more clearly like domain, physical control, virtual control, multi-domain coordination, etc.

Thanks,
Young

From: Dave Hood [mailto:[email-masked]]
Sent: Friday, October 24, 2014 3:42 PM
To: Leeyoung; Igor Bryskin; [email-masked]
Subject: RE: Comments on draft-ceccarelli-actn-framework-04

Dave

Hi Igor,

Regards,
Young

Hi Young,

Cheers,
Igor

Hi Dave,

Thanks,
Young

What do you think?
Dave

Hi Dave,

Thanks,
Young

Dave

Hi Dave,

Best regards,
Young

Dave