Subject: Re: [Actn] ACTN architecture

From: Daniele Ceccarelli <[email-masked]>
Date: Wed, 1 Oct 2014 12:57:54 +0000

Hi Dhruv, Young,
Trying to keep the reply as simple as possible:

>[Dhruv 3]: I completely agree with you on this point. And thus prefer if we do not dwell much on Daniele Case b, hierarchy among the PNC and PNC-PNC interface being out of scope and focus of ACTN.

Ok, it makes sense.

>[Dhruv 3]: we have not used the term 'multi-domain coordinator' in the draft-ceccarelli-actn-framework-03; but we use it in charter text, perhaps we can relook into this.

Yep, we need to fix that.

Thanks
Daniele

From: Dhruv Dhody [mailto:[email-masked]]
Sent: lunedì 29 settembre 2014 07:05
To: Leeyoung; Daniele Ceccarelli; [email-masked]
Subject: RE: ACTN architecture

Hi Young,

Thanks for the update to http://datatracker.ietf.org/doc/draft-ceccarelli-actn-framework/
I will send my comments on the update in a separate thread... Rest inline with tag [Dhruv 3]

(snip)

Reposting my architecture considerations and Young's replies in a dedicated thread.

1.      On multidomain issues: One question here: How do we want to manage multi-domain? I see two ways:

a.      A coordinator of virtual network controllers - i.e. 1:1 relationship between virtual network controller and physical network controller plus a coordinator of virtual network controllers on top

b.      A coordinator of physical network controllers - i.e. a coordinator of physical network controllers (1:N relationship between coordinator and PNCs) with a virtual network controller on top? (1:1 relationship between PNC coordinator and the VNC)

Maybe we should consider both architectures, maybe pick one.

YOUNG>> These options seem to be detailed architecture that the upcoming architecture document should address in detail. My personal opinion is that both architectures need to be considered as a starting point. There may be other variations. Then we may narrow the scope as an initial baseline architecture.
[[DanCe]] Agree. Let's keep track of both of them.
[Dhruv]: In the current architecture document we do not use the term 'coordinator';
In the charter it says - "Multi-domain network coordination function in ACTN is built on a control hierarchy where a multi-domain coordinator interacts with each domain controller (e.g., EMS/NMS, GMPLS/PCE control plane, SDN controller) for abstracting network resource information to provide virtual network control functions. This virtual network control functions are embedded in a multi-domain network coordinator to support various services/clients/applications to create and manage their own virtual networks that share the common transport network resources."
To me this reads as the coordinator and virtual network control function are embedded together. If we feel that multiple options are okay and need to be studied, we should relax the text in the charter.

YOUNG>> I think VNC-PNC construct is the main architecture interface of ACTN. Although Architecture document is being prepared, the current assumption is that PNC has a minimum module as proxy to communicate with VNC. When VNC deals with multi-domain networks, multi-domain coordination function arises within the VNC.  I think this is case a (Per Daniele). The coordinator VNC has to deal with multiple VNCs or PNCs with VN proxy function.
[Dhruv 2]:  In my opinion what Daniele suggest is more like -
Daniele Case a:

                 Virtual network Coordinator
                              |
                              |
                 -------------+------------
                |             |            |
                |             |            |
               VNC           VNC          VNC
                |             |            |
                |             |            |
               PNC           PNC          PNC

Daniele Case b:
                             VNC
                              |
                              |
                 Physical network Coordinator
                              |
                              |
                 -------------+------------
                |             |            |
                |             |            |
               PNC           PNC          PNC

Here the key difference is - 'multi-domain coordinator function' to be engaging with VNCs or PNCs in the southbound.

YOUNG 2> Yes. Agree.

>From your description I gather that the 'multi-domain coordinator function' can interact with multiple VNC (case a) or interact with multiple PNC (case b) which I also think is valid.
Making this look like....
                    Multi-domain Coordinator (parent
                              |               -VNC)
                              |
                 -------------+------------
                |             |            |
                |             |            |
               VNC           VNC          VNC
                |             |            |
                |             |            |
               PNC           PNC          PNC

  YOUNG 2> This above diagram is basically the same as Daniele's Case a.

                             VNC
                              | (probably embedded
                              |  together)
                   Multi-domain Coordinator
                              |
                              |
                 -------------+------------
                |             |            |
                |             |            |
                 PNC          PNC          PNC

     YOUNG 2>  This is very close to Daniele's Case b except the 'Multi-domain coordinator' is not explicitly defined as Physical Network Coordinator.  In the charter description, we embedded the multi-domain coordination function as part of VNC. Here VNC and MD coordinator can be decoupled as another possibility.  The above diagram is different from Daniele's Case b if we assume the interface between PNCs and the MD coordinator is of physical nature or of virtual nature. If this is of physical nature, then this interface may be slightly different from VNC-PNC interface (which we called VPI for Case a. This is a PNC-PNC interface in a hierarchical fashion, for the lack of a better term PPI interface.  What is the difference between VNC-PNC and PNC-PNC interfaces? Since we are dealing with virtualization as the main charter item, I would prefer to focus on VNC-PNC construct as Case a and also for Case b if we were to interpret the interface between MD Coordinator and PNCs is of virtual nature.

[Dhruv 3]: I completely agree with you on this point. And thus prefer if we do not dwell much on Daniele Case b, hierarchy among the PNC and PNC-PNC interface being out of scope and focus of ACTN.

For case b (per Daniele), I think we are only concerned about VNC-PNC (as 1:1) while how the PNC coordinator deals with its domain PNC controller is out of scope of ACTN work in  my view.  In this case, we are only dealing with the VNC with the PNC coordinator.  Multi-domain coordination is "delegated" to the PNC level.
[Dhruv 2]: I am not sure what you mean here?

YOUNG 2>  Please see my above comment.

So I think your point is that the current charter is more or less case a's perspective.  But I think case a is the base-line case to which ACTN work should be focused on. Case b is subset of case a.

I am not to sure

The charter text thus seems more closely related to case (b) where a multi-domain coordinator interacts with domain controllers (PNC) and this function resides with virtual network control function.
[Dhruv 2]: Yes.
 YOUNG 2>   Yes, with an understanding that the [VNC+MD Coordinator] is interfacing with PNCs in a virtual manner.

[Dhruv 3]: we have not used the term 'multi-domain coordinator' in the draft-ceccarelli-actn-framework-03; but we use it in charter text, perhaps we can relook into this.

Again on multidomain: maybe we could improve the architecture draft saying is centralized and what is distributed. E.g. VPN prefixes exchange could be distributed (controllers speaking MP-BGP with each other) while provisioning could be hierarchical (i.e. the coordinator asks controller A to provision a path with domain A and asks controller B to provide a path within B so to have an end to end path crossing domains A and B)...H-PCE like.

YOUNG>> Good point. I agree that the architecture draft should discuss these dichotomy of control regimes (e.g., centralized vs. distributed). One question I have: are you assuming the coordinator also speaks MP-BGP with lower level PN controllers? If not, would the coordinator need to collect the VPN prefixes using the interface between the coordinator and each PNC (that speaks MP-BGP)? Then can this be viewed as a centralized component?
[[DanCe]] The scenarios that come to my mind are more "horizontal". I would say the either the nodes speak MP-BGP with each other across the domains  (in case of distributed protocols) or the controllers gets the information from its own domain and then speak MP-BGP with the other controllers "on behalf of their domains"

[Dhruv]: I feel this is highly dependent on the physical network controllers, if its a PCE it has its own way to do inter-PCE communication and if the controller runs BGP  it may directly interact with other controller. IMHO the ACTN architecture should not impose any restriction on this interaction, nor make it a pre-requisite as in some case the two controller may not be able to interact with each other directly (different technology, vendor specific NMS etc).

YOUNG>> I agree with you on this.

Regards,
Dhruv