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

[John E Drake <[e-mail]>]

It's actually spelled Ignore 8->

Yours Irrespectively,

John

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

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); [e-mail]<mailto:[e-mail]>; Daniele Ceccarelli; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
Cc: Varma, Eve L (Eve)
Subject: RE: draft-ceccarelli-actn-framework-03.txt comments

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:[e-mail]]
Sent: Thursday, October 09, 2014 1:48 PM
To: BELOTTI, SERGIO (SERGIO); Leeyoung; [e-mail]<mailto:[e-mail]>; Daniele Ceccarelli; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
Cc: Varma, Eve L (Eve)
Subject: RE: draft-ceccarelli-actn-framework-03.txt comments

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:[e-mail]] On Behalf Of BELOTTI, SERGIO (SERGIO)
Sent: Thursday, October 09, 2014 5:59 AM
To: Leeyoung; [e-mail]<mailto:[e-mail]>; Daniele Ceccarelli; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
Cc: BELOTTI, SERGIO (SERGIO); Varma, Eve L (Eve)
Subject: Re: [Actn] draft-ceccarelli-actn-framework-03.txt comments

Hi Young,

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

Regards
Sergio



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

Hi Sergio,

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

Regards,
Young

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

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?

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.

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

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

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

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!



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

YOUNG>> Thanks. Good catch!

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

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.



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