Re: [Actn] New Version Notification for draft-ceccarelli-actn-framework-05.txt

[Dave Hood <[e-mail]>]

One point that should be understood about recursion is that, from the viewpoint of any given player, recursion is (or ought to be) invisible. Only from our viewpoint on Mt Olympus can we, the gods, tell that some particular deployment is recursive or not. Otherwise, the abstraction has not been properly structured.

The exception would be at the absolute bottom of the stack, where the visibility of physical parameters would be a clue. 

Dave

-----Original Message-----
From: ACTN [mailto:[e-mail]] On Behalf Of Igor Bryskin
Sent: Monday, January 05, 2015 11:45 AM
To: Daniele Ceccarelli; Khuzema Pithewan; BELOTTI, SERGIO (SERGIO); Leeyoung
Cc: [e-mail]; Victor Lopez; Dhruv Dhody; AshwoodsmithPeter
Subject: Re: [Actn] New Version Notification for draft-ceccarelli-actn-framework-05.txt

Hi Daniele,

I knew you'd love the football analogy.

You said:
DC>>>. I don't think that TFK controller (in your example below), which is a MDSC wants to know all the details of ADVA network and speak all the protocols and extensions that ADVA PNC speaks.

IB>> I think you are still missing the point. ADVA controller will only use ACTN interface to talk to TFK Controller (and nothing else). It will provide tFK with abstract TE topology of ADVA domain fine-tuned to the TFK needs (rather than actual TE topology). It will never convey to TFK any details that TFK does not care about. It will remain unknown to TFK what CP/MP protocols  ADVA uses internally.

DC>> My idea was to have the PNCs unaware of services (like GMPLS) and let only the MDSCs know about services. Maybe both scenarios should be foreseen.
IB>> This I don't get. PNC is always aware what is happening in the network it controls. If the actual service provisioning is controlled by local GMPLS CP, the latter is just a distributed automation of the PNC functionality. Stateful active PCE is one alternative to GMPLS-based PNC. Old-fashioned NMS is another alternative.

Cheers,
Igor

-----Original Message-----
From: Daniele Ceccarelli [mailto:[e-mail]]
Sent: Monday, January 05, 2015 10:45 AM
To: Igor Bryskin; Khuzema Pithewan; BELOTTI, SERGIO (SERGIO); Leeyoung
Cc: Dhruv Dhody; [e-mail]; Victor Lopez; AshwoodsmithPeter
Subject: RE: [Actn] New Version Notification for draft-ceccarelli-actn-framework-05.txt

Hi Igor, Khuzema, all,

I'm happy to see that there is a general agreement on the four different types of functionalities. The disagreement is still on their recursiveness and on where they are placed in the hierarchy, but this is step 2. 

I love the football metaphor because our idea was to define the "skills" of the players (scoring, passing, playmaking, goal keeping...).  Then we decided to call "forward" the player that is good at scoring and playmaking but has no goal keeping skill. Only the forwards need to be good at scoring? Not necessarily. The scoring skill can be present also in many midfielders, but it is not needed in the goal keeper. 

Igor is convincing me that such features might be more present at the different layers of the hierarchy than I supposed but there are still some of them that are limited to some levels of the hierarchy, like e.g. understanding physical impairments. I don't think that TFK controller (in your example below), which is a MDSC wants to know all the details of ADVA network and speak all the protocols and extensions that ADVA PNC speaks. 
You might want to build a controller extremely powerful and rich of functionalities to be sold both as PNC and MDSC, that's reasonable, but I would say not mandatory.

Igor, one thing is used to disagree with you about is the services management. My idea was to have the PNCs unaware of services (like GMPLS) and let only the MDSCs know about services. Maybe both scenarios should be foreseen.

Cheers
Daniele

> -----Original Message-----
> From: Igor Bryskin [mailto:[e-mail]]
> Sent: lunedì 5 gennaio 2015 14:47
> To: Khuzema Pithewan; BELOTTI, SERGIO (SERGIO); Leeyoung
> Cc: Dhruv Dhody; [e-mail]; Victor Lopez; Daniele Ceccarelli; 
> AshwoodsmithPeter
> Subject: RE: [Actn] New Version Notification for
> draft-ceccarelli-actn- framework-05.txt
> 
> Hi Khusema,
> 
> I do not believe that there are ACTN functions that are not 
> hierarchical in nature.
> 
> Please, consider the following simple example:
> A client Microsoft, MSFT, is using provider Telefonika, TFK, to setup 
> and manage its transport services. TFK is using two child domains, one 
> made of ADVA and another of Infanera, INFN switches.
> A couple of questions to you:
> 1. Is it not possible that in order to set up/manipulate a given e2e 
> transport service, MSFT will use more than one provider (i.e. not just
> TFK) ?  The answer "it is possible" means that MSFT is going to need 
> two things: a) multi- domain service coordination and b) an abstract 
> TE view of a multi-domain transport network so that MSFT would have a 
> say as to how the service is placed; 2. Suppose the client is not 
> MSFT, rather, a transport department of MSFT, providing transport 
> services to other MSFT departments, applications and even clients. In this case it would need to perform the "client-mapping"
> function, the very same one that TFK will do for its client MSFT, and 
> ADVA for its client TFK.
> 3. Where is the difference between MSFT, TFK and ADVA or INFN in the 
> context of ACTN?
> 
> When you say that certain ACTN functions need not to be hierarchical, 
> you put a celling/floor on the ACTN hierarchy. As mentioned before, I 
> see the ACTN architecture as an open at the top and the bottom 
> hierarchy of transport SDN controllers. Said controllers can 
> potentially support each of the ACTN functions (with some disabled or 
> not implemented, if not needed at the moment, but which could be enabled/implemented if/when needed).
> Each pair of controllers adjacent in the hierarchy use exactly the 
> same interface supported by exactly the same set of data models:
> topology, service, OAM, policies). Only this way IMHO it would be 
> possible to address the scaling challenges (e.g. to interconnect 
> millions of MSFT servers via a single framework).
> 
> Cheers,
> Igor
> 
> -----Original Message-----
> From: Khuzema Pithewan [mailto:[e-mail]]
> Sent: Friday, January 02, 2015 6:13 PM
> To: Igor Bryskin; BELOTTI, SERGIO (SERGIO); Leeyoung
> Cc: Dhruv Dhody; [e-mail]; Victor Lopez; Daniele Ceccarelli; 
> AshwoodsmithPeter
> Subject: RE: [Actn] New Version Notification for
> draft-ceccarelli-actn- framework-05.txt
> 
> Hi Igor/Young/Daniele/Peter,
> 
> Out of 4 ACTN main functions, I see following 2 are required to be 
> repeatable in the hierarchy and hence requires multi-level recursion.
> 
> 1. virtualization/abstraction function 2. multi domain coordination 
> function
> 
> Rest of the functions doesn’t need recursion because of their nature.
> 
> a. customer mapping function
> b. virtual service coordination
> 
> Both of the following functionality directly interfaces with Customer 
> applications and requires them to directly pass on the series of 
> commands to topology handler in order to realize a function of 
> application.  However these 2 functions need resiliency / redundancy 
> from customer application perspective and hence state coherency may be 
> required across different instances of the modules that hosts these functions.
> 
> 
> Physical network control has to be dedicated to one controller closest 
> to NE and hence doesn't need hierarchy.
> 
> With this I would like to propose a different packaging of these 5 
> functions, based on their characteristics.
> 
> Would like to propose that -
> 1. virtualization and Multi-domain control function to be bundled into 
> one component, which can be standardized in such a way that it can be 
> hierarchical and forms the core of ACTN framework 2. Physical Network 
> controller component can be built in such a way that it can interface 
> with Virtualization and multi-domain controller on north side and 
> controls NE towards south.
> 3. Customer mapping and virtual service co-ordination deals with 
> Virtualization and multi-domain controller on south and interfaces 
> with customer application on north.
> 
> To realize use-cases, where we don’t really have virtualization and 
> there is no need of multi-domain control, we have 2 options :
> Option#1 - Interface portion that deals with customer mapping function 
> is designed in such a way that it can deal with virtual or physical 
> topology in same way, as these use-cases won't need Virtual service coordination.
> Option#2 - Make it possible to have virtualization and multi-domain 
> control function as part of PNC.
> 
> I prefer option#1, as it simplifies architecture.
> 
> Thoughts?
> 
> Thanks
> Khuzema
> 
> 
> 
> -----Original Message-----
> From: ACTN [mailto:[e-mail]] On Behalf Of Igor Bryskin
> Sent: Monday, December 22, 2014 5:36 AM
> To: BELOTTI, SERGIO (SERGIO); Leeyoung
> Cc: Dhruv Dhody; [e-mail]; Victor Lopez; Daniele Ceccarelli; 
> AshwoodsmithPeter
> Subject: Re: [Actn] New Version Notification for
> draft-ceccarelli-actn- framework-05.txt
> 
> Young and Sergio,
> 
> Now the ACTN framework increasingly reminds me of the Barcelona FC
> lineup: here is Luis Suarez. He plays right forward position, but he 
> can also play left and center forward. Here is Neymar. He can play all 
> the positions as Suarez plus attacking midfielder, and here is Leo 
> Messi, who can play any position! ;+) ! I understand why such 
> redundancy in capabilities is necessary in football (injuries, fitness 
> problems, red cards, etc.). But why one would need 50%+ redundancy in 
> capabilities of distinct components in a network architecture? Can you 
> give an example of any other network solution designed in IETF, ITU or 
> anywhere else that has the same level of redundancy? Why any given 
> ACTN component  should not be Messi with some of his skills disabled 
> or not implemented if they are not necessary? For example, what does 
> it mean "client" and "client mapping"? Can the client serve its own 
> clients? If Yes, why the client is not , generally speaking, a MDSC?
> 
> Cheers, Merry Christmas and Happy New Year.
> Igor
> 
> -----Original Message-----
> From: BELOTTI, SERGIO (SERGIO)
> [mailto:[e-mail]]
> Sent: Monday, December 22, 2014 5:43 AM
> To: Leeyoung; Igor Bryskin
> Cc: [e-mail]; AshwoodsmithPeter; Daniele Ceccarelli; Dhruv Dhody; 
> Victor Lopez
> Subject: RE: [Actn] New Version Notification for
> draft-ceccarelli-actn- framework-05.txt
> 
> Hi Igor,
> 
> I think Young exactly pointed out what I tried to explain in my 
> previous mail so I do not have much to add.
> One of the basic use cases on which ACTN is focused is how to create a 
> virtualized environment permitting to operators the view of an 
> abstraction of the underlying multi-vendor, multi-admin and multi-technology network.
> You do not need to export towards MSDC specif characteristics of your 
> network but ACTN want to permit export of abstraction view .
> This has to be standardize in the interface between MSDC and PNC not 
> actual physical network resources.
> So, this restriction and scope is not idealistic but this 
> orchestration functionality is what operator want.
> 
> Cheers and ...Merry Christmas and Happy New Year.
> 
> Sergio
> 
> 
> 
> -----Original Message-----
> From: Leeyoung [mailto:[e-mail]]
> Sent: venerdì 19 dicembre 2014 22:27
> To: Igor Bryskin; BELOTTI, SERGIO (SERGIO); AshwoodsmithPeter; Daniele 
> Ceccarelli; Dhruv Dhody
> Cc: [e-mail]
> Subject: RE: [Actn] New Version Notification for
> draft-ceccarelli-actn- framework-05.txt
> 
> Hi Igor,
> 
> I think there needs some clarification about what is PNC and what is MSDC.
> We define PNC as follows (Section 3.3):
> 
> "The physical network controller is the one in charge of configuring 
> the network elements, monitoring the physical topology of the network 
> and passing it, either raw or abstracted, to the MDSC. ...
> The PNC, in addition to being in charge of controlling the physical 
> network, is able to implement two of the four ACTN main
> functionalities: multi domain coordination function and virtualization/abstraction function."
> 
> And MDSC as follows (Section 3.3):
> 
> "The MSDC (Multi Domain Service Coordinator) sits between the CNC (the 
> one issuing connectivity requests) and the PNCs (Physical Network 
> Controllers - the ones managing the physical network resources). The 
> MSDC can be collocated with the PNC, especially in those cases where 
> the service provider and the network provider are the same entity. ...
> The MDSC is the only building block of the architecture that is able 
> to implement all the four ACTN main functionalities, i.e. multi domain 
> coordination function, virtualization/abstraction function, customer 
> mapping function and virtual service coordination."
> 
> As Sergio pointed out, there are some duplicated functions between PNC 
> and
> MSDC: (i) multi-domain coordination; (ii) virtualization/function 
> while the MSDC performs two additional functionality interfacing the
> CNC: (i) customer mapping; (ii) virtual service coordination and the 
> PNC performs network control of physical networks.
> 
> With this definition, we can achieve what you describing. Please see 
> in-line for my specific comment.
> 
> Thanks,
> Young
> 
> 
> -----Original Message-----
> From: Igor Bryskin [mailto:[e-mail]]
> Sent: Friday, December 19, 2014 2:34 PM
> To: BELOTTI, SERGIO (SERGIO); Leeyoung; AshwoodsmithPeter; Daniele 
> Ceccarelli; Dhruv Dhody
> Cc: [e-mail]
> Subject: RE: [Actn] New Version Notification for
> draft-ceccarelli-actn- framework-05.txt
> 
> Sergio,
> 
> In a single vendor environment it is Ok to separate MDSC function from 
> PNC function (manipulating actual network resources) into separate 
> physical locations and have the two entities talk to each other any way they want.
> Nor I have a problem to put both functions into the same box (BTW neither
> does   Daniele according to some of his emails). But this is beside the point.
> My problem is that you define in the ACTN architecture two distinct entities:
> MDSC and PNC. This entails a standardized interface between the two 
> that would allow a vendor X MDSC to talk to a vendor Y PNC in terms of 
> actual network resources the same way as to vendor Z PNC. I think this 
> is an idealistic view: to me it is the same as to ask, for example, 
> CIEN, INFN, ADVA, ALU, etc. to start supporting WSON RFCs. If this was 
> possible, we would have by now a multi-vendor multi-domain GMPLS 
> solution. The RFCs may be endorsed by CCAMP WG, but it does not mean 
> that the vendors have actually implemented them and use in the 
> products. Each of the vendors have different hardware and a lot of 
> proprietary extensions imperative for provisioning of physical resources.
> 
> YOUNG>> Vendor X MDSC can talk to Vendor Y PNC and Vendor Z PNC in
> abstracted view (not actual network resource) based on what we defined 
> above. Again the PNC needs not send actual network resource info to MDSC.
> Rather, the PNC should send abstract network resource view to the MDSC.
> With this, multi-vendor controllers can interoperate with standard 
> data model.
> 
>  I do believe, though, that it is possible to get vendor X MDSC to 
> talk to vendor Y or Z MDSC in terms of abstract (visualized) network 
> resources. In other words, provider X and Y SDN controllers should see 
> each other as MDSCs capable when necessary of either or both MDSC 
> or/and PNC functions.
> 
> YOUNG>> Yes, this is the point I tried to come across in the above comment.
> 
> Cheers,
> Igor
> 
> -----Original Message-----
> From: BELOTTI, SERGIO (SERGIO)
> [mailto:[e-mail]]
> Sent: Friday, December 19, 2014 10:43 AM
> To: Leeyoung; AshwoodsmithPeter; Igor Bryskin; Daniele Ceccarelli; 
> Dhruv Dhody
> Cc: [e-mail]
> Subject: RE: [Actn] New Version Notification for
> draft-ceccarelli-actn- framework-05.txt
> 
> Hi all,
> 
> At first thanks to Igor and Peter to help discussion and in this way 
> highlighting possible needs or gaps in the reference model proposed in the framework.
> 
> I share Young observations: Peter's illustration is very interesting 
> but the fact to put an Hardware abstraction layer on MSDC is something 
> would not be part of his role in the network. E.g. if I remember well 
> hardware abstraction layer in the ONF architecture is on the NE of the 
> network domain, it is very close to physical aspect of the network 
> domain. If this would be one of the function on MSDC it is clearly not 
> in the scope of the reference model proposed that start from the basic 
> scope to create an entity strictly in relation with CNC (application
> level) to create an abstraction e2e view to simply network operation from client prespective.
> We can certainly encompass everything at one level , but scalability 
> and simplified view towards clients is not perceived .
> Moreover , as mentioned in chapter 3 , and indicated by Daniele, some 
> mails ago, it is not only a multi-domain coordination function in the 
> scope of MSDC but there are 2 specific  functionality like "customer mapping function"
> and " virtual service coordination" that in our view are part of a 
> more high entity with respect a controller like PNC. Encompassing all 
> in only one entity can fall heavily  in both scalability and  CPU 
> process requirement as mentioned  by Young.
> 
> Thanks
> Sergio
> 
> 
> 
> -----Original Message-----
> From: Leeyoung [mailto:[e-mail]]
> Sent: venerdì 19 dicembre 2014 00:01
> To: AshwoodsmithPeter; Igor Bryskin; BELOTTI, SERGIO (SERGIO); Daniele 
> Ceccarelli
> Cc: [e-mail]
> Subject: RE: [Actn] New Version Notification for
> draft-ceccarelli-actn- framework-05.txt
> 
> Hi Peter,
> 
> An interesting illustration! I agree with you on the code saving part. 
> The code saving, however, would come at the expense of scalability if 
> I understood correctly. This is exactly what operators want to avoid.
> 
> Besides, the second one's MSDC would have need more CPU to process the 
> larger data than the first one's MSDC.
> 
> Thanks,
> Young
> 
> 
> 
> -----Original Message-----
> From: ACTN [mailto:[e-mail]] On Behalf Of 
> AshwoodsmithPeter
> Sent: Thursday, December 18, 2014 1:33 PM
> To: Igor Bryskin; BELOTTI, SERGIO (SERGIO); Daniele Ceccarelli
> Cc: [e-mail]
> Subject: Re: [Actn] New Version Notification for
> draft-ceccarelli-actn- framework-05.txt
> 
> Igor, playing devil's advocate-  in the case you describe the PCN 
> control of the hub element could be through a dedicated PCN just for 
> that NE. For example (and I hope the ASCII art survives the email 
> mappings), given 7 network elements grouped into two domains and one 
> hub (N4), we could treat the single hub as a domain by itself with its own PCN.
> 
>                  M S D N
>                     |
>     +---------------+---------------+       <-- I/F 'C'
>     |               |               |
>    PCN             PCN             PCN
>     |               |               |
>  +--+--+            |            +--+--+    <-- I/F 'D'
>  |  |  |            |            |  |  |
> (N1,N2,N3)=========(N4)=========(N5,N6,N7)
>           I.D.LINK    I.D.LINK
> 
> 
> Alternatively if we treated the MSDN and PCN as the same 'thing', then 
> the combined block has to have a hardware abstraction layer anyway so 
> whatever is below that layer is logically a kind of PCN anyway EXCEPT 
> it does not have to worry about topology abstraction.
> 
> So the alternative requires the MSDNs to have some function X when 
> they are talking directly to a bit of hardware i.e. don't speak the 
> MSDN to MSDN I/F. I.E X is a kind of PCN 'light' (i.e. no abstraction capability).
> 
>                  M S D N
>                  |  X  |
>     +------------+  |  +------------+
>     |               |               |
>   MSDN              |              MSDN
>     X               |               X
>  +--+--+            |            +--+--+
>  |  |  |            |            |  |  |
> (N1,N2,N3)=========(N4)=========(N5,N6,N7)
>           I.D.LINK    I.D.LINK
> 
> If one compares the two approaches in terms of the amount of code 
> required, it's clear that there is a code savings with the second 
> approach because there is only one block that is abstracting topology 
> and passing it up, while with a totally separate PCN that type of code is replicated twice.
> 
> Are there other overlaps that disappear if MSDN and PCN are integrated?
> What are the disadvantages?
> 
> Peter
> 
> > -----Original Message-----
> > From: Igor Bryskin [mailto:[e-mail]]
> > Sent: Thursday, December 18, 2014 8:48 AM
> > To: BELOTTI, SERGIO (SERGIO); AshwoodsmithPeter; Daniele Ceccarelli
> > Cc: [e-mail]
> > Subject: RE: [Actn] New Version Notification for
> > draft-ceccarelli-actn- framework-05.txt
> >
> > Hi Sergio,
> >
> > I agree with what you said. This is especially true and apparent in 
> > the configurations where the domains controlled by the subordinate 
> > providers are interconnected not just by inter-domain links, but via 
> > segments of accrual network. Consider, for example, the situation 
> > when said domains are inter-connected in a star-n-spokes fashion 
> > with an actual network element as the star. MDSC would the only 
> > entity in this case to control it. So, esteemed fellow ACTNers:
> > a) Generally speaking, MDSC needs to be able to control actual 
> > network elements and links, and
> > b) PNC needs to be able to perform multi-domain coordination (in 
> > case it uses several subordinate PNCs of it's own)
> >
> > This brings us back to the same question: where is the conceptual 
> > difference between the two, and why do  they appear in the framework 
> > as separate logical entities?
> >
> > Cheers,
> > Igor
> >
> >
> > -----Original Message-----
> > From: BELOTTI, SERGIO (SERGIO) [mailto:sergio.belotti@alcatel- 
> > lucent.com]
> > Sent: Thursday, December 18, 2014 3:53 AM
> > To: AshwoodsmithPeter; Daniele Ceccarelli
> > Cc: Igor Bryskin; [e-mail]
> > Subject: RE: [Actn] New Version Notification for
> > draft-ceccarelli-actn- framework-05.txt
> >
> > Hi Peter,
> >
> > you're right : this functionality has to be part of "Multi domain 
> > coordination function", and has has to be explicitly mentioned.
> >
> > Thanks
> > Sergio
> >
> >
> > -----Original Message-----
> > From: ACTN [mailto:[e-mail]] On Behalf Of 
> > AshwoodsmithPeter
> > Sent: mercoledì 17 dicembre 2014 21:38
> > To: Daniele Ceccarelli; Igor Bryskin; [e-mail]
> > Subject: Re: [Actn] New Version Notification for
> > draft-ceccarelli-actn- framework-05.txt
> >
> > Hey Daniele,
> >
> > A few very minor typos and a simple question.
> >
> > Page3 "such that resource guarantee" should be "such that resource 
> > guarantees"
> > Page6 "bundle of voice service" should be "bundle of voice services"
> > Page6 "and they generally has very few" should be "and they 
> > generally have very few"
> > Page6 "which is usually best-efforts" should be "which is usually
> > best- effort"
> > Page6 "one of reasons" should be "one of the reasons"
> >
> > There are a number of other minor nits like that. I'll try to 
> > forward you some off the list.
> >
> > simple question:
> >
> > What about responsibility for inter domain links? Would that not be 
> > a function of the MCDF? Don't see it discussed.
> >
> > Peter
> >
> > > -----Original Message-----
> > > From: Daniele Ceccarelli [mailto:[e-mail]]
> > > Sent: Wednesday, December 17, 2014 11:43 AM
> > > To: AshwoodsmithPeter; Igor Bryskin; [e-mail]
> > > Subject: RE: [Actn] New Version Notification for
> > > draft-ceccarelli-actn- framework-05.txt
> > >
> > > Hi Peter,
> > >
> > > Thanks for jumping in. I definitely agree with you and Igor 
> > > depending on the cases. I think my last reply to Igor should 
> > > address your concerns.
> > >
> > > BR
> > > Daniele
> > >
> > > > -----Original Message-----
> > > > From: AshwoodsmithPeter [mailto:[e-mail]]
> > > > Sent: mercoledì 17 dicembre 2014 16:48
> > > > To: Igor Bryskin; Daniele Ceccarelli; [e-mail]
> > > > Subject: RE: [Actn] New Version Notification for
> > > > draft-ceccarelli-actn- framework-05.txt
> > > >
> > > > There is a definite elegance to what Igor suggests and 
> > > > experience
> > > with
> > > > recursion definitely teaches that elegance is associated with
> > > correctness.
> > > >
> > > > Peter
> > > >
> > > > > -----Original Message-----
> > > > > From: ACTN [mailto:[e-mail]] On Behalf Of Igor 
> > > > > Bryskin
> > > > > Sent: Wednesday, December 17, 2014 9:08 AM
> > > > > To: Daniele Ceccarelli; [e-mail]
> > > > > Subject: Re: [Actn] New Version Notification for
> > > > > draft-ceccarelli-actn- framework-05.txt
> > > > >
> > > > > Hi Daniele,
> > > > >
> > > > > >> I'm not too "religious" about the naming but I think a 
> > > > > >> distinction
> > > > > is useful.
> > > > >
> > > > > The point is that if we say that MDSC and PSC are the same, we 
> > > > > will have one component less in the framework, and the lesser 
> > > > > we have components the easier it is to make the framework recursive.
> > > > >
> > > > > >> One further thing that in my opinion is only relevant to 
> > > > > >> the
> > > MDSC
> > > > > >> is
> > > > > the management of non-connectivity services, i.e. the ones 
> > > > > that are called " Network Function Virtualization Services". I 
> > > > > am
> > think
> > > > > of a customer requesting for a virtual machine and a given 
> > > > > amount of storage. The PNC is the one in charge of providing
> > connectivity
> > > > > towards the data-center but other things like VM redundancy, 
> > > > > VM mobility between DCs, storage location and services like 
> > > > > that go beyond the scope of the PNC, or to better say: I would 
> > > > > split so different functionalities into different entities.
> > > > >
> > > > > I respectively disagree with this. IMHO the recursive nature 
> > > > > of the interface between service client and service provider 
> > > > > applies to
> > > all
> > > > > the provided services: abstract topology, connectivity, 
> > > > > network function virtualization, etc. I hope you agree that if 
> > > > > a client requests a VNF, the latter does not have to be mapped 
> > > > > directly on a physical NF, rather, it could be further 
> > > > > requested from a subordinate provider.
> > > > > To put it simply ACTN framework could be described as a stack 
> > > > > of MDSCs with the same interface (supported by the same set of
> > > > > models) between any two adjacent MDSCs in the stack.
> > > > >
> > > > > Cheers,
> > > > > Igor
> > > > >
> > > > > -----Original Message-----
> > > > > From: Daniele Ceccarelli
> > > > > [mailto:[e-mail]]
> > > > > Sent: Wednesday, December 17, 2014 5:51 AM
> > > > > To: Igor Bryskin; [e-mail]
> > > > > Subject: RE: [Actn] New Version Notification for
> > > > > draft-ceccarelli-actn- framework-05.txt
> > > > >
> > > > > Hi Igor,
> > > > >
> > > > > Thanks a lot for the review.
> > > > > Regarding your comments please see in line.
> > > > >
> > > > > Cheers,
> > > > > Daniele
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: Igor Bryskin [mailto:[e-mail]]
> > > > > > Sent: lunedì 15 dicembre 2014 20:50
> > > > > > To: Daniele Ceccarelli; [e-mail]
> > > > > > Subject: RE: [Actn] New Version Notification for
> > > > > > draft-ceccarelli-actn- framework-05.txt
> > > > > >
> > > > > > Hi Daniele,
> > > > > >
> > > > > > I have a couple of comments:
> > > > > > 1. I don't think that one of explicit Adrian's requests - 
> > > > > > the recursive nature of the ACTN architecture with 
> > > > > > corresponding
> > use
> > > > > cases
> > > > > > (when a client of a transport network serves as a transport 
> > > > > > provider for its own clients, and when the transport network 
> > > > > > provider makes
> > > > > use
> > > > > > of its own providers0 - is not properly elaborated  in the
> > > document.
> > > > > I
> > > > > > think a dedicated section is necessary.
> > > > >
> > > > > I tried to capture in figure 3 the PNC recursiveness but the
> > ASCII
> > > > > in this case didn't help much. Maybe a dedicated section with
> > some
> > > > > text and a focused figure would be helpful. If you could 
> > > > > provide it I would be happy to include it.
> > > > >
> > > > > >
> > > > > > 2. On Figure 4. It is shown that a PNC can make use of other 
> > > > > > PNCs (e.g. one in the middle of the picture). I assume that
> > said
> > > > > > PNC can talk to more than one subordinate PNCs. If this is 
> > > > > > the case, it must perform multi-domain coordination just like MDSC.
> > > > >
> > > > > Correct. If you remember the colors in Sergio's presentation, 
> > > > > there were functionalities associated to each controller. The
> > > "multidomain
> > > > > coordination" functionality is associated both to the PNC and 
> > > > > the
> > > MDSC.
> > > > > This is explained at the beginning of section 3 (the 4 
> > > > > functionalities are listed) and sections 3.1, 3.2, 3.3 state
> > which
> > > > > functionalities are present on each controller.
> > > > >
> > > > >   Furthermore, when MDSC performs such
> > > > > > coordination for a given service, it is assumed that the 
> > > > > > topology (nodes and
> > > > > > links) the service is placed on may be abstract and could be 
> > > > > > provided by underlying PNCs (which is correct); however, the 
> > > > > > service termination points must be *under direct control* of 
> > > > > > MDSC (I don't believe that service termination points could 
> > > > > > be virtualized and provided by subordinate PNCs). In other 
> > > > > > words, MDSC must physically control service termination 
> > > > > > points. The
> > > point
> > > > > > is that whether you
> > > > > call
> > > > > > it MDSC or VNC, I fail to see a difference between this
> > *animal*
> > > > > > and
> > > > > PNC.
> > > > > >
> > > > >
> > > > > I'm not too "religious" about the naming but I think a
> > distinction
> > > > > is useful. I think of the PNC as the entity which has the same
> > > scope
> > > > > of GMPLS, so only dealing with the "line interfaces" and not 
> > > > > the "customer interfaces", which are need for the provisioning 
> > > > > of services. In other word what IMHO is exported to "north" by 
> > > > > the PNC is just links and nodes (real or abstracted) while the 
> > > > > MDSC can
> > > also
> > > > > speak about services.
> > > > > One further thing that in my opinion is only relevant to the 
> > > > > MDSC
> > > is
> > > > > the management of non-connectivity services, i.e. the ones 
> > > > > that are called " Network Function Virtualization Services". I 
> > > > > am
> > think
> > > > > of a customer requesting for a virtual machine and a given 
> > > > > amount of storage. The PNC is the one in charge of providing
> > connectivity
> > > > > towards the data-center but other things like VM redundancy, 
> > > > > VM mobility between DCs, storage location and services like 
> > > > > that go beyond the scope of the PNC, or to better say: I would 
> > > > > split so different functionalities into different entities.
> > > > >
> > > > > That said I think no one would argue if we add a statement
> > saying:
> > > > > Both PNC and MSDC could be implemented into a single SDN
> > > controller.
> > > > >
> > > > > > Cheers,
> > > > > > Igor
> > > > > >
> > > > > > -----Original Message-----
> > > > > > From: ACTN [mailto:[e-mail]] On Behalf Of 
> > > > > > Daniele Ceccarelli
> > > > > > Sent: Monday, December 15, 2014 6:37 AM
> > > > > > To: [e-mail]
> > > > > > Subject: [Actn] New Version Notification for
> > > > > > draft-ceccarelli-actn- framework-05.txt
> > > > > >
> > > > > > Hi all,
> > > > > >
> > > > > > We just posted a new version of the framework document. 
> > > > > > Please have a look at it as there are many major changes.
> > > > > > A short recap:
> > > > > >
> > > > > > - 4 functionalities have been defined for the different
> > > controller.
> > > > > > The new functionality includes the management of services (i.e.
> > > > > > we're no longer speaking just about links and nodes but also
> > > about
> > > > > services)
> > > > > > - 2 types of services have been defined.
> > > > > > 	- Service-aware Connectivity Services: all the network
> > > service
> > > > > > operations used to provide connectivity between customer 
> > > > > > end-points
> > > > > e.g.
> > > > > > VPNs
> > > > > > 	- Network Function Virtualization Services: between
> > > customers'
> > > > > > premises and service provider premises and are provided 
> > > > > > mostly by cloud providers or content delivery providers. We 
> > > > > > are speaking about storage, virtual machines, VM mobility 
> > > > > > and so
> > on.
> > > > > > - VNC renamed into MDSC and a mapping between controller and 
> > > > > > functionalities has been provided
> > > > > > - Applicability section added
> > > > > > - Summary of the use cases added
> > > > > > - A mapping among use cases and what is (in authors opinion 
> > > > > > at
> > > > > > least) a new work in ACTN scope is provided.
> > > > > >
> > > > > > Comments are appreciated.
> > > > > >
> > > > > > Many thanks
> > > > > > The authors.
> > > > > >
> > > > > > -----Original Message-----
> > > > > > From: [e-mail] [mailto:internet-
> > [e-mail]]
> > > > > > Sent: lunedì 15 dicembre 2014 12:30
> > > > > > To: Daniele Ceccarelli; Luyuan Fang; Young Lee; Daniel King; 
> > > > > > Luyuan Fang; Daniele Ceccarelli; Daniel King; Young Lee; 
> > > > > > Diego
> > R.
> > > > > > Lopez; Diego Lopez; Sergio Belotti; Sergio Belotti
> > > > > > Subject: New Version Notification for 
> > > > > > draft-ceccarelli-actn-framework-05.txt
> > > > > >
> > > > > >
> > > > > > A new version of I-D, draft-ceccarelli-actn-framework-05.txt
> > > > > > has been successfully submitted by Daniele Ceccarelli and
> > posted
> > > > > > to the IETF repository.
> > > > > >
> > > > > > Name:		draft-ceccarelli-actn-framework
> > > > > > Revision:	05
> > > > > > Title:		Framework for Abstraction and Control of
> > > Transport
> > > > > > Networks
> > > > > > Document date:	2014-12-15
> > > > > > Group:		Individual Submission
> > > > > > Pages:		35
> > > > > > URL:            http://www.ietf.org/internet-drafts/draft-
> > > ceccarelli-
> > > > > actn-
> > > > > > framework-05.txt
> > > > > > Status:         https://datatracker.ietf.org/doc/draft-
> > > ceccarelli-
> > > > > actn-
> > > > > > framework/
> > > > > > Htmlized:       http://tools.ietf.org/html/draft-ceccarelli-
> > actn-
> > > > > framework-05
> > > > > > Diff:           http://www.ietf.org/rfcdiff?url2=draft-
> > > ceccarelli-
> > > > > actn-framework-
> > > > > > 05
> > > > > >
> > > > > > Abstract:
> > > > > >    This draft provides a framework for abstraction and 
> > > > > > control
> > of
> > > > > >    transport networks.
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > Please note that it may take a couple of minutes from the 
> > > > > > time of submission until the htmlized version and diff are 
> > > > > > available at
> > > > > tools.ietf.org.
> > > > > >
> > > > > > The IETF Secretariat
> > > > > >
> > > > > > _______________________________________________
> > > > > > ACTN mailing list
> > > > > > [e-mail]
> > > > > > https://www.ietf.org/mailman/listinfo/actn
> > > > > _______________________________________________
> > > > > ACTN mailing list
> > > > > [e-mail]
> > > > > https://www.ietf.org/mailman/listinfo/actn
> > _______________________________________________
> > ACTN mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/actn
> _______________________________________________
> ACTN mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/actn
> _______________________________________________
> ACTN mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/actn
_______________________________________________
ACTN mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/actn