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

["Varma, Eve L (Eve)" <[e-mail]>]

Hi,

Some additional clarifying text added on etherpad ☺

Best regards,
Eve

From: Vishnu Pavan Beeram [mailto:[e-mail]]
Sent: Tuesday, September 29, 2015 8:17 PM
To: Leeyoung
Cc: Igor Bryskin; Daniele Ceccarelli; 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)

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 <[e-mail]<mailto:[e-mail]>> 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:[e-mail]<mailto:[e-mail]>]
Sent: Monday, September 28, 2015 8:59 PM
To: Igor Bryskin
Cc: Daniele Ceccarelli; Leeyoung; Lou Berger; TEAS WG; Varma, Eve L (Eve); [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) 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]<mailto:[e-mail]>>
wrote:

> Hi Daniele,
>
>
>
> Please, see in line.
>
> Cheers,
>
> Igor
>
>
>
> *From:* Daniele Ceccarelli [mailto:[e-mail]<mailto:[e-mail]>]
> *Sent:* Saturday, September 26, 2015 3:29 PM
> *To:* Leeyoung <[e-mail]<mailto:[e-mail]>>; Igor Bryskin <
> [e-mail]<mailto:[e-mail]>>; Vishnu Pavan Beeram <[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)
>
>
>
> 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]<mailto:[e-mail]> <[e-mail]<mailto:[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]<mailto:[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.t
> xt
>
> 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]<mailto:[e-mail]>
> <[e-mail]<mailto:[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]<mailto:[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]<mailto:[e-mail]>
> <[e-mail]<mailto:[e-mail]>>]
> *Sent:* Friday, September 25, 2015 9:56 AM
> *To:* Igor Bryskin <[e-mail]<mailto:[e-mail]>>; 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)
>
>
>
> 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]<mailto:[e-mail]>
> <[e-mail]<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]<mailto:[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:[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