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 Lou,

That's fine - more succint.

Regards,
Eve

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


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:[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
>
>  
>
>
>
> _______________________________________________
> Teas mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/teas