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

[Daniele Ceccarelli <[e-mail]>]

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



> -----Original Message-----
> From: BELOTTI, SERGIO (SERGIO) [mailto:[e-mail]]
> Sent: martedì 14 ottobre 2014 11:38
> To: Igor Bryskin; Leeyoung; Daniele Ceccarelli; King, Daniel; [e-mail];
> [e-mail]; [e-mail]
> Cc: Varma, Eve L (Eve)
> Subject: RE: draft-ceccarelli-actn-framework-03.txt comments
> 
> 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:[e-mail]] On Behalf Of Igor Bryskin
> Sent: martedì 14 ottobre 2014 02:01
> To: Leeyoung; BELOTTI, SERGIO (SERGIO); Daniele Ceccarelli; King, Daniel;
> [e-mail]; [e-mail]; [e-mail]
> Cc: Varma, Eve L (Eve)
> Subject: Re: [Actn] draft-ceccarelli-actn-framework-03.txt comments
> 
> 
> 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:
> 
> 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)
> 
> 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:[e-mail]]
> Sent: Monday, October 13, 2014 9:17 AM
> To: BELOTTI, SERGIO (SERGIO); Daniele Ceccarelli; King, Daniel; Leeyoung;
> [e-mail]; [e-mail]; [e-mail]
> Cc: Varma, Eve L (Eve)
> Subject: RE: draft-ceccarelli-actn-framework-03.txt comments
> 
> Hi Sergio,
> A couple of comments in line.
> 
> Cheers,
> Igor
> 
> From: BELOTTI, SERGIO (SERGIO) [mailto:[e-mail]]
> Sent: Monday, October 13, 2014 9:15 AM
> To: Igor Bryskin; Daniele Ceccarelli; King, Daniel; Leeyoung; [e-mail];
> [e-mail]; [e-mail]
> 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:[e-mail]]
> Sent: venerdì 10 ottobre 2014 22:37
> To: Daniele Ceccarelli; King, Daniel; Leeyoung; BELOTTI, SERGIO (SERGIO);
> [e-mail]<mailto:[e-mail]>; [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 Daniele,
> Please, see in line.
> Igor
> 
> From: Daniele Ceccarelli [mailto:[e-mail]]
> Sent: Friday, October 10, 2014 1:25 PM
> To: Igor Bryskin; King, Daniel; Leeyoung; BELOTTI, SERGIO (SERGIO);
> [e-mail]<mailto:[e-mail]>; [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 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.
> 
> 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 .
> 
> 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
> 
> 
> 
> From: Igor Bryskin [mailto:[e-mail]]
> Sent: venerdì 10 ottobre 2014 03:16
> To: King, Daniel; Leeyoung; 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
> 
> 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:[e-mail]]
> Sent: Thursday, October 09, 2014 4:58 PM
> To: Leeyoung; 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 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:[e-mail]] On Behalf Of Leeyoung
> Sent: 09 October 2014 21:32
> 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: [Actn] 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,
> 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
> 
> 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 ,
> 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