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

[Daniele Ceccarelli <[e-mail]>]

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

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