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

[Vishnu Pavan Beeram <[e-mail]>]

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]> 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]]
> Sent: Thursday, September 24, 2015 1:23 PM
> To: Leeyoung; Vishnu Pavan Beeram
> Cc: Varma, Eve L (Eve); Daniele Ceccarelli; TEAS WG;
> [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]]
> >> Sent: Tuesday, September 22, 2015 1:35 PM
> >> To: Leeyoung; Vishnu Pavan Beeram
> >> Cc: TEAS WG; Daniele Ceccarelli; Varma, Eve L (Eve);
> >> [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]
> > https://www.ietf.org/mailman/listinfo/teas
>
>
>