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

From: Khuzema Pithewan <[email-masked]>
Date: Fri, 2 Jan 2015 23:12:54 +0000

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:[email-masked]] On Behalf Of Igor Bryskin
Sent: Monday, December 22, 2014 5:36 AM
To: BELOTTI, SERGIO (SERGIO); Leeyoung
Cc: Dhruv Dhody; [email-masked]; 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:[email-masked]]
Sent: Monday, December 22, 2014 5:43 AM
To: Leeyoung; Igor Bryskin
Cc: [email-masked]; 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:[email-masked]]
Sent: venerdì 19 dicembre 2014 22:27
To: Igor Bryskin; BELOTTI, SERGIO (SERGIO); AshwoodsmithPeter; Daniele Ceccarelli; Dhruv Dhody
Cc: [email-masked]
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:[email-masked]]
Sent: Friday, December 19, 2014 2:34 PM
To: BELOTTI, SERGIO (SERGIO); Leeyoung; AshwoodsmithPeter; Daniele Ceccarelli; Dhruv Dhody
Cc: [email-masked]
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:[email-masked]]
Sent: Friday, December 19, 2014 10:43 AM
To: Leeyoung; AshwoodsmithPeter; Igor Bryskin; Daniele Ceccarelli; Dhruv Dhody
Cc: [email-masked]
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:[email-masked]]
Sent: venerdì 19 dicembre 2014 00:01
To: AshwoodsmithPeter; Igor Bryskin; BELOTTI, SERGIO (SERGIO); Daniele Ceccarelli
Cc: [email-masked]
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:[email-masked]] On Behalf Of AshwoodsmithPeter
Sent: Thursday, December 18, 2014 1:33 PM
To: Igor Bryskin; BELOTTI, SERGIO (SERGIO); Daniele Ceccarelli
Cc: [email-masked]
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:[email-masked]]
> Sent: Thursday, December 18, 2014 8:48 AM
> To: BELOTTI, SERGIO (SERGIO); AshwoodsmithPeter; Daniele Ceccarelli
> Cc: [email-masked]
> 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; [email-masked]
> 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:[email-masked]] On Behalf Of 
> AshwoodsmithPeter
> Sent: mercoledì 17 dicembre 2014 21:38
> To: Daniele Ceccarelli; Igor Bryskin; [email-masked]
> 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:[email-masked]]
> > Sent: Wednesday, December 17, 2014 11:43 AM
> > To: AshwoodsmithPeter; Igor Bryskin; [email-masked]
> > 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:[email-masked]]
> > > Sent: mercoledì 17 dicembre 2014 16:48
> > > To: Igor Bryskin; Daniele Ceccarelli; [email-masked]
> > > 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:[email-masked]] On Behalf Of Igor 
> > > > Bryskin
> > > > Sent: Wednesday, December 17, 2014 9:08 AM
> > > > To: Daniele Ceccarelli; [email-masked]
> > > > 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:[email-masked]]
> > > > Sent: Wednesday, December 17, 2014 5:51 AM
> > > > To: Igor Bryskin; [email-masked]
> > > > 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:[email-masked]]
> > > > > Sent: lunedì 15 dicembre 2014 20:50
> > > > > To: Daniele Ceccarelli; [email-masked]
> > > > > 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:[email-masked]] On Behalf Of Daniele 
> > > > > Ceccarelli
> > > > > Sent: Monday, December 15, 2014 6:37 AM
> > > > > To: [email-masked]
> > > > > 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: [email-masked] [mailto:internet-
> [email-masked]]
> > > > > 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
> > > > > [email-masked]
> > > > > https://www.ietf.org/mailman/listinfo/actn
> > > > _______________________________________________
> > > > ACTN mailing list
> > > > [email-masked]
> > > > https://www.ietf.org/mailman/listinfo/actn
> _______________________________________________
> ACTN mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/actn
_______________________________________________
ACTN mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/actn
_______________________________________________
ACTN mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/actn

---

From: Igor Bryskin <[email-masked]>
Date: Mon, 5 Jan 2015 13:47:01 +0000

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:[email-masked]] 
Sent: Friday, January 02, 2015 6:13 PM
To: Igor Bryskin; BELOTTI, SERGIO (SERGIO); Leeyoung
Cc: Dhruv Dhody; [email-masked]; Victor Lopez; Daniele Ceccarelli; AshwoodsmithPeter
Subject: RE: [Actn] New Version Notification for draft-ceccarelli-actn-framework-05.txt

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.

Thoughts?

Thanks
Khuzema

-----Original Message-----
From: ACTN [mailto:[email-masked]] On Behalf Of Igor Bryskin
Sent: Monday, December 22, 2014 5:36 AM
To: BELOTTI, SERGIO (SERGIO); Leeyoung
Cc: Dhruv Dhody; [email-masked]; Victor Lopez; Daniele Ceccarelli; AshwoodsmithPeter
Subject: Re: [Actn] New Version Notification for draft-ceccarelli-actn-framework-05.txt

Young and Sergio,

-----Original Message-----
From: BELOTTI, SERGIO (SERGIO) [mailto:[email-masked]]
Sent: Monday, December 22, 2014 5:43 AM
To: Leeyoung; Igor Bryskin
Cc: [email-masked]; AshwoodsmithPeter; Daniele Ceccarelli; Dhruv Dhody; Victor Lopez
Subject: RE: [Actn] New Version Notification for draft-ceccarelli-actn-framework-05.txt

Hi Igor,

Sergio

-----Original Message-----
From: Leeyoung [mailto:[email-masked]]
Sent: venerdì 19 dicembre 2014 22:27
To: Igor Bryskin; BELOTTI, SERGIO (SERGIO); AshwoodsmithPeter; Daniele Ceccarelli; Dhruv Dhody
Cc: [email-masked]
Subject: RE: [Actn] New Version Notification for draft-ceccarelli-actn-framework-05.txt

Hi Igor,

Thanks,
Young

-----Original Message-----
From: Igor Bryskin [mailto:[email-masked]]
Sent: Friday, December 19, 2014 2:34 PM
To: BELOTTI, SERGIO (SERGIO); Leeyoung; AshwoodsmithPeter; Daniele Ceccarelli; Dhruv Dhody
Cc: [email-masked]
Subject: RE: [Actn] New Version Notification for draft-ceccarelli-actn-framework-05.txt

Sergio,

Cheers,
Igor

-----Original Message-----
From: BELOTTI, SERGIO (SERGIO) [mailto:[email-masked]]
Sent: Friday, December 19, 2014 10:43 AM
To: Leeyoung; AshwoodsmithPeter; Igor Bryskin; Daniele Ceccarelli; Dhruv Dhody
Cc: [email-masked]
Subject: RE: [Actn] New Version Notification for draft-ceccarelli-actn-framework-05.txt

Hi all,

Thanks
Sergio

-----Original Message-----
From: Leeyoung [mailto:[email-masked]]
Sent: venerdì 19 dicembre 2014 00:01
To: AshwoodsmithPeter; Igor Bryskin; BELOTTI, SERGIO (SERGIO); Daniele Ceccarelli
Cc: [email-masked]
Subject: RE: [Actn] New Version Notification for draft-ceccarelli-actn-framework-05.txt

Hi Peter,

Thanks,
Young

-----Original Message-----
From: ACTN [mailto:[email-masked]] On Behalf Of AshwoodsmithPeter
Sent: Thursday, December 18, 2014 1:33 PM
To: Igor Bryskin; BELOTTI, SERGIO (SERGIO); Daniele Ceccarelli
Cc: [email-masked]
Subject: Re: [Actn] New Version Notification for draft-ceccarelli-actn-framework-05.txt

                 M S D N
                    |

                 M S D N
                 |  X  |

Peter

---

From: Daniele Ceccarelli <[email-masked]>
Date: Mon, 5 Jan 2015 15:44:49 +0000

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

> Sent: lunedì 5 gennaio 2015 14:47
> To: Khuzema Pithewan; BELOTTI, SERGIO (SERGIO); Leeyoung
> 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.
> 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.
> 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
> 
> Out of 4 ACTN main functions, I see following 2 are required to be
> repeatable in the hierarchy and hence requires multi-level recursion.
> 
> 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.
> 
> 
> 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.
> 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?
> 
> 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 .
> "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."
> 
> "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.
> 
> 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.
> 
> 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
> 
> 
> 
> 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.
> 
> 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
>                     |
> 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  |
> 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.
>

---

From: Igor Bryskin <[email-masked]>
Date: Mon, 5 Jan 2015 19:45:29 +0000

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:[email-masked]] 
Sent: Monday, January 05, 2015 10:45 AM
To: Igor Bryskin; Khuzema Pithewan; BELOTTI, SERGIO (SERGIO); Leeyoung
Cc: Dhruv Dhody; [email-masked]; Victor Lopez; AshwoodsmithPeter
Subject: RE: [Actn] New Version Notification for draft-ceccarelli-actn-framework-05.txt

Hi Igor, Khuzema, all,

Cheers
Daniele

> 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.
> 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.
> 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
> 
> 1. virtualization/abstraction function 2. multi domain coordination 
> function
> 
> 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.
> 
> 
> With this I would like to propose a different packaging of these 5 
> functions, based on their characteristics.
> 
> 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 
> 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.
> 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.
> 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?
> 
> From: BELOTTI, SERGIO (SERGIO) 
> [mailto:[email-masked]]
> I think Young exactly pointed out what I tried to explain in my 
> previous mail so I do not have much to add.
> virtualized environment permitting to operators the view of an 
> abstraction of the underlying multi-vendor, multi-admin and multi-technology network.
> So, this restriction and scope is not idealistic but this 
> orchestration functionality is what operator want.
> 
> "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."
> 
> 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."
> 
> 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.
> 
> 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.
> 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.
> 
> 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.
> 
> From: BELOTTI, SERGIO (SERGIO) 
> [mailto:[email-masked]]
> 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
> 
> 
> 
> 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.
> 
> 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
>                     |
> 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  |
> 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.
> 
> > 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)
> >
> > Page6 "and they generally has very few" should be "and they 
> > generally have very few"
> > 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
> >
> > > depending on the cases. I think my last reply to Igor should 
> > > address your concerns.
> > >
> > > BR
> > > Daniele
> > >
> > > > > will have one component less in the framework, and the lesser 
> > > > > we have components the easier it is to make the framework recursive.
> > > > >
> > > > > the management of non-connectivity services, i.e. the ones 
> > > > > that are called " Network Function Virtualization Services". I 
> > > > > am
> > think
> > > > > 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
> > > > > > 1. I don't think that one of explicit Adrian's requests - 
> > > > > > the recursive nature of the ACTN architecture with 
> > > > > > corresponding
> > use
> > > > > cases
> > > > > text and a focused figure would be helpful. If you could 
> > > > > provide it I would be happy to include it.
> > > > >
> > > > > >
> > > > > > PNC can talk to more than one subordinate PNCs. If this is 
> > > > > > the case, it must perform multi-domain coordination just like MDSC.
> > > > >
> > > > > > 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
> > > > > 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.
> > > > > the management of non-connectivity services, i.e. the ones 
> > > > > that are called " Network Function Virtualization Services". I 
> > > > > am
> > think
> > > > > 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.
> > > > >
> > > > > > Daniele Ceccarelli
> > > > > > 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:
> > > > > >
> > > > > > 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.
> > > > > > 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
> > > > > >

---

From: Dave Hood <[email-masked]>
Date: Mon, 5 Jan 2015 20:21:49 +0000

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:[email-masked]] On Behalf Of Igor Bryskin
Sent: Monday, January 05, 2015 11:45 AM
To: Daniele Ceccarelli; Khuzema Pithewan; BELOTTI, SERGIO (SERGIO); Leeyoung
Cc: [email-masked]; Victor Lopez; Dhruv Dhody; AshwoodsmithPeter
Subject: Re: [Actn] New Version Notification for draft-ceccarelli-actn-framework-05.txt

Hi Daniele,

You said:

Cheers,
Igor

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

Hi Igor, Khuzema, all,

Cheers
Daniele

---

From: Khuzema Pithewan <[email-masked]>
Date: Mon, 5 Jan 2015 21:28:43 +0000

Hi Igor,

This is the description of Customer mapping function in the document . 

-----
Customer mapping function: 

F1 -> In charge of mapping customer VN
        setup commands into network provisioning requests to the
        Physical Network Controller (PNC) according to business OSS/NMS
        provisioned static or dynamic policy. 

F2 -> Moreover it provides
        mapping and translation of customer virtual network slices into
        physical network resources

-------

F1 translates VN setup command into topology related requests. I am not sure, if the intent can be translated multiple times to re-interpret what CNC is asking. Once interpreted into physical/abstract topology information, which if abstract, represent full network that CNC wants to control, we don’t really need further translation. All you need is virtualization/abstraction function in hierarchy to reach finer topplogy.

F1 also talks about policy translation. Policy also needs to translate into more concrete primitives that is supported by virtual topology. As per my understanding, these primitives could be related to administrative control, protection, OAM, diversity etc. further IMHO these primitives need to be supported by virtualization/abstraction function which should be hirerarchical.

F2 translates CNCs view into virtual/physical network slices. Once converted into virtual/physical slices, it can only be mapped to more fine grained virtual/physical slices, which should be taken care by topology handler, which should be part of virtualization and abstraction function.

Based on the way customer mapping is defined, I don’t see how we can have hierarchy of that.

Thanks
Khuzema

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

Hi Khusema,

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.

Cheers,
Igor

-----Original Message-----
From: Khuzema Pithewan [mailto:[email-masked]]
Sent: Friday, January 02, 2015 6:13 PM
To: Igor Bryskin; BELOTTI, SERGIO (SERGIO); Leeyoung
Cc: Dhruv Dhody; [email-masked]; Victor Lopez; Daniele Ceccarelli; AshwoodsmithPeter
Subject: RE: [Actn] New Version Notification for draft-ceccarelli-actn-framework-05.txt

Thoughts?

Thanks
Khuzema

-----Original Message-----
From: ACTN [mailto:[email-masked]] On Behalf Of Igor Bryskin
Sent: Monday, December 22, 2014 5:36 AM
To: BELOTTI, SERGIO (SERGIO); Leeyoung
Cc: Dhruv Dhody; [email-masked]; Victor Lopez; Daniele Ceccarelli; AshwoodsmithPeter
Subject: Re: [Actn] New Version Notification for draft-ceccarelli-actn-framework-05.txt

Young and Sergio,

-----Original Message-----
From: BELOTTI, SERGIO (SERGIO) [mailto:[email-masked]]
Sent: Monday, December 22, 2014 5:43 AM
To: Leeyoung; Igor Bryskin
Cc: [email-masked]; AshwoodsmithPeter; Daniele Ceccarelli; Dhruv Dhody; Victor Lopez
Subject: RE: [Actn] New Version Notification for draft-ceccarelli-actn-framework-05.txt

Hi Igor,

Sergio

-----Original Message-----
From: Leeyoung [mailto:[email-masked]]
Sent: venerdì 19 dicembre 2014 22:27
To: Igor Bryskin; BELOTTI, SERGIO (SERGIO); AshwoodsmithPeter; Daniele Ceccarelli; Dhruv Dhody
Cc: [email-masked]
Subject: RE: [Actn] New Version Notification for draft-ceccarelli-actn-framework-05.txt

Hi Igor,

Thanks,
Young

-----Original Message-----
From: Igor Bryskin [mailto:[email-masked]]
Sent: Friday, December 19, 2014 2:34 PM
To: BELOTTI, SERGIO (SERGIO); Leeyoung; AshwoodsmithPeter; Daniele Ceccarelli; Dhruv Dhody
Cc: [email-masked]
Subject: RE: [Actn] New Version Notification for draft-ceccarelli-actn-framework-05.txt

Sergio,

Cheers,
Igor

-----Original Message-----
From: BELOTTI, SERGIO (SERGIO) [mailto:[email-masked]]
Sent: Friday, December 19, 2014 10:43 AM
To: Leeyoung; AshwoodsmithPeter; Igor Bryskin; Daniele Ceccarelli; Dhruv Dhody
Cc: [email-masked]
Subject: RE: [Actn] New Version Notification for draft-ceccarelli-actn-framework-05.txt

Hi all,

Thanks
Sergio

-----Original Message-----
From: Leeyoung [mailto:[email-masked]]
Sent: venerdì 19 dicembre 2014 00:01
To: AshwoodsmithPeter; Igor Bryskin; BELOTTI, SERGIO (SERGIO); Daniele Ceccarelli
Cc: [email-masked]
Subject: RE: [Actn] New Version Notification for draft-ceccarelli-actn-framework-05.txt

Hi Peter,

Thanks,
Young

-----Original Message-----
From: ACTN [mailto:[email-masked]] On Behalf Of AshwoodsmithPeter
Sent: Thursday, December 18, 2014 1:33 PM
To: Igor Bryskin; BELOTTI, SERGIO (SERGIO); Daniele Ceccarelli
Cc: [email-masked]
Subject: Re: [Actn] New Version Notification for draft-ceccarelli-actn-framework-05.txt

                 M S D N
                    |

                 M S D N
                 |  X  |

Peter

---

From: Igor Bryskin <[email-masked]>
Date: Tue, 6 Jan 2015 14:13:48 +0000

Hi Khuzema,

You wrote:
" F1 translates VN setup command into topology related requests. I am not sure, if the intent can be translated multiple times to re-interpret what CNC is asking. Once interpreted into physical/abstract topology information, which if abstract, represent full network that CNC wants to control, we don’t really need further translation. All you need is virtualization/abstraction function in hierarchy to reach finer topology."

I think we mean different things by "hierarchical ACTN function". By this I mean an ACTN function that may repeat itself at each level of the ACTN hierarchy. For example, in the MSFT->TFK->ADVA case the MDSC function may happen at each level, following the same paradigm and according to the same model. MDSC at level X happens pretty much independently from MDSC at level Y. The same is true for the customer mapping function: ADVA does it for its client TFK, TFK for MSFT, MSFT for its clients, etc.
You seem to think of hierarchical ACTN function as a virtual function: i.e. certain level of dependency of a function at level X on the same function at lower level(s) of hierarchy.

Cheers,
Igor

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

Hi Igor,

-----

-------

Thanks
Khuzema

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

Hi Khusema,

Cheers,
Igor

-----Original Message-----
From: Khuzema Pithewan [mailto:[email-masked]]
Sent: Friday, January 02, 2015 6:13 PM
To: Igor Bryskin; BELOTTI, SERGIO (SERGIO); Leeyoung
Cc: Dhruv Dhody; [email-masked]; Victor Lopez; Daniele Ceccarelli; AshwoodsmithPeter
Subject: RE: [Actn] New Version Notification for draft-ceccarelli-actn-framework-05.txt

Thoughts?

Thanks
Khuzema

-----Original Message-----
From: ACTN [mailto:[email-masked]] On Behalf Of Igor Bryskin
Sent: Monday, December 22, 2014 5:36 AM
To: BELOTTI, SERGIO (SERGIO); Leeyoung
Cc: Dhruv Dhody; [email-masked]; Victor Lopez; Daniele Ceccarelli; AshwoodsmithPeter
Subject: Re: [Actn] New Version Notification for draft-ceccarelli-actn-framework-05.txt

Young and Sergio,

-----Original Message-----
From: BELOTTI, SERGIO (SERGIO) [mailto:[email-masked]]
Sent: Monday, December 22, 2014 5:43 AM
To: Leeyoung; Igor Bryskin
Cc: [email-masked]; AshwoodsmithPeter; Daniele Ceccarelli; Dhruv Dhody; Victor Lopez
Subject: RE: [Actn] New Version Notification for draft-ceccarelli-actn-framework-05.txt

Hi Igor,

Sergio

-----Original Message-----
From: Leeyoung [mailto:[email-masked]]
Sent: venerdì 19 dicembre 2014 22:27
To: Igor Bryskin; BELOTTI, SERGIO (SERGIO); AshwoodsmithPeter; Daniele Ceccarelli; Dhruv Dhody
Cc: [email-masked]
Subject: RE: [Actn] New Version Notification for draft-ceccarelli-actn-framework-05.txt

Hi Igor,

Thanks,
Young

-----Original Message-----
From: Igor Bryskin [mailto:[email-masked]]
Sent: Friday, December 19, 2014 2:34 PM
To: BELOTTI, SERGIO (SERGIO); Leeyoung; AshwoodsmithPeter; Daniele Ceccarelli; Dhruv Dhody
Cc: [email-masked]
Subject: RE: [Actn] New Version Notification for draft-ceccarelli-actn-framework-05.txt

Sergio,

Cheers,
Igor

-----Original Message-----
From: BELOTTI, SERGIO (SERGIO) [mailto:[email-masked]]
Sent: Friday, December 19, 2014 10:43 AM
To: Leeyoung; AshwoodsmithPeter; Igor Bryskin; Daniele Ceccarelli; Dhruv Dhody
Cc: [email-masked]
Subject: RE: [Actn] New Version Notification for draft-ceccarelli-actn-framework-05.txt

Hi all,

Thanks
Sergio

-----Original Message-----
From: Leeyoung [mailto:[email-masked]]
Sent: venerdì 19 dicembre 2014 00:01
To: AshwoodsmithPeter; Igor Bryskin; BELOTTI, SERGIO (SERGIO); Daniele Ceccarelli
Cc: [email-masked]
Subject: RE: [Actn] New Version Notification for draft-ceccarelli-actn-framework-05.txt

Hi Peter,

Thanks,
Young

-----Original Message-----
From: ACTN [mailto:[email-masked]] On Behalf Of AshwoodsmithPeter
Sent: Thursday, December 18, 2014 1:33 PM
To: Igor Bryskin; BELOTTI, SERGIO (SERGIO); Daniele Ceccarelli
Cc: [email-masked]
Subject: Re: [Actn] New Version Notification for draft-ceccarelli-actn-framework-05.txt

                 M S D N
                    |

                 M S D N
                 |  X  |

Peter

---

From: Khuzema Pithewan <[email-masked]>
Date: Tue, 6 Jan 2015 16:00:48 +0000

Hi igor,

Can you give some examples of customer mapping function in your usecase?

Khuzema

Sent from Samsung Mobile

-------- Original message --------
From: Igor Bryskin
Date:06/01/2015 6:18 AM (GMT-08:00)
To: Khuzema Pithewan ,"BELOTTI, SERGIO (SERGIO)" ,Leeyoung
Cc: Dhruv Dhody ,[email-masked],Victor Lopez ,Daniele Ceccarelli ,AshwoodsmithPeter
Subject: RE: [Actn] New Version Notification for draft-ceccarelli-actn-framework-05.txt

Hi Khuzema,

You wrote:

Cheers,
Igor

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

Hi Igor,

-----

-------

Thanks
Khuzema

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

Hi Khusema,

Cheers,
Igor

-----Original Message-----
From: Khuzema Pithewan [mailto:[email-masked]]
Sent: Friday, January 02, 2015 6:13 PM
To: Igor Bryskin; BELOTTI, SERGIO (SERGIO); Leeyoung
Cc: Dhruv Dhody; [email-masked]; Victor Lopez; Daniele Ceccarelli; AshwoodsmithPeter
Subject: RE: [Actn] New Version Notification for draft-ceccarelli-actn-framework-05.txt

Thoughts?

Thanks
Khuzema

-----Original Message-----
From: ACTN [mailto:[email-masked]] On Behalf Of Igor Bryskin
Sent: Monday, December 22, 2014 5:36 AM
To: BELOTTI, SERGIO (SERGIO); Leeyoung
Cc: Dhruv Dhody; [email-masked]; Victor Lopez; Daniele Ceccarelli; AshwoodsmithPeter
Subject: Re: [Actn] New Version Notification for draft-ceccarelli-actn-framework-05.txt

Young and Sergio,

-----Original Message-----
From: BELOTTI, SERGIO (SERGIO) [mailto:[email-masked]]
Sent: Monday, December 22, 2014 5:43 AM
To: Leeyoung; Igor Bryskin
Cc: [email-masked]; AshwoodsmithPeter; Daniele Ceccarelli; Dhruv Dhody; Victor Lopez
Subject: RE: [Actn] New Version Notification for draft-ceccarelli-actn-framework-05.txt

Hi Igor,

Sergio

-----Original Message-----
From: Leeyoung [mailto:[email-masked]]
Sent: venerdì 19 dicembre 2014 22:27
To: Igor Bryskin; BELOTTI, SERGIO (SERGIO); AshwoodsmithPeter; Daniele Ceccarelli; Dhruv Dhody
Cc: [email-masked]
Subject: RE: [Actn] New Version Notification for draft-ceccarelli-actn-framework-05.txt

Hi Igor,

Thanks,
Young

-----Original Message-----
From: Igor Bryskin [mailto:[email-masked]]
Sent: Friday, December 19, 2014 2:34 PM
To: BELOTTI, SERGIO (SERGIO); Leeyoung; AshwoodsmithPeter; Daniele Ceccarelli; Dhruv Dhody
Cc: [email-masked]
Subject: RE: [Actn] New Version Notification for draft-ceccarelli-actn-framework-05.txt

Sergio,

Cheers,
Igor

-----Original Message-----
From: BELOTTI, SERGIO (SERGIO) [mailto:[email-masked]]
Sent: Friday, December 19, 2014 10:43 AM
To: Leeyoung; AshwoodsmithPeter; Igor Bryskin; Daniele Ceccarelli; Dhruv Dhody
Cc: [email-masked]
Subject: RE: [Actn] New Version Notification for draft-ceccarelli-actn-framework-05.txt

Hi all,

Thanks
Sergio

-----Original Message-----
From: Leeyoung [mailto:[email-masked]]
Sent: venerdì 19 dicembre 2014 00:01
To: AshwoodsmithPeter; Igor Bryskin; BELOTTI, SERGIO (SERGIO); Daniele Ceccarelli
Cc: [email-masked]
Subject: RE: [Actn] New Version Notification for draft-ceccarelli-actn-framework-05.txt

Hi Peter,

Thanks,
Young

-----Original Message-----
From: ACTN [mailto:[email-masked]] On Behalf Of AshwoodsmithPeter
Sent: Thursday, December 18, 2014 1:33 PM
To: Igor Bryskin; BELOTTI, SERGIO (SERGIO); Daniele Ceccarelli
Cc: [email-masked]
Subject: Re: [Actn] New Version Notification for draft-ceccarelli-actn-framework-05.txt

                 M S D N
                    |

                 M S D N
                 |  X  |

Peter

---

From: Leeyoung <[email-masked]>
Date: Tue, 6 Jan 2015 17:26:58 +0000

Hi Igor and Khuzema,

Happy new year! I am joining this debate a bit late, but this is my take:

I tend to agree with Igor on the interpretation of customer mapping function that may repeat in each level of hierarchy. As MSFT is a customer of TFK, it will have its mapping of MSFT into TFK level. As TFK is a customer of ADVA, ADVA will need TFK mapping into ADVA level, etc in a recursive fashion. I think Khuzema lumped this as virtualization function. I think the current framework used 'customer' in a narrower sense to only imply the top level customer, namely, in this example, MSFT. I think this needs to be clarified. At any rate, the customer mapping function needs to be recursively instantiated across all level of hierarchy. 

Igor, is this what you are thinking?

Thanks,
Young

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

Hi Khuzema,

You wrote:

Cheers,
Igor

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

Hi Igor,

-----

-------

Thanks
Khuzema

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

Hi Khusema,

Cheers,
Igor

-----Original Message-----
From: Khuzema Pithewan [mailto:[email-masked]]
Sent: Friday, January 02, 2015 6:13 PM
To: Igor Bryskin; BELOTTI, SERGIO (SERGIO); Leeyoung
Cc: Dhruv Dhody; [email-masked]; Victor Lopez; Daniele Ceccarelli; AshwoodsmithPeter
Subject: RE: [Actn] New Version Notification for draft-ceccarelli-actn-framework-05.txt

Thoughts?

Thanks
Khuzema

-----Original Message-----
From: ACTN [mailto:[email-masked]] On Behalf Of Igor Bryskin
Sent: Monday, December 22, 2014 5:36 AM
To: BELOTTI, SERGIO (SERGIO); Leeyoung
Cc: Dhruv Dhody; [email-masked]; Victor Lopez; Daniele Ceccarelli; AshwoodsmithPeter
Subject: Re: [Actn] New Version Notification for draft-ceccarelli-actn-framework-05.txt

Young and Sergio,

-----Original Message-----
From: BELOTTI, SERGIO (SERGIO) [mailto:[email-masked]]
Sent: Monday, December 22, 2014 5:43 AM
To: Leeyoung; Igor Bryskin
Cc: [email-masked]; AshwoodsmithPeter; Daniele Ceccarelli; Dhruv Dhody; Victor Lopez
Subject: RE: [Actn] New Version Notification for draft-ceccarelli-actn-framework-05.txt

Hi Igor,

Sergio

-----Original Message-----
From: Leeyoung [mailto:[email-masked]]
Sent: venerdì 19 dicembre 2014 22:27
To: Igor Bryskin; BELOTTI, SERGIO (SERGIO); AshwoodsmithPeter; Daniele Ceccarelli; Dhruv Dhody
Cc: [email-masked]
Subject: RE: [Actn] New Version Notification for draft-ceccarelli-actn-framework-05.txt

Hi Igor,

Thanks,
Young

-----Original Message-----
From: Igor Bryskin [mailto:[email-masked]]
Sent: Friday, December 19, 2014 2:34 PM
To: BELOTTI, SERGIO (SERGIO); Leeyoung; AshwoodsmithPeter; Daniele Ceccarelli; Dhruv Dhody
Cc: [email-masked]
Subject: RE: [Actn] New Version Notification for draft-ceccarelli-actn-framework-05.txt

Sergio,

Cheers,
Igor

-----Original Message-----
From: BELOTTI, SERGIO (SERGIO) [mailto:[email-masked]]
Sent: Friday, December 19, 2014 10:43 AM
To: Leeyoung; AshwoodsmithPeter; Igor Bryskin; Daniele Ceccarelli; Dhruv Dhody
Cc: [email-masked]
Subject: RE: [Actn] New Version Notification for draft-ceccarelli-actn-framework-05.txt

Hi all,

Thanks
Sergio

-----Original Message-----
From: Leeyoung [mailto:[email-masked]]
Sent: venerdì 19 dicembre 2014 00:01
To: AshwoodsmithPeter; Igor Bryskin; BELOTTI, SERGIO (SERGIO); Daniele Ceccarelli
Cc: [email-masked]
Subject: RE: [Actn] New Version Notification for draft-ceccarelli-actn-framework-05.txt

Hi Peter,

Thanks,
Young

-----Original Message-----
From: ACTN [mailto:[email-masked]] On Behalf Of AshwoodsmithPeter
Sent: Thursday, December 18, 2014 1:33 PM
To: Igor Bryskin; BELOTTI, SERGIO (SERGIO); Daniele Ceccarelli
Cc: [email-masked]
Subject: Re: [Actn] New Version Notification for draft-ceccarelli-actn-framework-05.txt

                 M S D N
                    |

                 M S D N
                 |  X  |

Peter

---

From: Dave Hood <[email-masked]>
Date: Tue, 6 Jan 2015 17:31:52 +0000

A special case of abstraction is transparency. Architecturally, we would consider there to still be a functional block that recursively abstracts a resource view; it might just happen to be a pass-through in some particular circumstance.

But keep in mind that each level of customer may wish to identify resources using its own identifier space, so that even if the level of granularity and attribute exposure is the same at different levels, there may be a need for identifier translation.

Dave

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

Hi Igor and Khuzema,

Thanks,
Young

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

Hi Khuzema,

You wrote:

Cheers,
Igor

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

Hi Igor,

-----

-------

Thanks
Khuzema

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

Hi Khusema,

Cheers,
Igor

-----Original Message-----
From: Khuzema Pithewan [mailto:[email-masked]]
Sent: Friday, January 02, 2015 6:13 PM
To: Igor Bryskin; BELOTTI, SERGIO (SERGIO); Leeyoung
Cc: Dhruv Dhody; [email-masked]; Victor Lopez; Daniele Ceccarelli; AshwoodsmithPeter
Subject: RE: [Actn] New Version Notification for draft-ceccarelli-actn-framework-05.txt

Thoughts?

Thanks
Khuzema

-----Original Message-----
From: ACTN [mailto:[email-masked]] On Behalf Of Igor Bryskin
Sent: Monday, December 22, 2014 5:36 AM
To: BELOTTI, SERGIO (SERGIO); Leeyoung
Cc: Dhruv Dhody; [email-masked]; Victor Lopez; Daniele Ceccarelli; AshwoodsmithPeter
Subject: Re: [Actn] New Version Notification for draft-ceccarelli-actn-framework-05.txt

Young and Sergio,

-----Original Message-----
From: BELOTTI, SERGIO (SERGIO) [mailto:[email-masked]]
Sent: Monday, December 22, 2014 5:43 AM
To: Leeyoung; Igor Bryskin
Cc: [email-masked]; AshwoodsmithPeter; Daniele Ceccarelli; Dhruv Dhody; Victor Lopez
Subject: RE: [Actn] New Version Notification for draft-ceccarelli-actn-framework-05.txt

Hi Igor,

Sergio

-----Original Message-----
From: Leeyoung [mailto:[email-masked]]
Sent: venerdì 19 dicembre 2014 22:27
To: Igor Bryskin; BELOTTI, SERGIO (SERGIO); AshwoodsmithPeter; Daniele Ceccarelli; Dhruv Dhody
Cc: [email-masked]
Subject: RE: [Actn] New Version Notification for draft-ceccarelli-actn-framework-05.txt

Hi Igor,

Thanks,
Young

-----Original Message-----
From: Igor Bryskin [mailto:[email-masked]]
Sent: Friday, December 19, 2014 2:34 PM
To: BELOTTI, SERGIO (SERGIO); Leeyoung; AshwoodsmithPeter; Daniele Ceccarelli; Dhruv Dhody
Cc: [email-masked]
Subject: RE: [Actn] New Version Notification for draft-ceccarelli-actn-framework-05.txt

Sergio,

Cheers,
Igor

-----Original Message-----
From: BELOTTI, SERGIO (SERGIO) [mailto:[email-masked]]
Sent: Friday, December 19, 2014 10:43 AM
To: Leeyoung; AshwoodsmithPeter; Igor Bryskin; Daniele Ceccarelli; Dhruv Dhody
Cc: [email-masked]
Subject: RE: [Actn] New Version Notification for draft-ceccarelli-actn-framework-05.txt

Hi all,

Thanks
Sergio

-----Original Message-----
From: Leeyoung [mailto:[email-masked]]
Sent: venerdì 19 dicembre 2014 00:01
To: AshwoodsmithPeter; Igor Bryskin; BELOTTI, SERGIO (SERGIO); Daniele Ceccarelli
Cc: [email-masked]
Subject: RE: [Actn] New Version Notification for draft-ceccarelli-actn-framework-05.txt

Hi Peter,

Thanks,
Young

-----Original Message-----
From: ACTN [mailto:[email-masked]] On Behalf Of AshwoodsmithPeter
Sent: Thursday, December 18, 2014 1:33 PM
To: Igor Bryskin; BELOTTI, SERGIO (SERGIO); Daniele Ceccarelli
Cc: [email-masked]
Subject: Re: [Actn] New Version Notification for draft-ceccarelli-actn-framework-05.txt

                 M S D N
                    |

                 M S D N
                 |  X  |

Peter

---

From: Igor Bryskin <[email-masked]>
Date: Tue, 6 Jan 2015 17:43:30 +0000

1. Imposing limitations on a client with respect to the size and contents of the exposed abstract topology, connectivity, consumed network resources, number, types and parameters of provided services;
2. Honoring (within the limits) client preferences as to how the abstract topology exposed to him should look like (including scheduling in time)
3. Honoring client specific policies, defaults, templates, etc., (e.g.. if I asked for a new abstract link or a new transport service and didn't specify a particular attribute, then use this template)

-----Original Message-----
From: Khuzema Pithewan [mailto:[email-masked]] 
Sent: Tuesday, January 06, 2015 11:01 AM
To: Igor Bryskin; BELOTTI, SERGIO (SERGIO); Leeyoung
Cc: Dhruv Dhody; [email-masked]; Victor Lopez; Daniele Ceccarelli; AshwoodsmithPeter
Subject: Re: [Actn] New Version Notification for draft-ceccarelli-actn-framework-05.txt

Hi igor,

Khuzema

Sent from Samsung Mobile

-------- Original message --------
From: Igor Bryskin

Hi Khuzema,

You wrote:
" F1 translates VN setup command into topology related requests. I am not sure, if the intent can be translated multiple times to re-interpret what CNC is asking. Once interpreted into physical/abstract topology information, which if abstract, represent full network that CNC wants to control, we don't really need further translation. All you need is virtualization/abstraction function in hierarchy to reach finer topology."

Cheers,
Igor

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

Hi Igor,

-----

-------

F1 translates VN setup command into topology related requests. I am not sure, if the intent can be translated multiple times to re-interpret what CNC is asking. Once interpreted into physical/abstract topology information, which if abstract, represent full network that CNC wants to control, we don't really need further translation. All you need is virtualization/abstraction function in hierarchy to reach finer topplogy.

Based on the way customer mapping is defined, I don't see how we can have hierarchy of that.

Thanks
Khuzema

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

Hi Khusema,

Cheers,
Igor

-----Original Message-----
From: Khuzema Pithewan [mailto:[email-masked]]
Sent: Friday, January 02, 2015 6:13 PM
To: Igor Bryskin; BELOTTI, SERGIO (SERGIO); Leeyoung
Cc: Dhruv Dhody; [email-masked]; Victor Lopez; Daniele Ceccarelli; AshwoodsmithPeter
Subject: RE: [Actn] New Version Notification for draft-ceccarelli-actn-framework-05.txt

Rest of the functions doesn't need recursion because of their nature.

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.

Thoughts?

Thanks
Khuzema

-----Original Message-----
From: ACTN [mailto:[email-masked]] On Behalf Of Igor Bryskin
Sent: Monday, December 22, 2014 5:36 AM
To: BELOTTI, SERGIO (SERGIO); Leeyoung
Cc: Dhruv Dhody; [email-masked]; Victor Lopez; Daniele Ceccarelli; AshwoodsmithPeter
Subject: Re: [Actn] New Version Notification for draft-ceccarelli-actn-framework-05.txt

Young and Sergio,

-----Original Message-----
From: BELOTTI, SERGIO (SERGIO) [mailto:[email-masked]]
Sent: Monday, December 22, 2014 5:43 AM
To: Leeyoung; Igor Bryskin
Cc: [email-masked]; AshwoodsmithPeter; Daniele Ceccarelli; Dhruv Dhody; Victor Lopez
Subject: RE: [Actn] New Version Notification for draft-ceccarelli-actn-framework-05.txt

Hi Igor,

Sergio

-----Original Message-----
From: Leeyoung [mailto:[email-masked]]
Sent: venerdì 19 dicembre 2014 22:27
To: Igor Bryskin; BELOTTI, SERGIO (SERGIO); AshwoodsmithPeter; Daniele Ceccarelli; Dhruv Dhody
Cc: [email-masked]
Subject: RE: [Actn] New Version Notification for draft-ceccarelli-actn-framework-05.txt

Hi Igor,

Thanks,
Young

-----Original Message-----
From: Igor Bryskin [mailto:[email-masked]]
Sent: Friday, December 19, 2014 2:34 PM
To: BELOTTI, SERGIO (SERGIO); Leeyoung; AshwoodsmithPeter; Daniele Ceccarelli; Dhruv Dhody
Cc: [email-masked]
Subject: RE: [Actn] New Version Notification for draft-ceccarelli-actn-framework-05.txt

Sergio,

Cheers,
Igor

-----Original Message-----
From: BELOTTI, SERGIO (SERGIO) [mailto:[email-masked]]
Sent: Friday, December 19, 2014 10:43 AM
To: Leeyoung; AshwoodsmithPeter; Igor Bryskin; Daniele Ceccarelli; Dhruv Dhody
Cc: [email-masked]
Subject: RE: [Actn] New Version Notification for draft-ceccarelli-actn-framework-05.txt

Hi all,

Thanks
Sergio

-----Original Message-----
From: Leeyoung [mailto:[email-masked]]
Sent: venerdì 19 dicembre 2014 00:01
To: AshwoodsmithPeter; Igor Bryskin; BELOTTI, SERGIO (SERGIO); Daniele Ceccarelli
Cc: [email-masked]
Subject: RE: [Actn] New Version Notification for draft-ceccarelli-actn-framework-05.txt

Hi Peter,

Thanks,
Young

-----Original Message-----
From: ACTN [mailto:[email-masked]] On Behalf Of AshwoodsmithPeter
Sent: Thursday, December 18, 2014 1:33 PM
To: Igor Bryskin; BELOTTI, SERGIO (SERGIO); Daniele Ceccarelli
Cc: [email-masked]
Subject: Re: [Actn] New Version Notification for draft-ceccarelli-actn-framework-05.txt

                 M S D N
                    |

                 M S D N
                 |  X  |

Peter

---

From: Igor Bryskin <[email-masked]>
Date: Tue, 6 Jan 2015 17:45:55 +0000

Pretty much

-----Original Message-----
From: Leeyoung [mailto:[email-masked]] 
Sent: Tuesday, January 06, 2015 12:27 PM
To: Igor Bryskin; Khuzema Pithewan; BELOTTI, SERGIO (SERGIO)
Cc: Dhruv Dhody; [email-masked]; Victor Lopez; Daniele Ceccarelli; AshwoodsmithPeter
Subject: RE: [Actn] New Version Notification for draft-ceccarelli-actn-framework-05.txt

Hi Igor and Khuzema,

Thanks,
Young

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

Hi Khuzema,

You wrote:

Cheers,
Igor

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

Hi Igor,

-----

-------

Thanks
Khuzema

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

Hi Khusema,

Cheers,
Igor

-----Original Message-----
From: Khuzema Pithewan [mailto:[email-masked]]
Sent: Friday, January 02, 2015 6:13 PM
To: Igor Bryskin; BELOTTI, SERGIO (SERGIO); Leeyoung
Cc: Dhruv Dhody; [email-masked]; Victor Lopez; Daniele Ceccarelli; AshwoodsmithPeter
Subject: RE: [Actn] New Version Notification for draft-ceccarelli-actn-framework-05.txt

Thoughts?

Thanks
Khuzema

-----Original Message-----
From: ACTN [mailto:[email-masked]] On Behalf Of Igor Bryskin
Sent: Monday, December 22, 2014 5:36 AM
To: BELOTTI, SERGIO (SERGIO); Leeyoung
Cc: Dhruv Dhody; [email-masked]; Victor Lopez; Daniele Ceccarelli; AshwoodsmithPeter
Subject: Re: [Actn] New Version Notification for draft-ceccarelli-actn-framework-05.txt

Young and Sergio,

-----Original Message-----
From: BELOTTI, SERGIO (SERGIO) [mailto:[email-masked]]
Sent: Monday, December 22, 2014 5:43 AM
To: Leeyoung; Igor Bryskin
Cc: [email-masked]; AshwoodsmithPeter; Daniele Ceccarelli; Dhruv Dhody; Victor Lopez
Subject: RE: [Actn] New Version Notification for draft-ceccarelli-actn-framework-05.txt

Hi Igor,

Sergio

-----Original Message-----
From: Leeyoung [mailto:[email-masked]]
Sent: venerdì 19 dicembre 2014 22:27
To: Igor Bryskin; BELOTTI, SERGIO (SERGIO); AshwoodsmithPeter; Daniele Ceccarelli; Dhruv Dhody
Cc: [email-masked]
Subject: RE: [Actn] New Version Notification for draft-ceccarelli-actn-framework-05.txt

Hi Igor,

Thanks,
Young

-----Original Message-----
From: Igor Bryskin [mailto:[email-masked]]
Sent: Friday, December 19, 2014 2:34 PM
To: BELOTTI, SERGIO (SERGIO); Leeyoung; AshwoodsmithPeter; Daniele Ceccarelli; Dhruv Dhody
Cc: [email-masked]
Subject: RE: [Actn] New Version Notification for draft-ceccarelli-actn-framework-05.txt

Sergio,

Cheers,
Igor

-----Original Message-----
From: BELOTTI, SERGIO (SERGIO) [mailto:[email-masked]]
Sent: Friday, December 19, 2014 10:43 AM
To: Leeyoung; AshwoodsmithPeter; Igor Bryskin; Daniele Ceccarelli; Dhruv Dhody
Cc: [email-masked]
Subject: RE: [Actn] New Version Notification for draft-ceccarelli-actn-framework-05.txt

Hi all,

Thanks
Sergio

-----Original Message-----
From: Leeyoung [mailto:[email-masked]]
Sent: venerdì 19 dicembre 2014 00:01
To: AshwoodsmithPeter; Igor Bryskin; BELOTTI, SERGIO (SERGIO); Daniele Ceccarelli
Cc: [email-masked]
Subject: RE: [Actn] New Version Notification for draft-ceccarelli-actn-framework-05.txt

Hi Peter,

Thanks,
Young

-----Original Message-----
From: ACTN [mailto:[email-masked]] On Behalf Of AshwoodsmithPeter
Sent: Thursday, December 18, 2014 1:33 PM
To: Igor Bryskin; BELOTTI, SERGIO (SERGIO); Daniele Ceccarelli
Cc: [email-masked]
Subject: Re: [Actn] New Version Notification for draft-ceccarelli-actn-framework-05.txt

                 M S D N
                    |

                 M S D N
                 |  X  |

Peter

---

From: Khuzema Pithewan <[email-masked]>
Date: Wed, 7 Jan 2015 01:57:02 +0000

Hi Igor/Young,

I think we need some clarity in function definition. The way customer mapping function is defined, it means interpretation or conversion of customer services into set of commands that are expressed in terms of topology objects. Once they are expressed in terms of topology objects, it needs to be handled by virtual topology controller.

The set of function you have defined here, they seems to be like a topology filter or mapper to a client for a virtual topology. Some of these e.g. a portion of abstract topology, connectivity, consumed network resources are so close to the topology itself that separating them in a separate component will amount to repeating of data and then we need to worry about its coherency.  I agree some of these functions needs to be repeated with every level of virtualization/abstraction and it should be seen as a plugin to virtualization/abstraction controller and indeed this was my assumption (as Young pointed out in his another email).

Thanks
Khuzema

-----Original Message-----
From: Khuzema Pithewan [mailto:[email-masked]]
Sent: Tuesday, January 06, 2015 11:01 AM
To: Igor Bryskin; BELOTTI, SERGIO (SERGIO); Leeyoung
Cc: Dhruv Dhody; [email-masked]<mailto:[email-masked]>; Victor Lopez; Daniele Ceccarelli; AshwoodsmithPeter
Subject: Re: [Actn] New Version Notification for draft-ceccarelli-actn-framework-05.txt

Hi igor,

Khuzema

Sent from Samsung Mobile

-------- Original message --------
From: Igor Bryskin

Hi Khuzema,

You wrote:

Cheers,
Igor

-----Original Message-----
From: Khuzema Pithewan [mailto:[email-masked]]
Sent: Monday, January 05, 2015 4:29 PM
To: Igor Bryskin; BELOTTI, SERGIO (SERGIO); Leeyoung
Cc: Dhruv Dhody; [email-masked]<mailto:[email-masked]>; Victor Lopez; Daniele Ceccarelli; AshwoodsmithPeter
Subject: RE: [Actn] New Version Notification for draft-ceccarelli-actn-framework-05.txt

Hi Igor,

-----

-------

Thanks
Khuzema

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

Hi Khusema,

Cheers,
Igor

-----Original Message-----
From: Khuzema Pithewan [mailto:[email-masked]]
Sent: Friday, January 02, 2015 6:13 PM
To: Igor Bryskin; BELOTTI, SERGIO (SERGIO); Leeyoung
Cc: Dhruv Dhody; [email-masked]<mailto:[email-masked]>; Victor Lopez; Daniele Ceccarelli; AshwoodsmithPeter
Subject: RE: [Actn] New Version Notification for draft-ceccarelli-actn-framework-05.txt

Thoughts?

Thanks
Khuzema

-----Original Message-----
From: ACTN [mailto:[email-masked]] On Behalf Of Igor Bryskin
Sent: Monday, December 22, 2014 5:36 AM
To: BELOTTI, SERGIO (SERGIO); Leeyoung
Cc: Dhruv Dhody; [email-masked]<mailto:[email-masked]>; Victor Lopez; Daniele Ceccarelli; AshwoodsmithPeter
Subject: Re: [Actn] New Version Notification for draft-ceccarelli-actn-framework-05.txt

Young and Sergio,

-----Original Message-----
From: BELOTTI, SERGIO (SERGIO) [mailto:[email-masked]]
Sent: Monday, December 22, 2014 5:43 AM
To: Leeyoung; Igor Bryskin
Cc: [email-masked]<mailto:[email-masked]>; AshwoodsmithPeter; Daniele Ceccarelli; Dhruv Dhody; Victor Lopez
Subject: RE: [Actn] New Version Notification for draft-ceccarelli-actn-framework-05.txt

Hi Igor,

Sergio

-----Original Message-----
From: Leeyoung [mailto:[email-masked]]
Sent: venerdì 19 dicembre 2014 22:27
To: Igor Bryskin; BELOTTI, SERGIO (SERGIO); AshwoodsmithPeter; Daniele Ceccarelli; Dhruv Dhody
Cc: [email-masked]<mailto:[email-masked]>
Subject: RE: [Actn] New Version Notification for draft-ceccarelli-actn-framework-05.txt

Hi Igor,

Thanks,
Young

-----Original Message-----
From: Igor Bryskin [mailto:[email-masked]]
Sent: Friday, December 19, 2014 2:34 PM
To: BELOTTI, SERGIO (SERGIO); Leeyoung; AshwoodsmithPeter; Daniele Ceccarelli; Dhruv Dhody
Cc: [email-masked]<mailto:[email-masked]>
Subject: RE: [Actn] New Version Notification for draft-ceccarelli-actn-framework-05.txt

Sergio,

Cheers,
Igor

-----Original Message-----
From: BELOTTI, SERGIO (SERGIO) [mailto:[email-masked]]
Sent: Friday, December 19, 2014 10:43 AM
To: Leeyoung; AshwoodsmithPeter; Igor Bryskin; Daniele Ceccarelli; Dhruv Dhody
Cc: [email-masked]<mailto:[email-masked]>
Subject: RE: [Actn] New Version Notification for draft-ceccarelli-actn-framework-05.txt

Hi all,

Thanks
Sergio

-----Original Message-----
From: Leeyoung [mailto:[email-masked]]
Sent: venerdì 19 dicembre 2014 00:01
To: AshwoodsmithPeter; Igor Bryskin; BELOTTI, SERGIO (SERGIO); Daniele Ceccarelli
Cc: [email-masked]<mailto:[email-masked]>
Subject: RE: [Actn] New Version Notification for draft-ceccarelli-actn-framework-05.txt

Hi Peter,

Thanks,
Young

-----Original Message-----
From: ACTN [mailto:[email-masked]] On Behalf Of AshwoodsmithPeter
Sent: Thursday, December 18, 2014 1:33 PM
To: Igor Bryskin; BELOTTI, SERGIO (SERGIO); Daniele Ceccarelli
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [Actn] New Version Notification for draft-ceccarelli-actn-framework-05.txt

                 M S D N
                    |

                 M S D N
                 |  X  |

Peter

> Cc: [email-masked]<mailto:[email-masked]>
> Cc: Igor Bryskin; [email-masked]<mailto:[email-masked]>
> To: Daniele Ceccarelli; Igor Bryskin; [email-masked]<mailto:[email-masked]>
> > To: AshwoodsmithPeter; Igor Bryskin; [email-masked]<mailto:[email-masked]>
> > > To: Igor Bryskin; Daniele Ceccarelli; [email-masked]<mailto:[email-masked]>
> > > > To: Daniele Ceccarelli; [email-masked]<mailto:[email-masked]>
> > > > To: Igor Bryskin; [email-masked]<mailto:[email-masked]>
> > > > > To: Daniele Ceccarelli; [email-masked]<mailto:[email-masked]>
> > > > > To: [email-masked]<mailto:[email-masked]>
> > > > > From: [email-masked]<mailto:[email-masked]> [mailto:internet-
> [email-masked]<mailto:[email-masked]>]
> > > > > [email-masked]<mailto:[email-masked]>
> > > > [email-masked]<mailto:[email-masked]>
> [email-masked]<mailto:[email-masked]>
_______________________________________________
ACTN mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/actn
_______________________________________________
ACTN mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/actn

---

From: Daniele Ceccarelli <[email-masked]>
Date: Wed, 7 Jan 2015 10:48:13 +0000

Hi Igor,

Please find my replies in line.

Cheers
Daniele

> Sent: lunedì 5 gennaio 2015 20:45
> 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.
> 
[DanCe] using football terminology, your statement is an assist for me :)
The ADVA controller has an ACTN interface only northbound, hence it's a PNC
The TFK controller has an ACTN interface both noth and sounth, hence it's a MDSC 

> 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.
> 
[DanCe] If the PNC is a stateful PCE + GMPLS + NBI ACTN interface, it is always aware of what happens between line cards (i.e. LSPs and tunnels) but not of client cards (i.e. services). In this case services are managed by the MSDC.
If the PNC is an NMS, it is aware of paths and services. 
My idea was to have the PNC always dealing with LSPs and Tunnels ONLY and let the MSDC deal with services but I'm opening to your idea of a service aware PNC saying that "both solutions should be foreseen"

> 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
> 
> > services to other MSFT departments, applications and even clients. In this
> case it would need to perform the "client-mapping"

---

From: Daniele Ceccarelli <[email-masked]>
Date: Wed, 7 Jan 2015 10:51:48 +0000

Hi Dave,

I couldn't agree more, and this is one more reasons making me proposing different terms for PNC and MSDC (probably not correct names?).

I also think that despite the arguments on naming, architecture and football, this is a requirement that anyone has clear in mind (I hope). But in any case many thanks for remembering it explicitly.

Many thanks
Daniele

> From: Dave Hood
> Sent: lunedì 5 gennaio 2015 21:22
> To: Igor Bryskin; Daniele Ceccarelli; Khuzema Pithewan; BELOTTI, SERGIO
> (SERGIO); Leeyoung
> 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
>

---

From: Igor Bryskin <[email-masked]>
Date: Wed, 7 Jan 2015 15:47:27 +0000

Hi Daniele

[DanCe] using football terminology, your statement is an assist for me :) The ADVA controller has an ACTN interface only northbound, hence it's a PNC The TFK controller has an ACTN interface both noth and sounth, hence it's a MDSC 

IB>> Who is to say that ADVA cannot make use of its child domains? ADVA just like TFK uses the ACTN interface northbound and southbound. There are neither top nor bottom in the ACTN hierarchy

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

Hi Igor,

Cheers
Daniele

> DC>>>. I don't think that TFK controller (in your example below), 
> DC>>>which is a
> IB>> I think you are still missing the point. ADVA controller will 
> IB>> 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.
> 
[DanCe] using football terminology, your statement is an assist for me :) The ADVA controller has an ACTN interface only northbound, hence it's a PNC The TFK controller has an ACTN interface both noth and sounth, hence it's a MDSC 

> DC>> My idea was to have the PNCs unaware of services (like GMPLS) and 
> DC>> let
> IB>> This I don't get. PNC is always aware what is happening in the 
> IB>> 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.
> 

> 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.
> 
> 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.
> functionalities to be sold both as PNC and MDSC, that's reasonable, 
> but I would say not mandatory.
> 
> GMPLS) and let only the MDSCs know about services. Maybe both 
> scenarios should be foreseen.
> 
> Cheers
> Daniele
> 
> > 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.
> > 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 
> > function, the very same one that TFK will do for its client MSFT, 
> > and ADVA for its client TFK.
> > 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).
> > 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.
> >
> > 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.
> > 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.
> > 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 
> > 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?
> >
> > 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 
> > You do not need to export towards MSDC specif characteristics of 
> > your network but ACTN want to permit export of abstraction view .
> > the network elements, monitoring the physical topology of the 
> > network and passing it, either raw or abstracted, to the MDSC. ...
> > "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. ...
> > to implement all the four ACTN main functionalities, i.e. multi 
> > domain coordination function, virtualization/abstraction function, 
> > customer mapping function and virtual service coordination."
> >
> > 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.
> > 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.
> >
> > abstracted view (not actual network resource) based on what we 
> > defined above. Again the PNC needs not send actual network resource 
> > info to
> MDSC.
> > 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.
> >
> > highlighting possible needs or gaps in the reference model proposed 
> > in the
> framework.
> >
> > 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.
> > 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"
> > 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
> >
> >
> >
> > 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
> >
> >
> >
> > hub (N4), we could treat the single hub as a domain by itself with 
> > its own
> PCN.
> >
> >                  M S D N
> >                     |
> > 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.
> >
> > MSDN to MSDN I/F. I.E X is a kind of PCN 'light' (i.e. no 
> > abstraction
> capability).
> >
> >                  M S D N
> >                  |  X  |
> > 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.
> >
> > > 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:
> > > difference between the two, and why do  they appear in the 
> > > framework as separate logical entities?
> > >
> > > Cheers,
> > > Igor
> > >
> > >
> > > What about responsibility for inter domain links? Would that not 
> > > be a function of the MCDF? Don't see it discussed.
> > >
> > > Peter
> > >
> > > > > > 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.
> > > > > >
> > > > > > that are called " Network Function Virtualization Services". 
> > > > > > I am
> > > think
> > > > > > that go beyond the scope of the PNC, or to better say: I 
> > > > > > would split so different functionalities into different entities.
> > > > > >
> > > > > > 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
> > > > > > > (when a client of a transport network serves as a 
> > > > > > > transport provider for its own clients, and when the 
> > > > > > > transport network provider makes
> > > > > > use
> > > > > > > 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
> > > > > > > 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.
> > > > > > > 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
> > > > > > 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.
> > > > > > that are called " Network Function Virtualization Services". 
> > > > > > I am
> > > think
> > > > > > that go beyond the scope of the PNC, or to better say: I 
> > > > > > would split so different functionalities into different entities.
> > > > > >
> > > > > > > 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
> > > > > > > To: Daniele Ceccarelli; Luyuan Fang; Young Lee; Daniel 
> > > > > > > King; Luyuan Fang; Daniele Ceccarelli; Daniel King; Young 
> > > > > > > Lee; Diego
> > > R.

---

From: Leeyoung <[email-masked]>
Date: Wed, 7 Jan 2015 17:17:52 +0000

Hi Khuzema,

Yes I think we are talking about the same thing. Please see inline for my comment.

Thanks.
Young

Sent: Tuesday, January 06, 2015 7:57 PM

Hi Igor/Young,

YOUNG>> Yes, this is right when we narrowly define the customer as the top of the hierarchy (in this case, CNC) as the originator of VN request. There are some service policy and other information such as customer endpoint profile and other VN related parameters should be expressed among others in this customer mapping function between the CNC and MSDC.  But I began to think that the MSDC is a "customer" of the controllers (say PNC or another lower level MSDC) interfacing in its soundbound. Then I think there needs a "customer" mapping function, some of which is simply inherited from the originator of VN request (i.e. from CNC) and some of which needs to be filtered/pruned to be relevant to the server. And there may be a new "customer" policy created by the MSDC, for instance, the preference of inter-domain links, domain sequence (both of which are not inherited from the originator). These new elements need to be integrated with the customer mapping information inherited from the CNC. This aspect seems to be a bit more than virtualization/abstraction.

YOUNG>> Good point. I would not necessarily separate customer mapping and topology abstraction. This seems to be a bit implementation issue. When it comes to data model, I believe we have to support consistency check internally and formulate primitives and relevant information in the data model.

Thanks
Khuzema

-----Original Message-----
From: Khuzema Pithewan [mailto:[email-masked]]
Sent: Tuesday, January 06, 2015 11:01 AM
To: Igor Bryskin; BELOTTI, SERGIO (SERGIO); Leeyoung
Cc: Dhruv Dhody; [email-masked]<mailto:[email-masked]>; Victor Lopez; Daniele Ceccarelli; AshwoodsmithPeter
Subject: Re: [Actn] New Version Notification for draft-ceccarelli-actn-framework-05.txt

Hi igor,

Khuzema

Sent from Samsung Mobile

-------- Original message --------
From: Igor Bryskin

Hi Khuzema,

You wrote:

Cheers,
Igor

-----Original Message-----
From: Khuzema Pithewan [mailto:[email-masked]]
Sent: Monday, January 05, 2015 4:29 PM
To: Igor Bryskin; BELOTTI, SERGIO (SERGIO); Leeyoung
Cc: Dhruv Dhody; [email-masked]<mailto:[email-masked]>; Victor Lopez; Daniele Ceccarelli; AshwoodsmithPeter
Subject: RE: [Actn] New Version Notification for draft-ceccarelli-actn-framework-05.txt

Hi Igor,

-----

-------

Thanks
Khuzema

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

Hi Khusema,

Cheers,
Igor

-----Original Message-----
From: Khuzema Pithewan [mailto:[email-masked]]
Sent: Friday, January 02, 2015 6:13 PM
To: Igor Bryskin; BELOTTI, SERGIO (SERGIO); Leeyoung
Cc: Dhruv Dhody; [email-masked]<mailto:[email-masked]>; Victor Lopez; Daniele Ceccarelli; AshwoodsmithPeter
Subject: RE: [Actn] New Version Notification for draft-ceccarelli-actn-framework-05.txt

Thoughts?

Thanks
Khuzema

-----Original Message-----
From: ACTN [mailto:[email-masked]] On Behalf Of Igor Bryskin
Sent: Monday, December 22, 2014 5:36 AM
To: BELOTTI, SERGIO (SERGIO); Leeyoung
Cc: Dhruv Dhody; [email-masked]<mailto:[email-masked]>; Victor Lopez; Daniele Ceccarelli; AshwoodsmithPeter
Subject: Re: [Actn] New Version Notification for draft-ceccarelli-actn-framework-05.txt

Young and Sergio,

-----Original Message-----
From: BELOTTI, SERGIO (SERGIO) [mailto:[email-masked]]
Sent: Monday, December 22, 2014 5:43 AM
To: Leeyoung; Igor Bryskin
Cc: [email-masked]<mailto:[email-masked]>; AshwoodsmithPeter; Daniele Ceccarelli; Dhruv Dhody; Victor Lopez
Subject: RE: [Actn] New Version Notification for draft-ceccarelli-actn-framework-05.txt

Hi Igor,

Sergio

-----Original Message-----
From: Leeyoung [mailto:[email-masked]]
Sent: venerdì 19 dicembre 2014 22:27
To: Igor Bryskin; BELOTTI, SERGIO (SERGIO); AshwoodsmithPeter; Daniele Ceccarelli; Dhruv Dhody
Cc: [email-masked]<mailto:[email-masked]>
Subject: RE: [Actn] New Version Notification for draft-ceccarelli-actn-framework-05.txt

Hi Igor,

Thanks,
Young

-----Original Message-----
From: Igor Bryskin [mailto:[email-masked]]
Sent: Friday, December 19, 2014 2:34 PM
To: BELOTTI, SERGIO (SERGIO); Leeyoung; AshwoodsmithPeter; Daniele Ceccarelli; Dhruv Dhody
Cc: [email-masked]<mailto:[email-masked]>
Subject: RE: [Actn] New Version Notification for draft-ceccarelli-actn-framework-05.txt

Sergio,

Cheers,
Igor

-----Original Message-----
From: BELOTTI, SERGIO (SERGIO) [mailto:[email-masked]]
Sent: Friday, December 19, 2014 10:43 AM
To: Leeyoung; AshwoodsmithPeter; Igor Bryskin; Daniele Ceccarelli; Dhruv Dhody
Cc: [email-masked]<mailto:[email-masked]>
Subject: RE: [Actn] New Version Notification for draft-ceccarelli-actn-framework-05.txt

Hi all,

Thanks
Sergio

-----Original Message-----
From: Leeyoung [mailto:[email-masked]]
Sent: venerdì 19 dicembre 2014 00:01
To: AshwoodsmithPeter; Igor Bryskin; BELOTTI, SERGIO (SERGIO); Daniele Ceccarelli
Cc: [email-masked]<mailto:[email-masked]>
Subject: RE: [Actn] New Version Notification for draft-ceccarelli-actn-framework-05.txt

Hi Peter,

Thanks,
Young

-----Original Message-----
From: ACTN [mailto:[email-masked]] On Behalf Of AshwoodsmithPeter
Sent: Thursday, December 18, 2014 1:33 PM
To: Igor Bryskin; BELOTTI, SERGIO (SERGIO); Daniele Ceccarelli
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [Actn] New Version Notification for draft-ceccarelli-actn-framework-05.txt

                 M S D N
                    |

                 M S D N
                 |  X  |

Peter