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) 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 <[e-mail]>
wrote:

> Hi Daniele,
>
>
>
> Please, see in line.
>
> Cheers,
>
> Igor
>
>
>
> *From:* Daniele Ceccarelli [mailto:[e-mail]]
> *Sent:* Saturday, September 26, 2015 3:29 PM
> *To:* Leeyoung <[e-mail]>; Igor Bryskin <
> [e-mail]>; Vishnu Pavan Beeram <[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)
>
>
>
> 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?
>
>
>
> 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:[e-mail] <[e-mail]>]
> *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);
> [e-mail]
> *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:[e-mail]
> <[e-mail]>]
> *Sent:* Friday, September 25, 2015 10:54 AM
> *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)
>
>
>
> Hi Daniele,
>
> Please, see in line.
>
>
>
> Igor
>
>
>
> *From:* Daniele Ceccarelli [mailto:[e-mail]
> <[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 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
>
> 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]
> <[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]] *On Behalf Of *Daniele
> Ceccarelli
> *Sent:* Friday, September 25, 2015 8:13 AM
> *To:* 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)
>
>
>
> 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]
> <[e-mail]>]
> *Sent:* giovedì 24 settembre 2015 22:06
> *To:* Leeyoung
> *Cc:* Lou Berger; 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)
>
>
>
> 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
>
>
>