Subject: Re: [Teas] Proposed ACTN Definition Text (Re: 答复: Poll on draft-lee-teas-actn-requirements-01 a WG documents)

From: Igor Bryskin <[email-masked]>
Date: Thu, 1 Oct 2015 13:18:36 +0000

Hi Daniele,
Please, see in line.

Igor

From: Daniele Ceccarelli [mailto:[email-masked]]
Sent: Wednesday, September 30, 2015 11:14 AM
To: Igor Bryskin <[email-masked]>; Leeyoung <[email-masked]>; Vishnu Pavan Beeram <[email-masked]>
Cc: Lou Berger <[email-masked]>; TEAS WG <[email-masked]>; Varma, Eve L (Eve) <[email-masked]>; [email-masked]
Subject: RE: [Teas] Proposed ACTN Definition Text (Re: 答复: Poll on draft-lee-teas-actn-requirements-01 a WG documents)

Hi Igor,

Interesting discussion. Sorry for taking so long to reply…very busy period.
Please see in line.

Cheers,
Daniele

From: Igor Bryskin [mailto:[email-masked]]
Sent: lunedì 28 settembre 2015 14:34
To: Daniele Ceccarelli; Leeyoung; Vishnu Pavan Beeram
Cc: Lou Berger; TEAS WG; Varma, Eve L (Eve); [email-masked]<mailto:[email-masked]>
Subject: RE: [Teas] Proposed ACTN Definition Text (Re: 答复: Poll on draft-lee-teas-actn-requirements-01 a WG documents)

Hi Daniele,

Please, see in line.
Cheers,
Igor

From: Daniele Ceccarelli [mailto:[email-masked]]
Sent: Saturday, September 26, 2015 3:29 PM
To: Leeyoung <[email-masked]<mailto:[email-masked]>>; Igor Bryskin <[email-masked]<mailto:[email-masked]>>; Vishnu Pavan Beeram <[email-masked]<mailto:[email-masked]>>
Cc: Lou Berger <[email-masked]<mailto:[email-masked]>>; TEAS WG <[email-masked]<mailto:[email-masked]>>; Varma, Eve L (Eve) <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: RE: [Teas] Proposed ACTN Definition Text (Re: 答复: Poll on draft-lee-teas-actn-requirements-01 a WG documents)

Igor,

Young elaborated pretty well on my statements (thanks).

I would say that a) and b) in your bullets perfectly define what I meant as infrastructure.

c) is in my opinion a perfect example of connectivity service. You say that VPNs do not follow under the connectivity services category as they are not TE relate. Well a VPN does not provide TE, but connecting a VPN to a TE infrastructure in my opinion does. If a customer wants connectivity between 3 points with given TE constraints, why a VPN on top or a TE infrastructure shouldn’t meet that requirement?

IB>> Current TEAS WG work – Abstract TE Topology model – does allow configuring customized TE topologies on per VPN basis. There is also a work being discussed to model topologies that combine routing and TE topologies as well as SPRING related information. Can you elaborate what exactly is missing from the ACTN point of view?

DanCec>> Let me elaborate a bit more on this. There are situations in which traffic needs to be moved from one path to another, not only due to a failure, but also due to e.g. congestion or policies violation. I see two ways of moving the traffic, i) rerouting the infrastructure (i.e. LSP rerouting) or ii) remapping the client traffic to a different infrastructure (e.g. go to the ingress and egress nodes and dynamically do FEC (forwarding equivalence class…not forward error correction ☺ ) remapping of a give FEC to a different LSP. This is extremely useful in congestions situations, where offloading traffic from one LSP to a different LSP could help solving the congestion situation. I think this is traffic engineering. I also think that this is something that needs to be done extremely quickly.

IB>> I do not see a difference in reacting to congestion vs. to, say, a fiber cut. Policy (or policy violation) based re-routing seems like an implementation detail that requires no standardization.

On the virtual network function service, as Young mentioned, there are several use cases in ACTN and building the interaction between WAN SDN and Cloud SDN is a very common and requested use case. We could argue it’s not TEAS…well, if you correctly remember we tried to open a new working group because we thought that not 100% of the ACTN scope was covered by TEAS ☺

IB>> This sounds like a good project for a company like ERICSSSON, however, what exactly are the problems you want to solve that have not been or are not being worked on in other WGs?

DanCec>> It’s so cool to work for such a visionary company, isnt’ it ☺ Here I have to admit that it is a bit more complex to find a relationship with TEAS and Traffic Engineering in the network. Maybe the authors of the two drafts linked by Young below could help us shade some light on that otherwise we can possibly drop this part of the work (if everyone agrees) if we come to the conclusion that there is no room for it in TEAS.

Cheers
Daniele

From: Leeyoung [mailto:[email-masked]]
Sent: venerdì 25 settembre 2015 22:45
To: Igor Bryskin; Daniele Ceccarelli; Vishnu Pavan Beeram; Leeyoung
Cc: Lou Berger; TEAS WG; Varma, Eve L (Eve); [email-masked]<mailto:[email-masked]>
Subject: RE: [Teas] Proposed ACTN Definition Text (Re: 答复: Poll on draft-lee-teas-actn-requirements-01 a WG documents)

Hi Igor,

I agree with you from a pure TE connectivity perspective.

What Daniele is talking about is case where a TE connectivity has some constraints related with “customer’s” VN service policy. One example, a DCI case where the decision in selecting a destination for VM migration through TE networks may have not only QoS requirement but also other factors beyond QoS. Among them can be DC location (end-point) profile, preference/policy and capability; VNF mapping to the DC location, etc. Of course, these factors are not a pure TE connectivity constraints, but these factors may impact how to choose a destination of a TE connectivity from a source.

So the argument is who are the customer of such services? A couple of use-cases for ACTN addressed this kind of issues and they all concerned about DCI issues. Some of them are application providers that need to move massively large amount of data sets across DCNs and multiple WAN domains.

Here’s the link for relevant use-cases:

https://www.ietf.org/archive/id/draft-lopez-actn-vno-multidomains-01.txt
https://tools.ietf.org/html/draft-fang-actn-multidomain-dci-00

I see neither L2VPN or L3VPN alone can solve this type of issues. VPN operators can also be viewed as a customer to ACTN-enabled networks. In such case, there would be coordination across VPN providers and Transport providers to meet the end-customer’s need.

We can clearly start with a pure TE connectivity model, but not limited to this pure model. What do you think?

Regards,
Young

From: Igor Bryskin [mailto:[email-masked]]
Sent: Friday, September 25, 2015 10:54 AM
To: Daniele Ceccarelli; Vishnu Pavan Beeram; Leeyoung
Cc: Lou Berger; TEAS WG; Varma, Eve L (Eve); [email-masked]<mailto:[email-masked]>
Subject: RE: [Teas] Proposed ACTN Definition Text (Re: 答复: Poll on draft-lee-teas-actn-requirements-01 a WG documents)

Hi Daniele,
Please, see in line.

Igor

From: Daniele Ceccarelli [mailto:[email-masked]]
Sent: Friday, September 25, 2015 9:56 AM
To: Igor Bryskin <[email-masked]<mailto:[email-masked]>>; Vishnu Pavan Beeram <[email-masked]<mailto:[email-masked]>>; Leeyoung <[email-masked]<mailto:[email-masked]>>
Cc: Lou Berger <[email-masked]<mailto:[email-masked]>>; TEAS WG <[email-masked]<mailto:[email-masked]>>; Varma, Eve L (Eve) <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: RE: [Teas] Proposed ACTN Definition Text (Re: 答复: Poll on draft-lee-teas-actn-requirements-01 a WG documents)

I knew it was a topic worth being raised ☺

Igor, I’ll use my personal definitions that didn’t end up in the final ACTN definition but it can be useful to understand each other. I see these 3 entities:

1.       Infrastructure: nodes, links, but mostly LSP building the virtual networks between end points
IB>> According to TE topology modeling we have:

a)      Provider native TE topology (provider network nodes and links), could be used as underlay supporting abstract TE topologies (overlays);

b)      Abstract TE topologies (customized per-client) (abstract nodes inter=connected by abstract links), overlays supported, for example, by provider native TE topology, could be configured by either provider, client or both

c)       Transport services provided to the client: traffic engineered connections connecting provider WRT a given service ingress/egress access links (i.e. links connecting client devices to the provider network). The service paths and parameters could be expressed by the client in terms of abstract topology elements, translated by the provider controller into terms of the provider native topology.

2.       Connectivity Services: services built on top of the infrastructure to connect the clients, e.g. L2VPN, L3VPN. The customers asks for connectivity (with characteristics that will be mapped intor the infrastructure) identifying the end points.
IB>> Why this is a part of ACTN? Don’t we have other WGs working on this?
Considering that this is TEAS WG work, what this has to do with TE?

3.       Virtual Network Function Services: Services where the customer needs a virtual function FOR one of its sites (e.g. VM instantiation). In most cases this is a request for connectivity towards A datacenter…which one is not of any importance for the customer. This is what is collected in Luyan’s use cases.
IB>> The same questions

I guess what you call “transport service” refers to the infrastructure? Or maybe both infrastructure and connectivity services?
IB>> Please, see above

Cheers
Daniele

From: Igor Bryskin [mailto:[email-masked]]
Sent: venerdì 25 settembre 2015 15:04
To: Daniele Ceccarelli; Vishnu Pavan Beeram; Leeyoung
Cc: Lou Berger; TEAS WG; Varma, Eve L (Eve); [email-masked]<mailto:[email-masked]>
Subject: RE: [Teas] Proposed ACTN Definition Text (Re: 答复: Poll on draft-lee-teas-actn-requirements-01 a WG documents)

Daniele,

You are right. What you call “connectivity service” I call “transport service”, which is really “traffic engineered connectivity service”. You may think about “connectivity service” in a broader sense, e.g. IP or Ethernet non-TE (reachability based) connectivity, and it is a good question if such connectivity should be part of ACTN. I personally think not.

One other type of service provided by network to client is Customized Abstract Topology itself, i.e. when the Customized Abstract Topology is (re-)configured by the client, as opposite to another use case when the Customized Abstract Topology is configured by the network operator and presented to the client in read-only mode.

Cheers,
Igor

From: Teas [mailto:[email-masked]]<mailto:[mailto:[email-masked]]> On Behalf Of Daniele Ceccarelli
Sent: Friday, September 25, 2015 8:13 AM
To: Vishnu Pavan Beeram <[email-masked]<mailto:[email-masked]>>; Leeyoung <[email-masked]<mailto:[email-masked]>>
Cc: Lou Berger <[email-masked]<mailto:[email-masked]>>; TEAS WG <[email-masked]<mailto:[email-masked]>>; Varma, Eve L (Eve) <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [Teas] Proposed ACTN Definition Text (Re: 答复: Poll on draft-lee-teas-actn-requirements-01 a WG documents)

Thanks Igor for the comment on the policies, when shrinking it into the text we did too much “zipping” and lost some bits of info.

I just have a comment on the services. Is it clear what is meant with “services” ? The fwk provides a description of Connectivity Services and Network Function Virtualization Services. Is it worth spelling it clearly in the ACTN definition or everyone is ok with those 2 definitions?

Thanks
Daniele

From: Vishnu Pavan Beeram [mailto:[email-masked]]
Sent: giovedì 24 settembre 2015 22:06
To: Leeyoung
Cc: Lou Berger; Varma, Eve L (Eve); Daniele Ceccarelli; TEAS WG; [email-masked]<mailto:[email-masked]>
Subject: Re: [Teas] Proposed ACTN Definition Text (Re: 答复: Poll on draft-lee-teas-actn-requirements-01 a WG documents)

We (Lou and I) hacked on the wording a little bit, mainly from a clarification standpoint (not really trying to substantively change anything). The changes are in the etherpad: http://etherpad.tools.ietf.org:9000/p/teas-actn-def<http://www.google.com/url?q=http%3A%2F%2Fetherpad.tools.ietf.org%3A9000%2Fp%2Fteas-actn-def&sa=D&sntz=1&usg=AFQjCNFF5PidSDEuHcotj1m0c2gkQnTa8A>

Please feel free to go edit it. One open question we have (and is on the etherpad) is on the use of customer vs client (was a bit inconsistent). We don't have a strong opinion on which, and have changed the single instance of "client" to "customer".

Let us give folks a little bit more time to chime in on this thread.

Pavan and Lou

On Thu, Sep 24, 2015 at 2:41 PM, Leeyoung <[email-masked]<mailto:[email-masked]>> wrote:
Hi Lou,

Here's the updated version and also in word if that helps.

Thanks.
Young

----------------------------------------------------------------------------------------------------

Abstraction and Control of TE Networks (ACTN) is aimed to support virtual network operations needed to orchestrate, control and manage large-scale multi-domain TE networks so as to facilitate network programmability, automation, efficient resource sharing, and end-to-end virtual service aware connectivity and network function virtualization services. These are summarized as follows.

-       Abstraction and coordination of underlying network resources to higher-layer applications and customers, independent of how these resources are managed or controlled, so that they can dynamically control their virtual networks by creating, modifying, monitoring, and deleting them.

-       Multi-domain and multi-tenant virtual network operation via hierarchical abstraction of TE domains that facilitates multi-administration, multi-vendor, and multi-technology networks as a single virtualized network. This is achieved presenting the network domain as an abstracted topology to the customers via open and programmable interfaces. This allows for the recursion of controllers in a customer-provider relationship.

-       Orchestration of end-to-end virtual network services and applications via slicing of network resources to meet specific service, application and customer requirements.

-       Adaptation of customer requests (made on virtual resources) to the physical network resources performing the necessary mapping, translation, isolation, security, and policy that allows conveying, managing and enforcing client policies with respect to the services by the network to said customers.

-       Provision of a computation scheme and virtual control capability via a data model to customers who request virtual network services. Note that these customers could, themselves, be service providers.

-----Original Message-----
From: Lou Berger [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Thursday, September 24, 2015 1:23 PM
To: Leeyoung; Vishnu Pavan Beeram
Cc: Varma, Eve L (Eve); Daniele Ceccarelli; TEAS WG; [email-masked]<mailto:[email-masked]>
Subject: Re: [Teas] Proposed ACTN Definition Text (Re: 答复: Poll on draft-lee-teas-actn-requirements-01 a WG documents)

Young,

In the process thread, you said:
> "ACTN is aimed to support virtual network operations... "
>
> I would read the above as set of requirements rather solutions if we were to change wording slightly.

can you send the proposed wording? (presumably on top of Igor's changes)

Thanks,
Lou

On 9/24/2015 8:36 AM, Lou Berger wrote:
> NOTE: I've changed the title so that we can keep separate process
> discussion from the definition discussion.  Please keep comments
> limited to the appropriate thread so folks (like Adrian) that don't
> care about the process can ignore it.
>
>  <This is the non-process thread>
>
>
>
> On 9/23/2015 1:21 PM, Leeyoung wrote:
>> Hi Lou and Pavan,
>>
>> ...
>>
>> Here's the working version of what ACTN is based on the authors/contributors input and based on ACTN framework and problem statement drafts.
>>
>> We'd welcome the input of WG to refine this as a concerted effort.
>>
>> Thanks,
>>
>> Young (on behalf of all contributors)
>>
>> ---------------------------------------------------------------------
>> ---------------------------------------------------------------
>>
>> Abstraction and Control of TE Networks (ACTN) defines new methods and capabilities to support virtual network operations needed to orchestrate, control and manage multi-domain TE networks so as to facilitate network programmability, automation, efficient resource sharing, and end-to-end virtual service aware connectivity and network function virtualization services. These are summarized as follows.
>>
>> -    Abstraction and coordination of underlying network resources to higher-layer applications and customers, independent of how these resources are managed or controlled, so that they can dynamically control their virtual networks by creating, modifying, monitoring, and deleting them.
>>
>> -    Multi-domain and multi-tenant virtual network operation via hierarchical abstraction of TE domains that facilitates multi-administration, multi-vendor, and multi-technology networks as a single virtualized network. This is achieved presenting the network domain as an abstracted topology to the customers via open and programmable interfaces. This allows for the recursion of controllers in a customer-provider relationship.
>>
>> -    Orchestration of end-to-end virtual network services and applications via slicing of network resources to meet specific service, application and customer requirements.
>>
>> -    Adaptation of customer requests (made on virtual resources) to the physical network resources performing the necessary mapping, translation, isolation and, security/policy enforcement.
>>
>> -    Provision of a computation scheme and virtual control capability via a data model to customers who request virtual network services. Note that these customers could, themselves, be service providers.
>>
> Great.  This is constructive.  Thank you.
>
> WG,
>
> Please review/comment/propose changes.
>
> I've dropped the text into an etherpad
> (http://etherpad.tools.ietf.org:9000/p/teas-actn-def) to track the
> latest text.  Feel free to make changes there if you propose changes.
>
> Lou
>
>> -----Original Message-----
>> From: Lou Berger [mailto:[email-masked]<mailto:[email-masked]>]
>> Sent: Tuesday, September 22, 2015 1:35 PM
>> To: Leeyoung; Vishnu Pavan Beeram
>> Cc: TEAS WG; Daniele Ceccarelli; Varma, Eve L (Eve);
>> [email-masked]<mailto:[email-masked]>
>> Subject: Re: [Teas] 答复: Poll on draft-lee-teas-actn-requirements-01 a
>> WG documents
>>
>> Young,
>>
>> On 9/22/2015 1:32 PM, Leeyoung wrote:
>>> But not with the procedural violation! This would set a wrong
>>> precedent in IETF. I’d like to hold all of us accountable to the
>>> right procedure.
>> I'm not sure to what you are referring.  The sole formal procedural requirement for issuing a draft is WG chair approval, at which time chairs select the filename.  Now it is certainly normal and good practice for  WG chairs to ensure support for the work via such things as polls, but this isn't procedurally required.  Also, chairs always evaluate the filename as part of our approval process, and while less common,  approve file names different than the form used by the individual draft.  Feel free to look around and you'll find a few examples.
>>
>> Now we'd really like to move the discussion to something a bit more than process and get a definition for inclusion in the -01 rev of the document.  -- which in our opinion will formally answer the question of if ACTN is just a (set of) solutions or something broader, and thereby inform the filename choice.
>>
>> Can you and the other authors help with that?
>>
>> This question is open to all, so if you think you have a definition that's worth sharing, please chime in.
>>
>> Thanks,
>> Lou
>>
>>
>>
>>
>
> _______________________________________________
> Teas mailing list
> [email-masked]<mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/teas

---

From: Daniele Ceccarelli <[email-masked]>
Date: Thu, 1 Oct 2015 14:37:27 +0000

Hi Igor,

You’re right, but i don’t want to reroute LSPs (not only at least), i also want to remap a service from LSP1 to LSP2 and/or from VN1 to VN2.

Cheers
Daniele

From: Igor Bryskin [mailto:[email-masked]]
Sent: giovedì 1 ottobre 2015 15:19
To: Daniele Ceccarelli; Leeyoung; Vishnu Pavan Beeram
Cc: Lou Berger; TEAS WG; Varma, Eve L (Eve); [email-masked]
Subject: RE: [Teas] Proposed ACTN Definition Text (Re: 答复: Poll on draft-lee-teas-actn-requirements-01 a WG documents)

Hi Daniele,
Please, see in line.

Igor

To: Igor Bryskin <[email-masked]<mailto:[email-masked]>>; Leeyoung <[email-masked]<mailto:[email-masked]>>; Vishnu Pavan Beeram <[email-masked]<mailto:[email-masked]>>

Hi Igor,

Cheers,
Daniele

Hi Daniele,

Please, see in line.
Cheers,
Igor

Igor,

Cheers
Daniele

Hi Igor,

Regards,
Young

Hi Daniele,
Please, see in line.

Igor

Cheers
Daniele

Daniele,

Cheers,
Igor

Thanks
Daniele

Pavan and Lou

Thanks.
Young

-----Original Message-----
From: Lou Berger [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Thursday, September 24, 2015 1:23 PM
To: Leeyoung; Vishnu Pavan Beeram
Cc: Varma, Eve L (Eve); Daniele Ceccarelli; TEAS WG; [email-masked]<mailto:[email-masked]>
Subject: Re: [Teas] Proposed ACTN Definition Text (Re: 答复: Poll on draft-lee-teas-actn-requirements-01 a WG documents)

Young,

Thanks,
Lou

---

From: "Varma, Eve L (Eve)" <[email-masked]>
Date: Thu, 1 Oct 2015 16:55:42 +0000

Hi,

Some additional clarifying text added on etherpad ☺

Best regards,
Eve

From: Vishnu Pavan Beeram [mailto:[email-masked]]
Sent: Tuesday, September 29, 2015 8:17 PM
To: Leeyoung
Cc: Igor Bryskin; Daniele Ceccarelli; Lou Berger; TEAS WG; Varma, Eve L (Eve); [email-masked]
Subject: Re: [Teas] Proposed ACTN Definition Text (Re: 答复: Poll on draft-lee-teas-actn-requirements-01 a WG documents)

Young, Hi!
The primary intent behind proposing the first statement ("build on existing TE mechanisms") is to explicitly specify that the ACTN solutions will build on existing TE constructs (TE-Tunnels/LSPs/Paths; TE-Topological elements - TE-nodes/TE-links, etc) and TE protocol mechanisms wherever possible and appropriate.
The intent behind proposing the second statement ("controller based approaches") is to explicitly indicate the inclusion of solutions where the VN operations (as stated in the ACTN definition) are orchestrated/controlled by one or more logically centralized entities (controllers).
Please feel free to edit the these two statements on etherpad (to capture the above intent).
Regards,
-Pavan

On Tue, Sep 29, 2015 at 12:11 PM, Leeyoung <[email-masked]<mailto:[email-masked]>> wrote:
Hi Pavan,

Can you elaborate what "existing TE mechanisms" is meant? Some examples you have in mind for this term may help understand the text better?

In addition, what do you mean "controller-based" approaches?

Thanks.
Young

-----Original Message-----
From: Vishnu Pavan Beeram [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Monday, September 28, 2015 8:59 PM
To: Igor Bryskin
Cc: Daniele Ceccarelli; Leeyoung; Lou Berger; TEAS WG; Varma, Eve L (Eve); [email-masked]<mailto:[email-masked]>
Subject: Re: [Teas] Proposed ACTN Definition Text (Re: 答复: Poll on draft-lee-teas-actn-requirements-01 a WG documents)

We (Lou and I) would like to propose the following additional language (see the text on etherpad towards the end of the ACTN definition -
http://etherpad.tools.ietf.org:9000/p/teas-actn-def):

"ACTN solutions will build on existing TE mechanisms wherever possible and appropriate. Support for controller-based approaches is specifically included in the possible solution set."

Thoughts? Please feel free to make edits on the etherpad.

Regards,
-Pavan (and Lou)

On Mon, Sep 28, 2015 at 8:34 AM, Igor Bryskin <[email-masked]<mailto:[email-masked]>>
wrote:

> Hi Daniele,
>
>
>
> Please, see in line.
>
> Cheers,
>
> Igor
>
>
>
> *From:* Daniele Ceccarelli [mailto:[email-masked]<mailto:[email-masked]>]
> *Sent:* Saturday, September 26, 2015 3:29 PM
> *To:* Leeyoung <[email-masked]<mailto:[email-masked]>>; Igor Bryskin <
> [email-masked]<mailto:[email-masked]>>; Vishnu Pavan Beeram <[email-masked]<mailto:[email-masked]>>
> *Cc:* Lou Berger <[email-masked]<mailto:[email-masked]>>; TEAS WG <[email-masked]<mailto:[email-masked]>>; Varma,
> Eve L (Eve) <[email-masked]<mailto:[email-masked]>>;
> *Subject:* RE: [Teas] Proposed ACTN Definition Text (Re: 答复: Poll on
> draft-lee-teas-actn-requirements-01 a WG documents)
>
>
>
> Igor,
>
>
>
> c) is in my opinion a perfect example of connectivity service. You say
> that VPNs do not follow under the connectivity services category as
> they are not TE relate. Well a VPN does not provide TE, but connecting
> a VPN to a TE infrastructure in my opinion does. If a customer wants
> connectivity between 3 points with given TE constraints, why a VPN on
> top or a TE infrastructure shouldn’t meet that requirement?
>
>
>
> IB>> Current TEAS WG work – Abstract TE Topology model – does allow
> configuring customized TE topologies on per VPN basis. There is also a
> work being discussed to model topologies that combine routing and TE
> topologies as well as SPRING related information. Can you elaborate
> what exactly is missing from the ACTN point of view?
>
>
>
> On the virtual network function service, as Young mentioned, there are
> several use cases in ACTN and building the interaction between WAN SDN
> and Cloud SDN is a very common and requested use case. We could argue
> it’s not TEAS…well, if you correctly remember we tried to open a new
> working group because we thought that not 100% of the ACTN scope was
> covered by TEAS J
>
>
>
> IB>> This sounds like a good project for a company like ERICSSSON,
> however, what exactly are the problems you want to solve that have not
> been or are not being worked on in other WGs?
>
>
>
> Cheers
>
> Daniele
>
>
>
>
>
> *From:* Leeyoung [mailto:[email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>]
> *Sent:* venerdì 25 settembre 2015 22:45
> *To:* Igor Bryskin; Daniele Ceccarelli; Vishnu Pavan Beeram; Leeyoung
> *Cc:* Lou Berger; TEAS WG; Varma, Eve L (Eve);
> *Subject:* RE: [Teas] Proposed ACTN Definition Text (Re: 答复: Poll on
> draft-lee-teas-actn-requirements-01 a WG documents)
>
>
>
> Hi Igor,
>
>
>
> What Daniele is talking about is case where a TE connectivity has some
> constraints related with “customer’s” VN service policy. One example,
> a DCI case where the decision in selecting a destination for VM
> migration through TE networks may have not only QoS requirement but
> also other factors beyond QoS. Among them can be DC location
> (end-point) profile, preference/policy and capability; VNF mapping to
> the DC location, etc. Of course, these factors are not a pure TE
> connectivity constraints, but these factors may impact how to choose a destination of a TE connectivity from a source.
>
>
>
> So the argument is who are the customer of such services? A couple of
> use-cases for ACTN addressed this kind of issues and they all
> concerned about DCI issues. Some of them are application providers
> that need to move massively large amount of data sets across DCNs and multiple WAN domains.
>
>
>
> I see neither L2VPN or L3VPN alone can solve this type of issues. VPN
> operators can also be viewed as a customer to ACTN-enabled networks.
> In such case, there would be coordination across VPN providers and
> Transport providers to meet the end-customer’s need.
>
>
>
> We can clearly start with a pure TE connectivity model, but not
> limited to this pure model. What do you think?
>
>
>
> Regards,
>
> Young
>
>
>
> *From:* Igor Bryskin [mailto:[email-masked]<mailto:[email-masked]>
> <[email-masked]<mailto:[email-masked]>>]
> *Sent:* Friday, September 25, 2015 10:54 AM
> *To:* Daniele Ceccarelli; Vishnu Pavan Beeram; Leeyoung
> *Cc:* Lou Berger; TEAS WG; Varma, Eve L (Eve);
> *Subject:* RE: [Teas] Proposed ACTN Definition Text (Re: 答复: Poll on
> draft-lee-teas-actn-requirements-01 a WG documents)
>
>
>
> Hi Daniele,
>
> Please, see in line.
>
>
>
> Igor
>
>
>
> *From:* Daniele Ceccarelli [mailto:[email-masked]<mailto:[email-masked]>
> <[email-masked]<mailto:[email-masked]>>]
> *Sent:* Friday, September 25, 2015 9:56 AM
> *To:* Igor Bryskin <[email-masked]<mailto:[email-masked]>>; Vishnu Pavan Beeram <
> [email-masked]<mailto:[email-masked]>>; Leeyoung <[email-masked]<mailto:[email-masked]>>
> *Cc:* Lou Berger <[email-masked]<mailto:[email-masked]>>; TEAS WG <[email-masked]<mailto:[email-masked]>>; Varma,
> Eve L (Eve) <[email-masked]<mailto:[email-masked]>>;
> *Subject:* RE: [Teas] Proposed ACTN Definition Text (Re: 答复: Poll on
> draft-lee-teas-actn-requirements-01 a WG documents)
>
>
>
> I knew it was a topic worth being raised J
>
>
>
> Igor, I’ll use my personal definitions that didn’t end up in the final
> ACTN definition but it can be useful to understand each other. I see
> these
> 3 entities:
>
>
>
> 1.       *Infrastructure*: nodes, links, but mostly LSP building the
> virtual networks between end points
>
> a)      Provider native TE topology (provider network nodes and links),
> could be used as underlay supporting abstract TE topologies
> (overlays);
>
> b)      Abstract TE topologies (customized per-client) (abstract nodes
> inter=connected by abstract links), overlays supported, for example,
> by provider native TE topology, could be configured by either
> provider, client or both
>
> c)       Transport services provided to the client: traffic engineered
> connections connecting provider WRT a given service ingress/egress
> access links (i.e. links connecting client devices to the provider
> network). The service paths and parameters could be expressed by the
> client in terms of abstract topology elements, translated by the
> provider controller into terms of the provider native topology.
>
>
>
> 2.       *Connectivity Services*: services built on top of the
> infrastructure to connect the clients, e.g. L2VPN, L3VPN. The
> customers asks for connectivity (with characteristics that will be
> mapped intor the
> infrastructure) identifying the end points.
>
> 3.       *Virtual Network Function Services*: Services where the customer
> needs a virtual function FOR one of its sites (e.g. VM instantiation).
> In most cases this is a request for connectivity towards A
> datacenter…which one is not of any importance for the customer. This
> is what is collected in Luyan’s use cases.
>
> IB>> The same questions
>
>
>
> I guess what you call “transport service” refers to the
> infrastructure? Or maybe both infrastructure and connectivity services?
>
> IB>> Please, see above
>
>
>
> Cheers
>
> Daniele
>
>
>
> *From:* Igor Bryskin [mailto:[email-masked]<mailto:[email-masked]>
> <[email-masked]<mailto:[email-masked]>>]
> *Sent:* venerdì 25 settembre 2015 15:04
> *To:* Daniele Ceccarelli; Vishnu Pavan Beeram; Leeyoung
> *Cc:* Lou Berger; TEAS WG; Varma, Eve L (Eve);
> *Subject:* RE: [Teas] Proposed ACTN Definition Text (Re: 答复: Poll on
> draft-lee-teas-actn-requirements-01 a WG documents)
>
>
>
> Daniele,
>
>
>
> You are right. What you call “connectivity service” I call “transport
> service”, which is really “traffic engineered connectivity service”.
> You may think about “connectivity service” in a broader sense, e.g. IP
> or Ethernet non-TE (reachability based) connectivity, and it is a good
> question if such connectivity should be part of ACTN. I personally
> think not.
>
>
>
> One other type of service provided by network to client is Customized
> Abstract Topology itself, i.e. when the Customized Abstract Topology
> is (re-)configured by the client, as opposite to another use case when
> the Customized Abstract Topology is configured by the network operator
> and presented to the client in read-only mode.
>
>
>
> Cheers,
>
> Igor
>
>
>
>
>
> *From:* Teas [mailto:[email-masked]<mailto:[email-masked]>] *On Behalf Of *Daniele
> Ceccarelli
> *Sent:* Friday, September 25, 2015 8:13 AM
> *To:* Vishnu Pavan Beeram <[email-masked]<mailto:[email-masked]>>; Leeyoung <
> [email-masked]<mailto:[email-masked]>>
> *Cc:* Lou Berger <[email-masked]<mailto:[email-masked]>>; TEAS WG <[email-masked]<mailto:[email-masked]>>; Varma,
> Eve L (Eve) <[email-masked]<mailto:[email-masked]>>;
> *Subject:* Re: [Teas] Proposed ACTN Definition Text (Re: 答复: Poll on
> draft-lee-teas-actn-requirements-01 a WG documents)
>
>
>
> Thanks Igor for the comment on the policies, when shrinking it into
> the text we did too much “zipping” and lost some bits of info

---

From: Lou Berger <[email-masked]>
Date: Thu, 1 Oct 2015 14:18:05 -0400

Even
    your proposed changes are in quotes:
ACTN solutions will build on existing TE mechanisms "(i.e., TE
constructs and TE protocol mechanisms)" wherever possible and
appropriate; "however, this should not be construed as constraining
protocol extension solutions if satisfying requirements necessitates
this".  
 
how about *in place* of your changes
NEW
ACTN solutions will build on, and extend, existing TE constructs and
mechanisms wherever possible and appropriate.

Lou

On 10/1/2015 12:55 PM, Varma, Eve L (Eve) wrote:
>
> Hi,
>
>  
>
> Some additional clarifying text added on etherpad J
>
>  
>
> Best regards,
>
> Eve
>
>  
>
> *From:*Vishnu Pavan Beeram [mailto:[email-masked]]
> *Sent:* Tuesday, September 29, 2015 8:17 PM
> *To:* Leeyoung
> *Cc:* Igor Bryskin; Daniele Ceccarelli; Lou Berger; TEAS WG; Varma,
> Eve L (Eve); [email-masked]
> The primary intent behind proposing the first statement ("build on
> existing TE mechanisms") is to explicitly specify that the ACTN
> solutions will build on existing TE constructs (TE-Tunnels/LSPs/Paths;
> TE-Topological elements - TE-nodes/TE-links, etc) and TE protocol
> mechanisms wherever possible and appropriate.
>
> The intent behind proposing the second statement ("controller based
> approaches") is to explicitly indicate the inclusion of solutions
> where the VN operations (as stated in the ACTN definition) are
> orchestrated/controlled by one or more logically centralized entities
> (controllers).
>
> Can you elaborate what "existing TE mechanisms" is meant? Some
> examples you have in mind for this term may help understand the text
> better?
>
> Cc: Daniele Ceccarelli; Leeyoung; Lou Berger; TEAS WG; Varma, Eve L
> (Eve); [email-masked]
> <mailto:[email-masked]>
> Subject: Re: [Teas] Proposed ACTN Definition Text (Re: 答复: Poll on
> We (Lou and I) would like to propose the following additional language
> (see the text on etherpad towards the end of the ACTN definition -
> "ACTN solutions will build on existing TE mechanisms wherever possible
> and appropriate. Support for controller-based approaches is
> specifically included in the possible solution set."
>
> On Mon, Sep 28, 2015 at 8:34 AM, Igor Bryskin
> <[email-masked] <mailto:[email-masked]>>
> wrote:
>
> > Hi Daniele,
> >
> >
> >
> > Please, see in line.
> >
> > Cheers,
> >
> > Igor
> >
> >
> >
> > *From:* Daniele Ceccarelli [mailto:[email-masked]
> <mailto:[email-masked]>]
> > *To:* Leeyoung <[email-masked] <mailto:[email-masked]>>;
> Igor Bryskin <
> > [email-masked] <mailto:[email-masked]>>; Vishnu
> Pavan Beeram <[email-masked] <mailto:[email-masked]>>
> > *Cc:* Lou Berger <[email-masked] <mailto:[email-masked]>>; TEAS
> WG <[email-masked] <mailto:[email-masked]>>; Varma,
> > [email-masked]
> <mailto:[email-masked]>
> > *From:* Leeyoung [mailto:[email-masked]
> <mailto:[email-masked]> <[email-masked]
> <mailto:[email-masked]>>]
> > [email-masked]
> <mailto:[email-masked]>
> > connectivity constraints, but these factors may impact how to choose
> a destination of a TE connectivity from a source.
> >
> >
> >
> > <[email-masked] <mailto:[email-masked]>>]
> > [email-masked]
> <mailto:[email-masked]>
> > <[email-masked]
> <mailto:[email-masked]>>]
> > *To:* Igor Bryskin <[email-masked]
> <mailto:[email-masked]>>; Vishnu Pavan Beeram <
> > [email-masked] <mailto:[email-masked]>>; Leeyoung
> <[email-masked] <mailto:[email-masked]>>
> > *Cc:* Lou Berger <[email-masked] <mailto:[email-masked]>>; TEAS
> WG <[email-masked] <mailto:[email-masked]>>; Varma,
> > [email-masked]
> <mailto:[email-masked]>
> > <[email-masked] <mailto:[email-masked]>>]
> > [email-masked]
> <mailto:[email-masked]>
> > *From:* Teas [mailto:[email-masked]
> <mailto:[email-masked]>] *On Behalf Of *Daniele
> > Ceccarelli
> > *To:* Vishnu Pavan Beeram <[email-masked]
> <mailto:[email-masked]>>; Leeyoung <
> > [email-masked] <mailto:[email-masked]>>
> > *Cc:* Lou Berger <[email-masked] <mailto:[email-masked]>>; TEAS
> WG <[email-masked] <mailto:[email-masked]>>; Varma,
> > [email-masked]
> <mailto:[email-masked]>
> [email-masked]

---

From: Lou Berger <[email-masked]>
Date: Thu, 1 Oct 2015 15:19:08 -0400

All,
   We think the ACTN definition has reached a sufficient point where
we'd like to do the following:

1) leave the requirements document tied to the ACTN solution space and
publish draft-lee-teas-actn-requirements-01 as
draft-ietf-teas-actn-requirements-00

2) Immediately, publish draft-ietf-teas-actn-requirements-01 with the
discussed definition added to the intro section (Other changes to the
intro section to align with the definition are at the discretion of the
editor.)   The definition from etherpad is:

   Abstraction and Control of TE Networks (ACTN) refers to the set
   of virtual network operations needed to orchestrate, control and
   manage large-scale multi-domain TE networks so as to facilitate
   network programmability, automation, efficient resource sharing,
   and end-to-end virtual service aware connectivity and network
   function virtualization services.

   These operations are summarized as follows:

   - Abstraction and coordination of underlying network resources
     to higher-layer applications and customers, independent of how
     these resources are managed or controlled, so that these
     higher-layer entities can dynamically control virtual
     networks. Where control includes creating, modifying,
     monitoring, and deleting virtual networks.

   - Multi-domain and multi-tenant virtual network operations via
     hierarchical abstraction of TE domains that facilitates
     multi-administration, multi-vendor, and multi-technology
     networks as a single virtualized network. This is achieved by
     presenting the network domain as an abstracted topology to the
     customers via open and programmable interfaces. Which allows
     for the recursion of controllers in a customer-provider
     relationship.

   - Orchestration of end-to-end virtual network services and
     applications via allocation of network resources to meet
     specific service, application and customer requirements.

   - Adaptation of customer requests (made on virtual resources) to
     the physical network resources performing the necessary
     mapping, translation, isolation and, policy that allows
     conveying, managing and enforcing customer policies with
     respect to the services by the network to said customer.

   - Provision of a computation scheme and virtual control
     capability via a data model to customers who request virtual
     network services. Note that these customers could, themselves,
     be service providers.

   ACTN solutions will build on, and extend, existing TE constructs
   and TE mechanisms wherever possible and appropriate.  Support
   for controller-based approaches is specifically included in the
   possible solution set.

3) For any area of ACTN-related work/solutions that the
authors/contributors believe are outside the scope of the TEAS WG
charter: Please propose charter changes you think will cover the new
area of work on the list and we can discuss with the WG and our AD.

Thank you,
Lou and Pavan

---

From: "Varma, Eve L (Eve)" <[email-masked]>
Date: Thu, 1 Oct 2015 19:51:00 +0000

Hi Lou,

That's fine - more succint.

Regards,
Eve

----- Original Message -----
From: Lou Berger [mailto:[email-masked]]
Sent: Thursday, October 01, 2015 02:18 PM
To: Varma, Eve L (Eve); Vishnu Pavan Beeram <[email-masked]>; Leeyoung <[email-masked]>
Cc: Igor Bryskin <[email-masked]>; Daniele Ceccarelli <[email-masked]>; TEAS WG <[email-masked]>; [email-masked] <[email-masked]>
Subject: Re: [Teas] Proposed ACTN Definition Text (Re: 答复: Poll on draft-lee-teas-actn-requirements-01 a WG documents)

Even

Lou

On 10/1/2015 12:55 PM, Varma, Eve L (Eve) wrote:
> <mailto:[email-masked]>

---

From: Leeyoung <[email-masked]>
Date: Thu, 1 Oct 2015 19:56:43 +0000

Hi Lou and Pavan,

I think this is good. Thanks for driving this definition more clearer and acceptable to all and making this work workable in TEAS WG. 

I'd be happy to upload the requirements draft (00) shortly. 

Best regards,
Young

-----Original Message-----
From: Lou Berger [mailto:[email-masked]] 
Sent: Thursday, October 01, 2015 2:19 PM
To: TEAS WG
Cc: Vishnu Pavan Beeram; [email-masked]
Subject: Re: [Teas] WG adoption and draft naming process (Re: 答复: Poll on draft-lee-teas-actn-requirements-01 a WG documents)

All,
   We think the ACTN definition has reached a sufficient point where we'd like to do the following:

1) leave the requirements document tied to the ACTN solution space and publish draft-lee-teas-actn-requirements-01 as draft-ietf-teas-actn-requirements-00

2) Immediately, publish draft-ietf-teas-actn-requirements-01 with the discussed definition added to the intro section (Other changes to the intro section to align with the definition are at the discretion of the
editor.)   The definition from etherpad is:

3) For any area of ACTN-related work/solutions that the authors/contributors believe are outside the scope of the TEAS WG
charter: Please propose charter changes you think will cover the new area of work on the list and we can discuss with the WG and our AD.

Thank you,
Lou and Pavan

---

From: Lou Berger <[email-masked]>
Date: Thu, 1 Oct 2015 16:07:00 -0400

Great.  How long do you need to get the -01 draft ready?

Thanks,
Lou

---

From: Leeyoung <[email-masked]>
Date: Thu, 1 Oct 2015 20:08:52 +0000

I am working on it. It should be within 5 min. But you need to approve the 00 first so that I can upload 01 version.

Thanks.
Young 

-----Original Message-----
From: Teas [mailto:[email-masked]] On Behalf Of Lou Berger
Sent: Thursday, October 01, 2015 3:07 PM
To: Leeyoung; TEAS WG
Cc: [email-masked]; Vishnu Pavan Beeram
Subject: Re: [Teas] WG adoption and draft naming process (Re: 答复: Poll on draft-lee-teas-actn-requirements-01 a WG documents)

Thanks,
Lou