Re: [Teas] ACTN update

["Scharf, Michael (Nokia - DE)" <[e-mail]>]

Hi Daniele,

I don't think that MDSC can be considered as a subset of an orchestrator, for the current definition of MDSC. For instance, I read in draft-ietf-teas-actn-framework-01 this statement:

   "A key requirement for allowing recursion of MDSCs is that a single
   interface needs to be defined both for the north and the south
   bounds."

If that were the case, the northbound and southbound interface of an orchestrator would have to have that recursion property of MSDC as well, for a subset of its interfaces, right?

But, unfortunately, I don't believe that this is generally true. One indication is that draft-wu-opsawg-service-model-explained-03 defines different models on the different interfaces for an orchestrator (the names may not be consensus). These interfaces may even use entirely different protocols and data models in reality.

To me, the recursion envisioned for MDSC seems to contradict how orchestrators are discussed in other IETF WGs. I am not sure how this can be sorted except by revisiting the ACTN concepts and terms from a service provisioning workflow point of view.

Thanks

Michael


From: Daniele Ceccarelli [mailto:[e-mail]]
Sent: Thursday, November 17, 2016 6:20 PM
To: Scharf, Michael (Nokia - DE); TEAS WG ([e-mail])
Subject: RE: ACTN update

In line

BR
Daniele

From: Scharf, Michael (Nokia - DE) [mailto:[e-mail]]
Sent: giovedì 17 novembre 2016 21:10
To: Daniele Ceccarelli <[e-mail]<mailto:[e-mail]>>; TEAS WG ([e-mail]<mailto:[e-mail]>) <[e-mail]<mailto:[e-mail]>>
Subject: RE: ACTN update

Hi all,

I think ongoing discussions in OPSAWG and L2SM show that a "service orchestrator" implementing the L3SM model (or e.g. the L2SM model) may not necessarily directly talk to a domain controller.

DC> May not or may, this is just an example.  The goal of the slides is totally different and is to show the relationship between the orchestrator and the MDSC, since orchestrator is a well known term and the MDSC is not. There was a misunderstanding in thinking that the relationship is 1:1 while the MDSC is just a subset of the orchestrator functionalities. I hope you'll have the chance to read the minutes of the meeting when available.

There can be much more complex architectures, e.g., if the service provider and network operator are not the same organization.
DC> This is orthogonal with respect to the slides. If the service provide and the network operator are not in the same organization (very common situation) the "service" box will be inside the orchestrator and the MDSC will be out, what's the problem?

Also, the L3SM is a customer-facing model and the system may deal with customer "SLAs". Therefore, I am not sure if the term "TE" is really useful at the level of the L3SM model. Also, I believe the SLAs for a customer may not necessarily directly relate to TE. So, I find the notion "L3SM + TE" quite confusing.
DC> Again, that's just an example to say that it is L3SM plus constraints and not just "I want connectivity between X and Y". If you don't like "L3SM+TE" we can find a better one. If you have a suggestion it's more than welcome.

In summary, I don't think that this slide deck clarifies the role of ACTN in a real service provisioning architecture, e.g., for IP services.

And since there is already terminology discussion in OPSAWG and L2SM/L3SM, I find it not useful to add further ACTN-specific terms. This just increases the confusion that already exists.

Maybe TEAS should back of a bit and work with the other WGs on terminology alignment?
DC> if you have a proposal I'm more than happy to consider it

Thanks

Michael


From: Teas [mailto:[e-mail]] On Behalf Of Daniele Ceccarelli
Sent: Thursday, November 17, 2016 3:32 AM
To: TEAS WG ([e-mail]<mailto:[e-mail]>) <[e-mail]<mailto:[e-mail]>>
Subject: [Teas] ACTN update

Dear WG and ACTNers,

Please find attached some slides trying to clarify terminology, roles and functionalities in ACTN (in line with the discussion we had at the mic during the TEAS session). It provides an architectural explanation and a possible workflow description trying to see if it fits with the architecture.

My proposal is to:

1.       Add a section in the framework document to explain the relationship and the split of roles between PNC, MDSC and existing components like orchestrator and domain controller.

2.       Add a section to the "Applicability of YANG models for ACTN" to explain how this impacts the definition of the MPI and what is missing (i.e. TE-Service model). This will have impacts also on the PCEP applicability.

3.    Write a new document defining service mapping model that provides mappings across LxSM and TE-service model and that can be extend to support different service models (L3VPN/L2VPN/L1VPN, VTS, Transport Connectivity service, etc). Dhruv, Young and I are already working on this.


Opinions? Thoughts?

BR
Daniele