Subject: [Teas] ACTN update

From: Daniele Ceccarelli <[email-masked]>
Date: Thu, 17 Nov 2016 02:31:52 +0000

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

---

From: "Scharf, Michael (Nokia - DE)" <[email-masked]>
Date: Thu, 17 Nov 2016 12:10:09 +0000

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. There can be much more complex architectures, e.g., if the service provider and network operator are not the same organization.

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.

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?

Thanks

Michael

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

Dear WG and ACTNers,

My proposal is to:

Opinions? Thoughts?

BR
Daniele

---

From: Igor Bryskin <[email-masked]>
Date: Thu, 17 Nov 2016 16:07:36 +0000

Danielle,

Why in your opinion L3SM should know or care whether the provider looks after a single- or multi-domain network? There is a strong case for multi-vendor multi-domain transport network, but this is not necessarily true for a network providing L3 services, which (in contrast to, say.  L0/L1 transport network) could be a multi-vendor single domain network. In other words, why in the context of L3SM multi-domain service coordination is necessary?
Another question: when and how L3 service controller interacts with a transport controller (providing transport services)?

These clarifications I think would be useful.

Cheers,
Igor

From: Teas [mailto:[email-masked]] On Behalf Of Daniele Ceccarelli
Sent: Wednesday, November 16, 2016 9:32 PM
To: TEAS WG ([email-masked])
Subject: [Teas] ACTN update

Dear WG and ACTNers,

My proposal is to:

Opinions? Thoughts?

BR
Daniele

---

From: Igor Bryskin <[email-masked]>
Date: Thu, 17 Nov 2016 16:40:24 +0000

Hi Michael,

Agree completely with all your points.

Please, see in-line.

Igor

From: Teas [mailto:[email-masked]] On Behalf Of Scharf, Michael (Nokia - DE)
Sent: Thursday, November 17, 2016 7:10 AM
To: Daniele Ceccarelli; TEAS WG ([email-masked])
Subject: Re: [Teas] ACTN update

Hi all,

IB>> I would go even further. I'd say that L3 service controller normally never talks directly to a transport controller. Transport controller, however, could be called to react on or avoid congestion in IP/MPLS layer because of extra L3 services placed on current IP/MPLS topology, or as a part of disaster recovery IP topology reconfiguration.

IB>> I would also add that L3SM should not consider multi-domain scenarios, meaning that as far as the user concerned the network providing L3 services is a single domain network

IB>> Agree.

Thanks

Michael

Dear WG and ACTNers,

My proposal is to:

Opinions? Thoughts?

BR
Daniele

---

From: Daniele Ceccarelli <[email-masked]>
Date: Thu, 17 Nov 2016 17:19:44 +0000

In line

BR
Daniele

From: Scharf, Michael (Nokia - DE) [mailto:[email-masked]]
Sent: giovedì 17 novembre 2016 21:10
To: Daniele Ceccarelli <[email-masked]>; TEAS WG ([email-masked]) <[email-masked]>
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.

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:[email-masked]] On Behalf Of Daniele Ceccarelli
Sent: Thursday, November 17, 2016 3:32 AM
To: TEAS WG ([email-masked]<mailto:[email-masked]>) <[email-masked]<mailto:[email-masked]>>
Subject: [Teas] ACTN update

Dear WG and ACTNers,

My proposal is to:

Opinions? Thoughts?

BR
Daniele

---

From: Daniele Ceccarelli <[email-masked]>
Date: Thu, 17 Nov 2016 17:28:32 +0000

Hi Igor,

I've used the L3SM example because it is the customer facing model and it is what we have on top of the MDSC and the orchestrator and, being on top of the MDSC, means that the sigle-multi/domain aspects are hidden (on top of the MDSC you don't care and you don't know if between CE1 and CE2 or between AP1 and AP2 there is one, two or N domains.

In the context of L3SM multi-domain service coordination is NOT mandatory. The L3SM can be used on top of the MDSC in case of multiple domains  and in case of single domain it can be used either on top of the MDSC or on top of the PNC, this is a deployment choice and I just used an example.

The interaction between the overlay network (i.e. the services) and the underlay/infrastruscture (i.e. the VN, tunnels etc) is mandatory if you want to map a service against a given tunnel or set of tunnel. If you don't want to do so you don't need ACTN or SDN in the network and you can simply operate the network as you did yesterday, with the tunnels created by LDP and the unawareness of which service uses which tunnel...it is simply enough to kwno that a packet goes from a source to a destination and you don't care about the path, the constraints related to the service, and the capability to know which services are used by which tunnel.

Cheers
Daniele

From: Igor Bryskin [mailto:[email-masked]]
Sent: venerdì 18 novembre 2016 01:08
To: Daniele Ceccarelli <[email-masked]>; TEAS WG ([email-masked]) <[email-masked]>
Subject: RE: ACTN update

Danielle,

Cheers,
Igor

From: Teas [mailto:[email-masked]] On Behalf Of Daniele Ceccarelli
Sent: Wednesday, November 16, 2016 9:32 PM
To: TEAS WG ([email-masked]<mailto:[email-masked]>)
Subject: [Teas] ACTN update

Dear WG and ACTNers,

My proposal is to:

Opinions? Thoughts?

BR
Daniele

---

From: "Scharf, Michael (Nokia - DE)" <[email-masked]>
Date: Thu, 17 Nov 2016 17:53:17 +0000

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:[email-masked]]
Sent: Thursday, November 17, 2016 6:20 PM
To: Scharf, Michael (Nokia - DE); TEAS WG ([email-masked])
Subject: RE: ACTN update

In line

BR
Daniele

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

Hi all,

Thanks

Michael

Dear WG and ACTNers,

My proposal is to:

Opinions? Thoughts?

BR
Daniele

---

From: Igor Bryskin <[email-masked]>
Date: Thu, 17 Nov 2016 18:13:31 +0000

Hi Daniele,

Please, see in-line.

Igor

From: Daniele Ceccarelli [mailto:[email-masked]]
Sent: Thursday, November 17, 2016 12:29 PM
To: Igor Bryskin; TEAS WG ([email-masked])
Subject: RE: ACTN update

Hi Igor,

IB>> I agree with you, except that L3 service controller does not seat on top of MDSC as a direct client. The L3SM<=>MDSC relationship is indirect and much more complex. Also from your slide below it is hard to interpret that L3SM nulti0domain coordination is not mandatory (IMHO by the way it is simply not needed)

The interaction between the overlay network (i.e. the services) and the underlay/infrastruscture (i.e. the VN, tunnels etc) is mandatory if you want to map a service against a given tunnel or set of tunnel.

IB>> It is not clear what do you mean by tunnels. Normally L3 service (e.g. L3 VPN) PEs are connected via a mesh of IP/MPLS layer  RSVP-TE tunnels and L3 service specific LSPs are nested inside them. In any case, the TE part does not go deeper than IP/MPLS layer, and said RSVP-TE tunnels are not re-configured necessarily with every addition of a new L3 service. So, direct interaction between L3 service and transport service controllers is not mandatory (especially if the two are owned by separate organizations and implemented by separate vendors).

If you don't want to do so you don't need ACTN or SDN in the network and you can simply operate the network as you did yesterday, with the tunnels created by LDP and the unawareness of which service uses which tunnel...it is simply enough to kwno that a packet goes from a source to a destination and you don't care about the path, the constraints related to the service, and the capability to know which services are used by which tunnel.

IB>> The point is that L3 service SDN controller and transport service (T-SDN) controller are both needed, but the two do not have to be integrated into one solution. It should be possible for an operator to cherry pick the controllers (e.g. L3 service controller provided by JNPR and T-SDN controller provided by Huawei).

Cheers
Daniele

Danielle,

Cheers,
Igor

Dear WG and ACTNers,

My proposal is to:

Opinions? Thoughts?

BR
Daniele

---

From: Daniele Ceccarelli <[email-masked]>
Date: Thu, 17 Nov 2016 23:31:37 +0000

Hi Igor,

Some more thoughts in line in red.

Cheers
Daniele

From: Igor Bryskin [mailto:[email-masked]]
Sent: venerdì 18 novembre 2016 03:14
To: Daniele Ceccarelli <[email-masked]>; TEAS WG ([email-masked]) <[email-masked]>
Subject: RE: ACTN update

Hi Daniele,

Please, see in-line.

Igor

From: Daniele Ceccarelli [mailto:[email-masked]]
Sent: Thursday, November 17, 2016 12:29 PM
To: Igor Bryskin; TEAS WG ([email-masked]<mailto:[email-masked]>)
Subject: RE: ACTN update

Hi Igor,

IB>> I agree with you, except that L3 service controller does not seat on top of MDSC as a direct client. The L3SM<=>MDSC relationship is indirect and much more complex. Also from your slide below it is hard to interpret that L3SM nulti0domain coordination is not mandatory (IMHO by the way it is simply not needed)
DC: I get your point. The picture seems to mandate a multi-domain coordination between the "service" boxes, which is not the case, that's correct. The message that it wants to convey are the following:

1.       Coordination between the MDSC and the Service function in the Service Orchestrator is needed (in order to be able to map a service against a tunnel or a VN). It applies to single or multi domain and it doesn't care if it is single or multiple domains

2.       The MDSC does not the service

3.       The service can be created also at Controller level (within its own domain) and it is not the PNC that is doing that.

Hence a Service function box is needed in all the boxes, but this does not mean that they coordinate among them.

IB>> It is not clear what do you mean by tunnels. Normally L3 service (e.g. L3 VPN) PEs are connected via a mesh of IP/MPLS layer  RSVP-TE tunnels and L3 service specific LSPs are nested inside them. In any case, the TE part does not go deeper than IP/MPLS layer, and said RSVP-TE tunnels are not re-configured necessarily with every addition of a new L3 service. So, direct interaction between L3 service and transport service controllers is not mandatory (especially if the two are owned by separate organizations and implemented by separate vendors).
DC: I don't disagree with that. It must be possible to do the service to tunnel binding (i.e. I want L3VPN X to use tunnel Y) or in the classic way with not such a binding (i.e. I want an L3VPN between A and B and I don't care which tunnel will be used).
The binding does not mandate to create a new tunnel for each service obviously. Existing ones can and must be reusable.

IB>> The point is that L3 service SDN controller and transport service (T-SDN) controller are both needed, but the two do not have to be integrated into one solution. It should be possible for an operator to cherry pick the controllers (e.g. L3 service controller provided by JNPR and T-SDN controller provided by Huawei).
DC: again agree, what in the figure makes you think that this is not the case?

Cheers
Daniele

Danielle,

Cheers,
Igor

Dear WG and ACTNers,

My proposal is to:

Opinions? Thoughts?

BR
Daniele

---

From: "Scharf, Michael (Nokia - DE)" <[email-masked]>
Date: Fri, 18 Nov 2016 10:57:24 +0000

In case of L3VPNs and L2VPNs, a "service orchestrator" may not have to create tunnels (or pseudowires etc.). This can be a function of a "network orchestrator" or a "domain controller" (or however we call them(), or it can be a standalone function outside any "orchestrator".

I agree with Igor that the picture does not cover well the case of having different IP and optical controllers - simply because it only shows one layer.

Michael

From: Teas [mailto:[email-masked]] On Behalf Of Daniele Ceccarelli
Sent: Friday, November 18, 2016 12:32 AM
To: Igor Bryskin; TEAS WG ([email-masked])
Subject: Re: [Teas] ACTN update

Hi Igor,

Cheers
Daniele

Hi Daniele,

Please, see in-line.

Igor

Hi Igor,

Cheers
Daniele

Danielle,

Cheers,
Igor

Dear WG and ACTNers,

My proposal is to:

Opinions? Thoughts?

BR
Daniele

---

From: Igor Bryskin <[email-masked]>
Date: Fri, 18 Nov 2016 13:29:31 +0000

Daniele,
You still didn't answer my question. If the tunnels you refer to are TE tunnels inter-connecting PEs (via Ps) in IP/MPLS layer, and you want to map a given L3 service to a set of such tunnels, then what this has to do with MDSC? I thought we agreed that multi-domain service coordination is only required when a circuit-switched  transport service spanning multiple domains is set up or manipulated. Neither L3 services nor IP/MPLS TE tunnels supporting them require multi-domain coordination.

Cheers,
Igor

From: Daniele Ceccarelli [mailto:[email-masked]]
Sent: Thursday, November 17, 2016 6:32 PM
To: Igor Bryskin; TEAS WG ([email-masked])
Subject: RE: ACTN update

Hi Igor,

Cheers
Daniele

Hi Daniele,

Please, see in-line.

Igor

Hi Igor,

Cheers
Daniele

Danielle,

Cheers,
Igor

Dear WG and ACTNers,

My proposal is to:

Opinions? Thoughts?

BR
Daniele

---

From: Daniele Ceccarelli <[email-masked]>
Date: Fri, 18 Nov 2016 16:37:22 +0000

Hi Michael,

I'm replying from the plane so the discussion might have progressed in the meantime and I'll catch up later but wanted to reply to this.

Please have at how I changed the architecture slide, trying to reflect the fact that there is no multi domain coordination in the services and the one that I added on the MDSC recursiveness.

About recursiveness, we moved away from the statement that the CMI is equal to the MPI and also added the concept of MMI (MDSC-MDSC interface) because it is yet another interface. Consider for example the fact that on the CMI you have the VN awareness why in the MPI you don't...

We should update the fwk accordingly and IMO remove that statement.

BR
Daniele

From: Scharf, Michael (Nokia - DE) [mailto:[email-masked]]
Sent: venerdì 18 novembre 2016 02:53
To: Daniele Ceccarelli <[email-masked]>; TEAS WG ([email-masked]) <[email-masked]>
Subject: RE: ACTN update

Hi Daniele,

Thanks

Michael

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

In line

BR
Daniele

Hi all,

Thanks

Michael

Dear WG and ACTNers,

My proposal is to:

Opinions? Thoughts?

BR
Daniele

---

From: Daniele Ceccarelli <[email-masked]>
Date: Fri, 18 Nov 2016 17:06:23 +0000

Hi Igor,

I'm starting to understand the misunderstanding.
We changed this when the "T" of ACTN moved from "Transport" to "TE", this happen even before the WG adoption.

The tunnels I refer to are exactly TE tunnels at any layer between 0 and 3, including MPLS-TE and Segment Routing TE.
The role of the MDSC is setting up those tunnels (via coordination of multiple domains) and bind e.g. a L3VPN to those RSVP-TE or SR-TE tunnels. In theory it is possible to create a L3VPN directly on top of L0 or L1 tunnels but it is not an appealing use case...

Cheers
Daniele

From: Teas [mailto:[email-masked]] On Behalf Of Igor Bryskin
Sent: venerdì 18 novembre 2016 14:30
To: Daniele Ceccarelli <[email-masked]>; TEAS WG ([email-masked]) <[email-masked]>
Subject: Re: [Teas] ACTN update

Daniele,

Cheers,
Igor

Hi Igor,

Cheers
Daniele

Hi Daniele,

Please, see in-line.

Igor

Hi Igor,

Cheers
Daniele

Danielle,

Cheers,
Igor

Dear WG and ACTNers,

My proposal is to:

Opinions? Thoughts?

BR
Daniele

---

From: Daniele Ceccarelli <[email-masked]>
Date: Fri, 18 Nov 2016 17:29:07 +0000

The entity that creates the tunnels is the MDSC. The MDSC is a functionality and it can be included into the service orchestrator or the network orchestrator.

If the service is between nodes belonging to the same domain it is obviously possible to do it directly via the domain controller or (if the operator wants to have only the Service/Network Orchestator as unique point to control the network) via the Service/Network Orchestrator that in this case would speak just with one PNC.

Regarding the layers in the slide I only considered one layer (MPLS) because the service is done at one layer. I have added a slide with a packet-otpical scenario but I think it is irrelevant wrt the service to tunnel binding.

Critiques to the slides are more than welcome but also proposals on how to improve them would be highly useful.

Daniele

From: Scharf, Michael (Nokia - DE) [mailto:[email-masked]]
Sent: venerdì 18 novembre 2016 11:57
To: Daniele Ceccarelli <[email-masked]>; Igor Bryskin <[email-masked]>; TEAS WG ([email-masked]) <[email-masked]>
Subject: RE: ACTN update

Michael

Hi Igor,

Cheers
Daniele

Hi Daniele,

Please, see in-line.

Igor

Hi Igor,

Cheers
Daniele

Danielle,

Cheers,
Igor

Dear WG and ACTNers,

My proposal is to:

Opinions? Thoughts?

BR
Daniele

---

From: Igor Bryskin <[email-masked]>
Date: Fri, 18 Nov 2016 17:55:33 +0000

Daniele,

In the context of L3 services there is a big difference between TE tunnels in IP/MPLS layer and ones, say, in L0/L1 layers. The former inter-connect PEs (via Ps) and do not imply IP/MPLS topology reconfigurations. They directly support L3 services and could be easily added/removed/adjusted if/when prove necessary. In contrast, TE tunnels in L0/L1 do not directly support L3 services; rather, they support IP/MPLS TE links ( for example, between adjacent PE and P or between Ps) that could be dynamically added (or removed) if/when the current IP/MPLS topology is not sufficient to accommodate additional IP/MPLS TE tunnels  to support a new L3 service.

I doubt that network operators will like the idea of routine IP topology re-configurations every time a new L3 service is added or removed. Don't get me wrong, there are important use cases when dynamic IP topology re-configuration is required (e.g. severe congestion prevention or disaster recovery reconfiguration), but normal L3 service manipulation is likely to be not one of them - rare exceptions aside it is expected to be contained within existing IP/MPLS topology.

Cheers,
Igor

From: Daniele Ceccarelli [mailto:[email-masked]]
Sent: Friday, November 18, 2016 12:06 PM
To: Igor Bryskin; TEAS WG ([email-masked])
Subject: RE: ACTN update

Hi Igor,

Cheers
Daniele

Daniele,

Cheers,
Igor

Hi Igor,

Cheers
Daniele

Hi Daniele,

Please, see in-line.

Igor

Hi Igor,

Cheers
Daniele

Danielle,

Cheers,
Igor

Dear WG and ACTNers,

My proposal is to:

Opinions? Thoughts?

BR
Daniele

---

From: Igor Bryskin <[email-masked]>
Date: Mon, 21 Nov 2016 15:14:29 +0000

Daniele,

>From your slides:

*         XXXX (I don't have a name for that functionality) asks the MDSC if an underlay infrastructure meeting the requirements is available, if not create it.

You have to be more specific and describe what you mean by "underlay infrastructure". As mentioned in previous emails there are reasons as to why you cannot just say in one breath "The tunnels I refer to are exactly TE tunnels at any layer between 0 and 3"

L3 TE tunnels

L0/L1 TE tunnels

IP topology re-configuration

Not required

Implied

Tunnel termination points

PEs directly supporting L3 service

Any pair of PE-P, P-P, PE-PE (to be) adjacent in IP layer

Granularity

Fine, could be tailored and dynamically (re-)adjusted to the supported L3 service needs

Coarse, implies unused resources

You also said:
"In theory it is possible to create a L3VPN directly on top of L0 or L1 tunnels but it is not an appealing use case..."

Well, but this would be not L3VPN, rather, much more expensive L3PN, right?

Furthermore, from you slides:

*         Customer asks for a L3VPN between CE1 and CE2 (or between AP1 and AP2 if supported) with TE constraints using L3SM model enhanced with TE (missing).

Why? What is missing? If you want a customer to be able to map a L3 service onto the provider network resources, the client can do it:

a)      Using TE topology model negotiate desired network abstraction in the form of one or more abstract topologies;

b)     Using the provided abstract topology (ies) compute desired placement and configure desired TE tunnels via TE tunnel model;

c)      Using L3 service model map a L3 service onto the tunnels.

All three models are undeniably necessary. But why do we have to integrate them into an IETF endorsed version of Unified Theory Of Everything (a.k.a. ACTN), rather than coming up with a simple Best Known Practices document? As far as I can recall, it was never the policy of IETF to produce such things. One reason for that is that folks solving their own real (rather than somebody else's hypothetical) problems will surely come up with better ways to mix-n-match the models than we can suggest, especially, when each of such models may/does have a very long list of augmentations.

Cheers,
Igor

From: Daniele Ceccarelli [mailto:[email-masked]]
Sent: Friday, November 18, 2016 12:29 PM
To: Scharf, Michael (Nokia - DE); Igor Bryskin; TEAS WG ([email-masked])
Subject: RE: ACTN update

Daniele

Michael

Hi Igor,

Cheers
Daniele

Hi Daniele,

Please, see in-line.

Igor

Hi Igor,

Cheers
Daniele

Danielle,

Cheers,
Igor

Dear WG and ACTNers,

My proposal is to:

Opinions? Thoughts?

BR
Daniele