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

[Igor Bryskin <[e-mail]>]

Hi Daniele,
Please, see in line.

Igor

From: Daniele Ceccarelli [mailto:[e-mail]]
Sent: Friday, September 25, 2015 9:56 AM
To: Igor Bryskin <[e-mail]>; Vishnu Pavan Beeram <[e-mail]>; Leeyoung <[e-mail]>
Cc: Lou Berger <[e-mail]>; TEAS WG <[e-mail]>; Varma, Eve L (Eve) <[e-mail]>; [e-mail]
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:[e-mail]]
Sent: venerdì 25 settembre 2015 15:04
To: Daniele Ceccarelli; Vishnu Pavan Beeram; Leeyoung
Cc: Lou Berger; TEAS WG; Varma, Eve L (Eve); [e-mail]
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:[e-mail]]<mailto:[mailto:[e-mail]]> On Behalf Of Daniele Ceccarelli
Sent: Friday, September 25, 2015 8:13 AM
To: Vishnu Pavan Beeram <[e-mail]<mailto:[e-mail]>>; Leeyoung <[e-mail]<mailto:[e-mail]>>
Cc: Lou Berger <[e-mail]<mailto:[e-mail]>>; TEAS WG <[e-mail]<mailto:[e-mail]>>; Varma, Eve L (Eve) <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
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:[e-mail]]
Sent: giovedì 24 settembre 2015 22:06
To: Leeyoung
Cc: Lou Berger; Varma, Eve L (Eve); Daniele Ceccarelli; TEAS WG; [e-mail]<mailto:[e-mail]>
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 <[e-mail]<mailto:[e-mail]>> 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:[e-mail]<mailto:[e-mail]>]
Sent: Thursday, September 24, 2015 1:23 PM
To: Leeyoung; Vishnu Pavan Beeram
Cc: Varma, Eve L (Eve); Daniele Ceccarelli; TEAS WG; [e-mail]<mailto:[e-mail]>
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:[e-mail]<mailto:[e-mail]>]
>> Sent: Tuesday, September 22, 2015 1:35 PM
>> To: Leeyoung; Vishnu Pavan Beeram
>> Cc: TEAS WG; Daniele Ceccarelli; Varma, Eve L (Eve);
>> [e-mail]<mailto:[e-mail]>
>> 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
> [e-mail]<mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/teas