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

From: Daniele Ceccarelli <[email-masked]>
Date: Mon, 15 Dec 2014 11:36:59 +0000

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:[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

---

From: Igor Bryskin <[email-masked]>
Date: Mon, 15 Dec 2014 19:50:15 +0000

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.

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.  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.

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,

Many thanks
The authors.

-----Original Message-----
From: [email-masked] [mailto:[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

Abstract:

The IETF Secretariat

_______________________________________________
ACTN mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/actn

---

From: Daniele Ceccarelli <[email-masked]>
Date: Wed, 17 Dec 2014 10:50:39 +0000

Hi Igor,

Thanks a lot for the review.
Regarding your comments please see in line.

Cheers,
Daniele

> 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,
> 
> 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.

> 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)
> 	- 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.
> 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
> 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: Igor Bryskin <[email-masked]>
Date: Wed, 17 Dec 2014 14:08:24 +0000

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 th…

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,

Cheers,
Daniele

> Subject: RE: [Actn] New Version Notification for 
> draft-ceccarelli-actn- framework-05.txt
> 
> Hi Daniele,
> 
> 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.

> 
> 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.

> 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.
> 

> - 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)
> 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.
> 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
> 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: AshwoodsmithPeter <[email-masked]>
Date: Wed, 17 Dec 2014 15:47:53 +0000

There is a definite elegance to what Igor suggests and experience with recursion definitely teaches that elegance is associated with correctness. 

Peter

> From: ACTN [mailto:[email-masked]] On Behalf Of Igor Bryskin
> Sent: Wednesday, December 17, 2014 9:08 AM
> Subject: Re: [Actn] New Version Notification for draft-ceccarelli-actn-
> framework-05.txt
> 
> Hi Daniele,
> 
> 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
> 
> 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.
> 
> >
> 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.
> 
> 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
> >
> > URL:            http://www.ietf.org/internet-drafts/draft-ceccarelli-
> actn-
> > framework-05.txt
> > Status:         https://datatracker.ietf.org/doc/draft-ceccarelli-
> actn-
> > framework/
> > Diff:           http://www.ietf.org/rfcdiff?url2=draft-ceccarelli-
> actn-framework-
> > 05
> >
> > Abstract:

---

From: Daniele Ceccarelli <[email-masked]>
Date: Wed, 17 Dec 2014 16:42:38 +0000

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

> From: AshwoodsmithPeter [mailto:[email-masked]]
> Sent: mercoledì 17 dicembre 2014 16:48
> To: Igor Bryskin; Daniele Ceccarelli; [email-masked]
> There is a definite elegance to what Igor suggests and experience with
> recursion definitely teaches that elegance is associated with correctness.
> 
> Peter
> 
> > Subject: Re: [Actn] New Version Notification for
> > 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.
> >
> > > links) the service is placed on may be abstract and could be
> > > provided by underlying PNCs (which is correct); however, the service
> > 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.
> > 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
> > >
> > > 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:
> > >
> > > The new functionality includes the management of services (i.e.
> > > we're no longer speaking just about links and nodes but also about
> > services)
> > > - A mapping among use cases and what is (in authors opinion at
> > > least) a new work in ACTN scope is provided.
> > >

---

From: Daniele Ceccarelli <[email-masked]>
Date: Wed, 17 Dec 2014 16:42:37 +0000

Hi Igor,

I think you're perfectly right in the case of abstract topology (i.e. nodes and links). In that case I tend to agree with you when saying that there is no difference between MDSC and PCS.

In other cases (let's say in the case of the services) I think that limiting the PNC to the knowledge of the inner part of the network (i.e. same scope of the GMPLS: line interfaces) allows including also all the non SDN scenarios. In the case of a GMPLS controlled networks with a PCE on top, you just need to add a NBI plugin to the PCE to have a PNC but you don't want to have the PCE made aware of services and hence delegate that to the MDSC on top of you PNC (=PCE+GMPLS).

In a whole green field SDN scenario I would agree with you. 
In an abstract topology scenario I do agree with you.
I just wanted to cover also the rest.

Cheers,
Daniele

> Sent: mercoledì 17 dicembre 2014 15:08
> 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.
> with the same interface (supported by the same set of models) between any
> two adjacent MDSCs in the stack.
> 
> Cheers,
> Igor
> 
> 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.
> 
> >
> 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.
> 
> 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
> >
> > Diff:           http://www.ietf.org/rfcdiff?url2=draft-ceccarelli-actn-
> framework-
> > 05
> >
> > Abstract:

---

From: John E Drake <[email-masked]>
Date: Wed, 17 Dec 2014 18:32:30 +0000

"I adhered scrupulously to the precept of that brilliant theoretical physicist, L. Boltzmann, according to whom matters of elegance ought to be left to the tailor and to the cobbler."  - A. Einstein 1920

Yours Irrespectively,

John

> From: ACTN [mailto:[email-masked]] On Behalf Of
> AshwoodsmithPeter
> Sent: Wednesday, December 17, 2014 10:48 AM

---

From: Igor Bryskin <[email-masked]>
Date: Wed, 17 Dec 2014 19:19:39 +0000

Peter,
Thanks for the kind words.

John,
I know that you can turn any discussion into a philosophical one !
I do not disagree with the quote, but let me ask you this: in your opinion ACTN designers, such as Daniele and Young,, are they closer to tailors or to theoretical physicists? 
I do agree that you do not design elegant network architecture for the elegance sake. But I 100% agree with Peter: experience unequivocally tells us that elegant network solutions like beautiful people or animals tend to be healthier, stronger and more robust than the ugly ones. They develop faster, adopt to different environments better and withstand unexpected challenges easier. To put it simply they have a better chance to survive and therefore are likely to be correct.

Cheers,
Igor

-----Original Message-----
From: John E Drake [mailto:[email-masked]] 
Sent: Wednesday, December 17, 2014 1:33 PM
To: AshwoodsmithPeter; Igor Bryskin; Daniele Ceccarelli; [email-masked]
Subject: RE: [Actn] New Version Notification for draft-ceccarelli-actn-framework-05.txt

Yours Irrespectively,

John

> > >> I'm not too "religious" about the naming but I think a 
> > >> distinction
> > is useful.
> >
> > 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
> >
> > > (when a client of a transport network serves as a transport 
> > > provider for its own clients, and when the transport network 
> > > provider makes
> > use
> > 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.
> >
> > >
> > > (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.
> >
> > 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.
> >
> > > 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 
> > 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.
> > > Subject: [Actn] New Version Notification for 
> > > 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:
> > >
> > > operations used to provide connectivity between customer 
> > > end-points
> > e.g.
> > > VPNs
> > > cloud providers or content delivery providers. We are speaking 
> > > about storage, virtual machines, VM mobility and so on.
> > > 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

---

From: AshwoodsmithPeter <[email-masked]>
Date: Wed, 17 Dec 2014 19:22:48 +0000

LOL John, but if memory serves neither Einstein nor Boltzmann wrote:

    E = MC^2      { except lunchtimes when its doubled }
    S = k x log W { except Wednesdays }

:)

Merry X-mass

Peter

> Sent: Wednesday, December 17, 2014 1:32 PM
> "I adhered scrupulously to the precept of that brilliant theoretical
> physicist, L. Boltzmann, according to whom matters of elegance ought to
> be left to the tailor and to the cobbler."  - A. Einstein 1920
> 
> Yours Irrespectively,
> 
> John
> 
> > > >> One further thing that in my opinion is only relevant to the
> MDSC
> > > >> is
> > > > of its own providers0 - is not properly elaborated  in the
> document.
> > > I
> > > > Title:		Framework for Abstraction and Control of
> Transport
> > > > Networks

---

From: Leeyoung <[email-masked]>
Date: Wed, 17 Dec 2014 19:27:59 +0000

Well,

Igor, since you mentioned my name, I would say I am a simple network architect who knows not too much about theoretical physics nor tailoring. 

One more quote is we'd like to add: "Make things as simple as possible, but not simpler." --I believe that is what Daniele tried to elaborate in his last correspondence. :)

Young

-----Original Message-----
From: ACTN [mailto:[email-masked]] On Behalf Of Igor Bryskin
Sent: Wednesday, December 17, 2014 1:20 PM
To: John E Drake; AshwoodsmithPeter; Daniele Ceccarelli; [email-masked]
Subject: Re: [Actn] New Version Notification for draft-ceccarelli-actn-framework-05.txt

Peter,

John,

Cheers,
Igor

-----Original Message-----
From: John E Drake [mailto:[email-masked]]
Sent: Wednesday, December 17, 2014 1:33 PM
To: AshwoodsmithPeter; Igor Bryskin; Daniele Ceccarelli; [email-masked]
Subject: RE: [Actn] New Version Notification for draft-ceccarelli-actn-framework-05.txt

Yours Irrespectively,

John

---

From: AshwoodsmithPeter <[email-masked]>
Date: Wed, 17 Dec 2014 19:30:01 +0000

Igor, I spent a lot of time doing LISP interpreters and compilers where the 'correct' recursive solution was usually very simple and could not be reduced any further. It would be great if this was true of a hierarchical ACTN solution.

I suspect however that the practicality of existing deployed solutions will make this difficult to completely achieve but I agree with trying very hard to do so and questioning when we deviate.

Peter

> Sent: Wednesday, December 17, 2014 2:20 PM
> I do not disagree with the quote, but let me ask you this: in your
> opinion ACTN designers, such as Daniele and Young,, are they closer to
> tailors or to theoretical physicists?
> I do agree that you do not design elegant network architecture for the
> elegance sake. But I 100% agree with Peter: experience unequivocally
> tells us that elegant network solutions like beautiful people or
> animals tend to be healthier, stronger and more robust than the ugly
> ones. They develop faster, adopt to different environments better and
> withstand unexpected challenges easier. To put it simply they have a
> better chance to survive and therefore are likely to be correct.
> 
> Cheers,
> Igor
>

---

From: Igor Bryskin <[email-masked]>
Date: Wed, 17 Dec 2014 19:42:19 +0000

Peter, 
I spent last 14 year designing and developing GMPLS solutions. I am pretty sure that each of them if extended to support a properly designed north bound interface (which is, of course, a part of management plane and has nothing to do with GMPLS per-se) can happily participate in the hierarchical ACTN paradigm.

Igor

-----Original Message-----
From: AshwoodsmithPeter [mailto:[email-masked]] 
Sent: Wednesday, December 17, 2014 2:30 PM
To: Igor Bryskin; John E Drake; Daniele Ceccarelli; [email-masked]
Subject: RE: [Actn] New Version Notification for draft-ceccarelli-actn-framework-05.txt

Peter

> physicist, L. Boltzmann, according to whom matters of elegance ought 
> to be left to the tailor and to the cobbler."  - A. Einstein 1920
> 
> Yours Irrespectively,
> 
> John
> 
> > > 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.
> > >
> > > 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 
> > > I respectively disagree with this. IMHO the recursive nature of 
> > > the interface between service client and service provider applies 
> > > to
> all
> > > 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.
> > > MDSCs with the same interface (supported by the same set of 
> > > models) between any two adjacent MDSCs in the stack.
> > >
> > > Cheers,
> > > Igor
> > >
> > > 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
> > > > service termination points must be *under direct control* of 
> > > > MDSC (I don't believe that service termination points could be 
> > > 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 
> > > of a customer requesting for a virtual machine and a given amount 
> > > of storage. The PNC is the one in charge of providing connectivity 
> > > > 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: AshwoodsmithPeter <[email-masked]>
Date: Wed, 17 Dec 2014 20:37:43 +0000

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

> Sent: Wednesday, December 17, 2014 11:43 AM
> To: AshwoodsmithPeter; Igor Bryskin; [email-masked]
> 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
>

---

From: Igor Bryskin <[email-masked]>
Date: Wed, 17 Dec 2014 21:01:24 +0000

Hi Peter,
The question you asked is a good one. Let's assume for simplicity sake that each of the subordinate domains is  presented as a single abstract node. Then inter-domain links will be the links inter-connecting said abstract nodes. So, one approach would be to have subordinate controllers to be responsible for the ends of inter-domain links they terminate. Another approach would be to have MDSC to work with the overlay topology made up of abstract topologies provided by each of the domains + inter-domain links,  with the MDSC controlling the latter.

Igor  

-----Original Message-----
From: AshwoodsmithPeter [mailto:[email-masked]] 
Sent: Wednesday, December 17, 2014 3:38 PM
To: Daniele Ceccarelli; Igor Bryskin; [email-masked]
Subject: RE: [Actn] New Version Notification for draft-ceccarelli-actn-framework-05.txt

Hey Daniele,

simple question:

Peter

---

From: Leeyoung <[email-masked]>
Date: Wed, 17 Dec 2014 23:18:15 +0000

Hi Peter,

Thanks for your review and fixing some nits. The revision will take care of those nits. 

In regard to your question on whose responsibility for inter-domain links, the domain controller (termed as PNC) should be responsible to abstract all inter-domain links it interfaces with other domains. Then the MDSC is the control entity that puts together with all domain-level abstraction to create an end-to-end abstracted topology. See Section 4.1 under use case: draft-klee-actn-connectivity-multi-vendor-domains-02. 

Regards,
Young

-----Original Message-----
From: ACTN [mailto:[email-masked]] On Behalf Of AshwoodsmithPeter
Sent: Wednesday, December 17, 2014 2:38 PM
To: Daniele Ceccarelli; Igor Bryskin; [email-masked]
Subject: Re: [Actn] New Version Notification for draft-ceccarelli-actn-framework-05.txt

Hey Daniele,

simple question:

Peter

---

From: "BELOTTI, SERGIO (SERGIO)" <[email-masked]>
Date: Thu, 18 Dec 2014 08:53:04 +0000

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,

simple question:

Peter

---

From: Igor Bryskin <[email-masked]>
Date: Thu, 18 Dec 2014 13:48:17 +0000

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:[email-masked]] 
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,

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,

simple question:

Peter

---

From: John E Drake <[email-masked]>
Date: Thu, 18 Dec 2014 17:21:03 +0000

Eugenics?

Yours Irrespectively,

John

> I do not disagree with the quote, but let me ask you this: in your opinion
> ACTN designers, such as Daniele and Young,, are they closer to tailors or to
> theoretical physicists?
> elegance sake. But I 100% agree with Peter: experience unequivocally tells us
> that elegant network solutions like beautiful people or animals tend to be
> healthier, stronger and more robust than the ugly ones. They develop faster,
> adopt to different environments better and withstand unexpected
> challenges easier. To put it simply they have a better chance to survive and
> therefore are likely to be correct.
> 
> Cheers,
> Igor
> 
> "I adhered scrupulously to the precept of that brilliant theoretical physicist, L.
> Boltzmann, according to whom matters of elegance ought to be left to the
> tailor and to the cobbler."  - A. Einstein 1920
> 
> Yours Irrespectively,
> 
> John
>

---

From: AshwoodsmithPeter <[email-masked]>
Date: Thu, 18 Dec 2014 19:33:09 +0000

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

> Sent: Thursday, December 18, 2014 8:48 AM
> To: BELOTTI, SERGIO (SERGIO); AshwoodsmithPeter; Daniele Ceccarelli
> Cc: [email-masked]
> 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:
> 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
> 
> 
> you're right : this functionality has to be part of "Multi domain
> coordination function", and has has to be explicitly mentioned.
> 
> Thanks
> Sergio
> 
> 
> What about responsibility for inter domain links? Would that not be a
> function of the MCDF? Don't see it discussed.
> 
> Peter
> 
> > > > > recursive nature of the ACTN architecture with corresponding
> use
> > > > cases
> > > > > has been successfully submitted by Daniele Ceccarelli and
> posted
> > > > > to the IETF repository.
> > > > >
> > > > > Htmlized:       http://tools.ietf.org/html/draft-ceccarelli-
> actn-
> > > > framework-05

---

From: Igor Bryskin <[email-masked]>
Date: Thu, 18 Dec 2014 22:15:34 +0000

Peter,

Thanks for your input, this is very helpful.
One additional point. Consider that the leftmost PNC(controlling N1, N2, N3) would want to make use of its subordinate  domains D1, D2, D3, controlled by PNC11, PNC12 and PNC13.
In this case said PNC immediately turns into MDSC (no different from MDSC on the top). 
IMHO it is not just overlapping functionality, it is identical functionality.

Igor

-----Original Message-----
From: AshwoodsmithPeter [mailto:[email-masked]] 
Sent: Thursday, December 18, 2014 2: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: Thu, 18 Dec 2014 23:00:30 +0000

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

                 M S D N
                    |

                 M S D N
                 |  X  |

Peter

> I agree with what you said. This is especially true and apparent in 
> the configurations where the domains controlled by the subordinate 
> difference between the two, and why do  they appear in the framework 
> as separate logical entities?
> 
> Cheers,
> Igor
> 
> 
> Page6 "which is usually best-efforts" should be "which is usually 
> best- effort"
> > 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
> >
> > > > of a customer requesting for a virtual machine and a given 
> > > > amount of storage. The PNC is the one in charge of providing
> connectivity
> > > > the interface between service client and service provider 
> > > > applies to
> > all
> > > > 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.
> > > > coordination" functionality is associated both to the PNC and 
> > > > the
> > MDSC.
> > > > of a customer requesting for a virtual machine and a given 
> > > > amount of storage. The PNC is the one in charge of providing
> connectivity
> > > > > of submission until the htmlized version and diff are 
> > > > > available at
> > > > tools.ietf.org.
> > > > >
> > > > > The IETF Secretariat
> > > > >

---

From: Luyuan Fang <[email-masked]>
Date: Fri, 19 Dec 2014 04:43:33 +0000

Young,

I share the same view as you pointed.
Thanks,
Luyuan

-----Original Message-----
From: ACTN [mailto:[email-masked]] On Behalf Of Leeyoung
Sent: Thursday, December 18, 2014 6:01 PM
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: "BELOTTI, SERGIO (SERGIO)" <[email-masked]>
Date: Fri, 19 Dec 2014 15:43:08 +0000

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,

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: Fri, 19 Dec 2014 15:56:56 +0000

When we developed the SDN architecture<https://www.opennetworking.org/images/stories/downloads/sdn-resources/technical-reports/TR_SDN_ARCH_1.0_06062014.pdf> in ONF, the value of recursion was apparent, so we did not attempt to impose fine-grained classification on SDN controllers. Although they can and will differ in detail, they are architecturally the same: as directed by their own management, they are responsible to control the resources available to them, export a tenant-specific view to each of some number of customers, and ensure isolation between the various tenants.

It is entirely appropriate for the next step, such as ACTN, to consider specialization, preferably without breaking the more abstract concepts.

Dave

-----Original Message-----
From: ACTN [mailto:[email-masked]] On Behalf Of BELOTTI, SERGIO (SERGIO)
Sent: Friday, December 19, 2014 7: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-----

Cc: [email-masked]<mailto:[email-masked]>

Hi Peter,

Thanks,

Young

-----Original Message-----

Cc: [email-masked]<mailto:[email-masked]>

                 M S D N

                    |

    |               |               |

   PCN             PCN             PCN

    |               |               |

 |  |  |            |            |  |  |

          I.D.LINK    I.D.LINK

                 M S D N

                |  X  |

    |               |               |

  MSDN              |              MSDN

    X               |               X

+--+--+            |            +--+--+

 |  |  |            |            |  |  |

          I.D.LINK    I.D.LINK

Peter

> Cc: [email-masked]<mailto:[email-masked]>

> a) Generally speaking, MDSC needs to be able to control actual network

> elements and links, and

> From: BELOTTI, SERGIO (SERGIO) [mailto:sergio.belotti@alcatel-

> lucent.com]

> Cc: Igor Bryskin; [email-masked]<mailto:[email-masked]>

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

> Page3 "such that resource guarantee" should be "such that resource

> guarantees"

> 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.

> > To: AshwoodsmithPeter; Igor Bryskin; [email-masked]<mailto:[email-masked]>

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

> > > There is a definite elegance to what Igor suggests and experience

> > with

> > > recursion definitely teaches that elegance is associated with

> > correctness.

> > > > From: ACTN [mailto:[email-masked]] On Behalf Of Igor

> > > > Bryskin

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

> > > > are called " Network Function Virtualization Services". I am

> think

> > > > From: Daniele Ceccarelli

> > > > [mailto:[email-masked]]

> > > > To: Igor Bryskin; [email-masked]<mailto:[email-masked]>

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

> > > > 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

> > > > > PNCs (e.g. one in the middle of the picture). I assume that

> said

> > > > functionalities are listed) and sections 3.1, 3.2, 3.3 state

> which

> > > > > coordination for a given service, it is assumed that the

> > > > > topology (nodes and

> > > > > MDSC must physically control service termination points. The

> > point

> > > > > it MDSC or VNC, I fail to see a difference between this

> *animal*

> > > > is useful. I think of the PNC as the entity which has the same

> > scope

> > > > are called " Network Function Virtualization Services". I am

> think

> > > > 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

> > > > > From: ACTN [mailto:[email-masked]] On Behalf Of Daniele

> > > > > Ceccarelli

> > > > > To: [email-masked]<mailto:[email-masked]>

> > > > > - 4 functionalities have been defined for the different

> > > > > we're no longer speaking just about links and nodes but also

> > about

> > > > >          - Service-aware Connectivity Services: all the network

> > service

> > > > >          - Network Function Virtualization Services: between

> > customers'

> > > > > speaking about storage, virtual machines, VM mobility and so

> on.

> > > > > - VNC renamed into MDSC and a mapping between controller and

> > > > > functionalities has been provided

> > > > > From: [email-masked]<mailto:[email-masked]> [mailto:internet-

> [email-masked]<mailto:[email-masked]>]

> > > > > Luyuan Fang; Daniele Ceccarelli; Daniel King; Young Lee; Diego

> R.

> > > > > Subject: New Version Notification for

> > > > > draft-ceccarelli-actn-framework-05.txt

> > > > > URL:            http://www.ietf.org/internet-drafts/draft-

> > ceccarelli-

> > > > > Status:         https://datatracker.ietf.org/doc/draft-

> > ceccarelli-

> > > > > Diff:           http://www.ietf.org/rfcdiff?url2=draft-

> > ceccarelli-

> > > > >    This draft provides a framework for abstraction and control

> of

> > > > > [email-masked]<mailto:[email-masked]>

> > > > [email-masked]<mailto:[email-masked]>

> [email-masked]<mailto:[email-masked]>

ACTN mailing list

[email-masked]<mailto:[email-masked]>

ACTN mailing list

[email-masked]<mailto:[email-masked]>

---

From: AshwoodsmithPeter <[email-masked]>
Date: Fri, 19 Dec 2014 19:56:09 +0000

Luyuan/Young,

Not sure I follow your point re scalability? Can you elaborate a bit? Or if its written up somewhere that I've missed just point me to it.

Peter

> From: ACTN [mailto:[email-masked]] On Behalf Of Luyuan Fang
> Sent: Thursday, December 18, 2014 11:44 PM
> To: Leeyoung; AshwoodsmithPeter; Igor Bryskin; BELOTTI, SERGIO
> (SERGIO); Daniele Ceccarelli
> Cc: [email-masked]
> 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: Fri, 19 Dec 2014 20:33:51 +0000

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. 

 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.

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: Fri, 19 Dec 2014 21:26:43 +0000

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,

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. 

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,

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: Fri, 19 Dec 2014 21:39:12 +0000

Hi Peter, 

What I meant on scalability is that the PNCs need to give the MSDC an abstracted view of topology rather than the raw/actual topology. MDSC would then put several abstracted topology from each PNCs to create the end-to-end abstract topology. If PNCs were to send their raw/abstracted topology to the MSDC, then this is not scalable for the MSDC as it has to deal with a large amount of data processing. Operators (Telefonica, Microsoft and KT and SKT, CM and KDDI and others) indicated that the MSDC should be an abstracted view of their physical domains, not raw data. Some single domain has a magnitude of 1000's NEs and abstraction will help tremendously the operators (the MSDC) in managing their network. 

Thanks,
Young

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

Luyuan/Young,

Peter

> The code saving, however, would come at the expense of scalability if 
> I understood correctly. This is exactly what operators want to avoid.
> 
> 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  |
> > b) PNC needs to be able to perform multi-domain coordination (in 
> > case it uses several subordinate PNCs of it's own)
> >
> > What about responsibility for inter domain links? Would that not be 
> > a function of the MCDF? Don't see it discussed.
> >
> > Peter
> >
> > > > > 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.
> > > > > > 1. I don't think that one of explicit Adrian's requests - 
> > > > > > the recursive nature of the ACTN architecture with 
> > > > > > corresponding
> > use
> > > > > cases
> > > > > 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.
> > > > >

---

From: Leeyoung <[email-masked]>
Date: Fri, 19 Dec 2014 21:48:36 +0000

I think there was some typo. What I intended to say is:

What I meant on scalability is that the PNCs need to give the MSDC an abstracted view of topology rather than the raw/actual topology. MDSC would then put several abstracted topology from each PNCs to create the end-to-end abstract topology. If PNCs were to send their raw topology to the MSDC, then this is not scalable for the MSDC as it has to deal with a large amount of data processing. Operators (Telefonica, Microsoft and KT and SKT, CM and KDDI and others) indicated that the MSDC should be given an abstracted view of their physical domains, not raw data. Some single domain has a magnitude of 1000's NEs and abstraction will help tremendously the operators (the MSDC) in managing their network.

Young
-----Original Message-----
From: Leeyoung 
Sent: Friday, December 19, 2014 3:39 PM
To: AshwoodsmithPeter; Luyuan Fang; 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: AshwoodsmithPeter
Sent: Friday, December 19, 2014 1:56 PM
To: Luyuan Fang; Leeyoung; Igor Bryskin; BELOTTI, SERGIO (SERGIO); Daniele Ceccarelli
Cc: [email-masked]
Subject: RE: [Actn] New Version Notification for draft-ceccarelli-actn-framework-05.txt

Luyuan/Young,

Peter

---

From: "BELOTTI, SERGIO (SERGIO)" <[email-masked]>
Date: Mon, 22 Dec 2014 10:43:03 +0000

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,

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: Mon, 22 Dec 2014 13:36:24 +0000

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,

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