Subject: [Actn] draft-ceccarelli-actn-framework-03.txt comments

From: "BELOTTI, SERGIO (SERGIO)" <[email-masked]>
Date: Wed, 8 Oct 2014 12:33:45 +0000

Hi Daniele , Young and all authors,

I read you Framework draft and I have some comments on that. Most are editorial , other questions for clarifications.

General question: in the draft the concept of VNC is in the view of hierarchical level of controllers or linked to the multi-domain aspect that compel to provide to the customer a single virtualized network even if composed by real multi-domain multi-technology subnetworks? I mean, the "virtualizer function" provided by VNC, in case of a single domain context could be inside directly the PNC , correct?

Section 2 , page 4:
abstraction does not imply automatically virtualization,while virtualization implies to have surely a certain form of abstraction. I would suggest to consider good definition contained into ONF SDN architecture document chapter 2.3 Conventions about abstraction and virtualization. A good definition can help all the reading.

Section 5: It seems to me you mixed here aspects that are more related to policy like admission control  and guarantee of client isolation with real computational issue like Computing time , path constrains or re-optimization process. Moreover the term VNM for Virtual network mapping is a bit misleading since this term in already used e.g. in ABNO architecture for Virtual Network Manager

Section 6.1 : while it is clear the scope of the different control interface presented in figure 5, I'm a bit confused as to what I/F E is - data plane interface to provider physical network? Or is the intention to provide what can be the underlying model of resources allocated to a customer from network provider controller, and the mapping to real physical resources ? Nor clear to me the intention

Section 6.1, always figure 5: If a report of potential NW topology between a VNC and a CNC can be queried , the arrow in the drawn has to be bidirectional I guess

Figure 8 Section 6.4,page 28: "PCA abstracts the physical network topology into an abstracted topology" Looking at the description of VNC components in 6.2.2 it is the resource manager devoting to provide abstract topology. Does not exist any PCA component.

Figure 8 SEction 6.4, : In the picture there is no phase 7, and there are 2 phase 8

Page 30 : It is Interface C not B , between VNC and PNC

Thanks

Sergio

---

From: Leeyoung <[email-masked]>
Date: Wed, 8 Oct 2014 15:34:34 +0000

Hi Sergio,

Thanks for your feedback on the framework document. Please see in-line for my comment.

Regards,
Young

From: BELOTTI, SERGIO (SERGIO) [mailto:[email-masked]]
Sent: Wednesday, October 08, 2014 7:34 AM
To: [email-masked]; Daniele Ceccarelli; Leeyoung; [email-masked]; [email-masked]
Cc: BELOTTI, SERGIO (SERGIO); Varma, Eve L (Eve)
Subject: draft-ceccarelli-actn-framework-03.txt comments

YOUNG>> Yes. That is the correct view of VNC. For a single domain context, the VNC can be integrated with PNC. But we need to factor in other scenarios such as 1) VNC vendor may be different from PNC vendor or 2) VNC is a software function that operator may want to operate as its control. In my opinion, even for a single domain, I think there is benefit to define this interface as a standard interface.

Section 2 , page 4:

YOUNG>> Agree. We will look into the mentioned document if the usage of terms are aligned with this document. If not, we will clarify the terminology more clearly.

Section 5: It seems to me you mixed here aspects that are more related to policy like admission control  and guarantee of client isolation with real computational issue like Computing time , path constrains or re-optimization process. Moreover the term VNM for Virtual network mapping is a bit misleading since this term in already used e.g. in ABNO architecture for Virtual Network Manager.

YOUNG>> Indeed. In Section 5, we will put some notes on the aspect of real-time related from non real time aspect. VNM is not to be mixed with Virtual Network Manager. Here VNM is an algorithm which is known as Virtual Network Mapping which is a software module that converts client requests into actual networks. Virtual Network Manager is ABNO in my understanding is a developed concept from VNTM. But Dan King and I will look at this more carefully on this aspect what Virtual Network Manager is doing.

YOUNG>> Interface E is not what ACTN will focus on. It simply shows  an underlying model of resources allocated to a customer from network provider controller, and the mapping to real physical resources.

YOUNG>> Yes, You are right. It will be fixed.

YOUNG>> Sorry for inconsistency. The intention was the PCA is the same as the Resource Manager in VNC. Will make the term consistent. Good catch!

YOUNG>> Thanks. Good catch!

YOUNG>> If you are referring to Section 7.3 where:

   Interfaces should also be scalable as a large amount of data needs

   to be transported across customers to virtual network controllers

   and across virtual network controllers and physical network

   controllers.

I think this implies both interfaces B and C although primarily between VNC-PNC.

Thanks

Sergio

---

From: "BELOTTI, SERGIO (SERGIO)" <[email-masked]>
Date: Thu, 9 Oct 2014 09:58:48 +0000

Hi Young,

thanks a lot for reply , please see in line just some further clarification

Regards
Sergio

From: Leeyoung [mailto:[email-masked]]
Sent: mercoledì 8 ottobre 2014 17:35
To: BELOTTI, SERGIO (SERGIO); [email-masked]; Daniele Ceccarelli; [email-masked]; [email-masked]
Cc: Varma, Eve L (Eve)
Subject: RE: draft-ceccarelli-actn-framework-03.txt comments

Hi Sergio,

Regards,
Young

To: [email-masked]<mailto:[email-masked]>; Daniele Ceccarelli; Leeyoung; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>

Section 2 , page 4:

SB>>> If I understood form Adrian and Daniel ABNO draft the concept, VNTM is strictly related to planning function so I this it is very import point in the context of PNC , I would say

SB>>> So if I interpreted correctly your answer is more an internal interface to PNC , the figure is misleading since it seems like a DP interface .

   controllers.

SB>>> Sorry Young, iit is not referred to 7.3 , but in the chapter 6,5 , on Interface interaction, after point 6, is indicated Interface B as interface between VNC and PNC, figure 5 says it is I/F C

Thanks

Sergio

Thanks
Sergio

---

From: Leeyoung <[email-masked]>
Date: Thu, 9 Oct 2014 12:47:30 +0000

Hi Sergio,

Thank you also for providing more comments. Please see in-line for my comment with YOUNG 2>>

Regards,
Young

From: BELOTTI, SERGIO (SERGIO) [mailto:[email-masked]]
Sent: Thursday, October 09, 2014 4:59 AM
To: Leeyoung; [email-masked]; Daniele Ceccarelli; [email-masked]; [email-masked]
Cc: Varma, Eve L (Eve); BELOTTI, SERGIO (SERGIO)
Subject: RE: draft-ceccarelli-actn-framework-03.txt comments

Hi Young,

Regards
Sergio

Hi Sergio,

Regards,
Young

Section 2 , page 4:

YOUNG2>> OK. I think you meant VNTM is a management entity (off-line).

YOUNG2>> I am sorry for the confusion. It is actually a mapping from virtual network to physical network, which I think a DP interface.

   controllers.

YOUNG2>> Yes, you are right. It was a typo. Will correct.

Thanks

Sergio

Thanks
Sergio

---

From: Igor Bryskin <[email-masked]>
Date: Thu, 9 Oct 2014 18:47:56 +0000

Hi Young,

I believe having the same instance of VNC talking to different vendor domain PNCs is an extremely  idealistic view.

====> BTW I find PNC is a bad term, I like much better Actual Network Controller  (ANC). VNC (a.k.a. a Hypervisor) is managing abstract topologies, and to be able do that, it talks to a ANC- a controller which has an access and manages actual provider network).

One reason for this is that VNC needs to understand underlying actual topology, for example, to ensure that two abstract TE links are SRLG disjoint as requested. Actual topology semantics (especially in WDM layer) is very different from vendor to vendor and contains a great variety of proprietary extensions, failing to understand which leads to producing unprovisionable service paths. Do you really believe that a single VNC can talk in the same way to ADVA, INFN, ALU and Huawei ANCs? This is equivalent to ask all optical providers to switch to WSON :=).

This is not to say that you cannot build a hierarchy of VNCs, but in this case North VNC plays role of a client network controller wrt to South VNC, that is, uses the same X interface.
IHMO whenever a VNC has to talk to a ANC, it does so in a proprietary way, i.e. ADVA, INFN, ALU and Huawei will have their own VNCs exposing the same north bound interface to potentially the same client (e.g.TFK).
IHMO interface X is the only interface that the ACTN can work on.

Cheers,
Igor

From: ACTN [mailto:[email-masked]] On Behalf Of BELOTTI, SERGIO (SERGIO)
Sent: Thursday, October 09, 2014 5:59 AM
To: Leeyoung; [email-masked]; Daniele Ceccarelli; [email-masked]; [email-masked]
Cc: BELOTTI, SERGIO (SERGIO); Varma, Eve L (Eve)
Subject: Re: [Actn] draft-ceccarelli-actn-framework-03.txt comments

Hi Young,

Regards
Sergio

Hi Sergio,

Regards,
Young

Section 2 , page 4:

   controllers.

Thanks

Sergio

Thanks
Sergio

---

From: "Doolan, Paul (Coriant - US/Irving)" <[email-masked]>
Date: Thu, 9 Oct 2014 19:20:39 +0000

Hello Igor,

Because I agree wholeheartedly with the sentiments expressed in your 4th para I'll ignore your omission of Coriant in the one above it;-)

I think you nicely capture the practical realities of the matter at the optical layer and I've heard similar views expressed in other places as well. I hope some of those people will add to this conversation.

thanks,
pd

On Oct 9, 2014, at 2:47 PM, Igor Bryskin <[email-masked]<mailto:[email-masked]>>
 wrote:

Hi Young,

Cheers,
Igor

From: ACTN [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of BELOTTI, SERGIO (SERGIO)
Sent: Thursday, October 09, 2014 5:59 AM
To: Leeyoung; [email-masked]<mailto:[email-masked]>; Daniele Ceccarelli; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Cc: BELOTTI, SERGIO (SERGIO); Varma, Eve L (Eve)
Subject: Re: [Actn] draft-ceccarelli-actn-framework-03.txt comments

Hi Young,

Regards
Sergio

From: Leeyoung [mailto:[email-masked]<http://huawei.com>]
Sent: mercoledì 8 ottobre 2014 17:35
To: BELOTTI, SERGIO (SERGIO); [email-masked]<mailto:[email-masked]>; Daniele Ceccarelli; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Cc: Varma, Eve L (Eve)
Subject: RE: draft-ceccarelli-actn-framework-03.txt comments

Hi Sergio,

Regards,
Young

General question: in the draft the concept of VNC is in the view of hierarchical level of controllers or linked to the multi-domain aspect that compel to provide to the customer a single virtualized network even if composed by real multi-domain multi-technology subnetworks? I mean, the “virtualizer function” provided by VNC, in case of a single domain context could be inside directly the PNC , correct?

Section 2 , page 4:

Section 6.1 : while it is clear the scope of the different control interface presented in figure 5, I’m a bit confused as to what I/F E is – data plane interface to provider physical network? Or is the intention to provide what can be the underlying model of resources allocated to a customer from network provider controller, and the mapping to real physical resources ? Nor clear to me the intention

Figure 8 Section 6.4,page 28: “PCA abstracts the physical network topology into an abstracted topology” Looking at the description of VNC components in 6.2.2 it is the resource manager devoting to provide abstract topology. Does not exist any PCA component.

   controllers.

Thanks

Sergio

Thanks
Sergio
_______________________________________________
ACTN mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/actn

---

From: Leeyoung <[email-masked]>
Date: Thu, 9 Oct 2014 20:31:49 +0000

Hi Ignor,

Thank you for providing your comment that pauses us to think more and understand on the same level. I think your comment will contribute to crystallize the scope of work here.

First of all, I think there was a misunderstanding here. First, your assumption on VNC receiving actual underlying topology is incorrect. If VNC were to have actually topology (e.g. TED) of a network, this would be called a PNC and this is out of scope of ACTN. This aspect has been discussed by email threads Daniele started a few weeks ago. Check the archive on that. The reason this is out of scope is that PNC multi-domain issue is no different from today's GMPLS/PCE issue, especially in light of H-PCE. ACTN does not step on those areas. What VNC receives from each PNC (domain controller) is an abstracted topology with varying degrees from actual underlying topology. The reason why we distinguish the term VNC from PNC.

What can be defined on VNC-PNC is a vertical signaling coordination from VNC to each PNC. As long as the detailed path computation and signaling within a domain are completely up to the domain PNC. VNC is not to be operated on the same level as PNC. Its end-to-end path computation is based on what is exposed from PNCs to VNC. The actual topology information details is kept by PNCs and the PNCs expose abstracted topology that can hide the exact details while exposing a minimum level of constraints. For instance, the SRLG of virtual links (which may be concatenated actual links) can be exposed for diversity routing calculation at the VNC. This is very different from exposing the actual TE topology. You can view this as two level of path computation. VNC first computes an end-to-end path (using whatever constraint information it has), then coordinates with each PNC (telling the border nodes information), then each PNC computes the domain specific path. When a PNC cannot provide a path segment in its domain, then this needs to be signaled to VNC so that the VNC would arrange an alternate path segment to be able to find a feasible end-to-end path.  I would say this is a "two-phase" signaling and path computation. The point is that there must be some level of hiding on abstract topology exposure from PNC to VNC and proprietary characteristics of optical devices need to be dealt only with the corresponding PNC.

Regarding the term PNC vs. ANC, I wouldn't concern too much about the terminology whichever works better. Thank you for your suggestion.

Lastly, please check the use-cases written by operators in the below links that consistently say they need a standard interface that can coordinate their multi-domain issues.

https://datatracker.ietf.org/doc/draft-fang-actn-multidomain-dci/
https://datatracker.ietf.org/doc/draft-klee-actn-connectivity-multi-vendor-domains/
https://datatracker.ietf.org/doc/draft-kumaki-actn-multitenant-vno/
https://datatracker.ietf.org/doc/draft-lopez-actn-vno-multidomains/
https://datatracker.ietf.org/doc/draft-shin-actn-mvno-multi-domain/

Regards,
Young

Thanks,
Young

From: Igor Bryskin [mailto:[email-masked]]
Sent: Thursday, October 09, 2014 1:48 PM
To: BELOTTI, SERGIO (SERGIO); Leeyoung; [email-masked]; Daniele Ceccarelli; [email-masked]; [email-masked]
Cc: Varma, Eve L (Eve)
Subject: RE: draft-ceccarelli-actn-framework-03.txt comments

Hi Young,

Cheers,
Igor

Hi Young,

Regards
Sergio

Hi Sergio,

Regards,
Young

Section 2 , page 4:

   controllers.

Thanks

Sergio

Thanks
Sergio

---

From: Leeyoung <[email-masked]>
Date: Thu, 9 Oct 2014 20:53:19 +0000

Sorry Igor for misspelling your name, no joke here. Take my apology!

From: Leeyoung
Sent: Thursday, October 09, 2014 3:32 PM
To: 'Igor Bryskin'; BELOTTI, SERGIO (SERGIO); [email-masked]; Daniele Ceccarelli; [email-masked]; [email-masked]
Cc: Varma, Eve L (Eve)
Subject: RE: draft-ceccarelli-actn-framework-03.txt comments

Hi Ignor,

Regards,
Young

Thanks,
Young

Hi Young,

Cheers,
Igor

Hi Young,

Regards
Sergio

Hi Sergio,

Regards,
Young

Section 2 , page 4:

   controllers.

Thanks

Sergio

Thanks
Sergio

---

From: "King, Daniel" <[email-masked]>
Date: Thu, 9 Oct 2014 20:58:02 +0000

Hi All, including "Ignor" ;-)

Typical dichotomy between what operators want and what vendors are actually willing to provide, group consensus will eventually help resolve that. Either way, the latest version of the Framework I-D is trying to focus ACTN discussion and scope (i.e., the protocol work) on the interfaces which are in scope, namely:

1. The CNC-VNC Interface (CVI)
- Create, modify and delete virtual network service instances
- Resource model

2. The VNC-PNC Interface (VPI)
- Mapping of physical and virtual resources
- Requests: path, provision, modify and restore

As Young suggests, if the VNC received physical topology info it would be performing the role of the Physical Network Controller (PNC), which is obviously a (somehow) required function, but the interface (direct provisioning of the actual physical network) is out of scope for ACTN.

Br, Dan.

From: ACTN [mailto:[email-masked]] On Behalf Of Leeyoung
Sent: 09 October 2014 21:32
To: Igor Bryskin; BELOTTI, SERGIO (SERGIO); [email-masked]; Daniele Ceccarelli; [email-masked]; [email-masked]
Cc: Varma, Eve L (Eve)
Subject: Re: [Actn] draft-ceccarelli-actn-framework-03.txt comments

Hi Ignor,

Regards,
Young

Thanks,
Young

From: Igor Bryskin [mailto:[email-masked]]
Sent: Thursday, October 09, 2014 1:48 PM
To: BELOTTI, SERGIO (SERGIO); Leeyoung; [email-masked]<mailto:[email-masked]>; Daniele Ceccarelli; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Cc: Varma, Eve L (Eve)
Subject: RE: draft-ceccarelli-actn-framework-03.txt comments

Hi Young,

Cheers,
Igor

Hi Young,

Regards
Sergio

Hi Sergio,

Regards,
Young

Section 2 , page 4:

   controllers.

Thanks

Sergio

Thanks
Sergio

---

From: John E Drake <[email-masked]>
Date: Thu, 9 Oct 2014 21:14:14 +0000

It's actually spelled Ignore 8->

Yours Irrespectively,

John

From: ACTN [mailto:[email-masked]] On Behalf Of Leeyoung
Sent: Thursday, October 09, 2014 1:53 PM
To: Leeyoung; Igor Bryskin; BELOTTI, SERGIO (SERGIO); [email-masked]; Daniele Ceccarelli; [email-masked]; [email-masked]
Cc: Varma, Eve L (Eve)
Subject: Re: [Actn] draft-ceccarelli-actn-framework-03.txt comments

From: Leeyoung
Sent: Thursday, October 09, 2014 3:32 PM
To: 'Igor Bryskin'; BELOTTI, SERGIO (SERGIO); [email-masked]<mailto:[email-masked]>; Daniele Ceccarelli; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Cc: Varma, Eve L (Eve)
Subject: RE: draft-ceccarelli-actn-framework-03.txt comments

Hi Ignor,

Regards,
Young

Thanks,
Young

Hi Young,

Cheers,
Igor

Hi Young,

Regards
Sergio

Hi Sergio,

Regards,
Young

Section 2 , page 4:

   controllers.

Thanks

Sergio

Thanks
Sergio

---

From: Igor Bryskin <[email-masked]>
Date: Fri, 10 Oct 2014 01:15:43 +0000

Young and Dan,

It does not matter how you call me, and as John is helpfully applying, you can ignore what I am saying. But let me explain in some more details what I meant.

Suppose we have a client (such as TFK) of a multi-domain transport network, who wants to provision and manipulate e2e transport services the way he wants it (i.e. applying his policies). What would such client need?

1.     An access to a unified network TE topology that could be understood and used by the client's path computer to select service e2e paths. How does the client get such a topology? The necessary overlay topology comprises abstract topologies presented for the client by each of the transport domains + inter-domain TE links. Hence we are talking about interface #1 (and data model #1) between a provider hypervisor/VNC and the client controller to expose in a unified abstract  way  its topology on per client/tenant basis. Furthermore, the client controller can use this interface in the opposite direction to modify the said abstract topology (subject to the provider's  approval), because the client is the only guy who knows how the abstract topology exposed to him should look like to be useful (e.g. which and how the abstract links should be disjoint from each other, how many of them should be provided, their attributes, desired recovery capabilities, etc,). This knowledge is supposed to come from the client's network planning.

2.     A way to provision/modify/delete e2e services with the use of so computed e2e paths. The client's controller does that by chopping the paths into per-domain segments and instructs respective domain VNCs/Hypervisors to set up/manipulate service respective connection segments. Hence we are talking about interface #2 (data model #2) for the service segment manipulation;

3.     A way to monitor, troubleshoot, carry out maintenance of the active e2e services. This would require interface #3 (data model #3) between the client's controller and domains VNCs/Hypervisors for this purpose.

So, we are talking 3 Yang models with required modifications to neither Netconf/Restconf, nor
 To any other management, routing or signaling protocol.

Now I have a couple of questions to you:

1.     In this example, what else (in addition to these three models) the client such as TFK in your opinion would need?

2.     What else the network providers and their vendors such as ADVA or CIEN would need?

3.     What is the importance of a construct such as PNC?

My answer to 3. "Is not important at all, irrelevant" for the following reasons:

a)     What happens beyond the VNC/Hypervisor in the provider network is completely proprietary.

b)     There could be numerous ways as to how the provider network is managed. Examples: centralized PNC (as you call it), ADVA style GMPLS based network intelligence, CIEN style PNNI based control plane, etc. Why is that of ACTN's business?

Cheers,
Igor

From: King, Daniel [mailto:[email-masked]]
Sent: Thursday, October 09, 2014 4:58 PM
To: Leeyoung; Igor Bryskin; BELOTTI, SERGIO (SERGIO); [email-masked]; Daniele Ceccarelli; [email-masked]; [email-masked]
Cc: Varma, Eve L (Eve)
Subject: RE: draft-ceccarelli-actn-framework-03.txt comments

Br, Dan.

Hi Ignor,

Regards,
Young

Thanks,
Young

Hi Young,

Cheers,
Igor

Hi Young,

Regards
Sergio

Hi Sergio,

Regards,
Young

Section 2 , page 4:

   controllers.

Thanks

Sergio

Thanks
Sergio

---

From: Daniele Ceccarelli <[email-masked]>
Date: Fri, 10 Oct 2014 17:24:43 +0000

Hi Igor,

What do you mean by client here? The one that is the document is called "service provider" or the one that is called "client" ? From what you send I tend to think you are talking about the service provider, but I might be wrong, please correct me.

I don't think the client of the multi-domain network wants to have a so detailed view of the network, he does not care about domains, inter domain links or whatever, I would say he only cares about a given amount of Gbps from A to B with a given max delay and probably some diversity parameters.

On the other side, the one that cares about all of the issues you listed is the service provider (as per actual document terminology). However also the service provider does not go into physical impairment details. He cares about connectivity between the borders of the domains, inter domain links. How such connectivity is provisioned/managed is the network provider business. The network provides might be using GMPLS, NMS and ONF controller with Open Flow or whatever to control the network. Maybe calling it PNC is confusing? The PNC can be any of the things I've listed and much more.

Hence the interfaces to be considered are two, not three (as Dan said) I think this replies to questions 1 and 3. Just to add something regarding 2, I would say that they need just a single entry point to the network control (could be a small piece of code running on top of the PCE of your GMPLS domain), which acts as an interface between the VNC and the control plane of your network and performs: "- Mapping of physical and virtual resources" and  "Requests: path, provision, modify and restore".

Cheers
Daniele

From: Igor Bryskin [mailto:[email-masked]]
Sent: venerdì 10 ottobre 2014 03:16
To: King, Daniel; Leeyoung; BELOTTI, SERGIO (SERGIO); [email-masked]; Daniele Ceccarelli; [email-masked]; [email-masked]
Cc: Varma, Eve L (Eve)
Subject: RE: draft-ceccarelli-actn-framework-03.txt comments

Young and Dan,

Cheers,
Igor

From: King, Daniel [mailto:[email-masked]]
Sent: Thursday, October 09, 2014 4:58 PM
To: Leeyoung; Igor Bryskin; BELOTTI, SERGIO (SERGIO); [email-masked]<mailto:[email-masked]>; Daniele Ceccarelli; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Cc: Varma, Eve L (Eve)
Subject: RE: draft-ceccarelli-actn-framework-03.txt comments

Br, Dan.

From: ACTN [mailto:[email-masked]] On Behalf Of Leeyoung
Sent: 09 October 2014 21:32
To: Igor Bryskin; BELOTTI, SERGIO (SERGIO); [email-masked]<mailto:[email-masked]>; Daniele Ceccarelli; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Cc: Varma, Eve L (Eve)
Subject: Re: [Actn] draft-ceccarelli-actn-framework-03.txt comments

Hi Ignor,

Regards,
Young

Thanks,
Young

Hi Young,

Cheers,
Igor

Hi Young,

Regards
Sergio

Hi Sergio,

Regards,
Young

Section 2 , page 4:

   controllers.

Thanks

Sergio

Thanks
Sergio

---

From: Daniele Ceccarelli <[email-masked]>
Date: Fri, 10 Oct 2014 17:24:46 +0000

Hi Paul,

The idea, at least speaking on behalf of Daniele and not of all the authors, is to hide such complexity to the service provider and the client.

The service provider (VNC level) asks the network provider to provide connectivity between two points with given characteristics. If we want to export all the ingredients for autonomously performing and end to end path computation...then I agree with Igor: we will never succeed. It would also be an exercise of multi domain routing (reinventing the wheel) as we would just use an NBI to export routing information instead of using inter domain routing.

BR
Daniele

From: Doolan, Paul (Coriant - US/Irving) [mailto:[email-masked]]
Sent: giovedì 9 ottobre 2014 21:21
To: Igor Bryskin
Cc: BELOTTI, SERGIO (SERGIO); Leeyoung; [email-masked]; Daniele Ceccarelli; [email-masked]; [email-masked]; Varma, Eve L (Eve)
Subject: Re: [Actn] draft-ceccarelli-actn-framework-03.txt comments

Hello Igor,

thanks,
pd

Hi Young,

Cheers,
Igor

Hi Young,

Regards
Sergio

Hi Sergio,

Regards,
Young

Section 2 , page 4:

   controllers.

Thanks

Sergio

Thanks
Sergio

---

From: Igor Bryskin <[email-masked]>
Date: Fri, 10 Oct 2014 20:37:18 +0000

Hi Daniele,
Please, see in line.
Igor

From: Daniele Ceccarelli [mailto:[email-masked]]
Sent: Friday, October 10, 2014 1:25 PM
To: Igor Bryskin; King, Daniel; Leeyoung; BELOTTI, SERGIO (SERGIO); [email-masked]; [email-masked]; [email-masked]
Cc: Varma, Eve L (Eve)
Subject: RE: draft-ceccarelli-actn-framework-03.txt comments

Hi Igor,

IB>> By client I mean the client of a transport domain, the one who speaks Netconf/Restconf to the transport domain. The guy who speaks from the other end (i.e. on behalf of the transport service provider)  is the transport domain's Hypervisor.

IB>> Again, by client I mean multi-domain network controller (e.g. Telefonica SDN controller), not the client using services of the multi-domain network (i.e. not the Telefonica clients). Such client uses  the transport domains for a reason. "a given amount of Gbps from A to B" is too loose and little for the client to do the network planning. IMO the client needs to *plan* the abstract topologies provided by the transport domains the same or similar way as he would plan his own actual topology.

IB>> In this case my client is your service provider ;=). You architecturally separate client from the service provider, because you probably believe that it is possible to standardize the interface between the two. I disagree with that and don't think ACTN should work on this. In the context of ACTN I see only two constructs: Transport domain controller (transport service provider) and  Transport client controller (transport service user).

IB>> As I said, this is the task of the transport domain Hypervisor, whose role is, essentially, to translate back and forth abstract <=> actual topology elements and service requests/responses containing the abstract/actual topology paths. I think that the north/south interface between the transport domain Hypervisor and the entity representing the client of the transport domain (no matter how you call it) is the only interface ACTN can work on with the hope to produce something useful.

Cheers
Daniele

From: Igor Bryskin [mailto:[email-masked]]
Sent: venerdì 10 ottobre 2014 03:16
To: King, Daniel; Leeyoung; BELOTTI, SERGIO (SERGIO); [email-masked]<mailto:[email-masked]>; Daniele Ceccarelli; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Cc: Varma, Eve L (Eve)
Subject: RE: draft-ceccarelli-actn-framework-03.txt comments

Young and Dan,

Cheers,
Igor

Br, Dan.

Hi Ignor,

Regards,
Young

Thanks,
Young

Hi Young,

Cheers,
Igor

Hi Young,

Regards
Sergio

Hi Sergio,

Regards,
Young

Section 2 , page 4:

   controllers.

Thanks

Sergio

Thanks
Sergio

---

From: "BELOTTI, SERGIO (SERGIO)" <[email-masked]>
Date: Mon, 13 Oct 2014 13:15:21 +0000

Hi Igor,

Please, see in line

Regards
Sergio

From: Igor Bryskin [mailto:[email-masked]]
Sent: venerdì 10 ottobre 2014 22:37
To: Daniele Ceccarelli; King, Daniel; Leeyoung; BELOTTI, SERGIO (SERGIO); [email-masked]; [email-masked]; [email-masked]
Cc: Varma, Eve L (Eve)
Subject: RE: draft-ceccarelli-actn-framework-03.txt comments

Hi Daniele,
Please, see in line.
Igor

From: Daniele Ceccarelli [mailto:[email-masked]]
Sent: Friday, October 10, 2014 1:25 PM
To: Igor Bryskin; King, Daniel; Leeyoung; BELOTTI, SERGIO (SERGIO); [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Cc: Varma, Eve L (Eve)
Subject: RE: draft-ceccarelli-actn-framework-03.txt comments

Hi Igor,

SB>>> It is clear what you intend here, even if word client it seems to me more related to application than to a service provider. Moreover I would avoid in this phase to mention any reference to protocol implementation (e.g. Netconf/Restconf) : I think we are in the phase to understand architecture, what are the relevant interfaces, and what information is exchanged over the reference points/interfaces. I guess this is clearly stated also in the charter of BoF.  At an appropriate time - certainly not now - the next step is to check with other SDOs on the availability of relevant core/technology specific/application specific information model "fragments", and then finally proceed on the path of pruning/refactoring and mapping to REST/JSON, Netconf/YANG, and any other possible data modeling and configuration protocol existing. This is my understanding  of the BoF scope .

SB>>> yes, sure, in you view of "client" , this is the service provider Daniele is talking, so an abstract view of what is the real transport network is considered at this level. As I said to Young, in my previous mail, in the case of a single domain scenario VNC and PNC could also coincide but in case of a multi-domain scenarios the scope is to provide to application layer a single virtualized view of the underline multi domain network.

SB>>> ACTN here is not reinventing the wheel , in other SDO SDN specific is considered  the application layer , and the interface between AL and SDN controller (in this case the VNC of ACTN) . This interface permit to any client to directly impact to his own services and his own "virtualized" resources .

Cheers
Daniele

Young and Dan,

Cheers,
Igor

Br, Dan.

Hi Ignor,

Regards,
Young

Thanks,
Young

Hi Young,

Cheers,
Igor

Hi Young,

Regards
Sergio

Hi Sergio,

Regards,
Young

Section 2 , page 4:

   controllers.

Thanks

Sergio

Thanks
Sergio

---

From: Igor Bryskin <[email-masked]>
Date: Mon, 13 Oct 2014 14:17:26 +0000

Hi Sergio,
A couple of comments in line.

Cheers,
Igor

From: BELOTTI, SERGIO (SERGIO) [mailto:[email-masked]]
Sent: Monday, October 13, 2014 9:15 AM
To: Igor Bryskin; Daniele Ceccarelli; King, Daniel; Leeyoung; [email-masked]; [email-masked]; [email-masked]
Cc: Varma, Eve L (Eve); BELOTTI, SERGIO (SERGIO)
Subject: RE: draft-ceccarelli-actn-framework-03.txt comments

Hi Igor,

Please, see in line

Regards
Sergio

From: Igor Bryskin [mailto:[email-masked]]
Sent: venerdì 10 ottobre 2014 22:37
To: Daniele Ceccarelli; King, Daniel; Leeyoung; BELOTTI, SERGIO (SERGIO); [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Cc: Varma, Eve L (Eve)
Subject: RE: draft-ceccarelli-actn-framework-03.txt comments

Hi Daniele,
Please, see in line.
Igor

Hi Igor,

SB>>> It is clear what you intend here, even if word client it seems to me more related to application than to a service provider.

IB>> I am talking about the interface between transport domain server and  transport domain client. I would argue that the very same interface can be used between a multi-domain provider (e.g. Telefonika) and its clients. Not all such clients are dumb, as Daniele claims, and only care about "a given amount of Gbps from A to B". It is easy to envision that some of the clients would want from Telefonica a couple of SRLG-disjoint abstract links, so that the clients can have a say in the placement of their  services across the Telefonika network. Three points here:

a)      The client will be able to configure fully or partially the abstract topology he wants the network to present to him;

b)      The said abstract topology could be as simple (e.g. a single abstract node) or as complex (e.g. N abstract nodes interconnected by M abstract links) as the client wants it to be (subject to the provider's approval)

c)      The abstract topology presented to the client is completely decoupled from the provider's actual topology.

Therefore the same interface/set of models can be used between any transport network provider and its client. Furthermore, the interface can be used in the hierarchical way, that is, a client of a transport domain can serve its own clients using the same interface as it uses to talk to its own provider(s)

Moreover I would avoid in this phase to mention any reference to protocol implementation (e.g. Netconf/Restconf) : I think we are in the phase to understand architecture, what are the relevant interfaces, and what information is exchanged over the reference points/interfaces. I guess this is clearly stated also in the charter of BoF.

IB>> Agree. I used Netconf/Restconf as an example to make it clear what interface I was talking about.

 At an appropriate time - certainly not now - the next step is to check with other SDOs on the availability of relevant core/technology specific/application specific information model "fragments", and then finally proceed on the path of pruning/refactoring and mapping to REST/JSON, Netconf/YANG, and any other possible data modeling and configuration protocol existing. This is my understanding  of the BoF scope .

Cheers
Daniele

Young and Dan,

Cheers,
Igor

Br, Dan.

Hi Ignor,

Regards,
Young

Thanks,
Young

Hi Young,

Cheers,
Igor

Hi Young,

Regards
Sergio

Hi Sergio,

Regards,
Young

Section 2 , page 4:

   controllers.

Thanks

Sergio

Thanks
Sergio

---

From: Leeyoung <[email-masked]>
Date: Mon, 13 Oct 2014 21:12:10 +0000

Hi Igor,

After all we are agreeing with the interfaces of ACTN interest are Interface B and C, right?

Here I would like to give you a little clearer picture on multi-domain issues.

   +----------------+   +---------------+      +--------------+
   |   Customer 1   |   |   Customer 2  |  ... | Customer M   |
   +----------------+   +---------------+      +--------------+
                   \             |              /
                    \            |             /
       Interface B   \           |            /
                      \          |           /
                      +----------------------+
                      |   VNC Multi-domain   | E2E abstract
                      |      Coordination    | topology creation
                      +----------------------+
                       /         |            \
        Interface C   /          |             \  Network Topology
                     /           |              \ (abstract)
                    /            |               \
   +------------------+   +------------------+    +------------------+
   | Network Domain 1 |   | Network Domain 2 | .. | Network Domain N |
   +------------------+   +------------------+    +------------------+
        Vendor X                 Vendor Y               Vendor Z

What is sitting above "VNC" (that coordinates over multi-domain controllers) can be an internal service organization (of the same operator) or service providers (different operators, forming carriers of carrier). The control entity of these entities is referred to as Customer Network control (CNC). The VNC -CNC interface (Interface B) has different requirements than the VNC-PNC interface (Interface C). Topology abstraction is just one of the requirements and in multi-domain case, the VNC is performing multi-domain coordination function. VNC needs to have a standard interface that enable communications with different kinds of domain network control/management control (which is referred to as PNC, you call ANC). Each domain has its own ways of controlling its network, which ACTN is not touching those at all. Whatever the choices of vendor control regime will continue to be employed (GMPLS/ASON, PNNI, NMS, OpenFlow, etc.).

For this multi-domain coordination function assumed by VNC should be operated on an abstract level. We don't want to inject the same level of actual network topology (e.g., TED) as the domain controller operates its physical/actual networks. Is this agreeable? You said above this in c) The abstract topology presented to the client is completely decoupled from the provider's actual topology.

Now the VNC (multi-domain coordinator) needs to coordinate signaling across multi-domain controllers (in terms of the sequence of the end-to-end path across multiple domains). This is a new element I believe ACTN will have to develop. This interface C (VNC-PNC) is very different from Interface B (CNC-VNC). There are other differences (please see Section 6.5 of the framework document).  But I agree with you that from an abstract topology standpoint, similar model works for Interfaces B and C as you said  b)      The said abstract topology could be as simple (e.g. a single abstract node) or as complex (e.g. N abstract nodes interconnected by M abstract links) as the client wants it to be (subject to the provider's approval).

Best regards,
Young

From: Igor Bryskin [mailto:[email-masked]]
Sent: Monday, October 13, 2014 9:17 AM
To: BELOTTI, SERGIO (SERGIO); Daniele Ceccarelli; King, Daniel; Leeyoung; [email-masked]; [email-masked]; [email-masked]
Cc: Varma, Eve L (Eve)
Subject: RE: draft-ceccarelli-actn-framework-03.txt comments

Hi Sergio,

Cheers,
Igor

Hi Igor,

Please, see in line

Regards
Sergio

Hi Daniele,
Please, see in line.
Igor

Hi Igor,

Cheers
Daniele

Young and Dan,

Cheers,
Igor

Br, Dan.

Hi Ignor,

Regards,
Young

Thanks,
Young

Hi Young,

Cheers,
Igor

Hi Young,

Regards
Sergio

Hi Sergio,

Regards,
Young

Section 2 , page 4:

   controllers.

Thanks

Sergio

Thanks
Sergio

---

From: Igor Bryskin <[email-masked]>
Date: Tue, 14 Oct 2014 00:00:55 +0000

Young,

===》After all we are agreeing with the interfaces of ACTN interest are Interface B and C, right?

IB》No. I am saying that interface B and C are exactly the same interfaces. For example, on the picture Network domain 1 in order to provide the abstract topology to the multi-vendor VNC, may use fully or partially abstract topologies provided by one or more lower tier transport domains.
Likewise, Customer 1 on the picture may use an abstract topology provided by 
Multi-domain network (the VNC on the picture is part of).
In other words, the same interface C and the same set of models, could be used  hierarchically. 

Igor

IB>> I am talking about the interface between transport domain server and  transport domain client. I would argue that the very same interface can be used between a multi-domain provider (e.g. Telefonika) and its clients. Not all such clients are dumb, as Daniele claims, and only care about “a given amount of Gbps from A to B”. It is easy to envision that some of the clients would want from Telefonica a couple of SRLG-disjoint abstract links, so that the clients can have a say in the placement of their  services across the Telefonika network. Three points here:

b)      The said abstract topology could be as simple (e.g. a single abstract node) or as complex (e.g. N abstract nodes interconnected by M abstract links) as the client wants it to be (subject to the provider’s approval)

c)      The abstract topology presented to the client is completely decoupled from the provider’s actual topology.

What is sitting above “VNC” (that coordinates over multi-domain controllers) can be an internal service organization (of the same operator) or service providers (different operators, forming carriers of carrier). The control entity of these entities is referred to as Customer Network control (CNC). The VNC –CNC interface (Interface B) has different requirements than the VNC-PNC interface (Interface C). Topology abstraction is just one of the requirements and in multi-domain case, the VNC is performing multi-domain coordination function. VNC needs to have a standard interface that enable communications with different kinds of domain network control/management control (which is referred to as PNC, you call ANC). Each domain has its own ways of controlling its network, which ACTN is not touching those at all. Whatever the choices of vendor control regime will continue to be employed (GMPLS/ASON, PNNI, NMS, OpenFlow, etc.).

For this multi-domain coordination function assumed by VNC should be operated on an abstract level. We don’t want to inject the same level of actual network topology (e.g., TED) as the domain controller operates its physical/actual networks. Is this agreeable? You said above this in c) The abstract topology presented to the client is completely decoupled from the provider’s actual topology.

Now the VNC (multi-domain coordinator) needs to coordinate signaling across multi-domain controllers (in terms of the sequence of the end-to-end path across multiple domains). This is a new element I believe ACTN will have to develop. This interface C (VNC-PNC) is very different from Interface B (CNC-VNC). There are other differences (please see Section 6.5 of the framework document).  But I agree with you that from an abstract topology standpoint, similar model works for Interfaces B and C as you said  b)      The said abstract topology could be as simple (e.g. a single abstract node) or as complex (e.g. N abstract nodes interconnected by M abstract links) as the client wants it to be (subject to the provider’s approval).

Best regards,
Young

Hi Sergio,

Cheers,
Igor

Hi Igor,

Please, see in line

Regards
Sergio

Hi Daniele,
Please, see in line.
Igor

Hi Igor,

What do you mean by client here? The one that is the document is called “service provider” or the one that is called “client” ? From what you send I tend to think you are talking about the service provider, but I might be wrong, please correct me.

IB>> By client I mean the client of a transport domain, the one who speaks Netconf/Restconf to the transport domain. The guy who speaks from the other end (i.e. on behalf of the transport service provider)  is the transport domain’s Hypervisor.

IB>> I am talking about the interface between transport domain server and  transport domain client. I would argue that the very same interface can be used between a multi-domain provider (e.g. Telefonika) and its clients. Not all such clients are dumb, as Daniele claims, and only care about “a given amount of Gbps from A to B”. It is easy to envision that some of the clients would want from Telefonica a couple of SRLG-disjoint abstract links, so that the clients can have a say in the placement of their  services across the Telefonika network. Three points here:

b)      The said abstract topology could be as simple (e.g. a single abstract node) or as complex (e.g. N abstract nodes interconnected by M abstract links) as the client wants it to be (subject to the provider’s approval)

c)      The abstract topology presented to the client is completely decoupled from the provider’s actual topology.

 At an appropriate time – certainly not now – the next step is to check with other SDOs on the availability of relevant core/technology specific/application specific information model “fragments”, and then finally proceed on the path of pruning/refactoring and mapping to REST/JSON, Netconf/YANG, and any other possible data modeling and configuration protocol existing. This is my understanding  of the BoF scope .

I don’t think the client of the multi-domain network wants to have a so detailed view of the network, he does not care about domains, inter domain links or whatever, I would say he only cares about a given amount of Gbps from A to B with a given max delay and probably some diversity parameters.

IB>> Again, by client I mean multi-domain network controller (e.g. Telefonica SDN controller), not the client using services of the multi-domain network (i.e. not the Telefonica clients). Such client uses  the transport domains for a reason. “a given amount of Gbps from A to B” is too loose and little for the client to do the network planning. IMO the client needs to *plan* the abstract topologies provided by the transport domains the same or similar way as he would plan his own actual topology.

SB>>> yes, sure, in you view of “client” , this is the service provider Daniele is talking, so an abstract view of what is the real transport network is considered at this level. As I said to Young, in my previous mail, in the case of a single domain scenario VNC and PNC could also coincide but in case of a multi-domain scenarios the scope is to provide to application layer a single virtualized view of the underline multi domain network.

On the other side, the one that cares about all of the issues you listed is the service provider (as per actual document terminology). However also the service provider does not go into physical impairment details. He cares about connectivity between the borders of the domains, inter domain links. How such connectivity is provisioned/managed is the network provider business. The network provides might be using GMPLS, NMS and ONF controller with Open Flow or whatever to control the network. Maybe calling it PNC is confusing? The PNC can be any of the things I’ve listed and much more.

IB>> In this case my client is your service provider ;=). You architecturally separate client from the service provider, because you probably believe that it is possible to standardize the interface between the two. I disagree with that and don’t think ACTN should work on this. In the context of ACTN I see only two constructs: Transport domain controller (transport service provider) and  Transport client controller (transport service user).

SB>>> ACTN here is not reinventing the wheel , in other SDO SDN specific is considered  the application layer , and the interface between AL and SDN controller (in this case the VNC of ACTN) . This interface permit to any client to directly impact to his own services and his own “virtualized” resources .

Hence the interfaces to be considered are two, not three (as Dan said) I think this replies to questions 1 and 3. Just to add something regarding 2, I would say that they need just a single entry point to the network control (could be a small piece of code running on top of the PCE of your GMPLS domain), which acts as an interface between the VNC and the control plane of your network and performs: “- Mapping of physical and virtual resources” and  “Requests: path, provision, modify and restore”.

Cheers
Daniele

Young and Dan,

1.     An access to a unified network TE topology that could be understood and used by the client’s path computer to select service e2e paths. How does the client get such a topology? The necessary overlay topology comprises abstract topologies presented for the client by each of the transport domains + inter-domain TE links. Hence we are talking about interface #1 (and data model #1) between a provider hypervisor/VNC and the client controller to expose in a unified abstract  way  its topology on per client/tenant basis. Furthermore, the client controller can use this interface in the opposite direction to modify the said abstract topology (subject to the provider’s  approval), because the client is the only guy who knows how the abstract topology exposed to him should look like to be useful (e.g. which and how the abstract links should be disjoint from each other, how many of them should be provided, their attributes, desired recovery capabilities, etc,). This knowledge is supposed to come from the client’s network planning.

2.     A way to provision/modify/delete e2e services with the use of so computed e2e paths. The client’s controller does that by chopping the paths into per-domain segments and instructs respective domain VNCs/Hypervisors to set up/manipulate service respective connection segments. Hence we are talking about interface #2 (data model #2) for the service segment manipulation;

3.     A way to monitor, troubleshoot, carry out maintenance of the active e2e services. This would require interface #3 (data model #3) between the client’s controller and domains VNCs/Hypervisors for this purpose.

My answer to 3. “Is not important at all, irrelevant” for the following reasons:

b)     There could be numerous ways as to how the provider network is managed. Examples: centralized PNC (as you call it), ADVA style GMPLS based network intelligence, CIEN style PNNI based control plane, etc. Why is that of ACTN’s business?

Cheers,
Igor

Hi All, including “Ignor” ;-)

Br, Dan.

Hi Ignor,

First of all, I think there was a misunderstanding here. First, your assumption on VNC receiving actual underlying topology is incorrect. If VNC were to have actually topology (e.g. TED) of a network, this would be called a PNC and this is out of scope of ACTN. This aspect has been discussed by email threads Daniele started a few weeks ago. Check the archive on that. The reason this is out of scope is that PNC multi-domain issue is no different from today’s GMPLS/PCE issue, especially in light of H-PCE. ACTN does not step on those areas. What VNC receives from each PNC (domain controller) is an abstracted topology with varying degrees from actual underlying topology. The reason why we distinguish the term VNC from PNC.

What can be defined on VNC-PNC is a vertical signaling coordination from VNC to each PNC. As long as the detailed path computation and signaling within a domain are completely up to the domain PNC. VNC is not to be operated on the same level as PNC. Its end-to-end path computation is based on what is exposed from PNCs to VNC. The actual topology information details is kept by PNCs and the PNCs expose abstracted topology that can hide the exact details while exposing a minimum level of constraints. For instance, the SRLG of virtual links (which may be concatenated actual links) can be exposed for diversity routing calculation at the VNC. This is very different from exposing the actual TE topology. You can view this as two level of path computation. VNC first computes an end-to-end path (using whatever constraint information it has), then coordinates with each PNC (telling the border nodes information), then each PNC computes the domain specific path. When a PNC cannot provide a path segment in its domain, then this needs to be signaled to VNC so that the VNC would arrange an alternate path segment to be able to find a feasible end-to-end path.  I would say this is a “two-phase” signaling and path computation. The point is that there must be some level of hiding on abstract topology exposure from PNC to VNC and proprietary characteristics of optical devices need to be dealt only with the corresponding PNC.

Regarding the term PNC vs. ANC, I wouldn’t concern too much about the terminology whichever works better. Thank you for your suggestion.

Regards,
Young

Thanks,
Young

Hi Young,

Cheers,
Igor

Hi Young,

Regards
Sergio

Hi Sergio,

Regards,
Young

Section 2 , page 4:

   controllers.

Thanks

Sergio

Thanks
Sergio

---

From: "BELOTTI, SERGIO (SERGIO)" <[email-masked]>
Date: Tue, 14 Oct 2014 09:38:28 +0000

Hi Igor,

" IB》No. I am saying that interface B and C are exactly the same interfaces. For example, on the picture Network domain 1 in order to provide the abstract topology to the multi-vendor VNC, may use fully or partially abstract topologies provided by one or more lower tier transport domains.
Likewise, Customer 1 on the picture may use an abstract topology provided by Multi-domain network (the VNC on the picture is part of).
In other words, the same interface C and the same set of models, could be used  hierarchically. 

Igor"

I tend to disagree here. What that can be discussed in my view it is the need or not of interface C. What VNC is going to provide is a double function of virtualizer of the network towards client application level and orchestration, due to the need to span multiple (virtual)NEs or multiple network domain . If we immmagine to encompass these functionally into only one SDN controller , managing all virtual network you would not use another interface between VNC and PNC.
But here Young put correctly some problems and it is the correct time I think to consider all the aspects.
But towards client application there is another level of abstraction, a real virtualization (to client) of resources with different granularity and characteristics of the set of information needed to the lower level of controller, as well explained by Young.
It can debate if another separate entity as VNC can be , in this architecture, the good choice, but I do not have preclusion on that. 
I instead share your sentence about hierarchical level of controller. 

Thanks

Regards
Sergio

-----Original Message-----
From: ACTN [mailto:[email-masked]] On Behalf Of Igor Bryskin
Sent: martedì 14 ottobre 2014 02:01
To: Leeyoung; BELOTTI, SERGIO (SERGIO); Daniele Ceccarelli; King, Daniel; [email-masked]; [email-masked]; [email-masked]
Cc: Varma, Eve L (Eve)
Subject: Re: [Actn] draft-ceccarelli-actn-framework-03.txt comments

Young,

IB》No. I am saying that interface B and C are exactly the same interfaces. For example, on the picture Network domain 1 in order to provide the abstract topology to the multi-vendor VNC, may use fully or partially abstract topologies provided by one or more lower tier transport domains.
Likewise, Customer 1 on the picture may use an abstract topology provided by Multi-domain network (the VNC on the picture is part of).
In other words, the same interface C and the same set of models, could be used  hierarchically. 

Igor

Best regards,
Young

Hi Sergio,

Cheers,
Igor

Hi Igor,

Please, see in line

Regards
Sergio

Hi Daniele,
Please, see in line.
Igor

Hi Igor,

Cheers
Daniele

Young and Dan,

So, we are talking 3 Yang models with required modifications to neither Netconf/Restconf, nor  To any other management, routing or signaling protocol.

Cheers,
Igor

Br, Dan.

Hi Ignor,

Regards,
Young

Thanks,
Young

Hi Young,

Cheers,
Igor

Hi Young,

Regards
Sergio

Hi Sergio,

Regards,
Young

Section 2 , page 4:

SB>>> If I understood form Adrian and Daniel ABNO draft the concept, 
SB>>> VNTM is strictly related to planning function so I this it is very 
SB>>> import point in the context of PNC , I would say

   controllers.

SB>>> Sorry Young, iit is not referred to 7.3 , but in the chapter 6,5 , 
SB>>> on Interface interaction, after point 6, is indicated Interface B 
SB>>> as interface between VNC and PNC, figure 5 says it is I/F C

Thanks

Sergio

Thanks
Sergio

---

From: Daniele Ceccarelli <[email-masked]>
Date: Tue, 14 Oct 2014 10:27:27 +0000

Hi Igor,

I don't think that B and C are going to be the same interface either. 
Just loud thinking, some example that come to my mind are as follows:

1. Multi domain: Suppose Telefonica has its own VNC (the previous misunderstanding was due to the fact that you call Telefonica as the client, while for the terminology used in the draft Telefonica is the service provider and the client is e.g. the bank asking Telefonica for a VPN between 3 points) which runs on top of 2 domains with PNCs from different vendors. The VNC is aware of the fact that there are 3 domains below (hence C must be domain aware) while there is no need for the bank to know that different domains are used to connect his 3 points

2. Cloud + Transport: An interesting use case in my opinion is the provisioning of connectivity between data center X and Y. There would be a CNC (let's call it e.g. cloud network controller as it would probably be something different from a PNC) for data center X, one for data center Y and one or more PNC in the middle. The VNC would be an enable for providing connectivity between data centers over a transport network. Also in this case I think that interfaces B and C would be different.

3. Optical multi domain: it might be possible that Telefonica wants to have a set of impairments for computing end to end optical paths (i.e. optical impairment not limited to the PNC domain). In that case you would have them through interface C but not B.

Maybe we might come to the conclusion that one interface is a subset of the other or maybe there are requirements that lead to defining them as separate interfaces with just a little bit of overlap, but I think it is worth keeping them separate.
I would like to know a bit more about requirements on interface B as it could be an interface towards the client controller (where client == the bank) or directly an application (which I guess has different requirements than the ones to be put on intf C).

BR
Daniele

> Sent: martedì 14 ottobre 2014 11:38
> To: Igor Bryskin; Leeyoung; Daniele Ceccarelli; King, Daniel; [email-masked];
> [email-masked]; [email-masked]
> Cc: Varma, Eve L (Eve)
> " IB》No. I am saying that interface B and C are exactly the same interfaces.
> For example, on the picture Network domain 1 in order to provide the
> abstract topology to the multi-vendor VNC, may use fully or partially abstract
> topologies provided by one or more lower tier transport domains.
> Likewise, Customer 1 on the picture may use an abstract topology provided
> by Multi-domain network (the VNC on the picture is part of).
> I tend to disagree here. What that can be discussed in my view it is the need
> or not of interface C. What VNC is going to provide is a double function of
> virtualizer of the network towards client application level and orchestration,
> due to the need to span multiple (virtual)NEs or multiple network domain . If
> we immmagine to encompass these functionally into only one SDN controller
> , managing all virtual network you would not use another interface between
> VNC and PNC.
> But towards client application there is another level of abstraction, a real
> virtualization (to client) of resources with different granularity and
> characteristics of the set of information needed to the lower level of
> controller, as well explained by Young.
> It can debate if another separate entity as VNC can be , in this architecture,
> the good choice, but I do not have preclusion on that.
> To: Leeyoung; BELOTTI, SERGIO (SERGIO); Daniele Ceccarelli; King, Daniel;
> [email-masked]; [email-masked]; [email-masked]
> Cc: Varma, Eve L (Eve)
> IB》No. I am saying that interface B and C are exactly the same interfaces.
> For example, on the picture Network domain 1 in order to provide the
> abstract topology to the multi-vendor VNC, may use fully or partially abstract
> topologies provided by one or more lower tier transport domains.
> Likewise, Customer 1 on the picture may use an abstract topology provided
> by Multi-domain network (the VNC on the picture is part of).
> IB>> I am talking about the interface between transport domain server and
> transport domain client. I would argue that the very same interface can be
> used between a multi-domain provider (e.g. Telefonika) and its clients. Not
> all such clients are dumb, as Daniele claims, and only care about “a given
> amount of Gbps from A to B”. It is easy to envision that some of the clients
> would want from Telefonica a couple of SRLG-disjoint abstract links, so that
> the clients can have a say in the placement of their  services across the
> Telefonika network. Three points here:
> 
> b)      The said abstract topology could be as simple (e.g. a single abstract
> node) or as complex (e.g. N abstract nodes interconnected by M abstract
> links) as the client wants it to be (subject to the provider’s approval)
> 
> Therefore the same interface/set of models can be used between any
> transport network provider and its client. Furthermore, the interface can be
> used in the hierarchical way, that is, a client of a transport domain can serve
> its own clients using the same interface as it uses to talk to its own
> provider(s)
> 
> What is sitting above “VNC” (that coordinates over multi-domain controllers)
> can be an internal service organization (of the same operator) or service
> providers (different operators, forming carriers of carrier). The control entity
> of these entities is referred to as Customer Network control (CNC). The VNC
> –CNC interface (Interface B) has different requirements than the VNC-PNC
> interface (Interface C). Topology abstraction is just one of the requirements
> and in multi-domain case, the VNC is performing multi-domain coordination
> function. VNC needs to have a standard interface that enable
> communications with different kinds of domain network
> control/management control (which is referred to as PNC, you call ANC).
> Each domain has its own ways of controlling its network, which ACTN is not
> touching those at all. Whatever the choices of vendor control regime will
> continue to be employed (GMPLS/ASON, PNNI, NMS, OpenFlow, etc.).
> 
> For this multi-domain coordination function assumed by VNC should be
> operated on an abstract level. We don’t want to inject the same level of
> actual network topology (e.g., TED) as the domain controller operates its
> physical/actual networks. Is this agreeable? You said above this in c) The
> abstract topology presented to the client is completely decoupled from the
> provider’s actual topology.
> 
> Now the VNC (multi-domain coordinator) needs to coordinate signaling
> across multi-domain controllers (in terms of the sequence of the end-to-end
> path across multiple domains). This is a new element I believe ACTN will have
> to develop. This interface C (VNC-PNC) is very different from Interface B
> (CNC-VNC). There are other differences (please see Section 6.5 of the
> framework document).  But I agree with you that from an abstract topology
> standpoint, similar model works for Interfaces B and C as you said  b)      The
> said abstract topology could be as simple (e.g. a single abstract node) or as
> complex (e.g. N abstract nodes interconnected by M abstract links) as the
> client wants it to be (subject to the provider’s approval).
> 
> Best regards,
> Young
> 
> 
> 
> 
> To: BELOTTI, SERGIO (SERGIO); Daniele Ceccarelli; King, Daniel; Leeyoung;
> [email-masked]; [email-masked]; [email-masked]
> Cc: Varma, Eve L (Eve)
> To: Daniele Ceccarelli; King, Daniel; Leeyoung; BELOTTI, SERGIO (SERGIO);
> [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>;
> [email-masked]<mailto:[email-masked]>
> Cc: Varma, Eve L (Eve)
> To: Igor Bryskin; King, Daniel; Leeyoung; BELOTTI, SERGIO (SERGIO);
> [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>;
> [email-masked]<mailto:[email-masked]>
> Cc: Varma, Eve L (Eve)
> What do you mean by client here? The one that is the document is called
> “service provider” or the one that is called “client” ? From what you send I
> tend to think you are talking about the service provider, but I might be
> wrong, please correct me.
> 
> IB>> By client I mean the client of a transport domain, the one who speaks
> Netconf/Restconf to the transport domain. The guy who speaks from the
> other end (i.e. on behalf of the transport service provider)  is the transport
> domain’s Hypervisor.
> 
> SB>>> It is clear what you intend here, even if word client it seems to me
> more related to application than to a service provider.
> 
> IB>> I am talking about the interface between transport domain server and
> transport domain client. I would argue that the very same interface can be
> used between a multi-domain provider (e.g. Telefonika) and its clients. Not
> all such clients are dumb, as Daniele claims, and only care about “a given
> amount of Gbps from A to B”. It is easy to envision that some of the clients
> would want from Telefonica a couple of SRLG-disjoint abstract links, so that
> the clients can have a say in the placement of their  services across the
> Telefonika network. Three points here:
> 
> b)      The said abstract topology could be as simple (e.g. a single abstract
> node) or as complex (e.g. N abstract nodes interconnected by M abstract
> links) as the client wants it to be (subject to the provider’s approval)
> 
> Therefore the same interface/set of models can be used between any
> transport network provider and its client. Furthermore, the interface can be
> used in the hierarchical way, that is, a client of a transport domain can serve
> its own clients using the same interface as it uses to talk to its own
> provider(s)
> 
> Moreover I would avoid in this phase to mention any reference to protocol
> implementation (e.g. Netconf/Restconf) : I think we are in the phase to
> understand architecture, what are the relevant interfaces, and what
> information is exchanged over the reference points/interfaces. I guess this is
> clearly stated also in the charter of BoF.
> 
>  At an appropriate time – certainly not now – the next step is to check with
> other SDOs on the availability of relevant core/technology
> specific/application specific information model “fragments”, and then finally
> proceed on the path of pruning/refactoring and mapping to REST/JSON,
> Netconf/YANG, and any other possible data modeling and configuration
> protocol existing. This is my understanding  of the BoF scope .
> 
> I don’t think the client of the multi-domain network wants to have a so
> detailed view of the network, he does not care about domains, inter domain
> links or whatever, I would say he only cares about a given amount of Gbps
> from A to B with a given max delay and probably some diversity parameters.
> 
> IB>> Again, by client I mean multi-domain network controller (e.g. Telefonica
> SDN controller), not the client using services of the multi-domain network
> (i.e. not the Telefonica clients). Such client uses  the transport domains for a
> reason. “a given amount of Gbps from A to B” is too loose and little for the
> client to do the network planning. IMO the client needs to *plan* the
> abstract topologies provided by the transport domains the same or similar
> way as he would plan his own actual topology.
> 
> SB>>> yes, sure, in you view of “client” , this is the service provider Daniele is
> talking, so an abstract view of what is the real transport network is
> considered at this level. As I said to Young, in my previous mail, in the case of
> a single domain scenario VNC and PNC could also coincide but in case of a
> multi-domain scenarios the scope is to provide to application layer a single
> virtualized view of the underline multi domain network.
> 
> On the other side, the one that cares about all of the issues you listed is the
> service provider (as per actual document terminology). However also the
> service provider does not go into physical impairment details. He cares about
> connectivity between the borders of the domains, inter domain links. How
> such connectivity is provisioned/managed is the network provider business.
> The network provides might be using GMPLS, NMS and ONF controller with
> Open Flow or whatever to control the network. Maybe calling it PNC is
> confusing? The PNC can be any of the things I’ve listed and much more.
> 
> IB>> In this case my client is your service provider ;=). You architecturally
> separate client from the service provider, because you probably believe that
> it is possible to standardize the interface between the two. I disagree with
> that and don’t think ACTN should work on this. In the context of ACTN I see
> only two constructs: Transport domain controller (transport service provider)
> and  Transport client controller (transport service user).
> 
> SB>>> ACTN here is not reinventing the wheel , in other SDO SDN specific is
> considered  the application layer , and the interface between AL and SDN
> controller (in this case the VNC of ACTN) . This interface permit to any client
> to directly impact to his own services and his own “virtualized” resources .
> 
> 
> Hence the interfaces to be considered are two, not three (as Dan said) I think
> this replies to questions 1 and 3. Just to add something regarding 2, I would
> say that they need just a single entry point to the network control (could be a
> small piece of code running on top of the PCE of your GMPLS domain), which
> acts as an interface between the VNC and the control plane of your network
> and performs: “- Mapping of physical and virtual resources” and  “Requests:
> path, provision, modify and restore”.
> 
> IB>> As I said, this is the task of the transport domain Hypervisor, whose role
> is, essentially, to translate back and forth abstract <=> actual topology
> elements and service requests/responses containing the abstract/actual
> topology paths. I think that the north/south interface between the transport
> domain Hypervisor and the entity representing the client of the transport
> domain (no matter how you call it) is the only interface ACTN can work on
> with the hope to produce something useful.
> 
> Cheers
> Daniele
> 
> 
> 
> To: King, Daniel; Leeyoung; BELOTTI, SERGIO (SERGIO);
> [email-masked]<mailto:[email-masked]>; Daniele Ceccarelli;
> [email-masked]<mailto:[email-masked]>;
> [email-masked]<mailto:[email-masked]>
> Cc: Varma, Eve L (Eve)
> It does not matter how you call me, and as John is helpfully applying, you can
> ignore what I am saying. But let me explain in some more details what I
> meant.
> 
> Suppose we have a client (such as TFK) of a multi-domain transport network,
> who wants to provision and manipulate e2e transport services the way he
> wants it (i.e. applying his policies). What would such client need?
> 
> 
> 1.     An access to a unified network TE topology that could be understood and
> used by the client’s path computer to select service e2e paths. How does the
> client get such a topology? The necessary overlay topology comprises
> abstract topologies presented for the client by each of the transport domains
> + inter-domain TE links. Hence we are talking about interface #1 (and data
> model #1) between a provider hypervisor/VNC and the client controller to
> expose in a unified abstract  way  its topology on per client/tenant basis.
> Furthermore, the client controller can use this interface in the opposite
> direction to modify the said abstract topology (subject to the provider’s
> approval), because the client is the only guy who knows how the abstract
> topology exposed to him should look like to be useful (e.g. which and how
> the abstract links should be disjoint from each other, how many of them
> should be provided, their attributes, desired recovery capabilities, etc,). This
> knowledge is supposed to come from the client’s network planning.
> 
> 2.     A way to provision/modify/delete e2e services with the use of so
> computed e2e paths. The client’s controller does that by chopping the paths
> into per-domain segments and instructs respective domain
> VNCs/Hypervisors to set up/manipulate service respective connection
> segments. Hence we are talking about interface #2 (data model #2) for the
> service segment manipulation;
> 
> 3.     A way to monitor, troubleshoot, carry out maintenance of the active e2e
> services. This would require interface #3 (data model #3) between the
> client’s controller and domains VNCs/Hypervisors for this purpose.
> 
> So, we are talking 3 Yang models with required modifications to neither
> Netconf/Restconf, nor  To any other management, routing or signaling
> protocol.
> 
> b)     There could be numerous ways as to how the provider network is
> managed. Examples: centralized PNC (as you call it), ADVA style GMPLS
> based network intelligence, CIEN style PNNI based control plane, etc. Why is
> that of ACTN’s business?
> 
> Cheers,
> Igor
> 
> To: Leeyoung; Igor Bryskin; BELOTTI, SERGIO (SERGIO);
> [email-masked]<mailto:[email-masked]>; Daniele Ceccarelli;
> [email-masked]<mailto:[email-masked]>;
> [email-masked]<mailto:[email-masked]>
> Cc: Varma, Eve L (Eve)
> Typical dichotomy between what operators want and what vendors are
> actually willing to provide, group consensus will eventually help resolve that.
> Either way, the latest version of the Framework I-D is trying to focus ACTN
> discussion and scope (i.e., the protocol work) on the interfaces which are in
> scope, namely:
> 
> As Young suggests, if the VNC received physical topology info it would be
> performing the role of the Physical Network Controller (PNC), which is
> obviously a (somehow) required function, but the interface (direct
> provisioning of the actual physical network) is out of scope for ACTN.
> 
> Br, Dan.
> 
> To: Igor Bryskin; BELOTTI, SERGIO (SERGIO);
> [email-masked]<mailto:[email-masked]>; Daniele Ceccarelli;
> [email-masked]<mailto:[email-masked]>;
> [email-masked]<mailto:[email-masked]>
> Cc: Varma, Eve L (Eve)
> Thank you for providing your comment that pauses us to think more and
> understand on the same level. I think your comment will contribute to
> crystallize the scope of work here.
> 
> First of all, I think there was a misunderstanding here. First, your assumption
> on VNC receiving actual underlying topology is incorrect. If VNC were to have
> actually topology (e.g. TED) of a network, this would be called a PNC and this
> is out of scope of ACTN. This aspect has been discussed by email threads
> Daniele started a few weeks ago. Check the archive on that. The reason this
> is out of scope is that PNC multi-domain issue is no different from today’s
> GMPLS/PCE issue, especially in light of H-PCE. ACTN does not step on those
> areas. What VNC receives from each PNC (domain controller) is an abstracted
> topology with varying degrees from actual underlying topology. The reason
> why we distinguish the term VNC from PNC.
> 
> What can be defined on VNC-PNC is a vertical signaling coordination from
> VNC to each PNC. As long as the detailed path computation and signaling
> within a domain are completely up to the domain PNC. VNC is not to be
> operated on the same level as PNC. Its end-to-end path computation is
> based on what is exposed from PNCs to VNC. The actual topology
> information details is kept by PNCs and the PNCs expose abstracted topology
> that can hide the exact details while exposing a minimum level of constraints.
> For instance, the SRLG of virtual links (which may be concatenated actual
> links) can be exposed for diversity routing calculation at the VNC. This is very
> different from exposing the actual TE topology. You can view this as two level
> of path computation. VNC first computes an end-to-end path (using
> whatever constraint information it has), then coordinates with each PNC
> (telling the border nodes information), then each PNC computes the domain
> specific path. When a PNC cannot provide a path segment in its domain, then
> this needs to be signaled to VNC so that the VNC would arrange an alternate
> path segment to be able to find a feasible end-to-end path.  I would say this
> is a “two-phase” signaling and path computation. The point is that there must
> be some level of hiding on abstract topology exposure from PNC to VNC and
> proprietary characteristics of optical devices need to be dealt only with the
> corresponding PNC.
> 
> Regarding the term PNC vs. ANC, I wouldn’t concern too much about the
> terminology whichever works better. Thank you for your suggestion.
> 
> Lastly, please check the use-cases written by operators in the below links
> that consistently say they need a standard interface that can coordinate their
> multi-domain issues.
> 
> To: BELOTTI, SERGIO (SERGIO); Leeyoung;
> [email-masked]<mailto:[email-masked]>; Daniele Ceccarelli;
> [email-masked]<mailto:[email-masked]>;
> [email-masked]<mailto:[email-masked]>
> Cc: Varma, Eve L (Eve)
> ====> BTW I find PNC is a bad term, I like much better Actual Network
> Controller  (ANC). VNC (a.k.a. a Hypervisor) is managing abstract topologies,
> and to be able do that, it talks to a ANC- a controller which has an access and
> manages actual provider network).
> 
> One reason for this is that VNC needs to understand underlying actual
> topology, for example, to ensure that two abstract TE links are SRLG disjoint
> as requested. Actual topology semantics (especially in WDM layer) is very
> different from vendor to vendor and contains a great variety of proprietary
> extensions, failing to understand which leads to producing unprovisionable
> service paths. Do you really believe that a single VNC can talk in the same
> way to ADVA, INFN, ALU and Huawei ANCs? This is equivalent to ask all
> optical providers to switch to WSON :=).
> 
> This is not to say that you cannot build a hierarchy of VNCs, but in this case
> North VNC plays role of a client network controller wrt to South VNC, that is,
> uses the same X interface.
> IHMO whenever a VNC has to talk to a ANC, it does so in a proprietary way,
> i.e. ADVA, INFN, ALU and Huawei will have their own VNCs exposing the
> same north bound interface to potentially the same client (e.g.TFK).
> To: Leeyoung; [email-masked]<mailto:[email-masked]>; Daniele Ceccarelli;
> [email-masked]<mailto:[email-masked]>;
> [email-masked]<mailto:[email-masked]>
> To: BELOTTI, SERGIO (SERGIO); [email-masked]<mailto:[email-masked]>; Daniele
> Ceccarelli; [email-masked]<mailto:[email-masked]>;
> [email-masked]<mailto:[email-masked]>
> Cc: Varma, Eve L (Eve)
> To: [email-masked]<mailto:[email-masked]>; Daniele Ceccarelli; Leeyoung;
> [email-masked]<mailto:[email-masked]>;
> [email-masked]<mailto:[email-masked]>
> I read you Framework draft and I have some comments on that. Most are
> editorial , other questions for clarifications.
> 
> General question: in the draft the concept of VNC is in the view of
> hierarchical level of controllers or linked to the multi-domain aspect that
> compel to provide to the customer a single virtualized network even if
> composed by real multi-domain multi-technology subnetworks? I mean, the
> “virtualizer function” provided by VNC, in case of a single domain context
> could be inside directly the PNC , correct?
> 
> YOUNG>> Yes. That is the correct view of VNC. For a single domain context,
> the VNC can be integrated with PNC. But we need to factor in other
> scenarios such as 1) VNC vendor may be different from PNC vendor or 2)
> VNC is a software function that operator may want to operate as its control.
> In my opinion, even for a single domain, I think there is benefit to define this
> interface as a standard interface.
> 
> Section 2 , page 4:
> abstraction does not imply automatically virtualization,while virtualization
> implies to have surely a certain form of abstraction. I would suggest to
> consider good definition contained into ONF SDN architecture document
> chapter 2.3 Conventions about abstraction and virtualization. A good
> definition can help all the reading.
> 
> YOUNG>> Agree. We will look into the mentioned document if the usage of
> terms are aligned with this document. If not, we will clarify the terminology
> more clearly.
> 
> Section 5: It seems to me you mixed here aspects that are more related to
> policy like admission control  and guarantee of client isolation with real
> computational issue like Computing time , path constrains or re-optimization
> process. Moreover the term VNM for Virtual network mapping is a bit
> misleading since this term in already used e.g. in ABNO architecture for
> Virtual Network Manager.
> 
> YOUNG>> Indeed. In Section 5, we will put some notes on the aspect of real-
> time related from non real time aspect. VNM is not to be mixed with Virtual
> Network Manager. Here VNM is an algorithm which is known as Virtual
> Network Mapping which is a software module that converts client requests
> into actual networks. Virtual Network Manager is ABNO in my understanding
> is a developed concept from VNTM. But Dan King and I will look at this more
> carefully on this aspect what Virtual Network Manager is doing.
> 
> Section 6.1 : while it is clear the scope of the different control interface
> presented in figure 5, I’m a bit confused as to what I/F E is – data plane
> interface to provider physical network? Or is the intention to provide what
> can be the underlying model of resources allocated to a customer from
> network provider controller, and the mapping to real physical resources ?
> Nor clear to me the intention
> 
> YOUNG>> Interface E is not what ACTN will focus on. It simply shows  an
> underlying model of resources allocated to a customer from network
> provider controller, and the mapping to real physical resources.
> 
> SB>>> So if I interpreted correctly your answer is more an internal interface
> to PNC , the figure is misleading since it seems like a DP interface .
> 
> 
> Section 6.1, always figure 5: If a report of potential NW topology between a
> VNC and a CNC can be queried , the arrow in the drawn has to be
> bidirectional I guess
> 
> Figure 8 Section 6.4,page 28: “PCA abstracts the physical network topology
> into an abstracted topology” Looking at the description of VNC components
> in 6.2.2 it is the resource manager devoting to provide abstract topology.
> Does not exist any PCA component.
> 
> 
> 
> YOUNG>> Sorry for inconsistency. The intention was the PCA is the same as
> the Resource Manager in VNC. Will make the term consistent. Good catch!
> 
> 
>

---

From: Igor Bryskin <[email-masked]>
Date: Tue, 14 Oct 2014 13:35:12 +0000

Daniele and Sergio,

I respectfully disagree with your arguments and believe that interfaces B and C are the same. Please, consider this:

1. In the PCE architecture a PCC requests path computation from a PCE via defined for this purposes interface - PCEP. If the PCE cannot satisfy the request on its own, it may use some help from another PCE. To do so it becomes a PCC of the second PCE and requests the path computation via the *same* PCEP. There are numerous reasons as to why it wouldn't be a good thing if PCEs had to use a different interface to talk to each other, and one of such reasons is that it is much easier to orchestrate the required hierarchy  with a single interface, rather than with two or more.

2. I hope we all agree that the ACTN architecture must be hierarchical in nature. For example, on the Young's picture below Network domain 1 could be a multi-domain transport network in its own right and consume the abstract topologies presented by each of its child domains, each of which could be also multi-domain networks. In this case the Network domain 1 VNC will be no different from the Multi-domain VNC (Telefonika)  on the picture. In particular, the Network domain 1 VNC would have to do the same inter-domain orchestration Sergio is talking about.

3. I hope we also agree that interface C will include not just abstract topology discovery/manipulation interface, but also service provisioning interface to provision e2e service segments in each of the child domains the service is going through. Consider Customer 1 on the picture (a bank - client of Telefonika) that only needs to interconnect its sites. There is np need for such client to use an abstract topology presented to it by the Telefonika controller - the Customer will simply use the service provisioning part of interface C. However, it is easy to envision a use case where the Customer (especially such as investment bank or broker) would want to use an abstract topology provided by the Telefonika controller (e.g. two SRLG disjoint abstract links) to place its services with the "no fate share" guarantee. This is even more true IMO if the Customer is Daniele's Cloud Network Controller (CNC). In this case   the CNC will operate on more complex abstract topologies provided by Telefonika and possibly other providers, thus, becoming functionally indistinguishable from the Telefonika's own VNC.

4. Considering mentioned above arguments in 1.-3. the only thing that would justify interface B distinct from interface C is the former providing semantics that could not be found in the latter, and I really struggle to find such semantics.

Cheers,
Igor

-----Original Message-----
From: Daniele Ceccarelli [mailto:[email-masked]] 
Sent: Tuesday, October 14, 2014 6:27 AM
To: BELOTTI, SERGIO (SERGIO); Igor Bryskin; Leeyoung; King, Daniel; [email-masked]; [email-masked]; [email-masked]
Cc: Varma, Eve L (Eve)
Subject: RE: draft-ceccarelli-actn-framework-03.txt comments

Hi Igor,

BR
Daniele

> From: BELOTTI, SERGIO (SERGIO) 
> [mailto:[email-masked]]
> To: Igor Bryskin; Leeyoung; Daniele Ceccarelli; King, Daniel; 
> abstract topology to the multi-vendor VNC, may use fully or partially 
> abstract topologies provided by one or more lower tier transport domains.
> Likewise, Customer 1 on the picture may use an abstract topology 
> provided by Multi-domain network (the VNC on the picture is part of).
> I tend to disagree here. What that can be discussed in my view it is 
> the need or not of interface C. What VNC is going to provide is a 
> double function of virtualizer of the network towards client 
> application level and orchestration, due to the need to span multiple 
> (virtual)NEs or multiple network domain . If we immmagine to encompass 
> these functionally into only one SDN controller , managing all virtual 
> network you would not use another interface between VNC and PNC.
> But towards client application there is another level of abstraction, 
> a real virtualization (to client) of resources with different 
> granularity and characteristics of the set of information needed to 
> the lower level of controller, as well explained by Young.
> It can debate if another separate entity as VNC can be , in this 
> architecture, the good choice, but I do not have preclusion on that.
> To: Leeyoung; BELOTTI, SERGIO (SERGIO); Daniele Ceccarelli; King, 
> Daniel; [email-masked]; [email-masked]; [email-masked]
> Cc: Varma, Eve L (Eve)
> abstract topology to the multi-vendor VNC, may use fully or partially 
> abstract topologies provided by one or more lower tier transport domains.
> Likewise, Customer 1 on the picture may use an abstract topology 
> provided by Multi-domain network (the VNC on the picture is part of).
> IB>> I am talking about the interface between transport domain server 
> IB>> and
> transport domain client. I would argue that the very same interface 
> can be used between a multi-domain provider (e.g. Telefonika) and its 
> clients. Not all such clients are dumb, as Daniele claims, and only 
> care about “a given amount of Gbps from A to B”. It is easy to 
> envision that some of the clients would want from Telefonica a couple 
> of SRLG-disjoint abstract links, so that the clients can have a say in 
> the placement of their  services across the Telefonika network. Three points here:
> 
> transport network provider and its client. Furthermore, the interface 
> can be used in the hierarchical way, that is, a client of a transport 
> domain can serve its own clients using the same interface as it uses 
> to talk to its own
> provider(s)
> 
> What is sitting above “VNC” (that coordinates over multi-domain 
> controllers) can be an internal service organization (of the same 
> operator) or service providers (different operators, forming carriers 
> of carrier). The control entity of these entities is referred to as 
> Customer Network control (CNC). The VNC –CNC interface (Interface B) 
> has different requirements than the VNC-PNC interface (Interface C). 
> Topology abstraction is just one of the requirements and in 
> multi-domain case, the VNC is performing multi-domain coordination 
> communications with different kinds of domain network control/management control (which is referred to as PNC, you call ANC).
> Each domain has its own ways of controlling its network, which ACTN is 
> not touching those at all. Whatever the choices of vendor control 
> regime will continue to be employed (GMPLS/ASON, PNNI, NMS, OpenFlow, etc.).
> 
> operated on an abstract level. We don’t want to inject the same level 
> of actual network topology (e.g., TED) as the domain controller 
> operates its physical/actual networks. Is this agreeable? You said 
> above this in c) The abstract topology presented to the client is 
> completely decoupled from the provider’s actual topology.
> 
> across multi-domain controllers (in terms of the sequence of the 
> end-to-end path across multiple domains). This is a new element I 
> believe ACTN will have to develop. This interface C (VNC-PNC) is very 
> different from Interface B (CNC-VNC). There are other differences 
> (please see Section 6.5 of the framework document).  But I agree with you that from an abstract topology
> said abstract topology could be as simple (e.g. a single abstract 
> node) or as complex (e.g. N abstract nodes interconnected by M 
> abstract links) as the client wants it to be (subject to the provider’s approval).
> 
> Best regards,
> Young
> 
> 
> 
> 
> To: BELOTTI, SERGIO (SERGIO); Daniele Ceccarelli; King, Daniel; 
> Leeyoung; [email-masked]; [email-masked]; [email-masked]
> Cc: Varma, Eve L (Eve)
> From: BELOTTI, SERGIO (SERGIO) 
> [mailto:[email-masked]]
> To: Igor Bryskin; Daniele Ceccarelli; King, Daniel; Leeyoung; 
> To: Daniele Ceccarelli; King, Daniel; Leeyoung; BELOTTI, SERGIO 
> (SERGIO); [email-masked]<mailto:[email-masked]>; 
> What do you mean by client here? The one that is the document is 
> called “service provider” or the one that is called “client” ? From 
> what you send I tend to think you are talking about the service 
> provider, but I might be wrong, please correct me.
> 
> IB>> By client I mean the client of a transport domain, the one who 
> IB>> speaks
> other end (i.e. on behalf of the transport service provider)  is the 
> transport domain’s Hypervisor.
> 
> SB>>> It is clear what you intend here, even if word client it seems 
> SB>>> to me
> IB>> I am talking about the interface between transport domain server 
> IB>> and
> transport domain client. I would argue that the very same interface 
> can be used between a multi-domain provider (e.g. Telefonika) and its 
> clients. Not all such clients are dumb, as Daniele claims, and only 
> care about “a given amount of Gbps from A to B”. It is easy to 
> envision that some of the clients would want from Telefonica a couple 
> of SRLG-disjoint abstract links, so that the clients can have a say in 
> the placement of their  services across the Telefonika network. Three points here:
> 
> transport network provider and its client. Furthermore, the interface 
> can be used in the hierarchical way, that is, a client of a transport 
> domain can serve its own clients using the same interface as it uses 
> to talk to its own
> provider(s)
> 
> Moreover I would avoid in this phase to mention any reference to 
> protocol implementation (e.g. Netconf/Restconf) : I think we are in 
> the phase to understand architecture, what are the relevant 
> interfaces, and what information is exchanged over the reference 
> points/interfaces. I guess this is clearly stated also in the charter of BoF.
> 
> IB>> Agree. I used Netconf/Restconf as an example to make it clear 
> IB>> what
> interface I was talking about.
> 
>  At an appropriate time – certainly not now – the next step is to 
> check with other SDOs on the availability of relevant core/technology 
> specific/application specific information model “fragments”, and then 
> finally proceed on the path of pruning/refactoring and mapping to 
> REST/JSON, Netconf/YANG, and any other possible data modeling and 
> configuration protocol existing. This is my understanding  of the BoF scope .
> 
> I don’t think the client of the multi-domain network wants to have a 
> so detailed view of the network, he does not care about domains, inter 
> domain links or whatever, I would say he only cares about a given 
> amount of Gbps from A to B with a given max delay and probably some diversity parameters.
> 
> IB>> Again, by client I mean multi-domain network controller (e.g. 
> IB>> Telefonica
> SDN controller), not the client using services of the multi-domain 
> network (i.e. not the Telefonica clients). Such client uses  the 
> transport domains for a reason. “a given amount of Gbps from A to B” 
> is too loose and little for the client to do the network planning. IMO 
> the client needs to *plan* the abstract topologies provided by the 
> transport domains the same or similar way as he would plan his own actual topology.
> 
> SB>>> yes, sure, in you view of “client” , this is the service 
> SB>>> provider Daniele is
> considered at this level. As I said to Young, in my previous mail, in 
> the case of a single domain scenario VNC and PNC could also coincide 
> but in case of a multi-domain scenarios the scope is to provide to 
> application layer a single virtualized view of the underline multi domain network.
> 
> On the other side, the one that cares about all of the issues you 
> listed is the service provider (as per actual document terminology). 
> However also the service provider does not go into physical impairment 
> details. He cares about connectivity between the borders of the 
> domains, inter domain links. How such connectivity is provisioned/managed is the network provider business.
> IB>> In this case my client is your service provider ;=). You 
> IB>> architecturally
> separate client from the service provider, because you probably 
> believe that it is possible to standardize the interface between the 
> two. I disagree with that and don’t think ACTN should work on this. In 
> the context of ACTN I see only two constructs: Transport domain 
> controller (transport service provider) and  Transport client controller (transport service user).
> 
> SB>>> ACTN here is not reinventing the wheel , in other SDO SDN 
> SB>>> specific is
> considered  the application layer , and the interface between AL and 
> SDN controller (in this case the VNC of ACTN) . This interface permit 
> to any client to directly impact to his own services and his own “virtualized” resources .
> 
> 
> Hence the interfaces to be considered are two, not three (as Dan said) 
> I think this replies to questions 1 and 3. Just to add something 
> regarding 2, I would say that they need just a single entry point to 
> the network control (could be a small piece of code running on top of 
> the PCE of your GMPLS domain), which acts as an interface between the 
> VNC and the control plane of your network and performs: “- Mapping of physical and virtual resources” and  “Requests:
> IB>> As I said, this is the task of the transport domain Hypervisor, 
> IB>> whose role
> is, essentially, to translate back and forth abstract <=> actual 
> topology elements and service requests/responses containing the 
> abstract/actual topology paths. I think that the north/south interface 
> between the transport domain Hypervisor and the entity representing 
> the client of the transport domain (no matter how you call it) is the 
> only interface ACTN can work on with the hope to produce something useful.
> 
> Cheers
> Daniele
> 
> 
> 
> It does not matter how you call me, and as John is helpfully applying, 
> you can ignore what I am saying. But let me explain in some more 
> details what I meant.
> 
> Suppose we have a client (such as TFK) of a multi-domain transport 
> network, who wants to provision and manipulate e2e transport services 
> the way he wants it (i.e. applying his policies). What would such client need?
> 
> 
> used by the client’s path computer to select service e2e paths. How 
> does the client get such a topology? The necessary overlay topology 
> comprises abstract topologies presented for the client by each of the 
> transport domains
> + inter-domain TE links. Hence we are talking about interface #1 (and 
> + data
> model #1) between a provider hypervisor/VNC and the client controller 
> to expose in a unified abstract  way  its topology on per client/tenant basis.
> Furthermore, the client controller can use this interface in the 
> opposite direction to modify the said abstract topology (subject to 
> the provider’s approval), because the client is the only guy who knows 
> how the abstract topology exposed to him should look like to be useful 
> (e.g. which and how the abstract links should be disjoint from each 
> other, how many of them should be provided, their attributes, desired 
> recovery capabilities, etc,). This knowledge is supposed to come from the client’s network planning.
> 
> computed e2e paths. The client’s controller does that by chopping the 
> paths into per-domain segments and instructs respective domain 
> segments. Hence we are talking about interface #2 (data model #2) for 
> the service segment manipulation;
> 
> So, we are talking 3 Yang models with required modifications to 
> neither Netconf/Restconf, nor  To any other management, routing or 
> signaling protocol.
> 
> based network intelligence, CIEN style PNNI based control plane, etc. 
> Why is that of ACTN’s business?
> 
> Cheers,
> Igor
> 
> Either way, the latest version of the Framework I-D is trying to focus 
> ACTN discussion and scope (i.e., the protocol work) on the interfaces 
> which are in scope, namely:
> 
> As Young suggests, if the VNC received physical topology info it would 
> be performing the role of the Physical Network Controller (PNC), which 
> is obviously a (somehow) required function, but the interface (direct 
> First of all, I think there was a misunderstanding here. First, your 
> assumption on VNC receiving actual underlying topology is incorrect. 
> If VNC were to have actually topology (e.g. TED) of a network, this 
> would be called a PNC and this is out of scope of ACTN. This aspect 
> has been discussed by email threads Daniele started a few weeks ago. 
> Check the archive on that. The reason this is out of scope is that PNC 
> multi-domain issue is no different from today’s GMPLS/PCE issue, 
> especially in light of H-PCE. ACTN does not step on those areas. What 
> VNC receives from each PNC (domain controller) is an abstracted 
> topology with varying degrees from actual underlying topology. The reason why we distinguish the term VNC from PNC.
> 
> What can be defined on VNC-PNC is a vertical signaling coordination 
> from VNC to each PNC. As long as the detailed path computation and 
> signaling within a domain are completely up to the domain PNC. VNC is 
> not to be operated on the same level as PNC. Its end-to-end path 
> computation is based on what is exposed from PNCs to VNC. The actual 
> topology information details is kept by PNCs and the PNCs expose 
> abstracted topology that can hide the exact details while exposing a minimum level of constraints.
> links) can be exposed for diversity routing calculation at the VNC. 
> This is very different from exposing the actual TE topology. You can 
> view this as two level of path computation. VNC first computes an 
> end-to-end path (using whatever constraint information it has), then 
> coordinates with each PNC (telling the border nodes information), then 
> each PNC computes the domain specific path. When a PNC cannot provide 
> a path segment in its domain, then this needs to be signaled to VNC so 
> that the VNC would arrange an alternate path segment to be able to 
> find a feasible end-to-end path.  I would say this is a “two-phase” 
> signaling and path computation. The point is that there must be some 
> level of hiding on abstract topology exposure from PNC to VNC and 
> proprietary characteristics of optical devices need to be dealt only with the corresponding PNC.
> 
> Lastly, please check the use-cases written by operators in the below 
> links that consistently say they need a standard interface that can 
> coordinate their multi-domain issues.
> 
> https://datatracker.ietf.org/doc/draft-klee-actn-connectivity-multi-ve
> ndor-
> domains/
> I believe having the same instance of VNC talking to different vendor 
> domain PNCs is an extremely  idealistic view.
> 
> Controller  (ANC). VNC (a.k.a. a Hypervisor) is managing abstract 
> topologies, and to be able do that, it talks to a ANC- a controller 
> which has an access and manages actual provider network).
> 
> topology, for example, to ensure that two abstract TE links are SRLG 
> disjoint as requested. Actual topology semantics (especially in WDM 
> layer) is very different from vendor to vendor and contains a great 
> variety of proprietary extensions, failing to understand which leads 
> to producing unprovisionable service paths. Do you really believe that 
> a single VNC can talk in the same way to ADVA, INFN, ALU and Huawei 
> ANCs? This is equivalent to ask all optical providers to switch to WSON :=).
> 
> This is not to say that you cannot build a hierarchy of VNCs, but in 
> this case North VNC plays role of a client network controller wrt to 
> South VNC, that is, uses the same X interface.
> IHMO whenever a VNC has to talk to a ANC, it does so in a proprietary 
> way, i.e. ADVA, INFN, ALU and Huawei will have their own VNCs exposing 
> the same north bound interface to potentially the same client (e.g.TFK).
> To: BELOTTI, SERGIO (SERGIO); [email-masked]<mailto:[email-masked]>; 
> Daniele Ceccarelli; [email-masked]<mailto:[email-masked]>;
> From: BELOTTI, SERGIO (SERGIO) 
> [mailto:[email-masked]]
> hierarchical level of controllers or linked to the multi-domain aspect 
> that compel to provide to the customer a single virtualized network 
> even if composed by real multi-domain multi-technology subnetworks? I 
> mean, the “virtualizer function” provided by VNC, in case of a single 
> domain context could be inside directly the PNC , correct?
> 
> YOUNG>> Yes. That is the correct view of VNC. For a single domain 
> YOUNG>> context,
> In my opinion, even for a single domain, I think there is benefit to 
> define this interface as a standard interface.
> 
> Section 2 , page 4:
> abstraction does not imply automatically virtualization,while 
> virtualization implies to have surely a certain form of abstraction. I 
> would suggest to consider good definition contained into ONF SDN 
> architecture document chapter 2.3 Conventions about abstraction and 
> virtualization. A good definition can help all the reading.
> 
> YOUNG>> Agree. We will look into the mentioned document if the usage 
> YOUNG>> of
> terms are aligned with this document. If not, we will clarify the 
> terminology more clearly.
> 
> Section 5: It seems to me you mixed here aspects that are more related 
> to policy like admission control  and guarantee of client isolation 
> with real computational issue like Computing time , path constrains or 
> re-optimization process. Moreover the term VNM for Virtual network 
> mapping is a bit misleading since this term in already used e.g. in 
> ABNO architecture for Virtual Network Manager.
> 
> YOUNG>> Indeed. In Section 5, we will put some notes on the aspect of 
> YOUNG>> real-
> time related from non real time aspect. VNM is not to be mixed with 
> Virtual Network Manager. Here VNM is an algorithm which is known as 
> Virtual Network Mapping which is a software module that converts 
> client requests into actual networks. Virtual Network Manager is ABNO 
> in my understanding is a developed concept from VNTM. But Dan King and 
> I will look at this more carefully on this aspect what Virtual Network Manager is doing.
> 
> SB>>> VNTM is strictly related to planning function so I this it is 
> SB>>> very import point in the context of PNC , I would say
> 
> Section 6.1 : while it is clear the scope of the different control 
> interface presented in figure 5, I’m a bit confused as to what I/F E 
> is – data plane interface to provider physical network? Or is the 
> intention to provide what can be the underlying model of resources 
> allocated to a customer from network provider controller, and the mapping to real physical resources ?
> YOUNG>> Interface E is not what ACTN will focus on. It simply shows  
> YOUNG>> an
> SB>>> So if I interpreted correctly your answer is more an internal 
> SB>>> interface
> Section 6.1, always figure 5: If a report of potential NW topology 
> between a VNC and a CNC can be queried , the arrow in the drawn has to 
> be bidirectional I guess
> 
> Figure 8 Section 6.4,page 28: “PCA abstracts the physical network 
> topology into an abstracted topology” Looking at the description of 
> VNC components in 6.2.2 it is the resource manager devoting to provide abstract topology.
> YOUNG>> Sorry for inconsistency. The intention was the PCA is the same 
> YOUNG>> as
> Figure 8 SEction 6.4, : In the picture there is no phase 7, and there 
> are 2 phase
> 8
> 
> I think this implies both interfaces B and C although primarily 
> between VNC- PNC.
> 
> 
> 
> SB>>> Sorry Young, iit is not referred to 7.3 , but in the chapter 6,5 
> SB>>> , on Interface interaction, after point 6, is indicated 
> SB>>> Interface B as interface between VNC and PNC, figure 5 says it 
> SB>>> is I/F C
> 
> 
> Thanks
> 
> Sergio
> 
> 
> Thanks
> Sergio

---

From: Leeyoung <[email-masked]>
Date: Tue, 14 Oct 2014 15:00:49 +0000

Hi Igor,

I am afraid that you have not read what I put. You are only considering abstract topology. The function of VNC and CNC are different from each other as I elaborate in the previous email. If you can read more carefully on the multi-domain coordination function of VNC in the picture, we may discuss more fruitfully. 

Interfaces B and C are clearly different interfaces, but there are some functions (like abstract topology) may be based on same model with different granularity, but that is only one aspect of the interface. What CNC and VNC do is quite different as I said before VNC has to coordinate multi-domain routing calculation and signaling coordination over several network domains. CNC does not do this function. 

Regards,
Young

-----Original Message-----
From: Igor Bryskin [mailto:[email-masked]] 
Sent: Monday, October 13, 2014 7:01 PM
To: Leeyoung; BELOTTI, SERGIO (SERGIO); Daniele Ceccarelli; King, Daniel; [email-masked]; [email-masked]; [email-masked]
Cc: Varma, Eve L (Eve)
Subject: RE: draft-ceccarelli-actn-framework-03.txt comments

Young,

Igor

Best regards,
Young

Hi Sergio,

Cheers,
Igor

Hi Igor,

Please, see in line

Regards
Sergio

Hi Daniele,
Please, see in line.
Igor

Hi Igor,

Cheers
Daniele

Young and Dan,

Cheers,
Igor

Br, Dan.

Hi Ignor,

Regards,
Young

Thanks,
Young

Hi Young,

Cheers,
Igor

Hi Young,

Regards
Sergio

Hi Sergio,

Regards,
Young

Section 2 , page 4:

   controllers.

Thanks

Sergio

Thanks
Sergio

---

From: Leeyoung <[email-masked]>
Date: Tue, 14 Oct 2014 15:07:41 +0000

Hi Sergio,

I agree with you on your perspective on VNC's dual functionality, virtualizer + multi-domain orchestration.

Regards,
Young

-----Original Message-----
From: ACTN [mailto:[email-masked]] On Behalf Of BELOTTI, SERGIO (SERGIO)
Sent: Tuesday, October 14, 2014 4:38 AM
To: Igor Bryskin; Leeyoung; Daniele Ceccarelli; King, Daniel; [email-masked]; [email-masked]; [email-masked]
Cc: Varma, Eve L (Eve)
Subject: Re: [Actn] draft-ceccarelli-actn-framework-03.txt comments

Hi Igor,

Igor"

Thanks

Regards
Sergio

-----Original Message-----
From: ACTN [mailto:[email-masked]] On Behalf Of Igor Bryskin
Sent: martedì 14 ottobre 2014 02:01
To: Leeyoung; BELOTTI, SERGIO (SERGIO); Daniele Ceccarelli; King, Daniel; [email-masked]; [email-masked]; [email-masked]
Cc: Varma, Eve L (Eve)
Subject: Re: [Actn] draft-ceccarelli-actn-framework-03.txt comments

Young,

Igor

Best regards,
Young

Hi Sergio,

Cheers,
Igor

Hi Igor,

Please, see in line

Regards
Sergio

Hi Daniele,
Please, see in line.
Igor

Hi Igor,

Cheers
Daniele

Young and Dan,

Cheers,
Igor

Br, Dan.

Hi Ignor,

Regards,
Young

Thanks,
Young

Hi Young,

Cheers,
Igor

Hi Young,

Regards
Sergio

Hi Sergio,

Regards,
Young

Section 2 , page 4:

   controllers.

Thanks

Sergio

Thanks
Sergio
[email-masked]

---

From: Leeyoung <[email-masked]>
Date: Tue, 14 Oct 2014 15:09:43 +0000

Hi Daniele,

I completely agree with you on your three points. Perhaps, we can go into more fruitful discussion by looking at Section 6.5 (Requirements for Interface B and C). 

Thanks,
Young

-----Original Message-----
From: Daniele Ceccarelli [mailto:[email-masked]] 
Sent: Tuesday, October 14, 2014 5:27 AM
To: BELOTTI, SERGIO (SERGIO); Igor Bryskin; Leeyoung; King, Daniel; [email-masked]; [email-masked]; [email-masked]
Cc: Varma, Eve L (Eve)
Subject: RE: draft-ceccarelli-actn-framework-03.txt comments

Hi Igor,

BR
Daniele

> abstract
> abstract

---

From: Igor Bryskin <[email-masked]>
Date: Tue, 14 Oct 2014 15:40:30 +0000

Young,
==>I am afraid that you have not read what I put. 
Don't be afraid :=). Not only I read , but I have an implementation close to what you describe.

===> You are only considering abstract topology.
No I am not. What can you do with the abstract topology, apart from using it for service provisioning? Look at it with a sexy GUI?

===>  The function of VNC and CNC are different from each other as I elaborate in the previous email.

Sure, but they both are parts of the same network controller which exposes and uses the same interface (interface C) and the same set of models (one for abstract topology manipulation and one for the service provisioning) north-bound and south-bound. This is how you make the architecture hierarchical.

===> If you can read more carefully on the multi-domain coordination function of VNC in the picture, we may discuss more fruitfully. 
I also suggest you to read carefully my response to Sergio and Daniele.

Cheers,
Igor

Regards,
Young

-----Original Message-----
From: Igor Bryskin [mailto:[email-masked]] 
Sent: Monday, October 13, 2014 7:01 PM
To: Leeyoung; BELOTTI, SERGIO (SERGIO); Daniele Ceccarelli; King, Daniel; [email-masked]; [email-masked]; [email-masked]
Cc: Varma, Eve L (Eve)
Subject: RE: draft-ceccarelli-actn-framework-03.txt comments

Young,

Igor

Best regards,
Young

Hi Sergio,

Cheers,
Igor

Hi Igor,

Please, see in line

Regards
Sergio

Hi Daniele,
Please, see in line.
Igor

Hi Igor,

Cheers
Daniele

Young and Dan,

Cheers,
Igor

Br, Dan.

Hi Ignor,

Regards,
Young

Thanks,
Young

Hi Young,

Cheers,
Igor

Hi Young,

Regards
Sergio

Hi Sergio,

Regards,
Young

Section 2 , page 4:

   controllers.

Thanks

Sergio

Thanks
Sergio