Subject: [Teas] Poll on draft-lee-teas-actn-requirements-01 a WG documents

From: Lou Berger <[email-masked]>
Date: Wed, 2 Sep 2015 16:25:29 -0400

All,

This is start of a two week poll on making
draft-lee-teas-actn-requirements-01 a TEAS working group document.
Please send email to the list indicating “yes/support” or “no/do not
support”. If indicating no, please state your technical reservations
with the document.  If yes, please also feel free to provide comments
you'd like to see addressed once the document is a WG document.

The poll ends September 16th
Thanks,
Lou and Pavan

---

From: Daniele Ceccarelli <[email-masked]>
Date: Thu, 3 Sep 2015 07:09:21 +0000

Yes/Support

(co-author)
Daniele

> -----Original Message-----
> From: Teas [mailto:[email-masked]] On Behalf Of Lou Berger
> Sent: mercoledì 2 settembre 2015 22:25
> To: TEAS WG
> Subject: [Teas] Poll on draft-lee-teas-actn-requirements-01 a WG documents
> 
> All,
> 
> Please send email to the list indicating "yes/support" or "no/do not support".
> If indicating no, please state your technical reservations with the document.
> If yes, please also feel free to provide comments you'd like to see addressed
> once the document is a WG document.
> 
> _______________________________________________
> Teas mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/teas

---

From: "BELOTTI, SERGIO (SERGIO)" <[email-masked]>
Date: Thu, 3 Sep 2015 07:28:36 +0000

YES/SUPPORT

(co-author)

Thanks
sergio

-----Original Message-----
From: Teas [mailto:[email-masked]] On Behalf Of Lou Berger
Sent: mercoledì 2 settembre 2015 22:25
To: TEAS WG
Subject: [Teas] Poll on draft-lee-teas-actn-requirements-01 a WG documents

All,

This is start of a two week poll on making
draft-lee-teas-actn-requirements-01 a TEAS working group document.
Please send email to the list indicating "yes/support" or "no/do not support". If indicating no, please state your technical reservations with the document.  If yes, please also feel free to provide comments you'd like to see addressed once the document is a WG document.

---

From: Dieter Beller <[email-masked]>
Date: Thu, 3 Sep 2015 09:32:47 +0200

+1

Thanks,

Dieter

On 03.09.2015 09:28, BELOTTI, SERGIO
(SERGIO) wrote:

YES/SUPPORT

(co-author)

Thanks
sergio

-----Original Message-----
From: Teas [mailto:[email-masked]] On Behalf Of Lou Berger
Sent: mercoledì 2 settembre 2015 22:25
To: TEAS WG
Subject: [Teas] Poll on draft-lee-teas-actn-requirements-01 a WG documents

All,

---

From: "Varma, Eve L (Eve)" <[email-masked]>
Date: Thu, 3 Sep 2015 11:37:50 +0000

+1

Best regards,
Eve
On 03.09.2015 09:28, BELOTTI, SERGIO (SERGIO) wrote:

YES/SUPPORT

(co-author)

Thanks

sergio

-----Original Message-----

To: TEAS WG

All,

Thanks,

Lou and Pavan

Teas mailing list

[email-masked]<mailto:[email-masked]>

---

From: Yuji Tochio <[email-masked]>
Date: Thu, 03 Sep 2015 21:31:59 +0900

Support

Regards, Yuji

---

From: "Andrew G. Malis" <[email-masked]>
Date: Thu, 3 Sep 2015 09:30:05 -0400

Lou,

Yes/support - this is very good work.

Cheers,
Andy

---

From: Quintin zhao <[email-masked]>
Date: Thu, 3 Sep 2015 18:16:19 +0000

Yes/Support.

Regards,
Quintin

On Wed, Sep 2, 2015 at 4:25 PM, Lou Berger <[email-masked]<mailto:[email-masked]>> wrote:
All,

---

From: "Takuya Miyasaka" <[email-masked]>
Date: Fri, 4 Sep 2015 09:14:59 +0900

Yes/Support (as contributor)

Thanks,
Takuya

> Sent: Thursday, September 03, 2015 5:25 AM
> To: TEAS WG
> Please send email to the list indicating "yes/support" or "no/do not support". If indicating no, please state your technical
> reservations with the document.  If yes, please also feel free to provide comments you'd like to see addressed once the
> document is a WG document.
>

---

From: Loa Andersson <[email-masked]>
Date: Fri, 4 Sep 2015 09:52:19 +0200

Lou,

I agree with Andy, this is good work - I support it going forward.

/Loa

On 2015-09-03 15:30, Andrew G. Malis wrote:
>     [email-masked] <mailto:[email-masked]>

---

From: Xufeng Liu <[email-masked]>
Date: Fri, 4 Sep 2015 15:30:31 +0000

Yes/support.

Regards,
- Xufeng

> Sent: Wednesday, September 02, 2015 4:25 PM
> To: TEAS WG
> Please send email to the list indicating "yes/support" or "no/do not support". If
> indicating no, please state your technical reservations with the document.  If
> yes, please also feel free to provide comments you'd like to see addressed once
> the document is a WG document.
>

---

From: Leeyoung <[email-masked]>
Date: Fri, 4 Sep 2015 15:58:45 +0000

Yes/support (co-author)

Thanks.
Young

-----Original Message-----
From: Teas [mailto:[email-masked]] On Behalf Of Lou Berger
Sent: Wednesday, September 02, 2015 3:25 PM
To: TEAS WG
Subject: [Teas] Poll on draft-lee-teas-actn-requirements-01 a WG documents

All,

This is start of a two week poll on making
draft-lee-teas-actn-requirements-01 a TEAS working group document.
Please send email to the list indicating "yes/support" or "no/do not
support". If indicating no, please state your technical reservations
with the document.  If yes, please also feel free to provide comments
you'd like to see addressed once the document is a WG document.

---

From: Jeff Tantsura <[email-masked]>
Date: Fri, 4 Sep 2015 18:29:59 +0000

Yes/support

Regards,
Jeff

---

From: "Zhangxian (Xian)" <[email-masked]>
Date: Sun, 6 Sep 2015 00:42:32 +0000

Yes/support.

Regards,
Xian

-----Original Message-----
From: Teas [mailto:[email-masked]] On Behalf Of Lou Berger
Sent: 2015年9月3日 4:25
To: TEAS WG
Subject: [Teas] Poll on draft-lee-teas-actn-requirements-01 a WG documents

All,

---

From: Zhenghaomian <[email-masked]>
Date: Sun, 6 Sep 2015 00:54:27 +0000

Yes/Support. 

Best wishes,
Haomian

-----Original Message-----
From: Teas [mailto:[email-masked]] On Behalf Of Lou Berger
Sent: Wednesday, September 02, 2015 3:25 PM
To: TEAS WG
Subject: [Teas] Poll on draft-lee-teas-actn-requirements-01 a WG documents

All,

---

From: Fatai Zhang <[email-masked]>
Date: Sun, 6 Sep 2015 06:59:09 +0000

Yes/support.

Best Regards

Fatai

-----Original Message-----
From: Teas [mailto:[email-masked]] On Behalf Of Lou Berger
Sent: Thursday, September 03, 2015 4:25 AM
To: TEAS WG
Subject: [Teas] Poll on draft-lee-teas-actn-requirements-01 a WG documents

All,

---

From: Huaimo Chen <[email-masked]>
Date: Mon, 7 Sep 2015 01:10:02 +0000

Support.

Best Regards,
Huaimo
-----Original Message-----
From: Teas [mailto:[email-masked]] On Behalf Of Lou Berger
Sent: Wednesday, September 02, 2015 4:25 PM
To: TEAS WG
Subject: [Teas] Poll on draft-lee-teas-actn-requirements-01 a WG documents

All,

---

From: "Dongjie (Jimmy)" <[email-masked]>
Date: Mon, 7 Sep 2015 06:53:09 +0000

Yes/support.

-Jie

> If indicating no, please state your technical reservations with the document.  If

---

From: Mach Chen <[email-masked]>
Date: Tue, 8 Sep 2015 01:30:45 +0000

Yes/support.

Best regards,
Mach

---

From: Kwangkoog Lee <[email-masked]>
Date: Tue, 8 Sep 2015 08:33:42 +0700

I support this document.

best regards, 
Kwangkoog Lee 

Sent from my iPhone

> On 2015. 9. 8., at 오전 8:30, Mach Chen <[email-masked]> wrote:
> 
> Yes/support.
> 
> Best regards,
> Mach
>

---

From: Aihua Guo <[email-masked]>
Date: Tue, 8 Sep 2015 18:54:00 +0000

Yes/support.

Aihua

-----Original Message-----
From: Teas [mailto:[email-masked]] On Behalf Of Kwangkoog Lee
Sent: Monday, September 07, 2015 9:34 PM
To: Mach Chen
Cc: Lou Berger; TEAS WG
Subject: Re: [Teas] Poll on draft-lee-teas-actn-requirements-01 a WG documents

I support this document.

best regards,
Kwangkoog Lee 

Sent from my iPhone

>> If yes, please also feel free to provide comments you'd like to see 
>> addressed once the document is a WG document.
>>

---

From: Dhruv Dhody <[email-masked]>
Date: Mon, 14 Sep 2015 19:57:28 +0530

Yes / Support

Regards,
Dhruv
(As a co-author)

---

From: Lou Berger <[email-masked]>
Date: Thu, 17 Sep 2015 07:04:08 -0400

All,
    The WG poll is closed.

Authors,
    Please republish draft-lee-teas-actn-requirements-01 as
draft-ietf-teas-vn-controller-requirements-00 with only the date and
file name changed.
Comments received (publicly and privately) should be discussed and
addresses in the -01 version.

Please note the file name change. Normally it's pretty formulaic.  But
this draft is a little different as it has evolved over time to its
current form and where we expect it to  go.  In particular, we see this
draft as a companion to the 'interconnected-te' work and covering the
various possible controller-based TE models  (where the previous work
was more focused on fully distributed control models).  So we think a
broader name warranted.

Again, no other changes to the draft should be made at this time.

Thank you,
Lou and Pavan

---

From: Daniele Ceccarelli <[email-masked]>
Date: Thu, 17 Sep 2015 15:05:50 +0000

Hi Lou,

I´m a bit surprised by this name change. May I ask the rationale for such a request?
Is it due to the desire to get rid of the name ACTN or to the need to call it VNC? 

If you recall the MDSC used to be called VNC and we decided to change it because it was misleading. Changing the name of the entire architecture into the wrong name of a single controller is creating confusion in my opinion. The name ACTN doesn´t preclude any companionship with the interconnected-TE.
Moreover ACTN is a name that has been around for 2 years, has been used in IETF, publications and conferences...I would really like to keep it.

Thanks
Daniele

> Sent: giovedì 17 settembre 2015 13:04
> To: TEAS WG; [email-masked]
> draft-ietf-teas-vn-controller-requirements-00 with only the date and file
> name changed.
> Please note the file name change. Normally it's pretty formulaic.  But this
> draft is a little different as it has evolved over time to its current form and
> where we expect it to  go.  In particular, we see this draft as a companion to
> the 'interconnected-te' work and covering the various possible controller-
> based TE models  (where the previous work was more focused on fully
> distributed control models).  So we think a broader name warranted.
>

---

From: "BELOTTI, SERGIO (SERGIO)" <[email-masked]>
Date: Thu, 17 Sep 2015 15:40:44 +0000

Hi, as co-author, I completely share Daniele's comment, and I'd really like to maintain "ACTN" in the title as well.

Thanks
Sergio

-----Original Message-----
From: Daniele Ceccarelli [mailto:[email-masked]] 
Sent: giovedì 17 settembre 2015 17:06
To: Lou Berger; TEAS WG; [email-masked]
Subject: RE: [Teas] Poll on draft-lee-teas-actn-requirements-01 a WG documents

Hi Lou,

Thanks
Daniele

> current form and where we expect it to  go.  In particular, we see 
> this draft as a companion to the 'interconnected-te' work and covering 
> the various possible controller- based TE models  (where the previous 
> work was more focused on fully distributed control models).  So we think a broader name warranted.
> 
> > with the document.  If yes, please also feel free to provide 
> > comments you'd like to see addressed once the document is a WG document.
> >

---

From: Leeyoung <[email-masked]>
Date: Thu, 17 Sep 2015 16:44:22 +0000

Hi

I express the same concern with Daniele and Sergio in this thread. ACTN has a bigger scope than VN control/controller. The current requirement draft has encompassed a number of use-cases to put various requirements into a single draft as the basis of the work. 

I would ask for reconsidering the change of the draft's name. 

Best regards,
Young

-----Original Message-----
From: Daniele Ceccarelli [mailto:[email-masked]] 
Sent: Thursday, September 17, 2015 10:06 AM
To: Lou Berger; TEAS WG; [email-masked]
Subject: RE: [Teas] Poll on draft-lee-teas-actn-requirements-01 a WG documents

Hi Lou,

Thanks
Daniele

---

From: Lou Berger <[email-masked]>
Date: Thu, 17 Sep 2015 12:53:04 -0400

Daniele, Authors,

To me (perhaps us) the VN controller name seemed to line up well with
the current text and was *broader* than ACTN, i.e., could cover any TE
control approach that doesn't use a fully distributed control plane.

Perhaps answering the following will help inform the choice of name:
- What about the requirements in the current draft is limited to 'ACTN'?

- Do you have an alternate name that covers any TE control architecture
that doesn't use a fully distributed control plane?

Thanks,
Lou

---

From: "Varma, Eve L (Eve)" <[email-masked]>
Date: Thu, 17 Sep 2015 19:19:32 +0000

Hi Lou,

To me, the name ACTN seems to be *broad" and I would also prefer to retain it.

With best regards,
Eve

-----Original Message-----
From: Teas [mailto:[email-masked]] On Behalf Of Lou Berger
Sent: Thursday, September 17, 2015 12:53 PM
To: Daniele Ceccarelli; TEAS WG; [email-masked]
Subject: Re: [Teas] Poll on draft-lee-teas-actn-requirements-01 a WG documents

Daniele, Authors,

To me (perhaps us) the VN controller name seemed to line up well with the current text and was *broader* than ACTN, i.e., could cover any TE control approach that doesn't use a fully distributed control plane.

- Do you have an alternate name that covers any TE control architecture that doesn't use a fully distributed control plane?

Thanks,
Lou

On 09/17/2015 11:05 AM, Daniele Ceccarelli wrote:
>> Please note the file name change. Normally it's pretty formulaic.  
>> But this draft is a little different as it has evolved over time to 
>> its current form and where we expect it to  go.  In particular, we 
>> see this draft as a companion to the 'interconnected-te' work and 
>> covering the various possible controller- based TE models  (where the 
>> previous work was more focused on fully distributed control models).  So we think a broader name warranted.
>>

---

From: Daniele Ceccarelli <[email-masked]>
Date: Thu, 17 Sep 2015 19:35:41 +0000

Lou,

I can´t imagine anything broader that Abstraction and Control of transport networks...it includes any type of control: centralized, distributed and hybrid (and spans from layer 0 to 2,5).

> - What about the requirements in the current draft is limited to 'ACTN'?
Limited to the broadest concept? If we want to call it limited...

> - Do you have an alternate name that covers any TE control architecture that
> doesn't use a fully distributed control plane?
ACTN is ok. The PNC can be any "magic box" used to control the physical network: an SDN controller (with e.g. OF, NetConf, PCEP as SBI, a PCE that controls a GMPLS network, an NMS, whatever you can put an ACTN interface on top as NBI.

Thanks,
Daniele

> From: Lou Berger [mailto:[email-masked]]
> Sent: giovedì 17 settembre 2015 18:53
> To me (perhaps us) the VN controller name seemed to line up well with the
> current text and was *broader* than ACTN, i.e., could cover any TE control
> approach that doesn't use a fully distributed control plane.
> 
> - Do you have an alternate name that covers any TE control architecture that
> doesn't use a fully distributed control plane?
> 
> Thanks,
> Lou
> 
> > If you recall the MDSC used to be called VNC and we decided to change it
> because it was misleading. Changing the name of the entire architecture into
> the wrong name of a single controller is creating confusion in my opinion.
> The name ACTN doesn´t preclude any companionship with the
> interconnected-TE.
> > Moreover ACTN is a name that has been around for 2 years, has been used
> in IETF, publications and conferences...I would really like to keep it.
> >
> > Thanks
> > Daniele
> >
> >

---

From: Lou Berger <[email-masked]>
Date: Thu, 17 Sep 2015 16:25:05 -0400

Daniele,
    A lot of my reservation with the current title is with 'Transport
Networks' part.  Back pre-WG reorg, ccamp really was only concerned with
Transport networks.  Now with TEAS, our scope has been extended to any
TE network, including MPLS-TE.  So I think we need to broaden the scope
to all TE, not just Transport Networks.

A secondary point is that purely distributed control plane solutions
also provide 'Abstract Control'.  Consider VNTs covered in the
interconnected-te draft.  So I think we need to distinguish this work
here too.

I'm certainly not wedded to vn-controller-requirements, but I think
think the above concerns have to be covered.  BTW I did reread the
document to see if the comment really extended to the meat of the text. 
But thankfully the ACTN term isn't core to the document.

Thanks,
Lou

---

From: "Doolan, Paul (Coriant - US/Irving)" <[email-masked]>
Date: Thu, 17 Sep 2015 20:28:41 +0000

Hello Lou and Pavan,

this instruction to change ACTN to VN-Controller seems a little high handed. 

Young Lee, Danielle and their co-authors have spent a long time working on this and creating mind share and name recognition for ACTN. I know what it stands for as do audiences around the world to whom the team have introduced the idea and from whom they have garnered support. In contrast I have absolutely no idea what a vn-controller requirements draft might be about and, if you persist with this renaming, it clearly makes no sense to make 'no other changes to the draft' since, at the very least, the (new) title needs explanation.

I really think the draft should be adopted as (originally) named. If you want to change the name then coming back to the WG with a clearly articulated rationale and asking for its support would seem to me to be a more inclusive way to do things.

my 10cents,
pd

---

From: Leeyoung <[email-masked]>
Date: Thu, 17 Sep 2015 20:42:47 +0000

Hi Lou,

We spend a lot of time what Transport Network is in the past two years or so since the conception of ACTN.

In regard to Transport Network, we defined it as follows in the framework draft in Section 1:
https://tools.ietf.org/html/draft-ceccarelli-teas-actn-framework-00 

"The term Transport Network in this draft refers to any connection-
oriented network that has the ability of dynamic provisioning and
traffic engineering such that resource guarantees can be provided to
the network's clients.  Some examples of networks that are in scope 
of this definition are optical networks, MPLS Transport Profile (MPLS-TP), 
MPLS Traffic Engineering (MPLS-TE), and other emerging 
technologies with connection-oriented behavior."

Hope this answer your first point. 

In regards to your second point is yes I agree that abstract control also includes purely distributed control plane solutions. 
We are not preclude this in ACTN as Danielle indicated in his previous email. 

Thanks,
Young

-----Original Message-----
From: Lou Berger [mailto:[email-masked]] 
Sent: Thursday, September 17, 2015 3:25 PM
To: Daniele Ceccarelli; TEAS WG; [email-masked]
Subject: Re: [Teas] Poll on draft-lee-teas-actn-requirements-01 a WG documents

Daniele,

Thanks,
Lou

---

From: "Andrew G. Malis" <[email-masked]>
Date: Thu, 17 Sep 2015 17:26:25 -0400

Lou,

I'm very much in agreement with Paul.

Thanks,
Andy

On Thu, Sep 17, 2015 at 4:28 PM, Doolan, Paul (Coriant - US/Irving) <
[email-masked]> wrote:

> Young Lee, Danielle and their co-authors have spent a long time working on
> this and creating mind share and name recognition for ACTN. I know what it
> stands for as do audiences around the world to whom the team have
> introduced the idea and from whom they have garnered support. In contrast I
> have absolutely no idea what a vn-controller requirements draft might be
> about and, if you persist with this renaming, it clearly makes no sense to
> make 'no other changes to the draft' since, at the very least, the (new)
> title needs explanation.
>
> I really think the draft should be adopted as (originally) named. If you
> want to change the name then coming back to the WG with a clearly
> articulated rationale and asking for its support would seem to me to be a
> more inclusive way to do things.
>
> my 10cents,
> pd
>
>
>
>

---

From: Lou Berger <[email-masked]>
Date: Thu, 17 Sep 2015 20:51:12 -0400

Paul,

> this instruction to change ACTN to VN-Controller seems a little high handed. 

I/we hear you. But...

> Young Lee, Danielle and their co-authors have spent a long time working on this and creating mind share and name recognition for ACTN. I know what it stands for as do audiences around the world to whom the team have introduced the idea and from whom they have garnered support. 

That's fair, but from our perspective the IETF has been working TE a lot
longer than the term ACTN has been around, and that is the context where
this work fits. 

As I stated at the last meeting, it's my (not to speak for Pavan, but
think he agrees too)  option that this work is complimentary to the
interconnected-te particularly as it is more focused on the
controller/non-fully distributed control plane approaches.   We think
that covering such controller based TE models as very important and
fills an important gap in the TE architecture.

Right now, we (the WG) are just at the requirements stage and those
requirements apply quite broadly and that is what we (the chairs) want
to make clear by the name change.

> In contrast I have absolutely no idea what a vn-controller requirements draft might be about and, 

> if you persist with this renaming, it clearly makes no sense to make 'no other changes to the draft' since, at the very least, the (new) title needs explanation.

It's just a filename.  That said, we (chairs) are trying to project
where the work will end up based on the WG consensus process.  Chairs
have changed names in the past and been right and sometimes wrong, but
in the end we have an RFC published with the title that represents WG
consensus and an RFC number. 

> I really think the draft should be adopted as (originally) named. If you want to change the name then coming back to the WG with a clearly articulated rationale and asking for its support would see…

It's not unusual for chairs to change names of a draft at adoption. 
Normally it goes without comment.  Perhaps if this wasn't the first
'actn' document it would have.

Again, we're open to alternatives that capture the scope of the work.

Lou

---

From: Lou Berger <[email-masked]>
Date: Thu, 17 Sep 2015 21:08:01 -0400

Young,

See below.

> We spend a lot of time what Transport Network is in the past two years or so since the conception of ACTN.

Understood, but keep in mind, we're just now entering the formal
standardization process. I know that many authors feel their work is
mature when they submit the individual draft. But as is always the case,
individual documents are just a starting point.  It is with / after
adoption that change should be expected.  (again, as always) the point
of such changes are to make this work more applicable to the whole WG
and not just the authors/contributors who originated the work.

> Hope this answer your first point. 

This is good, but we have a wider industry understanding of the
"Transport Network" term that generally excludes portions of what we,
the IETF, include as part of TE.  I think the IETF experience with
MPLS-TP highlights that MPLS-TE, arguably the most deployed IETF TE
technology, isn't considered by many to be a Transport Network.  Perhaps
I'm wrong, but I'd bet that many who work on MPLS-TE don't even consider
that they themselves are working on a "Transport Network" technology.

> We are not preclude this in ACTN as Danielle indicated in his previous email. 

So the IETF already has a large body of work that is focused on purely
distributed control plane solutions.  I'm not sure there is a need for
another set of requirements/architecture/... documents covering this
topic.  I do think we all agree that there are gaps and work to be done
on controller-based/non-fully distributed control models. And as I
stated both publicly and privately in Prague, this is where we (the
chairs) believe this work should be focused.

Thanks,
Lou

---

From: "Zhangxian (Xian)" <[email-masked]>
Date: Fri, 18 Sep 2015 01:19:47 +0000

Hi, All, 

 I cannot agree more with what Daniele said: 

"I can´t imagine anything broader that Abstraction and Control of transport networks...it includes any type of control: centralized, distributed and hybrid (and spans from layer 0 to 2,5)."

 "VN controller", reads to me, narrower than what the draft is covering, which also includes control of multi-domain/multi-layer networks.

My 2cents,
Xian

-----Original Message-----
From: Teas [mailto:[email-masked]] On Behalf Of Daniele Ceccarelli
Sent: 2015年9月18日 3:36
To: Lou Berger; TEAS WG; [email-masked]
Subject: Re: [Teas] Poll on draft-lee-teas-actn-requirements-01 a WG documents

Lou,

Thanks,
Daniele

---

From: Zhenghaomian <[email-masked]>
Date: Fri, 18 Sep 2015 01:42:56 +0000

Hi, Lou and all,

I share the same comments on keeping the actn name in the title as Young, Daniele, Sergio, and many other people. 

I am not here to argue the IETF procedure on WG adoption. I know the chairs have the power to change the draft name, but I believe that always happens when the current title is severely misleading. Currently I don't think there is an obvious inconsistency between the title and the content of this draft, so it is not proper to change it *at this moment*. My understanding is, when people poll on this draft by saying 'yes/support', they tend to agree with the ACTN title and support the usage of such terminology, there was no such comments (about scope of transport network) during the poll. As this draft will be a WG draft, we (the WG) can definitely talk it afterwards. As you said, all the draft will end with a RFC number, why we MUST change the title abbreviation NOW? It will confuse more people. 

BTW, I don't think VN-controller can cover all the ACTN stuffs, currently the work is not limited to controller, obviously the interfaces are also considered. 

My 2 cents, 
Haomian

-----邮件原件-----
发件人: Teas [mailto:[email-masked]] 代表 Lou Berger
发送时间: 2015年9月18日 9:08
收件人: Leeyoung; Daniele Ceccarelli; TEAS WG; [email-masked]
主题: Re: [Teas] Poll on draft-lee-teas-actn-requirements-01 a WG documents

Young,

See below.

> We spend a lot of time what Transport Network is in the past two years or so since the conception of ACTN.

Understood, but keep in mind, we're just now entering the formal standardization process. I know that many authors feel their work is mature when they submit the individual draft. But as is always the case, individual documents are just a starting point.  It is with / after adoption that change should be expected.  (again, as always) the point of such changes are to make this work more applicable to the whole WG and not just the authors/contributors who originated the work.

> the network's clients.  Some examples of networks that are in scope of 
> this definition are optical networks, MPLS Transport Profile 
> (MPLS-TP), MPLS Traffic Engineering (MPLS-TE), and other emerging 

This is good, but we have a wider industry understanding of the "Transport Network" term that generally excludes portions of what we, the IETF, include as part of TE.  I think the IETF experience with MPLS-TP highlights that MPLS-TE, arguably the most deployed IETF TE technology, isn't considered by many to be a Transport Network.  Perhaps I'm wrong, but I'd bet that many who work on MPLS-TE don't even consider that they themselves are working on a "Transport Network" technology.

> We are not preclude this in ACTN as Danielle indicated in his previous email. 

So the IETF already has a large body of work that is focused on purely distributed control plane solutions.  I'm not sure there is a need for another set of requirements/architecture/... documents covering this topic.  I do think we all agree that there are gaps and work to be done on controller-based/non-fully distributed control models. And as I stated both publicly and privately in Prague, this is where we (the
chairs) believe this work should be focused.

Thanks,
Lou

> To: Daniele Ceccarelli; TEAS WG; 
> [email-masked]
> Networks' part.  Back pre-WG reorg, ccamp really was only concerned 
> with Transport networks.  Now with TEAS, our scope has been extended 
> to any TE network, including MPLS-TE.  So I think we need to broaden 
> the scope to all TE, not just Transport Networks.
>
>>> - Do you have an alternate name that covers any TE control 
>>> architecture that doesn't use a fully distributed control plane?
>>> To: Daniele Ceccarelli; TEAS WG; 
>>> [email-masked]
>>> To me (perhaps us) the VN controller name seemed to line up well 
>>> with the current text and was *broader* than ACTN, i.e., could cover 
>>> any TE control approach that doesn't use a fully distributed control plane.
>>>
>>> - Do you have an alternate name that covers any TE control 
>>> architecture that doesn't use a fully distributed control plane?
>>>
>>> Thanks,
>>> Lou
>>>
>>>> I´m a bit surprised by this name change. May I ask the rationale 
>>>> for such a
>>> request?
>>>> Is it due to the desire to get rid of the name ACTN or to the need 
>>>> to call it
>>> VNC?
>>> because it was misleading. Changing the name of the entire 
>>> architecture into the wrong name of a single controller is creating confusion in my opinion.
>>>>> draft-ietf-teas-vn-controller-requirements-00 with only the date 
>>>>> and file name changed.
>>>>> But this draft is a little different as it has evolved over time 
>>>>> to its current form and where we expect it to  go.  In particular, 
>>>>> we see this draft as a companion to the 'interconnected-te' work 
>>>>> and covering the various possible controller- based TE models  
>>>>> (where the previous work was more focused on fully distributed 
>>>>> control models).  So
>>> we think a broader name warranted.
>>>>>> Please send email to the list indicating "yes/support" or "no/do 
>>>>>> not support". If indicating no, please state your technical 
>>>>>> reservations with the document.  If yes, please also feel free to 
>>>>>> provide comments you'd like to see addressed once the document is 
>>>>>> a WG
>>> document.

---

From: "Varma, Eve L (Eve)" <[email-masked]>
Date: Fri, 18 Sep 2015 02:18:35 +0000

+1

-----Original Message-----
From: Teas [mailto:[email-masked]] On Behalf Of Zhenghaomian
Sent: Thursday, September 17, 2015 9:43 PM
To: Lou Berger; Leeyoung; Daniele Ceccarelli; TEAS WG; [email-masked]
Subject: [Teas] 答复: Poll on draft-lee-teas-actn-requirements-01 a WG documents

Hi, Lou and all,

My 2 cents,
Haomian

-----邮件原件-----
发件人: Teas [mailto:[email-masked]] 代表 Lou Berger
发送时间: 2015年9月18日 9:08
收件人: Leeyoung; Daniele Ceccarelli; TEAS WG; [email-masked]
主题: Re: [Teas] Poll on draft-lee-teas-actn-requirements-01 a WG documents

Young,

See below.

Thanks,
Lou

---

From: Daniele Ceccarelli <[email-masked]>
Date: Fri, 18 Sep 2015 07:22:46 +0000

Lou,

Is your concern mostly related to the "transport" word? In the last years the concept of transport evolved pretty much, mostly with transport SDN and it is no longer tied to the L0-L1 but it covers whatever mean used to transport IP. Young already pointed out what the draft aims to cover.

If you're so strongly willing to change the name we could turn "Transport" into TE so that it becomes Abstraction and Control of TE networks. (this is my personal proposal, not shared by the other ACTNers)...and ACTN remains, but with the "broader" scope and it is "more" complementary to the interconnected TE.
The change of the file name is not just the change of a file name. 

Daniele

> Sent: venerdì 18 settembre 2015 02:51
> To: Doolan, Paul (Coriant - US/Irving)
> Cc: TEAS WG; [email-masked]
> > Young Lee, Danielle and their co-authors have spent a long time working
> on this and creating mind share and name recognition for ACTN. I know what
> it stands for as do audiences around the world to whom the team have
> introduced the idea and from whom they have garnered support.
> 
> As I stated at the last meeting, it's my (not to speak for Pavan, but think he
> agrees too)  option that this work is complimentary to the interconnected-te
> particularly as it is more focused on the
> that covering such controller based TE models as very important and fills an
> important gap in the TE architecture.
> 
> requirements apply quite broadly and that is what we (the chairs) want to
> make clear by the name change.
> 
> > if you persist with this renaming, it clearly makes no sense to make 'no
> other changes to the draft' since, at the very least, the (new) title needs
> explanation.
> 
> It's just a filename.  That said, we (chairs) are trying to project where the
> work will end up based on the WG consensus process.  Chairs have changed
> names in the past and been right and sometimes wrong, but in the end we
> have an RFC published with the title that represents WG consensus and an
> RFC number.
> 
> > I really think the draft should be adopted as (originally) named. If you want
> to change the name then coming back to the WG with a clearly articulated
> rationale and asking for its support would seem to me to be a more inclusive
> way to do things.
> 
> Normally it goes without comment.  Perhaps if this wasn't the first 'actn'
> document it would have.
> 
> >> covering the various possible controller-based TE models  (where the

---

From: Vishnu Pavan Beeram <[email-masked]>
Date: Fri, 18 Sep 2015 08:04:59 -0400

A few points to mull over and move the discussion along:

- Fitting "ACTN" into the "TEAS" body of work:
Work focusing on "how TE networks can be abstracted and managed in a
controller(s) driven environment" is an obvious item of interest to the WG.
And this is primarily where we believe the "ACTN" work can contribute; the
requirements discussed in the document that just got adopted by the WG
aligns well with this. The intent behind the name-change was to have
something generic enough to capture what we want this work to be about.
Note that this is just a requirements document and since this is the first
document to be adopted in this realm, it is important to get the "naming"
right now rather than later. "VN Controller" is perhaps not a great choice
-- very much open to other choices that would capture the essence of the
first statement above.

- Complementing existing TEAS work:
<draft-ietf-teas-interconnected-te-info-exchange> discusses the
architecture for the exchange of TE information between interconnected TE
networks in support of end-to-end TE path establishment. It discusses in
great detail the notion of "abstraction in TE networks". Our sincere hope
(belief rather) is that the <actn-requirements> document (and other <actn>
related documents that get adopted by the WG) would be complementary to
(/consistent with) the <interconnected-te-info-exchange> draft.

- Focus on the term "Controller":
One train of thought is to use this new work (conveniently facilitated by
the induction of ACTN into TEAS) to focus solely on the "controller"
aspects (given the belief that non-controller aspects are adequately
covered by existing solutions). Personally, I don't have a strong
preference on whether the "naming" should reflect this or not (Danielle's
latest suggestion - use "TE" in the ACTN acronym - is pretty close to what
I personally would like it to be), but it is important to get some clarity
on this "scoping" detail before zeroing in on any "name".

Regards,
-Pavan

On Fri, Sep 18, 2015 at 3:22 AM, Daniele Ceccarelli <
[email-masked]> wrote:

> Lou,
>
> Is your concern mostly related to the "transport" word? In the last years
> the concept of transport evolved pretty much, mostly with transport SDN and
> it is no longer tied to the L0-L1 but it covers whatever mean used to
> transport IP. Young already pointed out what the draft aims to cover.
>
> If you're so strongly willing to change the name we could turn "Transport"
> into TE so that it becomes Abstraction and Control of TE networks. (this is
> my personal proposal, not shared by the other ACTNers)...and ACTN remains,
> but with the "broader" scope and it is "more" complementary to the
> interconnected TE.
> think he
> where the

---

From: Daniele Ceccarelli <[email-masked]>
Date: Fri, 18 Sep 2015 12:37:41 +0000

Pavan,

Please see inline.

BR
Daniele

From: Vishnu Pavan Beeram [mailto:[email-masked]]
Sent: venerdì 18 settembre 2015 14:05
To: Daniele Ceccarelli
Cc: Lou Berger; Doolan, Paul (Coriant - US/Irving); [email-masked]; TEAS WG
Subject: Re: [Teas] Poll on draft-lee-teas-actn-requirements-01 a WG documents

- Fitting "ACTN" into the "TEAS" body of work:
Work focusing on "how TE networks can be abstracted and managed in a controller(s) driven environment" is an obvious item of interest to the WG. And this is primarily where we believe the "ACTN" work can contribute; the requirements discussed in the document that just got adopted by the WG aligns well with this. The intent behind the name-change was to have something generic enough to capture what we want this work to be about. Note that this is just a requirements document and since this is the first document to be adopted in this realm, it is important to get the "naming" right now rather than later. "VN Controller" is perhaps not a great choice -- very much open to other choices that would capture the essence of the first statement above.
[DanCe] The IETF is contribution driven. If the WG contributed a draft related to a subset of what the chairs expect, it means that there is interest just in that subset. If the chairs wanted something generic enough they should have asked for a document generic enough (before the wg adoption), not call for the adoption of a document and then ask to change its scope. The authors are interested in writing ACTN requirements, which not only is a subset of what the chairs ask for but is also slightly different since we’re not speaking just about nodes and links.

- Complementing existing TEAS work:
<draft-ietf-teas-interconnected-te-info-exchange> discusses the architecture for the exchange of TE information between interconnected TE networks in support of end-to-end TE path establishment. It discusses in great detail the notion of "abstraction in TE networks". Our sincere hope (belief rather) is that the <actn-requirements> document (and other <actn> related documents that get adopted by the WG) would be complementary to (/consistent with) the <interconnected-te-info-exchange> draft.
[DanCe] What does complementary mean? Complementary in the sense that interconnected TE is for multi-domain LSP establishment in distributed control plane and ACTN does the same for centralized one? ACTN has a broader scope. The multi domain and multi layer part can be seen as complimentary, but again ACTN is not just nodes and links, it includes services, VNF, network slices and so on.

- Focus on the term "Controller":
One train of thought is to use this new work (conveniently facilitated by the induction of ACTN into TEAS) to focus solely on the "controller" aspects (given the belief that non-controller aspects are adequately covered by existing solutions). Personally, I don't have a strong preference on whether the "naming" should reflect this or not (Danielle's latest suggestion - use "TE" in the ACTN acronym - is pretty close to what I personally would like it to be), but it is important to get some clarity on this "scoping" detail before zeroing in on any "name".
[DanCe] The scoping should have been made clear before the call for adoption. The authors scoped the draft as X and asked for the adoption of X and now they are requested to publish the draft as a starting point for Y. In 2 years we have put together use cases, an architecture and would have liked to start working on solutions for that, we’d like not to start from the beginning again. Please note the list of ACTN related drafts in TEAS (not to consider the expired ones still submitted as draft-xxxxx-actn…)

[http://tools.ietf.org/images/search-small.gif]<https://www.google.com/search?as_q=%22draft-klee-teas-actn-connectivity-multi-domain-02%22&as_sitesearch=mailarchive.ietf.org/arch/browse/teas/>

draft-klee-teas-actn-connectivity-multi-domain<http://tools.ietf.org/id/draft-klee-teas-actn-connectivity-multi-domain-02.txt>

-02<http://tools.ietf.org/html/draft-klee-teas-actn-connectivity-multi-domain-02.txt>

2015-06-08

[http://tools.ietf.org/images/search-small.gif]<https://www.google.com/search?as_q=%22draft-kumaki-teas-actn-multitenant-vno-00%22&as_sitesearch=mailarchive.ietf.org/arch/browse/teas/>

draft-kumaki-teas-actn-multitenant-vno<http://tools.ietf.org/id/draft-kumaki-teas-actn-multitenant-vno-00.txt>

-00<http://tools.ietf.org/html/draft-kumaki-teas-actn-multitenant-vno-00.txt>

2015-07-06

[http://tools.ietf.org/images/search-small.gif]<https://www.google.com/search?as_q=%22draft-lam-teas-usage-info-model-net-topology-01%22&as_sitesearch=mailarchive.ietf.org/arch/browse/teas/>

draft-lam-teas-usage-info-model-net-topology<http://tools.ietf.org/id/draft-lam-teas-usage-info-model-net-topology-01.txt>

-01<http://tools.ietf.org/html/draft-lam-teas-usage-info-model-net-topology-01.txt>

2015-07-03

[http://tools.ietf.org/images/search-small.gif]<https://www.google.com/search?as_q=%22draft-lee-teas-actn-requirements-01%22&as_sitesearch=mailarchive.ietf.org/arch/browse/teas/>

draft-lee-teas-actn-requirements<http://tools.ietf.org/id/draft-lee-teas-actn-requirements-01.txt>

-01<http://tools.ietf.org/html/draft-lee-teas-actn-requirements-01.txt>

2015-07-27

[http://tools.ietf.org/images/search-small.gif]<https://www.google.com/search?as_q=%22draft-leebelotti-teas-actn-info-00%22&as_sitesearch=mailarchive.ietf.org/arch/browse/teas/>

draft-leebelotti-teas-actn-info<http://tools.ietf.org/id/draft-leebelotti-teas-actn-info-00.txt>

-00<http://tools.ietf.org/html/draft-leebelotti-teas-actn-info-00.txt>

2015-07-02

[http://tools.ietf.org/images/search-small.gif]<https://www.google.com/search?as_q=%22draft-leeking-teas-actn-problem-statement-00%22&as_sitesearch=mailarchive.ietf.org/arch/browse/teas/>

draft-leeking-teas-actn-problem-statement<http://tools.ietf.org/id/draft-leeking-teas-actn-problem-statement-00.txt>

-00<http://tools.ietf.org/html/draft-leeking-teas-actn-problem-statement-00.txt>

2015-06-09

[http://tools.ietf.org/images/search-small.gif]<https://www.google.com/search?as_q=%22draft-suzuki-teas-actn-multidomain-opc-00%22&as_sitesearch=mailarchive.ietf.org/arch/browse/teas/>

draft-suzuki-teas-actn-multidomain-opc<http://tools.ietf.org/id/draft-suzuki-teas-actn-multidomain-opc-00.txt>

-00<http://tools.ietf.org/html/draft-suzuki-teas-actn-multidomain-opc-00.txt>

2015-07-06

[http://tools.ietf.org/images/search-small.gif]<https://www.google.com/search?as_q=%22draft-xu-teas-actn-abstract-alarm-report-00%22&as_sitesearch=mailarchive.ietf.org/arch/browse/teas/>

draft-xu-teas-actn-abstract-alarm-report<http://tools.ietf.org/id/draft-xu-teas-actn-abstract-alarm-report-00.txt>

-00<http://tools.ietf.org/html/draft-xu-teas-actn-abstract-alarm-report-00.txt>

2015-07-06

[http://tools.ietf.org/images/search-small.gif]<https://www.google.com/search?as_q=%22draft-ceccarelli-teas-actn-framework-00%22&as_sitesearch=mailarchive.ietf.org/arch/browse/teas/>

draft-ceccarelli-teas-actn-framework<http://tools.ietf.org/id/draft-ceccarelli-teas-actn-framework-00.txt>

-00<http://tools.ietf.org/html/draft-ceccarelli-teas-actn-framework-00.txt>

2015-06-15

Regards,
-Pavan

On Fri, Sep 18, 2015 at 3:22 AM, Daniele Ceccarelli <[email-masked]<mailto:[email-masked]>> wrote:
Lou,

Daniele

> From: Lou Berger [mailto:[email-masked]<mailto:[email-masked]>]
> Cc: TEAS WG; [email-masked]<mailto:[email-masked]>

---

From: "Varma, Eve L (Eve)" <[email-masked]>
Date: Fri, 18 Sep 2015 12:56:46 +0000

Dear all,

I must agree with Daniele’s points.   In reviewing the inputs re draft-lee-teas-actn-requirements becoming a WG document, which resulted in its adoption as such, I don’t recall any inputs other than “Support”;  I didn’t see “Support, but clarify….” or “Support, but change….”  Given this, I am truly surprised at the discussion that has now arisen.

While I have no real issue in changing Transport to TE in the document title to move this forward, though I don’t see the issue with using the term Transport (which hasn’t been considered solely L0/L1 for a long time), I hope that the authors would be able to move forward quickly to publish as a WG draft with essentially the same title.

Bes regards,
Eve

From: Teas [mailto:[email-masked]] On Behalf Of Daniele Ceccarelli
Sent: Friday, September 18, 2015 8:38 AM
To: Vishnu Pavan Beeram
Cc: Doolan, Paul (Coriant - US/Irving); Lou Berger; [email-masked]; TEAS WG
Subject: Re: [Teas] Poll on draft-lee-teas-actn-requirements-01 a WG documents

Pavan,

Please see inline.

BR
Daniele

From: Vishnu Pavan Beeram [mailto:[email-masked]]
Sent: venerdì 18 settembre 2015 14:05
To: Daniele Ceccarelli
Cc: Lou Berger; Doolan, Paul (Coriant - US/Irving); [email-masked]<mailto:[email-masked]>; TEAS WG
Subject: Re: [Teas] Poll on draft-lee-teas-actn-requirements-01 a WG documents

2015-06-08

2015-07-06

2015-07-03

2015-07-27

2015-07-02

2015-06-09

2015-07-06

2015-07-06

2015-06-15

Regards,
-Pavan

Daniele

---

From: Igor Bryskin <[email-masked]>
Date: Fri, 18 Sep 2015 13:03:56 +0000

Daniele,

I think you've come with a good compromise. I believe that the notion "Traffic Engineered network" is wider than the notion "Transport network". IMO every transport network requires some sort of traffic engineering, while a traffic engineered network is not necessarily transport network. For example, MPLS/SPRING network could be traffic engineered while is not, generally speaking, transport network. So, Abstraction and Control of Traffic Engineered Networks (ACTN or ACTEN) seems as broad as it gets, and IMO is in full agreement with TE interconnect work.
So, I suggest we agree on this name and move on. Arguments about names seem innocuous, but we have unfortunate precedents when such arguments held us for years (recall UNI vs.ENNI, vs.XNI, etc.)

Regards,
Igor

-----Original Message-----
From: Teas [mailto:[email-masked]] On Behalf Of Daniele Ceccarelli
Sent: Friday, September 18, 2015 3:23 AM
To: Lou Berger <[email-masked]>; Doolan, Paul (Coriant - US/Irving) <[email-masked]>
Cc: [email-masked]; TEAS WG <[email-masked]>
Subject: Re: [Teas] Poll on draft-lee-teas-actn-requirements-01 a WG documents

Lou,

Daniele

---

From: Lou Berger <[email-masked]>
Date: Fri, 18 Sep 2015 10:44:27 -0400

Daniele,

see below.

On 09/18/2015 08:37 AM, Daniele Ceccarelli wrote:
> Pavan,
> 
>  
> 
> Please see inline.
> 
>  
> 
> BR
> Daniele
> 
>  
> 
> *From:*Vishnu Pavan Beeram [mailto:[email-masked]]
> *Sent:* venerdì 18 settembre 2015 14:05
> *To:* Daniele Ceccarelli
> *Cc:* Lou Berger; Doolan, Paul (Coriant - US/Irving);
> [email-masked]; TEAS WG
> *Subject:* Re: [Teas] Poll on draft-lee-teas-actn-requirements-01 a WG
> documents
> 
>  
> 
> controller(s) driven environment" is an obvious item of interest to the
> WG. And this is primarily where we believe the "ACTN" work can
> contribute; the requirements discussed in the document that just got
> adopted by the WG aligns well with this. The intent behind the
> name-change was to have something generic enough to capture what we want
> this work to be about. Note that this is just a requirements document
> and since this is the first document to be adopted in this realm, it is
> important to get the "naming" right now rather than later. "VN
> Controller" is perhaps not a great choice -- very much open to other
> choices that would capture the essence of the first statement above.
> 
> */[DanCe] The IETF is contribution driven. If the WG contributed a draft
> related to a subset of what the chairs expect, it means that there is
> interest just in that subset. If the chairs wanted something generic
> enough they should have asked for a document generic enough (before the
> wg adoption), not call for the adoption of a document and then ask to
> change its scope. 

Daniele,

You and the authors should not be surprised by any of our comments,
except perhaps the timing of the name change.  The relationship to the
interconnected-draft as well as broadening of the work should come as no
surprise.  This was mentioned by us publicly in-session in Prague as
well as privately.  Also I exchanged e-mail with you regarding whether
to bring this point up during adoption or to wait until after adoption,
and mentioned that I didn't want to delay adoption, so would wait.  So
now is that time.

Please remember that a WG doesn't have any control over an individual
draft and it is only once adopted that a WG can formally control the
draft, and the adopted draft is just a *starting* point and the WG may
take it any direction it chooses.

> The authors are interested in writing ACTN
> requirements, 

If the authors are only interested in the WG blessing what has already
been put together without any WG input than I suggest that the authors
don't understand the IETF process.

> which not only is a subset of what the chairs ask for but
> is also slightly different since we’re not speaking just about nodes and
> links. /*
> 

So, this goes back to my original question which remains unanswered:

The draft seems to be a *generic* requirements documents independent of
solution, so why limit it's scope to ACTN. (Although ACTN is certainly
the expected solution approach.)

> architecture for the exchange of TE information between interconnected
> TE networks in support of end-to-end TE path establishment. It discusses
> in great detail the notion of "abstraction in TE networks". Our sincere
> hope (belief rather) is that the <actn-requirements> document (and other
> <actn> related documents that get adopted by the WG) would be
> complementary to (/consistent with) the
> <interconnected-te-info-exchange> draft.
> 
> */[DanCe] What does complementary mean? Complementary in the sense that
> interconnected TE is for multi-domain LSP establishment in distributed
> control plane and ACTN does the same for centralized one? ACTN has a
> broader scope. The multi domain and multi layer part can be seen as
> complimentary, but again ACTN is not just nodes and links, it includes
> services, VNF, network slices and so on./*

not sure about VNF (which I'm not sure fits in the scope of TEAS, but
happy to hear why you think it does), but past TE work has included all
of these.

So what requirements are being brought to the table in this document?

As I read it, it comes down to the control model implied in the
interfaces -- i.e , which imply/enable a non-fully distributed TE
control plane.  And this is certainly both new and "complementary" to
past IETF TE work.

> *//*
> One train of thought is to use this new work (conveniently facilitated
> by the induction of ACTN into TEAS) to focus solely on the "controller"
> preference on whether the "naming" should reflect this or not
> (Danielle's latest suggestion - use "TE" in the ACTN acronym - is pretty
> close to what I personally would like it to be), but it is important to
> get some clarity on this "scoping" detail before zeroing in on any "name".
> 
> */[DanCe] The scoping should have been made clear before the call for
> adoption. The authors scoped the draft as X and asked for the adoption
> of X and now they are requested to publish the draft as a starting point
> for Y.

Nothing yet has changed in the document contents.  At this point there
is an open action on the contents from the last meeting, which is for
the authors to consider how best to address the comments made publicly
and then expanded upon privately (not to exclude anyone, but just to
because face to face is faster.)

In Prague, my inclination was to wait until this was done before polling
for adoption, but one of the authors convinced me that the current
*requirements* document was a sufficient *starting* point and this would
be done once adopted.  I still think this is a fine path, as long as the
authors understand there is still work to be done.

> In 2 years we have put together use cases, an architecture and
> would have liked to start working on solutions for that, we’d like not
> to start from the beginning again. Please note the list of ACTN related
> drafts in TEAS (not to consider the expired ones still submitted as
> draft-xxxxx-actn…)/*

So this sounds like the common refrain from authors who bring what they
feel as mature work to the IETF.  i.e., "This (set of) individual drafts
are mature and both ready for adoption and last call."

It was my understanding that this work was sent by the ADs to TEAS to
ensure that the ACTN work of the last two years is aligned with the TE
work that the IETF has been doing for about the last 15 years. Again I
think we all agree that there are important new capabilities that should
be standardized, but we don't want the expected direction of the work to
 get lost and this is the basis for the name change.

Again, as Pavan said, the name we came up with is not great and we're
open to others.  I think answering my unanswered question would help
identify a better one.

Lou

> 
> */ /*
> 
> http://tools.ietf.org/images/search-small.gif
> <https://www.google.com/search?as_q=%22draft-klee-teas-actn-connectivity-multi-domain-02%22&as_sitesearch=mailarchive.ietf.org/arch/browse/teas/>
> 
> 	
> 
> draft-klee-teas-actn-connectivity-multi-domain
> <http://tools.ietf.org/id/draft-klee-teas-actn-connectivity-multi-domain-02.txt>
> 
> 	
> 
> -02
> <http://tools.ietf.org/html/draft-klee-teas-actn-connectivity-multi-domain-02.txt>
> 
> 			
> 
> 2015-06-08  
> 
> http://tools.ietf.org/images/search-small.gif
> <https://www.google.com/search?as_q=%22draft-kumaki-teas-actn-multitenant-vno-00%22&as_sitesearch=mailarchive.ietf.org/arch/browse/teas/>
> 
> 	
> 
> draft-kumaki-teas-actn-multitenant-vno
> <http://tools.ietf.org/id/draft-kumaki-teas-actn-multitenant-vno-00.txt>
> 
> 	
> 
> -00
> <http://tools.ietf.org/html/draft-kumaki-teas-actn-multitenant-vno-00.txt>
> 
> 			
> 
> 2015-07-06  
> 
> http://tools.ietf.org/images/search-small.gif
> <https://www.google.com/search?as_q=%22draft-lam-teas-usage-info-model-net-topology-01%22&as_sitesearch=mailarchive.ietf.org/arch/browse/teas/>
> 
> 	
> 
> draft-lam-teas-usage-info-model-net-topology
> <http://tools.ietf.org/id/draft-lam-teas-usage-info-model-net-topology-01.txt>
> 
> 	
> 
> -01
> <http://tools.ietf.org/html/draft-lam-teas-usage-info-model-net-topology-01.txt>
> 
> 			
> 
> 2015-07-03  
> 
> http://tools.ietf.org/images/search-small.gif
> <https://www.google.com/search?as_q=%22draft-lee-teas-actn-requirements-01%22&as_sitesearch=mailarchive.ietf.org/arch/browse/teas/>
> 
> 	
> 
> draft-lee-teas-actn-requirements
> <http://tools.ietf.org/id/draft-lee-teas-actn-requirements-01.txt>
> 
> 	
> 
> -01 <http://tools.ietf.org/html/draft-lee-teas-actn-requirements-01.txt>
> 
> 			
> 
> 2015-07-27  
> 
> http://tools.ietf.org/images/search-small.gif
> <https://www.google.com/search?as_q=%22draft-leebelotti-teas-actn-info-00%22&as_sitesearch=mailarchive.ietf.org/arch/browse/teas/>
> 
> 	
> 
> draft-leebelotti-teas-actn-info
> <http://tools.ietf.org/id/draft-leebelotti-teas-actn-info-00.txt>
> 
> 	
> 
> -00 <http://tools.ietf.org/html/draft-leebelotti-teas-actn-info-00.txt>
> 
> 			
> 
> 2015-07-02  
> 
> http://tools.ietf.org/images/search-small.gif
> <https://www.google.com/search?as_q=%22draft-leeking-teas-actn-problem-statement-00%22&as_sitesearch=mailarchive.ietf.org/arch/browse/teas/>
> 
> 	
> 
> draft-leeking-teas-actn-problem-statement
> <http://tools.ietf.org/id/draft-leeking-teas-actn-problem-statement-00.txt>
> 
> 	
> 
> -00
> <http://tools.ietf.org/html/draft-leeking-teas-actn-problem-statement-00.txt>
> 
> 			
> 
> 2015-06-09 
> 
> http://tools.ietf.org/images/search-small.gif
> <https://www.google.com/search?as_q=%22draft-suzuki-teas-actn-multidomain-opc-00%22&as_sitesearch=mailarchive.ietf.org/arch/browse/teas/>
> 
> 	
> 
> draft-suzuki-teas-actn-multidomain-opc
> <http://tools.ietf.org/id/draft-suzuki-teas-actn-multidomain-opc-00.txt>
> 
> 	
> 
> -00
> <http://tools.ietf.org/html/draft-suzuki-teas-actn-multidomain-opc-00.txt>
> 
> 			
> 
> 2015-07-06  
> 
> http://tools.ietf.org/images/search-small.gif
> <https://www.google.com/search?as_q=%22draft-xu-teas-actn-abstract-alarm-report-00%22&as_sitesearch=mailarchive.ietf.org/arch/browse/teas/>
> 
> 	
> 
> draft-xu-teas-actn-abstract-alarm-report
> <http://tools.ietf.org/id/draft-xu-teas-actn-abstract-alarm-report-00.txt>
> 
> 	
> 
> -00
> <http://tools.ietf.org/html/draft-xu-teas-actn-abstract-alarm-report-00.txt>
> 
> 			
> 
> 2015-07-06
> 
> http://tools.ietf.org/images/search-small.gif
> <https://www.google.com/search?as_q=%22draft-ceccarelli-teas-actn-framework-00%22&as_sitesearch=mailarchive.ietf.org/arch/browse/teas/>
> 
> 	
> 
> draft-ceccarelli-teas-actn-framework
> <http://tools.ietf.org/id/draft-ceccarelli-teas-actn-framework-00.txt>
> 
> 	
> 
> -00 <http://tools.ietf.org/html/draft-ceccarelli-teas-actn-framework-00.txt>
> 
> 			
> 
> 2015-06-15  
> 
> */ /*
> 
> */ /*
> 
> Regards,
> 
> -Pavan
> 
>  
> 
> On Fri, Sep 18, 2015 at 3:22 AM, Daniele Ceccarelli
> <[email-masked]
> <mailto:[email-masked]>> wrote:
> 
> Lou,
> 
> Is your concern mostly related to the "transport" word? In the last
> years the concept of transport evolved pretty much, mostly with
> transport SDN and it is no longer tied to the L0-L1 but it covers
> whatever mean used to transport IP. Young already pointed out what the
> draft aims to cover.
> 
> If you're so strongly willing to change the name we could turn
> "Transport" into TE so that it becomes Abstraction and Control of TE
> networks. (this is my personal proposal, not shared by the other
> ACTNers)...and ACTN remains, but with the "broader" scope and it is
> "more" complementary to the interconnected TE.
>> From: Lou Berger [mailto:[email-masked] <mailto:[email-masked]>]
> <mailto:[email-masked]>

---

From: "BELOTTI, SERGIO (SERGIO)" <[email-masked]>
Date: Fri, 18 Sep 2015 14:45:14 +0000

+1 support to Daniele and Eve.
I think Daniele proposal can be a good level of compromise .

In addition:
- Fitting "ACTN" into the "TEAS" body of work:
Work focusing on "how TE networks can be abstracted and managed in a controller(s) driven environment" is an obvious item of interest to the WG. And this is primarily where we believe the "ACTN" work can contribute; the requirements discussed in the document that just got adopted by the WG aligns well with this. The intent behind the name-change was to have something generic enough to capture what we want this work to be about. Note that this is just a requirements document and since this is the first document to be adopted in this realm, it is important to get the "naming" right now rather than later. "VN Controller" is perhaps not a great choice -- very much open to other choices that would capture the essence of the first statement above.
During Dallas meeting, it was clearly asked in the ACTN discussion , what WG thought about ACTN work and how ACTN (not VC or VC-controller or something else) can fit to TEAS working group objective and scope. The answer of the audience was clearly , support of ACTN work into the TEAS WG, and so we do not need NOW, to discuss where the “ACTN” work can or cannot contribute. ACTN was clearly explained , and the decision of WG was related to that type of work , not towards another intent , larger or smaller this can be.

Thanks
sergio

From: Varma, Eve L (Eve) [mailto:[email-masked]]
Sent: venerdì 18 settembre 2015 14:57
To: Daniele Ceccarelli; Vishnu Pavan Beeram
Cc: Doolan, Paul (Coriant - US/Irving); Lou Berger; [email-masked]; TEAS WG
Subject: RE: [Teas] Poll on draft-lee-teas-actn-requirements-01 a WG documents

Dear all,

Bes regards,
Eve

From: Teas [mailto:[email-masked]] On Behalf Of Daniele Ceccarelli
Sent: Friday, September 18, 2015 8:38 AM
To: Vishnu Pavan Beeram
Cc: Doolan, Paul (Coriant - US/Irving); Lou Berger; [email-masked]<mailto:[email-masked]>; TEAS WG
Subject: Re: [Teas] Poll on draft-lee-teas-actn-requirements-01 a WG documents

Pavan,

Please see inline.

BR
Daniele

2015-06-08

2015-07-06

2015-07-03

2015-07-27

2015-07-02

2015-06-09

2015-07-06

2015-07-06

2015-06-15

Regards,
-Pavan

Daniele

---

From: Lou Berger <[email-masked]>
Date: Fri, 18 Sep 2015 10:55:30 -0400

On 09/18/2015 08:56 AM, Varma, Eve L (Eve) wrote:
> Dear all,
> 
>  
> 
> I must agree with Daniele’s points.   In reviewing the inputs re
> draft-lee-teas-actn-requirements becoming a WG document, which resulted
> in its adoption as such, I don’t recall any inputs other than “Support”;
>  I didn’t see “Support, but clarify….” or “Support, but change….”  Given
> this, I am truly surprised at the discussion that has now arisen.

Eve,

See my last message.  The comments were made in Pargue (publicly and
expanded upon privately), and I had a discussion with the Authors via
e-mail during the adoption period  -- in this brief e-mail exchange I
indicated that I decided to not impede adoption as I believe the current
contents of the document is a great starting point for the WG.

I specifically didn't want the discussion on what is basically how the
"ACTN" *solution* fits in with the rest of IETF TE to impede the
adoption of what is essentially a generic TE requirements document.

> While I have no real issue in changing Transport to TE in the document
> title to move this forward, though I don’t see the issue with using the
> term Transport (which hasn’t been considered solely L0/L1 for a long
> time), I hope that the authors would be able to move forward quickly to
> publish as a WG draft with essentially the same title.

Changing the title is not yet on the table and would not occur in the
-00 rev of the document.

Lou

> 
>  
> 
> Bes regards,
> 
> Eve
> 
>  
> 
> *From:*Teas [mailto:[email-masked]] *On Behalf Of *Daniele Ceccarelli
> *Sent:* Friday, September 18, 2015 8:38 AM
> *To:* Vishnu Pavan Beeram
> *Cc:* Doolan, Paul (Coriant - US/Irving); Lou Berger;
> <mailto:[email-masked]>; TEAS WG
> change its scope. The authors are interested in writing ACTN
> requirements, which not only is a subset of what the chairs ask for but
> for Y. In 2 years we have put together use cases, an architecture and

---

From: Lou Berger <[email-masked]>
Date: Fri, 18 Sep 2015 11:24:25 -0400

> I think Daniele proposal can be a good level of compromise .

I agree that replacing "Transport Networks" with "TE Networks" is
definitely a very good change, and certainly readily understandable from
the TEAS WG context.

Now on to the AC part.  Fundamentally we're trying to capture what's new
in the requirements documented in the draft.  Abstraction and Control
are both things supported by today's standards, so what's new from the
requirements perspective? I have to say even reading the PS draft, it
wasn't immediately obvious. We've stated in other messages our view. It
would be great to get some better options on the table.

Thanks,
Lou

> During Dallas meeting, it was clearly asked in the ACTN discussion ,
> what WG thought about ACTN work and how ACTN (not VC or VC-controller or
> something else) can fit to TEAS working group objective and scope. The
> answer of the audience was clearly , support of ACTN work into the TEAS
> WG, and so we do not need NOW, to discuss where the “ACTN” work can or
> cannot contribute. ACTN was clearly explained , and the decision of WG
> was related to that type of work , not towards another intent , larger
> or smaller this can be.
> 
>  
> 
> Thanks
> 
> sergio
> 
>  
> 
>  
> 
>  
> 
> *From:*Varma, Eve L (Eve) [mailto:[email-masked]]
> *Sent:* venerdì 18 settembre 2015 14:57
> *To:* Daniele Ceccarelli; Vishnu Pavan Beeram
> *Subject:* RE: [Teas] Poll on draft-lee-teas-actn-requirements-01 a WG
> documents
> 
>  
> 
> Dear all,
> 
>  
>

---

From: "Doolan, Paul (Coriant - US/Irving)" <[email-masked]>
Date: Fri, 18 Sep 2015 15:33:59 +0000

Hi Lou,

> The comments were made in Pargue (publicly

So that we're all on the same page (Eve wasn't at the Prague meeting), what you are recorded in the minutes as having said with respect to draft-lee-teas-actn-requirements-01 is:

Lou Berger: A good start on requirements, and notable section on impact
          on YANG but this section needs further development. I would also like
          to see more discussion on future requirements. For adoption, I think we
          need to polish the aforementioned sections.
Which is fine by me but does IMO qualify as advance warning of your current position. No "oh and by the way change the title" for example.

pd

---

From: Leeyoung <[email-masked]>
Date: Fri, 18 Sep 2015 15:43:08 +0000

Hi Lou and Pavan

I think Transport to TE is a good compromise. I personally support that idea. In regards to the content of the requirements in the current draft, the WG reached a consensus that this draft is a good start and expressed their opinion through the poll. There is no reason to debate again the legitimacy of the content of the requirements, which were based on numerous use-cases from the operators, identifying the gaps and issues.  

I can go ahead to change with no change of the draft title (actn), but I can change what ACTN stands for from Abstraction and Control of Transport Network to Abstraction and Control of TE Network. 

If this is fine, we can move ahead. 

Thanks.
Young

-----Original Message-----
From: Lou Berger [mailto:[email-masked]] 
Sent: Friday, September 18, 2015 10:24 AM
To: BELOTTI, SERGIO (SERGIO); Varma, Eve L (Eve); Daniele Ceccarelli; Vishnu Pavan Beeram
Cc: Doolan, Paul (Coriant - US/Irving); [email-masked]; TEAS WG
Subject: Re: [Teas] Poll on draft-lee-teas-actn-requirements-01 a WG documents

> I think Daniele proposal can be a good level of compromise .

I agree that replacing "Transport Networks" with "TE Networks" is definitely a very good change, and certainly readily understandable from the TEAS WG context.

Now on to the AC part.  Fundamentally we're trying to capture what's new in the requirements documented in the draft.  Abstraction and Control are both things supported by today's standards, so what's new from the requirements perspective? I have to say even reading the PS draft, it wasn't immediately obvious. We've stated in other messages our view. It would be great to get some better options on the table.

Thanks,
Lou

> controller(s) driven environment" is an obvious item of interest to 
> the WG. And this is primarily where we believe the "ACTN" work can 
> name-change was to have something generic enough to capture what we 
> want this work to be about. Note that this is just a requirements 
> document and since this is the first document to be adopted in this 
> realm, it is important to get the "naming" right now rather than 
> later. "VN Controller" is perhaps not a great choice -- very much open 
> to other choices that would capture the essence of the first statement above.
> 
> what WG thought about ACTN work and how ACTN (not VC or VC-controller 
> or something else) can fit to TEAS working group objective and scope. 
> The answer of the audience was clearly , support of ACTN work into the 
> TEAS WG, and so we do not need NOW, to discuss where the “ACTN” work 
> can or cannot contribute. ACTN was clearly explained , and the 
> decision of WG was related to that type of work , not towards another 
> intent , larger or smaller this can be.
> 
>  
> 
> Thanks
> 
> sergio
> 
>  
> 
>  
> 
>  
> 
> draft-lee-teas-actn-requirements becoming a WG document, which 
> resulted in its adoption as such, I don’t recall any inputs other than 
> “Support”;  I didn’t see “Support, but clarify….” or “Support, but 
> change….”  Given this, I am truly surprised at the discussion that has now arisen.
> 
>  
> 
> title to move this forward, though I don’t see the issue with using 
> the term Transport (which hasn’t been considered solely L0/L1 for a 
> long time), I hope that the authors would be able to move forward 
> quickly to publish as a WG draft with essentially the same title.
> 
>  
> 
> Bes regards,
> 
> Eve
> 
>  
> 
> controller(s) driven environment" is an obvious item of interest to 
> the WG. And this is primarily where we believe the "ACTN" work can 
> name-change was to have something generic enough to capture what we 
> want this work to be about. Note that this is just a requirements 
> document and since this is the first document to be adopted in this 
> realm, it is important to get the "naming" right now rather than 
> later. "VN Controller" is perhaps not a great choice -- very much open 
> to other choices that would capture the essence of the first statement above.
> 
> */[DanCe] The IETF is contribution driven. If the WG contributed a 
> draft related to a subset of what the chairs expect, it means that 
> there is interest just in that subset. If the chairs wanted something 
> generic enough they should have asked for a document generic enough 
> (before the wg adoption), not call for the adoption of a document and 
> then ask to change its scope. The authors are interested in writing 
> ACTN requirements, which not only is a subset of what the chairs ask 
> for but is also slightly different since we’re not speaking just about 
> nodes and links. /*
> 
> 
> TE networks in support of end-to-end TE path establishment. It 
> discusses in great detail the notion of "abstraction in TE networks". 
> Our sincere hope (belief rather) is that the <actn-requirements> 
> document (and other <actn> related documents that get adopted by the 
> WG) would be complementary to (/consistent with) the 
> */[DanCe] What does complementary mean? Complementary in the sense 
> that interconnected TE is for multi-domain LSP establishment in 
> distributed control plane and ACTN does the same for centralized one? 
> ACTN has a broader scope. The multi domain and multi layer part can be 
> seen as complimentary, but again ACTN is not just nodes and links, it 
> includes services, VNF, network slices and so on./*
> 
> 
> (Danielle's latest suggestion - use "TE" in the ACTN acronym - is 
> pretty close to what I personally would like it to be), but it is 
> important to get some clarity on this "scoping" detail before zeroing in on any "name".
> 
> of X and now they are requested to publish the draft as a starting 
> point for Y. In 2 years we have put together use cases, an 
> architecture and would have liked to start working on solutions for 
> that, we’d like not to start from the beginning again. Please note the 
> list of ACTN related drafts in TEAS (not to consider the expired ones 
> still submitted as
> draft-xxxxx-actn…)/*
> 
> */ /*
> 
> <https://www.google.com/search?as_q=%22draft-klee-teas-actn-connectivi
> ty-multi-domain-02%22&as_sitesearch=mailarchive.ietf.org/arch/browse/t
> eas/>
> 
> 	
> 
> <https://www.google.com/search?as_q=%22draft-kumaki-teas-actn-multiten
> ant-vno-00%22&as_sitesearch=mailarchive.ietf.org/arch/browse/teas/>
> 
> 	
> 
> <https://www.google.com/search?as_q=%22draft-lam-teas-usage-info-model
> -net-topology-01%22&as_sitesearch=mailarchive.ietf.org/arch/browse/tea
> s/>
> 
> 	
> 
> <https://www.google.com/search?as_q=%22draft-lee-teas-actn-requirement
> s-01%22&as_sitesearch=mailarchive.ietf.org/arch/browse/teas/>
> 
> 	
> 
> <http://tools.ietf.org/html/draft-lee-teas-actn-requirements-01.txt>
> 
> 			
> 
> 2015-07-27
> 
> <https://www.google.com/search?as_q=%22draft-leebelotti-teas-actn-info
> -00%22&as_sitesearch=mailarchive.ietf.org/arch/browse/teas/>
> 
> 	
> 
> <http://tools.ietf.org/html/draft-leebelotti-teas-actn-info-00.txt>
> 
> 			
> 
> 2015-07-02
> 
> <https://www.google.com/search?as_q=%22draft-leeking-teas-actn-problem
> -statement-00%22&as_sitesearch=mailarchive.ietf.org/arch/browse/teas/>
> 
> 	
> 
> <https://www.google.com/search?as_q=%22draft-suzuki-teas-actn-multidom
> ain-opc-00%22&as_sitesearch=mailarchive.ietf.org/arch/browse/teas/>
> 
> 	
> 
> <https://www.google.com/search?as_q=%22draft-xu-teas-actn-abstract-ala
> rm-report-00%22&as_sitesearch=mailarchive.ietf.org/arch/browse/teas/>
> 
> 	
> 
> <https://www.google.com/search?as_q=%22draft-ceccarelli-teas-actn-fram
> ework-00%22&as_sitesearch=mailarchive.ietf.org/arch/browse/teas/>
> 
> 	
> 
> <http://tools.ietf.org/html/draft-ceccarelli-teas-actn-framework-00.tx
> t>
> 
> 			
> 
> 2015-06-15
> 
> */ /*
> 
> */ /*
> 
> Regards,
> 
> -Pavan
> 
>  
> 
>> > this instruction to change ACTN to VN-Controller seems a little 
>> > high
>> handed.
>>
>> I/we hear you. But...
>>
>> on this and creating mind share and name recognition for ACTN. I know 
>> what it stands for as do audiences around the world to whom the team 
>> have introduced the idea and from whom they have garnered support.
>>
>> That's fair, but from our perspective the IETF has been working TE a 
>> lot longer than the term ACTN has been around, and that is the 
>> context where this work fits.
>>
>> requirements apply quite broadly and that is what we (the chairs) 
>> want to make clear by the name change.
>>
>> other changes to the draft' since, at the very least, the (new) title 
>> needs explanation.
>>
>> have changed names in the past and been right and sometimes wrong, 
>> but in the end we have an RFC published with the title that 
>> represents WG consensus and an RFC number.
>>
>> to change the name then coming back to the WG with a clearly 
>> articulated rationale and asking for its support would seem to me to 
>> be a more inclusive way to do things.
>>
>> >> and covering the various possible controller-based TE models  
>> >> (where the previous work was more focused on fully distributed control models).
>> >> So we think a broader name warranted.
>> >>

---

From: Leeyoung <[email-masked]>
Date: Fri, 18 Sep 2015 15:51:06 +0000

Igor,

Good point. I express the support of this idea. You explained very well. 

Thanks.
Young

-----Original Message-----
From: Igor Bryskin [mailto:[email-masked]] 
Sent: Friday, September 18, 2015 8:04 AM
To: Daniele Ceccarelli; Lou Berger; Doolan, Paul (Coriant - US/Irving)
Cc: [email-masked]; TEAS WG
Subject: RE: [Teas] Poll on draft-lee-teas-actn-requirements-01 a WG documents

Daniele,

Regards,
Igor

-----Original Message-----
From: Teas [mailto:[email-masked]] On Behalf Of Daniele Ceccarelli
Sent: Friday, September 18, 2015 3:23 AM
To: Lou Berger <[email-masked]>; Doolan, Paul (Coriant - US/Irving) <[email-masked]>
Cc: [email-masked]; TEAS WG <[email-masked]>
Subject: Re: [Teas] Poll on draft-lee-teas-actn-requirements-01 a WG documents

Lou,

Daniele

> lot longer than the term ACTN has been around, and that is the context 
> where this work fits.
> 
> >> covering the various possible controller-based TE models  (where 
> >> the previous work was more focused on fully distributed control models).

---

From: Lou Berger <[email-masked]>
Date: Fri, 18 Sep 2015 12:36:22 -0400

Paul,

>           need to polish the aforementioned sections.
Also stated as related to this draft and the framework : 

         Lou Berger: Understanding what the protocol extension requirements are
          would be very helpful. The interconnected-te document went through a
          similar process. Please look to focus your document in the context of
          technologies that we have available, and its ok to have "this piece
          is missing".
          Daniele: Is it ok to keep that discussion (gap analysis) in this document?
          Lou Berger: Yes
          Young Lee: The document was intended to be used as a framework with
          functional components. Is it ok?
          Lou Berger: Yes, this is a complimentary to the interconnected-te
          document. Please authors, consider the previous comment and see if you
          can update the document.

The minutes actually are  unfortunately a bit sparse (and the recording
of the chairs mic is really poor) and I did mention that this would come
up in the context of adoption.  Particularly missing was the discussion
on the work being an addition/complement to existing work by covering
"logically centralized" TE solutions.   Both Daniele and Young seems to
agree with these points. 

If anyone feels up to listening to the minutes and updating the minutes
that would be great.

Audio is at
https://www.ietf.org/audio/ietf93/ietf93-congresshalli-20150722-1300.mp3
and edits can be made to
http://tools.ietf.org/wg/teas/minutes?item=minutes-93-teas.html and we
can get the official minutes corrected from there.

> Which is fine by me but does IMO qualify as advance warning of your current position. No "oh and by the way change the title" for example.
The title isn't being change, the file name is. 

Lou

>>> needs

---

From: Leeyoung <[email-masked]>
Date: Fri, 18 Sep 2015 16:47:21 +0000

Hi Lou,

Actually this is meeting minutes on the ACTN Framework draft presentation and we agreed to include some gap analysis of some type. 
We will come up with that topic in the upcoming revision on this. I thought you are going to poll the framework draft soon. 

In regards to the requirements draft, what Paul is quoting is correct and the current requirement draft incorporated your comments on impact on YANG and others. 

Thanks.
Young

-----Original Message-----
From: Lou Berger [mailto:[email-masked]] 
Sent: Friday, September 18, 2015 11:36 AM
To: Doolan, Paul (Coriant - US/Irving)
Cc: Varma, Eve L (Eve); Daniele Ceccarelli; Vishnu Pavan Beeram; [email-masked]; TEAS WG
Subject: Re: [Teas] Poll on draft-lee-teas-actn-requirements-01 a WG documents

Paul,

Audio is at

Lou

>>> I must agree with Daniele's points.   In reviewing the inputs re
>>> in its adoption as such, I don't recall any inputs other than "Support";
>>> I didn't see "Support, but clarify.." or "Support, but change.."  Given
>>> title to move this forward, though I don't see the issue with using the
>>> term Transport (which hasn't been considered solely L0/L1 for a long
>>> is also slightly different since we're not speaking just about nodes and
>>> links. /*
>>>
>>>
>>> would have liked to start working on solutions for that, we'd like not
>>> draft-xxxxx-actn.)/*

---

From: Lou Berger <[email-masked]>
Date: Fri, 18 Sep 2015 13:44:06 -0400

Young,

Daniele closed his slides by talking about overall status.  So the
comments were both about the document and more general.  I listened to
the (painful) audio and added a few more notes:
see
http://etherpad.tools.ietf.org:9000/p/notes-ietf-93-teas?useMonospaceFont=true

also perhaps you can answer the following:

or said another way:

- Abstraction and Control are both things supported by today's
standards, so what's new from the
requirements perspective?

Thanks,
Lou

---

From: Leeyoung <[email-masked]>
Date: Fri, 18 Sep 2015 18:47:21 +0000

Hi Lou,

The content of the ACTN requirement draft is what we are going to continue to refine. As you indicated during the last meeting, we have already sections to discuss what can be done with existing work and what may not. Of course, this discussion will need to be refined to determine if any new solution would be warranted or not. I believe your concern has been addressed already in the current requirement draft at least as a beginning point and we will have ample opportunity to refine this with WG discussions and meetings. 

With that, if this is fine with you, we can update the draft and move on. 

Thanks.
Young

-----Original Message-----
From: Lou Berger [mailto:[email-masked]] 
Sent: Friday, September 18, 2015 12:44 PM
To: Leeyoung; Doolan, Paul (Coriant - US/Irving)
Cc: Varma, Eve L (Eve); Daniele Ceccarelli; Vishnu Pavan Beeram; [email-masked]; TEAS WG
Subject: Re: [Teas] Poll on draft-lee-teas-actn-requirements-01 a WG documents

Young,

Daniele closed his slides by talking about overall status.  So the comments were both about the document and more general.  I listened to the (painful) audio and added a few more notes:
see
http://etherpad.tools.ietf.org:9000/p/notes-ietf-93-teas?useMonospaceFont=true

or said another way:

- Abstraction and Control are both things supported by today's standards, so what's new from the requirements perspective?

Thanks,
Lou
On 9/18/2015 12:47 PM, Leeyoung wrote:
> Cc: Varma, Eve L (Eve); Daniele Ceccarelli; Vishnu Pavan Beeram; 
> The minutes actually are  unfortunately a bit sparse (and the 
> recording of the chairs mic is really poor) and I did mention that 
> this would come up in the context of adoption.  Particularly missing 
> was the discussion on the work being an addition/complement to existing work by covering
> If anyone feels up to listening to the minutes and updating the 
> minutes that would be great.
>
> Audio is at
>>>> resulted in its adoption as such, I don't recall any inputs other 
>>>> than "Support"; I didn't see "Support, but clarify.." or "Support, 
>>>> but change.."  Given this, I am truly surprised at the discussion that has now arisen.
>>> Eve,
>>>
>>> expanded upon privately), and I had a discussion with the Authors 
>>> via e-mail during the adoption period  -- in this brief e-mail 
>>> exchange I indicated that I decided to not impede adoption as I 
>>> believe the current contents of the document is a great starting point for the WG.
>>>
>>> I specifically didn't want the discussion on what is basically how 
>>> the "ACTN" *solution* fits in with the rest of IETF TE to impede the 
>>>> While I have no real issue in changing Transport to TE in the 
>>>> document title to move this forward, though I don't see the issue 
>>>> with using the term Transport (which hasn't been considered solely 
>>>> L0/L1 for a long time), I hope that the authors would be able to 
>>>> move forward quickly to publish as a WG draft with essentially the same title.
>>> Changing the title is not yet on the table and would not occur in 
>>> the -00 rev of the document.
>>>
>>> Lou
>>>
>>>>
>>>> Bes regards,
>>>>
>>>> Eve
>>>>
>>>>
>>>>
>>>> *Subject:* Re: [Teas] Poll on draft-lee-teas-actn-requirements-01 a 
>>>> WG documents
>>>>
>>>>
>>>>
>>>> Pavan,
>>>>
>>>>
>>>>
>>>> Please see inline.
>>>>
>>>>
>>>>
>>>> BR
>>>> Daniele
>>>>
>>>>
>>>>
>>>> *Subject:* Re: [Teas] Poll on draft-lee-teas-actn-requirements-01 a 
>>>> WG documents
>>>>
>>>>
>>>>
>>>> contribute; the requirements discussed in the document that just 
>>>> got adopted by the WG aligns well with this. The intent behind the 
>>>> later. "VN Controller" is perhaps not a great choice -- very much 
>>>> open to other choices that would capture the essence of the first statement above.
>>>>
>>>> there is interest just in that subset. If the chairs wanted 
>>>> something generic enough they should have asked for a document 
>>>> generic enough (before the wg adoption), not call for the adoption 
>>>> of a document and then ask to change its scope. The authors are 
>>>> interested in writing ACTN requirements, which not only is a subset 
>>>> of what the chairs ask for but is also slightly different since 
>>>> we're not speaking just about nodes and links. /*
>>>>
>>>>
>>>> architecture for the exchange of TE information between 
>>>> interconnected TE networks in support of end-to-end TE path 
>>>> establishment. It discusses in great detail the notion of 
>>>> "abstraction in TE networks". Our sincere hope (belief rather) is 
>>>> that the <actn-requirements> document (and other <actn> related 
>>>> documents that get adopted by the WG) would be complementary to 
>>>> distributed control plane and ACTN does the same for centralized 
>>>> one? ACTN has a broader scope. The multi domain and multi layer 
>>>> part can be seen as complimentary, but again ACTN is not just nodes 
>>>> and links, it includes services, VNF, network slices and so on./*
>>>>
>>>>
>>>> One train of thought is to use this new work (conveniently 
>>>> facilitated by the induction of ACTN into TEAS) to focus solely on the "controller"
>>>> aspects (given the belief that non-controller aspects are 
>>>> adequately covered by existing solutions). Personally, I don't have 
>>>> a strong preference on whether the "naming" should reflect this or 
>>>> not (Danielle's latest suggestion - use "TE" in the ACTN acronym - 
>>>> is pretty close to what I personally would like it to be), but it 
>>>> is important to get some clarity on this "scoping" detail before zeroing in on any "name".
>>>>
>>>> */[DanCe] The scoping should have been made clear before the call 
>>>> for adoption. The authors scoped the draft as X and asked for the 
>>>> adoption of X and now they are requested to publish the draft as a 
>>>> starting point for Y. In 2 years we have put together use cases, an 
>>>> that, we'd like not to start from the beginning again. Please note 
>>>> the list of ACTN related drafts in TEAS (not to consider the 
>>>> expired ones still submitted as
>>>> draft-xxxxx-actn.)/*
>>>>
>>>> */ /*
>>>>
>>>> <https://www.google.com/search?as_q=%22draft-klee-teas-actn-connect
>>>> ivity-multi-domain-02%22&as_sitesearch=mailarchive.ietf.org/arch/br
>>>> owse/teas/>
>>>>
>>>> 	
>>>>
>>>> <https://www.google.com/search?as_q=%22draft-kumaki-teas-actn-multi
>>>> tenant-vno-00%22&as_sitesearch=mailarchive.ietf.org/arch/browse/tea
>>>> s/>
>>>>
>>>> 	
>>>>
>>>> <https://www.google.com/search?as_q=%22draft-lam-teas-usage-info-mo
>>>> del-net-topology-01%22&as_sitesearch=mailarchive.ietf.org/arch/brow
>>>> se/teas/>
>>>>
>>>> 	
>>>>
>>>> <https://www.google.com/search?as_q=%22draft-lee-teas-actn-requirem
>>>> ents-01%22&as_sitesearch=mailarchive.ietf.org/arch/browse/teas/>
>>>>
>>>> 	
>>>>
>>>> <http://tools.ietf.org/html/draft-lee-teas-actn-requirements-01.txt
>>>> >
>>>>
>>>> 			
>>>>
>>>> 2015-07-27
>>>>
>>>> <https://www.google.com/search?as_q=%22draft-leebelotti-teas-actn-i
>>>> nfo-00%22&as_sitesearch=mailarchive.ietf.org/arch/browse/teas/>
>>>>
>>>> 	
>>>>
>>>> <https://www.google.com/search?as_q=%22draft-leeking-teas-actn-prob
>>>> lem-statement-00%22&as_sitesearch=mailarchive.ietf.org/arch/browse/
>>>> teas/>
>>>>
>>>> 	
>>>>
>>>> <https://www.google.com/search?as_q=%22draft-suzuki-teas-actn-multi
>>>> domain-opc-00%22&as_sitesearch=mailarchive.ietf.org/arch/browse/tea
>>>> s/>
>>>>
>>>> 	
>>>>
>>>> <https://www.google.com/search?as_q=%22draft-xu-teas-actn-abstract-
>>>> alarm-report-00%22&as_sitesearch=mailarchive.ietf.org/arch/browse/t
>>>> eas/>
>>>>
>>>> 	
>>>>
>>>> <https://www.google.com/search?as_q=%22draft-ceccarelli-teas-actn-f
>>>> ramework-00%22&as_sitesearch=mailarchive.ietf.org/arch/browse/teas/
>>>> >
>>>>
>>>> 	
>>>>
>>>> <http://tools.ietf.org/html/draft-ceccarelli-teas-actn-framework-00
>>>> .txt>
>>>>
>>>> 			
>>>>
>>>> 2015-06-15
>>>>
>>>> */ /*
>>>>
>>>> */ /*
>>>>
>>>> Regards,
>>>>
>>>> -Pavan
>>>>
>>>>
>>>>
>>>> whatever mean used to transport IP. Young already pointed out what 
>>>> the draft aims to cover.
>>>>
>>>> "Transport" into TE so that it becomes Abstraction and Control of 
>>>> TE networks. (this is my personal proposal, not shared by the other 
>>>>> on this and creating mind share and name recognition for ACTN. I 
>>>>> know what it stands for as do audiences around the world to whom 
>>>>> the team have introduced the idea and from whom they have garnered support.
>>>>>
>>>>> That's fair, but from our perspective the IETF has been working TE 
>>>>> a lot longer than the term ACTN has been around, and that is the 
>>>>> Right now, we (the WG) are just at the requirements stage and 
>>>>> those requirements apply quite broadly and that is what we (the 
>>>>> chairs) want to make clear by the name change.
>>>>>
>>>>>> In contrast I have absolutely no idea what a vn-controller 
>>>>>> requirements draft might be about and, if you persist with this 
>>>>>> renaming, it clearly makes no sense to make 'no
>>>>> work will end up based on the WG consensus process.  Chairs have 
>>>>> changed names in the past and been right and sometimes wrong, but 
>>>>> in the end we have an RFC published with the title that represents 
>>>>> WG consensus and an RFC number.
>>>>>
>>>>>> I really think the draft should be adopted as (originally) named. 
>>>>>> If
>>>> you want
>>>>> articulated rationale and asking for its support would seem to me 
>>>>> to be a more
>>>> inclusive
>>>>> way to do things.
>>>>>
>>>>>>> Comments received (publicly and privately) should be discussed 
>>>>>>> and addresses in the -01 version.
>>>>>>>
>>>>>>> to its current form and where we expect it to  go.  In 
>>>>>>> particular, we see this draft as a companion to the 
>>>>>>> 'interconnected-te' work and covering the various possible 
>>>>>>> controller-based TE models  (where the previous work was more focused on fully distributed control models).
>>>>>>>> Please send email to the list indicating "yes/support" or 
>>>>>>>> "no/do not support". If indicating no, please state your 
>>>>>>>> technical reservations with the document.  If yes, please also 
>>>>>>>> feel free to provide comments you'd like to see addressed once 
>>>>>>>> the document is a WG
>>>>> document.

---

From: Igor Bryskin <[email-masked]>
Date: Fri, 18 Sep 2015 18:51:58 +0000

Hi Lou,
You asked:

First, I think that at this stage it is a bit too late to ask questions like this, isn't it?
Second, I'd leave for the designers of the ACTN to answer this. My personal answer would be this:
Luyuan was talking about the need of interconnecting millions of MSFT servers. How do you describe a transport network capable of doing that? One solution is via hierarchical abstraction of numerous TE domains provided by multiple providers. Please, correct me if I am wrong, but I am not aware of any IETF documents setting requirements for said abstracted hierarchical TE networks: presentation, features, re-configuration capabilities, models, etc. Nor I am aware of any architecture or framework describing what exactly operators and/or SDN controllers/applications can do with such networks, in particular how they can orchestrate end-to-end transport services, manipulate and monitor them, place them with sufficient diversity from each other, etc. How they can perform capacity analysis of said networks and other network planning functions? How they convey policies wrt various transport behaviors and profiles? This kind of things IMO need to be addressed under the ACTN umbrella.

Regards,
igor

-----Original Message-----
From: Teas [mailto:[email-masked]] On Behalf Of Lou Berger
Sent: Friday, September 18, 2015 1:44 PM
To: Leeyoung <[email-masked]>; Doolan, Paul (Coriant - US/Irving) <[email-masked]>
Cc: [email-masked]; TEAS WG <[email-masked]>; Daniele Ceccarelli <[email-masked]>; Varma, Eve L (Eve) <[email-masked]>; Vishnu Pavan Beeram <[email-masked]>
Subject: Re: [Teas] Poll on draft-lee-teas-actn-requirements-01 a WG documents

Young,

or said another way:

Thanks,
Lou

---

From: Lou Berger <[email-masked]>
Date: Fri, 18 Sep 2015 15:37:07 -0400

Igor,

> First, I think that at this stage it is a bit too late to ask questions like this, isn't it?
So the new part of ACTN (WRT TEAS) identified/discussed/seemingly agreed
to in Prague was the support for a "logically centralized" control
model.  -- more on this later.

My question here, really was more limited than ACTN as a whole but
really the requirements documents.  The core requirements say nothing
about distributed or "logically centralized" control models and the only
place it shows is by inference in the interfaces section.  So the
question is an honest one, and I appreciate you being the 1st at taking
a stab at responding to it.

> Luyuan was talking about the need of interconnecting millions of MSFT servers. How do you describe a transport network capable of doing that? One solution is via hierarchical abstraction of numerou…

This is all goodness and also the closest I've seen to a succinct
definition of what's new in ACTN.  Perhaps it can serve as the
foundation of a short paragraph defining what it is for inclusion in the
intro of -01 of the WG draft.

Your answer is much broader than the above definition ("logically
centralized" control model), which is fine, but also highlights a bit
why we're trying to frame the work now as it is being formally brought
into the WG.

Thanks,
Lou

---

From: Zhenghaomian <[email-masked]>
Date: Sat, 19 Sep 2015 05:52:22 +0000

Hi, Lou and Igor,

Nice discussion for clarifying what is new requirement for ACTN. The authors may have more comments on specifying that. I tried to share my point here. 

I like the idea ACTN is an umbrella that contains a wide range of work. The draft will definitely be polished later (as a WG draft) and the scope will become clear by carefully understanding what requirement is in the ACTN scope and what is not. This is necessary and just the reason why we consider it as 'ACTN requirement' draft. If you say there is different understanding with ACTN scope or the current scope is not clear enough, I would like to agree and will be open for discussion; however if you think the 'ACTN' should be equivalent to 'complementary TE-interconnected info-exchange work', that is misunderstanding. I don't think this is the motivation/objective for ACTN authors. ACTN, as an umbrella, should be proper to have its requirement, use case, framework and other drafts with its name, that is different from 'complementary TE-interconnected work', so it should be fine to keep the actn term in name abbreviation. 

For the distributed or 'logical centralized' control models, my opinion is model is something solution related rather than requirement, and can be included in framework. 

Thanks a lot.

Best wishes,
Haomian

-----邮件原件-----
发件人: Teas [mailto:[email-masked]] 代表 Lou Berger
发送时间: 2015年9月19日 3:37
收件人: Igor Bryskin; Leeyoung; Doolan, Paul (Coriant - US/Irving)
抄送: TEAS WG; Daniele Ceccarelli; Vishnu Pavan Beeram; Varma, Eve L (Eve); [email-masked]
主题: Re: [Teas] Poll on draft-lee-teas-actn-requirements-01 a WG documents

Igor,

> First, I think that at this stage it is a bit too late to ask questions like this, isn't it?
So the new part of ACTN (WRT TEAS) identified/discussed/seemingly agreed to in Prague was the support for a "logically centralized" control model.  -- more on this later.

My question here, really was more limited than ACTN as a whole but really the requirements documents.  The core requirements say nothing about distributed or "logically centralized" control models and the only place it shows is by inference in the interfaces section.  So the question is an honest one, and I appreciate you being the 1st at taking a stab at responding to it.

> Luyuan was talking about the need of interconnecting millions of MSFT servers. How do you describe a transport network capable of doing that? One solution is via hierarchical abstraction of numerou…

This is all goodness and also the closest I've seen to a succinct definition of what's new in ACTN.  Perhaps it can serve as the foundation of a short paragraph defining what it is for inclusion in the intro of -01 of the WG draft.

Your answer is much broader than the above definition ("logically centralized" control model), which is fine, but also highlights a bit why we're trying to frame the work now as it is being formally brought into the WG.

Thanks,
Lou
> <[email-masked]>; Daniele Ceccarelli <[email-masked]>; 
> Varma, Eve L (Eve) <[email-masked]>; Vishnu Pavan Beeram 
> <[email-masked]>
>> https://www.ietf.org/audio/ietf93/ietf93-congresshalli-20150722-1300.
>> m
>> p3
>> and edits can be made to
>> http://tools.ietf.org/wg/teas/minutes?item=minutes-93-teas.html and 
>> we can get the official minutes corrected from there.
>>
>>
>>>> See my last message.  The comments were made in Pargue (publicly 
>>>> and expanded upon privately), and I had a discussion with the 
>>>> Authors via e-mail during the adoption period  -- in this brief 
>>>> e-mail exchange I indicated that I decided to not impede adoption 
>>>> as I believe the current contents of the document is a great starting point for the WG.
>>>>
>>>> the "ACTN" *solution* fits in with the rest of IETF TE to impede 
>>>> the adoption of what is essentially a generic TE requirements document.
>>>>
>>>>> *Subject:* Re: [Teas] Poll on draft-lee-teas-actn-requirements-01 
>>>>> a WG documents
>>>>>
>>>>>
>>>>>
>>>>> Pavan,
>>>>>
>>>>>
>>>>>
>>>>> Please see inline.
>>>>>
>>>>>
>>>>>
>>>>> BR
>>>>> Daniele
>>>>>
>>>>>
>>>>>
>>>>> *Subject:* Re: [Teas] Poll on draft-lee-teas-actn-requirements-01 
>>>>> a WG documents
>>>>>
>>>>>
>>>>>
>>>>> controller(s) driven environment" is an obvious item of interest 
>>>>> to the WG. And this is primarily where we believe the "ACTN" work 
>>>>> can contribute; the requirements discussed in the document that 
>>>>> just got adopted by the WG aligns well with this. The intent 
>>>>> behind the name-change was to have something generic enough to 
>>>>> capture what we want this work to be about. Note that this is just 
>>>>> a requirements document and since this is the first document to be 
>>>>> adopted in this realm, it is important to get the "naming" right 
>>>>> now rather than later. "VN Controller" is perhaps not a great 
>>>>> choice -- very much open to other choices that would capture the essence of the first statement above.
>>>>>
>>>>> interested in writing ACTN requirements, which not only is a 
>>>>> subset of what the chairs ask for but is also slightly different 
>>>>> since we're not speaking just about nodes and links. /*
>>>>>
>>>>>
>>>>> part can be seen as complimentary, but again ACTN is not just 
>>>>> nodes and links, it includes services, VNF, network slices and so 
>>>>> on./*
>>>>>
>>>>>
>>>>> adequately covered by existing solutions). Personally, I don't 
>>>>> have a strong preference on whether the "naming" should reflect 
>>>>> this or not (Danielle's latest suggestion - use "TE" in the ACTN 
>>>>> acronym - is pretty close to what I personally would like it to 
>>>>> be), but it is important to get some clarity on this "scoping" detail before zeroing in on any "name".
>>>>>
>>>>> starting point for Y. In 2 years we have put together use cases, 
>>>>> an architecture and would have liked to start working on solutions 
>>>>> for that, we'd like not to start from the beginning again. Please 
>>>>> note the list of ACTN related drafts in TEAS (not to consider the 
>>>>> <http://tools.ietf.org/id/draft-klee-teas-actn-connectivity-multi-
>>>>> d
>>>>> omain-02.txt>
>>>>>
>>>>> 	
>>>>>
>>>>> -02
>>>>> <http://tools.ietf.org/html/draft-klee-teas-actn-connectivity-mult
>>>>> i
>>>>> -domain-02.txt>
>>>>>
>>>>> 			
>>>>>
>>>>> 2015-06-08
>>>>>
>>>>> <http://tools.ietf.org/id/draft-kumaki-teas-actn-multitenant-vno-0
>>>>> 0
>>>>> .txt>
>>>>>
>>>>> 	
>>>>>
>>>>> -00
>>>>> <http://tools.ietf.org/html/draft-kumaki-teas-actn-multitenant-vno
>>>>> -
>>>>> 00.txt>
>>>>>
>>>>> 			
>>>>>
>>>>> 2015-07-06
>>>>>
>>>>> <http://tools.ietf.org/id/draft-lam-teas-usage-info-model-net-topo
>>>>> l
>>>>> ogy-01.txt>
>>>>>
>>>>> 	
>>>>>
>>>>> -01
>>>>> <http://tools.ietf.org/html/draft-lam-teas-usage-info-model-net-to
>>>>> p
>>>>> ology-01.txt>
>>>>>
>>>>> 			
>>>>>
>>>>> 2015-07-03
>>>>>
>>>>> <https://www.google.com/search?as_q=%22draft-lee-teas-actn-require
>>>>> m ents-01%22&as_sitesearch=mailarchive.ietf.org/arch/browse/teas/>
>>>>>
>>>>> 	
>>>>>
>>>>> <https://www.google.com/search?as_q=%22draft-leebelotti-teas-actn-
>>>>> i nfo-00%22&as_sitesearch=mailarchive.ietf.org/arch/browse/teas/>
>>>>>
>>>>> 	
>>>>>
>>>>> <http://tools.ietf.org/html/draft-leebelotti-teas-actn-info-00.txt
>>>>> >
>>>>>
>>>>> 			
>>>>>
>>>>> 2015-07-02
>>>>>
>>>>> <http://tools.ietf.org/id/draft-leeking-teas-actn-problem-statemen
>>>>> t
>>>>> -00.txt>
>>>>>
>>>>> 	
>>>>>
>>>>> -00
>>>>> <http://tools.ietf.org/html/draft-leeking-teas-actn-problem-statem
>>>>> e
>>>>> nt-00.txt>
>>>>>
>>>>> 			
>>>>>
>>>>> 2015-06-09
>>>>>
>>>>> <http://tools.ietf.org/id/draft-suzuki-teas-actn-multidomain-opc-0
>>>>> 0
>>>>> .txt>
>>>>>
>>>>> 	
>>>>>
>>>>> -00
>>>>> <http://tools.ietf.org/html/draft-suzuki-teas-actn-multidomain-opc
>>>>> -
>>>>> 00.txt>
>>>>>
>>>>> 			
>>>>>
>>>>> 2015-07-06
>>>>>
>>>>> <http://tools.ietf.org/id/draft-xu-teas-actn-abstract-alarm-report
>>>>> -
>>>>> 00.txt>
>>>>>
>>>>> 	
>>>>>
>>>>> -00
>>>>> <http://tools.ietf.org/html/draft-xu-teas-actn-abstract-alarm-repo
>>>>> r
>>>>> t-00.txt>
>>>>>
>>>>> 			
>>>>>
>>>>> 2015-07-06
>>>>>
>>>>> <http://tools.ietf.org/id/draft-ceccarelli-teas-actn-framework-00.
>>>>> t
>>>>> xt>
>>>>>
>>>>> 	
>>>>>
>>>>> -00
>>>>> Is your concern mostly related to the "transport" word? In the 
>>>>> last years the concept of transport evolved pretty much, mostly 
>>>>> with transport SDN and it is no longer tied to the L0-L1 but it 
>>>>> covers whatever mean used to transport IP. Young already pointed 
>>>>> out what the draft aims to cover.
>>>>>
>>>>> TE networks. (this is my personal proposal, not shared by the 
>>>>> other ACTNers)...and ACTN remains, but with the "broader" scope 
>>>>> and it is "more" complementary to the interconnected TE.
>>>>>> That's fair, but from our perspective the IETF has been working 
>>>>>> TE a lot longer than the term ACTN has been around, and that is 
>>>>>> the context where this work fits.
>>>>>>
>>>>>> in the end we have an RFC published with the title that 
>>>>>>>> draft-ietf-teas-vn-controller-requirements-00 with only the 
>>>>>>>> date and file name changed.
>>>>>>>> But this draft is a little different as it has evolved over 
>>>>>>>> time to its current form and where we expect it to  go.  In

---

From: "Zhangxian (Xian)" <[email-masked]>
Date: Sat, 19 Sep 2015 07:15:07 +0000

Hi, Lou, 

   You said: 
" The core requirements say nothing
about distributed or "logically centralized" control models and the only
place it shows is by inference in the interfaces section."

  This requirement draft is no way an independent one, but rather takes the framework proposed in [1] as an assumption, so it implies that it is based on a "logically centralized" control models, isn't it? Since you asked, I was a bit surprised that the framework was not adopted first, but rather the requirement draft which depends on the former. 

  As for your question (i.e., Abstraction and Control are both things supported by today's standards, so what's new from the requirements perspective?): I am not sure I get your exact point, do you mean that the requirements listed in the draft can already be supported by the existing RFCs developed by TEAS/CCAMP? I believe there is no disagreement that the architecture put forwarded by the ACTN team is new. As for the list of requirements, let's focus on one or two examples to start with: how is the requirement 3, i.e. VN Query, supported by existing protocols/RFCs? I do not think we have any solution yet.

Regards,
Xian

[1] https://tools.ietf.org/html/draft-ceccarelli-teas-actn-framework-00

-----Original Message-----
From: Teas [mailto:[email-masked]] On Behalf Of Lou Berger
Sent: 2015年9月19日 3:37
To: Igor Bryskin; Leeyoung; Doolan, Paul (Coriant - US/Irving)
Cc: TEAS WG; Daniele Ceccarelli; Vishnu Pavan Beeram; Varma, Eve L (Eve); [email-masked]
Subject: Re: [Teas] Poll on draft-lee-teas-actn-requirements-01 a WG documents

Igor,

Thanks,
Lou

---

From: Lou Berger <[email-masked]>
Date: Sun, 20 Sep 2015 09:22:22 -0400

Haomian,

Thank you for the input.  see below.

> I like the idea ACTN is an umbrella that contains a wide range of work. The draft will definitely be polished later (as a WG draft) and the scope will become clear by carefully understanding what r…

This goes to what ACTN is.  Every time I've asked the question ("what s
it and what's different/new") in the past.  I'm shown a picture of a lot
of boxes with unique names and am told *This is ACTN*.  So to me this
says ACTN is a solution -- and if ACTN is a solution to a problem, then
the requirements document should be focused on the problem, not the
solution. Hence, this discussion.

Now, Igor's definition (which I'll paraphrase as ACTN = Large scale
integrated control of TE networks -- and I'm sure he/someone will
correct or modify) helps to say that ACTN is a problem space not a
specific solution. 

> For the distributed or 'logical centralized' control models, my opinion is model is something solution related rather than requirement, and can be included in framework. 

Sure, but this only makes sense if the problem being solved by ACTN !=
just 'logical centralized' control models..

Thanks,
Lou

---

From: Lou Berger <[email-masked]>
Date: Sun, 20 Sep 2015 09:50:37 -0400

Xian,

On 9/19/2015 3:15 AM, Zhangxian (Xian) wrote:
>   As for your question (i.e., Abstraction and Control are both things supported by today's standards, so what's new from the requirements perspective?): I am not sure I get your exact point, do you mean that the requirements listed in the draft can already be supported by the existing RFCs developed by TEAS/CCAMP?

Close, but turn it around a bit.  I'm asking what new capabilities are
being asked for, from TE networks,  in the requirements.  Saying ACTN
requirements cover ACTN is a bit circular.  As a parallel, consider
MPLS-TP.  When considering what's new in MPLS-TP requirements, it's
possible to go read a fairly succinct definition in RFC5654:

   MPLS
   Transport Profile (MPLS-TP) [that] supports the capabilities and
   functionalities needed for packet-transport network services and
   operations through combining the packet experience of MPLS with the
   operational experience and practices of existing transport networks.

and

   This document specifies the requirements of an MPLS Transport Profile
   (MPLS-TP).

So this is a case there the requirements were specific to the solution
space, which may also be the case here.  But, at the last meeting we
seemed to be headed to address a particular problem space ("logically
centralized" control models), given this we were motivated to make the
name change.

Now the case is being made (notably by Igor, who providing technical
substanciation) that ACTN is aimed at solving a super-set/broader
problem.  To me  this is the strongest justification made so far to keep
actn in the name.   -- presuming that -01 rev of the document adds the
appropriate definition of ACTN to the document.

>  I believe there is no disagreement that the architecture put forwarded by the ACTN team is new. 
And I think we all agree there is good work needed / to be done.

> As for the list of requirements, let's focus on one or two examples to start with: how is the requirement 3, i.e. VN Query, supported by existing protocols/RFCs? I do not think we have any solution yet.
I'm not sure focusing on a gap analysis is really part of this
conversation.

But since you ask,  YANG TE Topology and perhaps even BGP-LS seem to
have significant overlap with that requirement.  -- Again whether it
does or doesn't, doesn't change the requirements naming discussion or
the ACTN definition discussion which we've evolved into. 

Thanks,
Lou

---

From: "BELOTTI, SERGIO (SERGIO)" <[email-masked]>
Date: Sun, 20 Sep 2015 16:36:25 +0000

Now on to the AC part.  

SB> Daniele proposed TE Network trying to cope with your "out of blue" request regarding limitation of term Transport in the context of TEAS. This could be a good compromise , even if it seems WG perceived "Transport Network" as completely "readily understandable from TEAS WG context " if, in Dallas, to the question regarding of full matching of ACTN context into TEAS, there has been full support for that.
It is absolutely no time to discuss every syllable of name now, if there was something that you do not like form ACTN name there has been many chance to discuss and none in the WG NEVER sustains this. 

Fundamentally we're trying to capture what's new in the requirements documented in the draft.  Abstraction and Control are both things supported by today's standards, so what's new from the requirements perspective? I have to say even reading the PS draft, it wasn't immediately obvious. We've stated in other messages our view. It would be great to get some better options on the table.

Thanks,
Lou

>> > requirements draft might be about and,
>>
>> > If you want

---

From: "BELOTTI, SERGIO (SERGIO)" <[email-masked]>
Date: Sun, 20 Sep 2015 16:49:31 +0000

Please avoid to exploit the fact Eve was not present in Prague, to hold up something that never happen !

"The comments were made in Pargue (publicly and expanded upon privately), and I had a discussion with the Authors via e-mail during the adoption period"

As reported by other WG participant there has not been any mention of clarifications or even changing name (!): none think that requirements document is complete , absolutely not, and now that WG support it as WG, this can exploit all the WG to enhance the content . Great for that.

Moreover I'm one of the author and I never been asked privately to discuss nothing by the chair neither vocally nor via mail.

Thanks

Belotti Sergio - System Architect
ALCATEL-LUCENT  IP Routing&Transport
via Trento 30 Vimercate (MB) - Italy
phone +39 (039) 6863033

-----Original Message-----
From: Lou Berger [mailto:[email-masked]] 
Sent: venerdì 18 settembre 2015 16:56
To: Varma, Eve L (Eve); Daniele Ceccarelli; Vishnu Pavan Beeram
Cc: Doolan, Paul (Coriant - US/Irving); [email-masked]; TEAS WG
Subject: Re: [Teas] Poll on draft-lee-teas-actn-requirements-01 a WG documents

Eve,

See my last message.  The comments were made in Pargue (publicly and expanded upon privately), and I had a discussion with the Authors via e-mail during the adoption period  -- in this brief e-mail exchange I indicated that I decided to not impede adoption as I believe the current contents of the document is a great starting point for the WG.

I specifically didn't want the discussion on what is basically how the "ACTN" *solution* fits in with the rest of IETF TE to impede the adoption of what is essentially a generic TE requirements document.

Lou

>> changed names in the past and been right and sometimes wrong, but in 
>> the end we have an RFC published with the title that represents WG 
>> be a more

---

From: "Zhangxian (Xian)" <[email-masked]>
Date: Mon, 21 Sep 2015 03:07:58 +0000

Hi Lou,   

    Thank you for your reply and good examples. Before diving into the details, we do need to focus on the main point: name changing/ACTN definition. So, here goes my rough thought: 

    ACTN (Abstraction and Control of TE Networks, which seems to be the best compromise so far.) supports the capabilities and functionalities needed to operate, control and manage the virtualized networks via hierarchical abstraction of TE domains so as to meet operators' requirements on better network programmability, automation and facilitating resource sharing.

    This summary is according to my best and limited understanding of ACTN since I am not really involved in the work deeply and open to further amendment/correction. 

    My further reply inline marked with [Xian]:   

-----Original Message-----
From: Lou Berger [mailto:[email-masked]] 
Sent: 2015年9月20日 21:51
To: Zhangxian (Xian); Igor Bryskin; Leeyoung; Doolan, Paul (Coriant - US/Irving)
Cc: TEAS WG; Daniele Ceccarelli; Vishnu Pavan Beeram; Varma, Eve L (Eve); [email-masked]
Subject: Re: [Teas] Poll on draft-lee-teas-actn-requirements-01 a WG documents

Xian,

   MPLS

and

[Xian]: I do think Igor really provides a good explanation of ACTN. But to me, that explanation does not add anything new, but rather cap it well with much less words. As you see, I have tried to provide a simple summary of what ACTN is and I hope we can get converged soon.

And I think we all agree there is good work needed / to be done.
[Xian]: Good to know this.

I'm not sure focusing on a gap analysis is really part of this
conversation.
[Xian]: Sure; I did not think that way either; merely want to understand your point better via some examples. 

[Xian]: Well, this is open to debate and will indeed come into picture at a later stage. Thank you for bringing me back to the main point and let's get focused on it at this point of time.

Cheers,
Xian

Thanks,
Lou

---

From: Daniele Ceccarelli <[email-masked]>
Date: Mon, 21 Sep 2015 12:44:05 +0000

Lou,

I don’t think it that having to a detailed post-mortem of "who said what and when" is leading us towards resolution, and would prefer to take a more constructive and collaborative approach.  However, I do feel compelled to reply to two of your statements that I view as unwarranted and take great exception to, below.  
 
Excerpt 1. You said: "This goes to what ACTN is.  Every time I've asked the question ("what is it and what's different/new") in the past.  I'm shown a picture of a lot of boxes with unique names and am told *This is ACTN*. "
 
I am extremely concerned that this statement is being made after WG adoption (with a wide support from the WG) as motivation for changing the title.  As you know, this has been explained in 1 bar BoF, 2 BoFs, the requirement draft, the framework draft, an info model draft already including many primitives, not to mention the many use cases drafts and presentation (plus a conference call). I imagine all the people that supported the adoption and that raised their hands at the polling in Dallas have at least a basic idea of what ACTN is.  For example, Igor perfectly understood the intent and expressed it quite well. In addition to Igor’s explanation, I would add that ACTN “doesn't care” how the network is controlled, (whether centralized, distributed, control plane or management plane), but only about providing a centralized hierarchy that presents to the final customer not only an abstracted network (nodes and links) but also services and Virtual Network Functions (more details in the fwk).
 
Excerpt 2. You said:”If the authors are only interested in the WG blessing what has already been put together without any WG input than I suggest that the authors don't understand the IETF process.”
 
You surely know that this is not the case, the authors being well aware – and respectful - of the IETF process, and have never suggested that the drafts are ready for publication. Certainly, as usual for a draft adopted by the WG, it still needs a lot of work (e.g., corrections, refinements, and enhancements) within its stated ACTN scope.  While the authors are happy to see their work improved and modified, turning it into something totally different (or much wider) from their focus immediately after a successful WG adoption process, when the usual approach is to retain the file name and just remove the individual author, is disturbing.  
 
It would be helpful if you could tell us what you mean as "complimentary to the interconnected-TE work" to better understand what requirements are not covered under the current ACTN umbrella, as this would give an opportunity for other contributors who might be interested in addressing those requirements to develop targeted drafts.  
 
Looking forward to progress a fruitful thread and publishing the WG draft so work can progress.
Daniele

> Sent: domenica 20 settembre 2015 15:22
> To: Zhenghaomian; Igor Bryskin; Leeyoung; Doolan, Paul (Coriant - US/Irving)
> Cc: TEAS WG; Daniele Ceccarelli; Vishnu Pavan Beeram; Varma, Eve L (Eve);
> Subject: Re: 答复: [Teas] Poll on draft-lee-teas-actn-requirements-01 a WG
> documents
> 
> 
> Haomian,
> 
> > Nice discussion for clarifying what is new requirement for ACTN. The
> authors may have more comments on specifying that. I tried to share my
> point here.
> >
> > I like the idea ACTN is an umbrella that contains a wide range of work. The
> draft will definitely be polished later (as a WG draft) and the scope will
> become clear by carefully understanding what requirement is in the ACTN
> scope and what is not. This is necessary and just the reason why we consider
> it as 'ACTN requirement' draft. If you say there is different understanding
> with ACTN scope or the current scope is not clear enough, I would like to
> agree and will be open for discussion; however if you think the 'ACTN' should
> be equivalent to 'complementary TE-interconnected info-exchange work',
> that is misunderstanding. I don't think this is the motivation/objective for
> ACTN authors. ACTN, as an umbrella, should be proper to have its
> requirement, use case, framework and other drafts with its name, that is
> different from 'complementary TE-interconnected work', so it should be fine
> to keep the actn term in name abbreviation.
> 
> This goes to what ACTN is.  Every time I've asked the question ("what s it and
> what's different/new") in the past.  I'm shown a picture of a lot of boxes with
> unique names and am told *This is ACTN*.  So to me this says ACTN is a
> solution -- and if ACTN is a solution to a problem, then the requirements
> document should be focused on the problem, not the solution. Hence, this
> discussion.
> 
> Now, Igor's definition (which I'll paraphrase as ACTN = Large scale integrated
> control of TE networks -- and I'm sure he/someone will correct or modify)
> helps to say that ACTN is a problem space not a specific solution.
> 
> > For the distributed or 'logical centralized' control models, my opinion is
> model is something solution related rather than requirement, and can be
> included in framework.
> 
> Sure, but this only makes sense if the problem being solved by ACTN != just
> 'logical centralized' control models..
> 
> Thanks,
> Lou
> 
> >
> > Thanks a lot.
> >
> > Best wishes,
> > Haomian
> >
> >
> > -----邮件原件-----
> > 抄送: TEAS WG; Daniele Ceccarelli; Vishnu Pavan Beeram; Varma, Eve L
> > (Eve); [email-masked]
> >> - Abstraction and Control are both things supported by today's standards,
> so what's new from the requirements perspective?
> >>
> > So the new part of ACTN (WRT TEAS) identified/discussed/seemingly
> agreed to in Prague was the support for a "logically centralized" control
> > My question here, really was more limited than ACTN as a whole but really
> the requirements documents.  The core requirements say nothing about
> distributed or "logically centralized" control models and the only place it
> shows is by inference in the interfaces section.  So the question is an honest
> one, and I appreciate you being the 1st at taking a stab at responding to it.
> >
> >> Luyuan was talking about the need of interconnecting millions of MSFT
> servers. How do you describe a transport network capable of doing that?
> One solution is via hierarchical abstraction of numerous TE domains provided
> by multiple providers. Please, correct me if I am wrong, but I am not aware
> of any IETF documents setting requirements for said abstracted hierarchical
> TE networks: presentation, features, re-configuration capabilities, models,
> etc. Nor I am aware of any architecture or framework describing what
> exactly operators and/or SDN controllers/applications can do with such
> networks, in particular how they can orchestrate end-to-end transport
> services, manipulate and monitor them, place them with sufficient diversity
> from each other, etc. How they can perform capacity analysis of said
> networks and other network planning functions? How they convey policies
> wrt various transport behaviors and profiles? This kind of things IMO need to
> be addressed under the ACTN umbrella.
> > This is all goodness and also the closest I've seen to a succinct definition of
> what's new in ACTN.  Perhaps it can serve as the foundation of a short
> paragraph defining what it is for inclusion in the intro of -01 of the WG draft.
> >
> centralized" control model), which is fine, but also highlights a bit why we're
> trying to frame the work now as it is being formally brought into the WG.
> >
> > Thanks,
> > Lou
> >> Regards,
> >> igor
> >>
> >>
> >>
> >> Varma, Eve L (Eve) <[email-masked]>; Vishnu Pavan
> >> Beeram <[email-masked]>
> >> Daniele closed his slides by talking about overall status.  So the comments
> were both about the document and more general.  I listened to the (painful)
> audio and added a few more notes:
> >> see
> >> http://etherpad.tools.ietf.org:9000/p/notes-ietf-93-teas?useMonospace
> >> F
> >> ont=true
> >>
> >> - Abstraction and Control are both things supported by today's standards,
> so what's new from the requirements perspective?
> >>
> >> Thanks,
> >> Lou
> >>> Actually this is meeting minutes on the ACTN Framework draft
> presentation and we agreed to include some gap analysis of some type.
> >>> We will come up with that topic in the upcoming revision on this. I
> thought you are going to poll the framework draft soon.
> >>>
> >>> In regards to the requirements draft, what Paul is quoting is correct and
> the current requirement draft incorporated your comments on impact on
> YANG and others.
> >>>
> >>> Thanks.
> >>> Young
> >>>
> >>>
> >>>
> >>>> So that we're all on the same page (Eve wasn't at the Prague meeting),
> what you are recorded in the minutes as having said with respect to draft-
> lee-teas-actn-requirements-01 is:
> >>>>
> >>>> Which is fine by me but does IMO qualify as advance warning of your
> current position. No "oh and by the way change the title" for example.
> >>>>>> than "Support"; I didn't see "Support, but clarify.." or
> >>>>>> "Support, but change.."  Given this, I am truly surprised at the
> discussion that has now arisen.
> >>>>> Eve,
> >>>>>
> >>>>>> *From:*Teas [mailto:[email-masked]] *On Behalf Of
> *Daniele
> >>>>>> Ceccarelli
> >>>>>> capture what we want this work to be about. Note that this is
> >>>>>> just a requirements document and since this is the first document
> >>>>>> to be adopted in this realm, it is important to get the "naming"
> >>>>>> right now rather than later. "VN Controller" is perhaps not a
> >>>>>> great choice -- very much open to other choices that would capture
> the essence of the first statement above.
> >>>>>>
> >>>>>> */[DanCe] The IETF is contribution driven. If the WG contributed
> >>>>>> a draft related to a subset of what the chairs expect, it means
> >>>>>> that there is interest just in that subset. If the chairs wanted
> >>>>>> generic enough (before the wg adoption), not call for the
> >>>>>> adoption of a document and then ask to change its scope. The
> >>>>>> authors are interested in writing ACTN requirements, which not
> >>>>>> only is a subset of what the chairs ask for but is also slightly
> >>>>>> different since we're not speaking just about nodes and links. /*
> >>>>>>
> >>>>>>
> >>>>>> */[DanCe] What does complementary mean? Complementary in the
> >>>>>> sense that interconnected TE is for multi-domain LSP
> >>>>>> establishment in distributed control plane and ACTN does the same
> >>>>>> for centralized one? ACTN has a broader scope. The multi domain
> >>>>>> and multi layer part can be seen as complimentary, but again ACTN
> >>>>>> is not just nodes and links, it includes services, VNF, network
> >>>>>> slices and so
> >>>>>> on./*
> >>>>>>
> >>>>>>
> >>>>>> adoption of X and now they are requested to publish the draft as
> >>>>>> a starting point for Y. In 2 years we have put together use
> >>>>>> cases, an architecture and would have liked to start working on
> >>>>>> solutions for that, we'd like not to start from the beginning
> >>>>>> again. Please note the list of ACTN related drafts in TEAS (not
> >>>>>> to consider the expired ones still submitted as
> >>>>>> draft-xxxxx-actn.)/*
> >>>>>>
> >>>>>> */ /*
> >>>>>>
> >>>>>> <https://www.google.com/search?as_q=%22draft-klee-teas-actn-
> conne
> >>>>>> c
> >>>>>> t
> >>>>>> ivity-multi-domain-02%22&as_sitesearch=mailarchive.ietf.org/arch/
> >>>>>> b
> >>>>>> r
> >>>>>> owse/teas/>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> <https://www.google.com/search?as_q=%22draft-kumaki-teas-
> actn-mul
> >>>>>> t
> >>>>>> i
> >>>>>> tenant-vno-
> 00%22&as_sitesearch=mailarchive.ietf.org/arch/browse/t
> >>>>>> e
> >>>>>> a
> >>>>>> s/>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> <https://www.google.com/search?as_q=%22draft-lam-teas-usage-
> info-
> >>>>>> m
> >>>>>> o
> >>>>>> del-net-topology-01%22&as_sitesearch=mailarchive.ietf.org/arch/br
> >>>>>> o
> >>>>>> w
> >>>>>> se/teas/>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> <https://www.google.com/search?as_q=%22draft-lee-teas-actn-
> requir
> >>>>>> e m
> >>>>>> <http://tools.ietf.org/id/draft-lee-teas-actn-requirements-01.txt
> >>>>>> >
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> -01
> >>>>>> <http://tools.ietf.org/html/draft-lee-teas-actn-requirements-01.t
> >>>>>> x
> >>>>>> t
> >>>>>>
> >>>>>>
> >>>>>> 2015-07-27
> >>>>>>
> >>>>>> <https://www.google.com/search?as_q=%22draft-leebelotti-teas-
> actn
> >>>>>> - i
> >>>>>> <https://www.google.com/search?as_q=%22draft-leeking-teas-
> actn-pr
> >>>>>> o
> >>>>>> b
> >>>>>> lem-statement-
> 00%22&as_sitesearch=mailarchive.ietf.org/arch/brows
> >>>>>> e
> >>>>>> /
> >>>>>> teas/>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> <https://www.google.com/search?as_q=%22draft-suzuki-teas-actn-
> mul
> >>>>>> t
> >>>>>> i
> >>>>>> domain-opc-
> 00%22&as_sitesearch=mailarchive.ietf.org/arch/browse/t
> >>>>>> e
> >>>>>> a
> >>>>>> s/>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> <https://www.google.com/search?as_q=%22draft-xu-teas-actn-
> abstrac
> >>>>>> t
> >>>>>> -
> >>>>>> alarm-report-
> 00%22&as_sitesearch=mailarchive.ietf.org/arch/browse
> >>>>>> /
> >>>>>> t
> >>>>>> eas/>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> <https://www.google.com/search?as_q=%22draft-ceccarelli-teas-
> actn
> >>>>>> -
> >>>>>> f
> >>>>>> ramework-
> 00%22&as_sitesearch=mailarchive.ietf.org/arch/browse/tea
> >>>>>> s
> >>>>>> /
> >>>>>>
> >>>>>>
> >>>>>> <http://tools.ietf.org/html/draft-ceccarelli-teas-actn-framework-
> >>>>>> 0
> >>>>>> 0
> >>>>>> .txt>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> 2015-06-15
> >>>>>>
> >>>>>> */ /*
> >>>>>>
> >>>>>> */ /*
> >>>>>>
> >>>>>> Regards,
> >>>>>>
> >>>>>> -Pavan
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>> changed names in the past and been right and sometimes wrong,
> >>>>>>> articulated rationale and asking for its support would seem to
> >>>>>>> me to be a more
> >>>>>> inclusive
> >>>>>>> way to do things.
> >>>>>>>
> >>>>>>>>> controller-based TE models  (where the previous work was more
> focused on fully distributed control models).
> >>>>>>>>>> technical reservations with the document.  If yes, please
> >>>>>>>>>> also feel free to provide comments you'd like to see

---

From: Lou Berger <[email-masked]>
Date: Mon, 21 Sep 2015 22:30:32 -0400

Daniele, ACTN authors, All,

On 9/21/2015 8:44 AM, Daniele Ceccarelli wrote:
> ...

Okay, let's take a step back here. 

The basic question is how does ACTN fit into the TEAS WG. 

Based on the discussions to date in the context of the WG, we thought we
understood where we were going WRT ACTN, but perhaps not.  We also
clearly expected to answer this in greater detail  as the WG  moved
towards "ACTN" solutions. 

As has been pointed out earlier in the thread, having the first document
on a topic without any definition of the topic is a bit awkward.  So
perhaps now would be a good time to provide a definition of ACTN that
can be added to the requirements document. 

Could someone (individually or collectively) provide a definition of
ACTN that would be suitable for inclusion in a -01 of the WG
requirements document on the topic?

Also as mentioned before, it may be helpful to look at the MPLS-TP
requirements document, RFC 5654, which provides an example of such a
definition.

Thank you,
Lou

---

From: "Varma, Eve L (Eve)" <[email-masked]>
Date: Tue, 22 Sep 2015 15:39:19 +0000

Hi Lou,

Adding a definition seems a reasonable thing to do, considering all the discussion that's taken place.  From a procedure perspective, I assume the authors should first publish draft-teas-actn-requirements-00 as a WG draft without any changes to the content, and thereafter proceed from there to change “Transport” to “TE” within the draft and add a definition?

Best regards,
Eve

-----Original Message-----
From: Lou Berger [mailto:[email-masked]] 
Sent: Monday, September 21, 2015 10:31 PM
To: Daniele Ceccarelli; Leeyoung; [email-masked]
Cc: Varma, Eve L (Eve); Vishnu Pavan Beeram; TEAS WG
Subject: Re: [Teas] 答复: Poll on draft-lee-teas-actn-requirements-01 a WG documents

Based on the discussions to date in the context of the WG, we thought we understood where we were going WRT ACTN, but perhaps not.  We also clearly expected to answer this in greater detail  as the WG  moved towards "ACTN" solutions. 

As has been pointed out earlier in the thread, having the first document on a topic without any definition of the topic is a bit awkward.  So perhaps now would be a good time to provide a definition of ACTN that can be added to the requirements document. 

Could someone (individually or collectively) provide a definition of ACTN that would be suitable for inclusion in a -01 of the WG requirements document on the topic?

Also as mentioned before, it may be helpful to look at the MPLS-TP requirements document, RFC 5654, which provides an example of such a definition.

Thank you,
Lou

---

From: Lou Berger <[email-masked]>
Date: Tue, 22 Sep 2015 11:59:01 -0400

Eve,
    Let's try to  focus on the getting the questions answered, with the
understanding that content changes go into -01. -00  will be the text
currently published.

> Could someone (individually or collectively) provide a definition of ACTN that would be suitable for inclusion in a -01 of the WG requirements document on the topic?

Any input on this would be much appreciated.

Thanks,
Lou

---

From: "Varma, Eve L (Eve)" <[email-masked]>
Date: Tue, 22 Sep 2015 16:01:38 +0000

Hi Lou,

OK - so the authors should go ahead and publish draft-teas-actn-requirements-00 and then start working on the content changes for 01.  Thanks for answering my procedural question.

Best regards,
Eve

-----Original Message-----
From: Lou Berger [mailto:[email-masked]] 
Sent: Tuesday, September 22, 2015 11:59 AM
To: Varma, Eve L (Eve); Daniele Ceccarelli; Leeyoung; [email-masked]
Cc: Vishnu Pavan Beeram; TEAS WG
Subject: Re: [Teas] 答复: Poll on draft-lee-teas-actn-requirements-01 a WG documents

Eve,
    Let's try to  focus on the getting the questions answered, with the understanding that content changes go into -01. -00  will be the text currently published.

Thanks,
Lou

On 9/22/2015 11:39 AM, Varma, Eve L (Eve) wrote:
> To: Daniele Ceccarelli; Leeyoung;

---

From: Lou Berger <[email-masked]>
Date: Tue, 22 Sep 2015 12:07:06 -0400

Let's try again.  I thought I was perfectly clear, but I guess not.

The filename of the -00 version is subject to the results of the
discussion. 

Is this clear?

Lou

---

From: Leeyoung <[email-masked]>
Date: Tue, 22 Sep 2015 16:38:17 +0000

Hi Lou,
 
Procedurally, the WG has adopted the current draft-lee-teas-actn-requirements-01 version as WG draft. In that, we have references to the framework and problem statement drafts in which ACTN is described. 
 
I think the publication of 00 version as the TEAS WG is the first thing to do. Once that is done, we can work on the description/definition of ACTN explicitly in 01 version based on those references. 
 
Best regards,
Young

-----Original Message-----
From: Lou Berger [mailto:[email-masked]] 
Sent: Tuesday, September 22, 2015 11:07 AM
To: Varma, Eve L (Eve); Daniele Ceccarelli; Leeyoung; [email-masked]
Cc: Vishnu Pavan Beeram; TEAS WG
Subject: Re: [Teas] 答复: Poll on draft-lee-teas-actn-requirements-01 a WG documents

The filename of the -00 version is subject to the results of the discussion. 

Is this clear?

Lou

On 9/22/2015 12:01 PM, Varma, Eve L (Eve) wrote:
> To: Varma, Eve L (Eve); Daniele Ceccarelli; Leeyoung;

---

From: Vishnu Pavan Beeram <[email-masked]>
Date: Tue, 22 Sep 2015 13:20:25 -0400

> ACTN that would be suitable for inclusion in a -01 of the WG requirements
> document on the topic?
>

I thought the proposal texts from Igor and Xian were pretty good for a
start. Can the authors please build on this and put together some text that
succinctly defines ACTN (text that, hopefully, justifies using "ACTN" to
characterize the set of requirements that have been put forth)? Given all
the work that has gone into this (and all the documents that have been put
together so far) over the past couple of years, I would like to think that
this wouldn't take too long.

Regards,
-Pavan

> > Adding a definition seems a reasonable thing to do, considering all the
> discussion that's taken place.  From a procedure perspective, I assume the
> authors should first publish draft-teas-actn-requirements-00 as a WG draft
> without any changes to the content, and thereafter proceed from there to
> change “Transport” to “TE” within the draft and add a definition?
> >
> > Best regards,
> > Eve
> >
> understood where we were going WRT ACTN, but perhaps not.  We also clearly
> expected to answer this in greater detail  as the WG  moved towards "ACTN"
> solutions.
> >
> perhaps now would be a good time to provide a definition of ACTN that can
> be added to the requirements document.
> >
> ACTN that would be suitable for inclusion in a -01 of the WG requirements
> document on the topic?
> >

---

From: Leeyoung <[email-masked]>
Date: Tue, 22 Sep 2015 17:32:53 +0000

Hi Pavan,

We’d love to do so. 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. As I indicated in my previous email to the list, the description of ACTN is already there in the referenced drafts, framework and problem statement. Justification of ACTN into the TEAG WG has already expressed in the adoption process, has it not?

The requirements are based on operators’ use-cases under the umbrella of ACTN. There is no reason to challenge them at this juncture, isn’t?

Regards,
Young

From: Vishnu Pavan Beeram [mailto:[email-masked]]
Sent: Tuesday, September 22, 2015 12:20 PM
To: Lou Berger
Cc: Varma, Eve L (Eve); Daniele Ceccarelli; Leeyoung; [email-masked]; TEAS WG
Subject: Re: [Teas] 答复: Poll on draft-lee-teas-actn-requirements-01 a WG documents

I thought the proposal texts from Igor and Xian were pretty good for a start. Can the authors please build on this and put together some text that succinctly defines ACTN (text that, hopefully, justifies using "ACTN" to characterize the set of requirements that have been put forth)? Given all the work that has gone into this (and all the documents that have been put together so far) over the past couple of years, I would like to think that this wouldn't take too long.
Regards,
-Pavan

On 9/22/2015 11:39 AM, Varma, Eve L (Eve) wrote:
> To: Daniele Ceccarelli; Leeyoung; [email-masked]<mailto:[email-masked]>

---

From: "BELOTTI, SERGIO (SERGIO)" <[email-masked]>
Date: Tue, 22 Sep 2015 17:33:52 +0000

Dear Pavan,

you probably missed a basic input: do you know the story of draft-lee-teas-actn-requirements ? this draft did not exist before Dallas meeting, when, after a tunes of documents regarding ACTN in the different BOF (Framework, problem statement, Use cases ) , Lou asked us do not have ACTN requirements distributed in Framework or Use cases but collected in a specific separated document , indeed draft-lee.

So we work during Dallas meeting to collect specific ACTN requirements as required by chair and provide the new document that in fact in his first abstract says “This draft provides a set of requirements for abstraction and

   control of transport networks.”.

So can you kindly explain why we should put the text  “justifies using "ACTN" to characterize the set of requirements that have been put forth” when the draft has been created exactly to collect requirements for ACTN ?

With Best Regards
Sergio

From: Vishnu Pavan Beeram [mailto:[email-masked]]
Sent: martedì 22 settembre 2015 19:20
To: Lou Berger
Cc: Varma, Eve L (Eve); Daniele Ceccarelli; Leeyoung; [email-masked]; TEAS WG
Subject: Re: [Teas] 答复: Poll on draft-lee-teas-actn-requirements-01 a WG documents

---

From: Vishnu Pavan Beeram <[email-masked]>
Date: Tue, 22 Sep 2015 13:52:25 -0400

>
> So can you kindly explain why we should put the text  “justifies using
> "ACTN" to characterize the set of requirements that have been put forth”
> when the draft has been created exactly to collect requirements for ACTN ?
>
Since this is the first document under the "ACTN umbrella" to be adopted by
the WG, I think it is fair to expect a definition for "ACTN" to be present
in this document and to expect it to be debated thoroughly. I don't
understand the reluctance to come up with a definition or point to an
existing definition.

Regards,
-Pavan

>
>
>
> *From:* Vishnu Pavan Beeram [mailto:[email-masked]]
> *Sent:* martedì 22 settembre 2015 19:20
> *To:* Lou Berger
> *Cc:* Varma, Eve L (Eve); Daniele Ceccarelli; Leeyoung;
> *Subject:* Re: [Teas] 答复: Poll on draft-lee-teas-actn-requirements-01 a
> WG documents
>
>
>
>
>

---

From: Leeyoung <[email-masked]>
Date: Tue, 22 Sep 2015 17:56:47 +0000

Hi Pavan,

I thought the WG has already adopted the ACTN requirements draft. What do you mean, Since this is the first document under the "ACTN umbrella" to be adopted by the WG?

Young

From: Vishnu Pavan Beeram [mailto:[email-masked]]
Sent: Tuesday, September 22, 2015 12:52 PM
To: BELOTTI, SERGIO (SERGIO)
Cc: Lou Berger; Varma, Eve L (Eve); Daniele Ceccarelli; Leeyoung; [email-masked]; TEAS WG
Subject: Re: [Teas] 答复: Poll on draft-lee-teas-actn-requirements-01 a WG documents

So can you kindly explain why we should put the text  “justifies using "ACTN" to characterize the set of requirements that have been put forth” when the draft has been created exactly to collect requirements for ACTN ?
Since this is the first document under the "ACTN umbrella" to be adopted by the WG, I think it is fair to expect a definition for "ACTN" to be present in this document and to expect it to be debated thoroughly. I don't understand the reluctance to come up with a definition or point to an existing definition.
Regards,
-Pavan

From: Vishnu Pavan Beeram [mailto:[email-masked]<mailto:[email-masked]>]
Sent: martedì 22 settembre 2015 19:20
To: Lou Berger
Cc: Varma, Eve L (Eve); Daniele Ceccarelli; Leeyoung; [email-masked]<mailto:[email-masked]>; TEAS WG
Subject: Re: [Teas] 答复: Poll on draft-lee-teas-actn-requirements-01 a WG documents

---

From: "BELOTTI, SERGIO (SERGIO)" <[email-masked]>
Date: Tue, 22 Sep 2015 18:06:29 +0000

It is certainly fair as soon as required before WG adoption as WG seems to me already support for this , not after , and before publication. If missed definition, that , btw, I explained you why it is missed in the draft document,  would be a real problem for WG, I guess WG would have expressed needs for this update before WG adoption request.
Any debate as you mention would be on a further version of the document when an update would been required not when WG already expressed support for version 00 adoption.

Regards
Sergio

Sent: martedì 22 settembre 2015 19:52

---

From: Lou Berger <[email-masked]>
Date: Tue, 22 Sep 2015 14:35:25 -0400

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

---

From: Leeyoung <[email-masked]>
Date: Wed, 23 Sep 2015 17:21:58 +0000

Hi Lou and Pavan, 

OK, I think we are converging. I personally have not seen any cases where WG chairs demanded the name change of the adopted work, but this may have been limited to my own experience. With that, we would like to move on and provide the definition of ACTN. 

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. 

-----Original Message-----
From: Lou Berger [mailto:[email-masked]] 
Sent: Tuesday, September 22, 2015 1:35 PM
To: Leeyoung; Vishnu Pavan Beeram
Cc: TEAS WG; Daniele Ceccarelli; Varma, Eve L (Eve); [email-masked]
Subject: Re: [Teas] 答复: Poll on draft-lee-teas-actn-requirements-01 a WG documents

Young,

> precedent in IETF. I’d like to hold all of us accountable to the right 

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.

This question is open to all, so if you think you have a definition that's worth sharing, please chime in.

Thanks,
Lou

---

From: Lou Berger <[email-masked]>
Date: Thu, 24 Sep 2015 08:36:24 -0400

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>

> Young (on behalf of all contributors)

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

---

From: Lou Berger <[email-masked]>
Date: Thu, 24 Sep 2015 08:37:01 -0400

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 process thread>

On 9/23/2015 1:21 PM, Leeyoung wrote:
> Hi Lou and Pavan, 
>
> OK, I think we are converging. I personally have not seen any cases where WG chairs demanded the name change of the adopted work, but this may have been limited to my own experience. 

Yes. It must be.  Perhaps because (a) it isn't an every day occurrence, 
and (b)  I've never seen a set of authors balk to this level on a name
change -- in fact I can't recall *ever* seeing authors protest a change
by a chair.

For examples, take a look at the replaced by section of
http://tools.ietf.org/wg/ccamp/

Another good example is draft-giacalone-ospf-te-express-path which was
replaced by
draft-ospf-te-metric-extensions 

If you/anyone else has questions about WG draft adoption process --
please ask them by replying to this thread.  It seems that there a more
than a few confused on this.

WRT the draft filename:

To me the definition still reads as ACTN is a set of solutions (i.e., =
"new methods and capabilities to support virtual network operations") . 
While this understanding lead us to name the requirements draft
independently from the solution in an attempt to highlight why the
requirements don't apply to existing work, perhaps it would be fine to
tie the two directly together -- I'll talk off line with Pavan.
Either way, vn-orchestration or vn-operation would be/have been a better
choice than vn-controller.

Lou

---

From: Igor Bryskin <[email-masked]>
Date: Thu, 24 Sep 2015 16:29:04 +0000

Hi Young,

I'd add "large-scale" at least in some places where you mention "TE networks". It is the large-scale aspect which points to/ requires new problems to be solved (totally agree with Lou), in particular, the hierarchical abstraction with no limit to the number of hierarchy levels and with both ends (top and bottom) open.

I'd also add:
"Conveying, managing and enforcing client policies with respect to the services provided by the network to said clients"

Regards,
 Igor

-----Original Message-----
From: Teas [mailto:[email-masked]] On Behalf Of Lou Berger
Sent: Thursday, September 24, 2015 8:36 AM
To: Leeyoung <[email-masked]>; Vishnu Pavan Beeram <[email-masked]>
Cc: Varma, Eve L (Eve) <[email-masked]>; Daniele Ceccarelli <[email-masked]>; TEAS WG <[email-masked]>; [email-masked]
Subject: [Teas] Proposed ACTN Definition Text (Re: 答复: Poll on draft-lee-teas-actn-requirements-01 a WG documents)

WG,

Lou

---

From: Leeyoung <[email-masked]>
Date: Thu, 24 Sep 2015 17:21:47 +0000

Hi Lou,

We can tone down what ACTN is as follows:

"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. 

Then I would envision the requirements and solutions can be tied together under the umbrella of ACTN. 

Just my thought.

Regards,
Young

-----Original Message-----
From: Lou Berger [mailto:[email-masked]] 
Sent: Thursday, September 24, 2015 7:37 AM
To: Leeyoung; Vishnu Pavan Beeram
Cc: TEAS WG; Daniele Ceccarelli; Varma, Eve L (Eve); [email-masked]
Subject: WG adoption and draft naming process (Re: [Teas] 答复: Poll on draft-lee-teas-actn-requirements-01 a WG documents)

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.

> OK, I think we are converging. I personally have not seen any cases where WG chairs demanded the name change of the adopted work, but this may have been limited to my own experience. 

Yes. It must be.  Perhaps because (a) it isn't an every day occurrence, and (b)  I've never seen a set of authors balk to this level on a name change -- in fact I can't recall *ever* seeing authors protest a change by a chair.

For examples, take a look at the replaced by section of http://tools.ietf.org/wg/ccamp/

Another good example is draft-giacalone-ospf-te-express-path which was replaced by draft-ospf-te-metric-extensions 

If you/anyone else has questions about WG draft adoption process -- please ask them by replying to this thread.  It seems that there a more than a few confused on this.

WRT the draft filename:

To me the definition still reads as ACTN is a set of solutions (i.e., = "new methods and capabilities to support virtual network operations") . 
While this understanding lead us to name the requirements draft independently from the solution in an attempt to highlight why the requirements don't apply to existing work, perhaps it would be fine to tie the two directly together -- I'll talk off line with Pavan.
Either way, vn-orchestration or vn-operation would be/have been a better choice than vn-controller.

Lou

---

From: Leeyoung <[email-masked]>
Date: Thu, 24 Sep 2015 17:24:44 +0000

Hi Igor,

I think both of your points are very good points. I personally would agree to add those terms to the text. 

Let me give it a try how to fit those wording to the current text and get back to you. Would you mind possibly using "scalable" instead of "large-scale"? It might be a bit easier to put the term in the right place. 

Thanks.
Young

-----Original Message-----
From: Igor Bryskin [mailto:[email-masked]] 
Sent: Thursday, September 24, 2015 11:29 AM
To: Lou Berger; Leeyoung; Vishnu Pavan Beeram
Cc: Varma, Eve L (Eve); Daniele Ceccarelli; TEAS WG; [email-masked]
Subject: RE: [Teas] Proposed ACTN Definition Text (Re: 答复: Poll on draft-lee-teas-actn-requirements-01 a WG documents)

Hi Young,

I'd also add:

Regards,
 Igor

-----Original Message-----
From: Teas [mailto:[email-masked]] On Behalf Of Lou Berger
Sent: Thursday, September 24, 2015 8:36 AM
To: Leeyoung <[email-masked]>; Vishnu Pavan Beeram <[email-masked]>
Cc: Varma, Eve L (Eve) <[email-masked]>; Daniele Ceccarelli <[email-masked]>; TEAS WG <[email-masked]>; [email-masked]
Subject: [Teas] Proposed ACTN Definition Text (Re: 答复: Poll on draft-lee-teas-actn-requirements-01 a WG documents)

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.

On 9/23/2015 1:21 PM, Leeyoung wrote:
> ----------------------------------------------------------------------
> --------------------------------------------------------------
>

WG,

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

> Cc: TEAS WG; Daniele Ceccarelli; Varma, Eve L (Eve); 
>> precedent in IETF. I’d like to hold all of us accountable to the 
>> right procedure.

---

From: Leeyoung <[email-masked]>
Date: Thu, 24 Sep 2015 17:47:32 +0000

Hi Igor,

I would do the following as a first attempt. The new elements are added in double quotes (" ").  

For the first one: 

Abstraction and Control of TE Networks (ACTN) defines new methods and capabilities 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.

Or

Abstraction and Control of TE Networks (ACTN) defines new methods and capabilities to support "scalable" 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.

For the second one:

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." 

Thanks.
Young

-----Original Message-----
From: Leeyoung 
Sent: Thursday, September 24, 2015 12:25 PM
To: 'Igor Bryskin'; Lou Berger; Vishnu Pavan Beeram
Cc: Varma, Eve L (Eve); Daniele Ceccarelli; TEAS WG; [email-masked]
Subject: RE: [Teas] Proposed ACTN Definition Text (Re: 答复: Poll on draft-lee-teas-actn-requirements-01 a WG documents)

Hi Igor,

Thanks.
Young

-----Original Message-----
From: Igor Bryskin [mailto:[email-masked]]
Sent: Thursday, September 24, 2015 11:29 AM
To: Lou Berger; Leeyoung; Vishnu Pavan Beeram
Cc: Varma, Eve L (Eve); Daniele Ceccarelli; TEAS WG; [email-masked]
Subject: RE: [Teas] Proposed ACTN Definition Text (Re: 答复: Poll on draft-lee-teas-actn-requirements-01 a WG documents)

Hi Young,

I'd also add:

Regards,
 Igor

-----Original Message-----
From: Teas [mailto:[email-masked]] On Behalf Of Lou Berger
Sent: Thursday, September 24, 2015 8:36 AM
To: Leeyoung <[email-masked]>; Vishnu Pavan Beeram <[email-masked]>
Cc: Varma, Eve L (Eve) <[email-masked]>; Daniele Ceccarelli <[email-masked]>; TEAS WG <[email-masked]>; [email-masked]
Subject: [Teas] Proposed ACTN Definition Text (Re: 答复: Poll on draft-lee-teas-actn-requirements-01 a WG documents)

WG,

Lou

---

From: Igor Bryskin <[email-masked]>
Date: Thu, 24 Sep 2015 17:55:50 +0000

WRT the first item I like better the first suggestion.
WER the second item what you propose works for me.

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

Hi Igor,

For the first one: 

Or

For the second one:

Thanks.
Young

-----Original Message-----
From: Leeyoung
Sent: Thursday, September 24, 2015 12:25 PM
To: 'Igor Bryskin'; Lou Berger; Vishnu Pavan Beeram
Cc: Varma, Eve L (Eve); Daniele Ceccarelli; TEAS WG; [email-masked]
Subject: RE: [Teas] Proposed ACTN Definition Text (Re: 答复: Poll on draft-lee-teas-actn-requirements-01 a WG documents)

Hi Igor,

Thanks.
Young

-----Original Message-----
From: Igor Bryskin [mailto:[email-masked]]
Sent: Thursday, September 24, 2015 11:29 AM
To: Lou Berger; Leeyoung; Vishnu Pavan Beeram
Cc: Varma, Eve L (Eve); Daniele Ceccarelli; TEAS WG; [email-masked]
Subject: RE: [Teas] Proposed ACTN Definition Text (Re: 答复: Poll on draft-lee-teas-actn-requirements-01 a WG documents)

Hi Young,

I'd also add:

Regards,
 Igor

-----Original Message-----
From: Teas [mailto:[email-masked]] On Behalf Of Lou Berger
Sent: Thursday, September 24, 2015 8:36 AM
To: Leeyoung <[email-masked]>; Vishnu Pavan Beeram <[email-masked]>
Cc: Varma, Eve L (Eve) <[email-masked]>; Daniele Ceccarelli <[email-masked]>; TEAS WG <[email-masked]>; [email-masked]
Subject: [Teas] Proposed ACTN Definition Text (Re: 答复: Poll on draft-lee-teas-actn-requirements-01 a WG documents)

WG,

Lou

---

From: Leeyoung <[email-masked]>
Date: Thu, 24 Sep 2015 18:08:27 +0000

Hi Igor,

Good! We can go with your preference. Other folks may have different ideas or additional comments, so let us wait and see.

Thanks.
Young 

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

Hi Igor,

For the first one: 

Or

For the second one:

Thanks.
Young

-----Original Message-----
From: Leeyoung
Sent: Thursday, September 24, 2015 12:25 PM
To: 'Igor Bryskin'; Lou Berger; Vishnu Pavan Beeram
Cc: Varma, Eve L (Eve); Daniele Ceccarelli; TEAS WG; [email-masked]
Subject: RE: [Teas] Proposed ACTN Definition Text (Re: 答复: Poll on draft-lee-teas-actn-requirements-01 a WG documents)

Hi Igor,

Thanks.
Young

-----Original Message-----
From: Igor Bryskin [mailto:[email-masked]]
Sent: Thursday, September 24, 2015 11:29 AM
To: Lou Berger; Leeyoung; Vishnu Pavan Beeram
Cc: Varma, Eve L (Eve); Daniele Ceccarelli; TEAS WG; [email-masked]
Subject: RE: [Teas] Proposed ACTN Definition Text (Re: 答复: Poll on draft-lee-teas-actn-requirements-01 a WG documents)

Hi Young,

I'd also add:

Regards,
 Igor

-----Original Message-----
From: Teas [mailto:[email-masked]] On Behalf Of Lou Berger
Sent: Thursday, September 24, 2015 8:36 AM
To: Leeyoung <[email-masked]>; Vishnu Pavan Beeram <[email-masked]>
Cc: Varma, Eve L (Eve) <[email-masked]>; Daniele Ceccarelli <[email-masked]>; TEAS WG <[email-masked]>; [email-masked]
Subject: [Teas] Proposed ACTN Definition Text (Re: 答复: Poll on draft-lee-teas-actn-requirements-01 a WG documents)

WG,

Lou

---

From: Lou Berger <[email-masked]>
Date: Thu, 24 Sep 2015 14:22:44 -0400

Young,

> 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

---

From: Leeyoung <[email-masked]>
Date: Thu, 24 Sep 2015 18:41:00 +0000

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. 

-	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.

-----Original Message-----
From: Lou Berger [mailto:[email-masked]] 
Sent: Thursday, September 24, 2015 1:23 PM
To: Leeyoung; Vishnu Pavan Beeram
Cc: Varma, Eve L (Eve); Daniele Ceccarelli; TEAS WG; [email-masked]
Subject: Re: [Teas] Proposed ACTN Definition Text (Re: 答复: Poll on draft-lee-teas-actn-requirements-01 a WG documents)

Young,

Thanks,
Lou

On 9/24/2015 8:36 AM, Lou Berger wrote:
> 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.
>
>> ---------------------------------------------------------------------
>> ---------------------------------------------------------------
>>

---

From: Vishnu Pavan Beeram <[email-masked]>
Date: Thu, 24 Sep 2015 16:06:25 -0400

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 <[email-masked]> wrote:

> 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.
>
> Cc: Varma, Eve L (Eve); Daniele Ceccarelli; TEAS WG;
> Subject: Re: [Teas] Proposed ACTN Definition Text (Re: 答复: Poll on
> draft-lee-teas-actn-requirements-01 a WG documents)
>
> Young,
>
> >> Here's the working version of what ACTN is based on the
> authors/contributors input and based on ACTN framework and problem
> statement drafts.
> >>
> >> 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.
> >>
> 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.
> >>

---

From: "Zhangxian (Xian)" <[email-masked]>
Date: Fri, 25 Sep 2015 00:31:35 +0000

Hi, all,

The updated text looks good to me.

Regards,
Xian

From: Teas [mailto:[email-masked]] On Behalf Of Vishnu Pavan Beeram
Sent: 2015年9月25日 4:06
To: Leeyoung
Cc: [email-masked]; Lou Berger; Daniele Ceccarelli; Varma, Eve L (Eve); TEAS WG
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".

Pavan and Lou

On Thu, Sep 24, 2015 at 2:41 PM, Leeyoung <[email-masked]<mailto:[email-masked]>> wrote:
Hi Lou,

Thanks.
Young

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

Young,

Thanks,
Lou

On 9/24/2015 8:36 AM, Lou Berger wrote:
>> [email-masked]<mailto:[email-masked]>

---

From: "Giovanni Martinelli (giomarti)" <[email-masked]>
Date: Fri, 25 Sep 2015 06:48:20 +0000

Hi all,

ok with text probably a trivial comment: so we are moving away from "flow/tunnels/links" and putting more ephasis on (TE) virtual networks (whatever souce you cook it)  right? Hence I see why  “interconnected”   arise … not beeing in the text, is somewhat implicit or just letf away (or I may be missed some point in past discussion) ?

no storm, just simple clarification. As said I’m also fine with current status

Cheers
G

On 25 Sep 2015, at 02:31, Zhangxian (Xian) <[email-masked]<mailto:[email-masked]>> wrote:

Hi, all,

Regards,
Xian

From: Teas [mailto:[email-masked]] On Behalf Of Vishnu Pavan Beeram
Sent: 2015年9月25日 4:06
To: Leeyoung
Cc: [email-masked]<mailto:[email-masked]>; Lou Berger; Daniele Ceccarelli; Varma, Eve L (Eve); TEAS WG
Subject: Re: [Teas] Proposed ACTN Definition Text (Re: 答复: Poll on draft-lee-teas-actn-requirements-01 a WG documents)

Pavan and Lou

Thanks.
Young

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

Young,

Thanks,
Lou

---

From: Daniele Ceccarelli <[email-masked]>
Date: Fri, 25 Sep 2015 12:12:41 +0000

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:[email-masked]]
Sent: giovedì 24 settembre 2015 22:06
To: Leeyoung
Cc: Lou Berger; Varma, Eve L (Eve); Daniele Ceccarelli; TEAS WG; [email-masked]
Subject: Re: [Teas] Proposed ACTN Definition Text (Re: 答复: Poll on draft-lee-teas-actn-requirements-01 a WG documents)

Pavan and Lou

Thanks.
Young

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

Young,

Thanks,
Lou

---

From: Igor Bryskin <[email-masked]>
Date: Fri, 25 Sep 2015 13:04:01 +0000

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:[email-masked]] On Behalf Of Daniele Ceccarelli
Sent: Friday, September 25, 2015 8:13 AM
To: Vishnu Pavan Beeram <[email-masked]>; Leeyoung <[email-masked]>
Cc: Lou Berger <[email-masked]>; TEAS WG <[email-masked]>; Varma, Eve L (Eve) <[email-masked]>; [email-masked]
Subject: Re: [Teas] Proposed ACTN Definition Text (Re: 答复: Poll on draft-lee-teas-actn-requirements-01 a WG documents)

Thanks
Daniele

From: Vishnu Pavan Beeram [mailto:[email-masked]]
Sent: giovedì 24 settembre 2015 22:06
To: Leeyoung
Cc: Lou Berger; Varma, Eve L (Eve); Daniele Ceccarelli; TEAS WG; [email-masked]<mailto:[email-masked]>
Subject: Re: [Teas] Proposed ACTN Definition Text (Re: 答复: Poll on draft-lee-teas-actn-requirements-01 a WG documents)

Pavan and Lou

Thanks.
Young

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

Young,

Thanks,
Lou

---

From: Daniele Ceccarelli <[email-masked]>
Date: Fri, 25 Sep 2015 13:55:41 +0000

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

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.

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.

I guess what you call “transport service” refers to the infrastructure? Or maybe both infrastructure and connectivity services?

Cheers
Daniele

From: Igor Bryskin [mailto:[email-masked]]
Sent: venerdì 25 settembre 2015 15:04
To: Daniele Ceccarelli; Vishnu Pavan Beeram; Leeyoung
Cc: Lou Berger; TEAS WG; Varma, Eve L (Eve); [email-masked]
Subject: RE: [Teas] Proposed ACTN Definition Text (Re: 答复: Poll on draft-lee-teas-actn-requirements-01 a WG documents)

Daniele,

Cheers,
Igor

From: Teas [mailto:[email-masked]]<mailto:[mailto:[email-masked]]> On Behalf Of Daniele Ceccarelli
Sent: Friday, September 25, 2015 8:13 AM
To: Vishnu Pavan Beeram <[email-masked]<mailto:[email-masked]>>; Leeyoung <[email-masked]<mailto:[email-masked]>>
Cc: Lou Berger <[email-masked]<mailto:[email-masked]>>; TEAS WG <[email-masked]<mailto:[email-masked]>>; Varma, Eve L (Eve) <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [Teas] Proposed ACTN Definition Text (Re: 答复: Poll on draft-lee-teas-actn-requirements-01 a WG documents)

Thanks
Daniele

Pavan and Lou

Thanks.
Young

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

Young,

Thanks,
Lou

---

From: Leeyoung <[email-masked]>
Date: Fri, 25 Sep 2015 15:51:55 +0000

+1,

Thanks,
Young

From: Zhangxian (Xian)
Sent: Thursday, September 24, 2015 7:32 PM
To: Vishnu Pavan Beeram; Leeyoung
Cc: [email-masked]; Lou Berger; Daniele Ceccarelli; Varma, Eve L (Eve); TEAS WG
Subject: RE: [Teas] Proposed ACTN Definition Text (Re: 答复: Poll on draft-lee-teas-actn-requirements-01 a WG documents)

Hi, all,

Regards,
Xian

Pavan and Lou

Thanks.
Young

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

Young,

Thanks,
Lou

---

From: Igor Bryskin <[email-masked]>
Date: Fri, 25 Sep 2015 15:53:44 +0000

Hi Daniele,
Please, see in line.

Igor

From: Daniele Ceccarelli [mailto:[email-masked]]
Sent: Friday, September 25, 2015 9:56 AM
To: Igor Bryskin <[email-masked]>; Vishnu Pavan Beeram <[email-masked]>; Leeyoung <[email-masked]>
Cc: Lou Berger <[email-masked]>; TEAS WG <[email-masked]>; Varma, Eve L (Eve) <[email-masked]>; [email-masked]
Subject: RE: [Teas] Proposed ACTN Definition Text (Re: 答复: Poll on draft-lee-teas-actn-requirements-01 a WG documents)

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?

IB>> The same questions

IB>> Please, see above

Cheers
Daniele

Daniele,

Cheers,
Igor

Thanks
Daniele

Pavan and Lou

Thanks.
Young

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

Young,

Thanks,
Lou

---

From: Leeyoung <[email-masked]>
Date: Fri, 25 Sep 2015 20:45:28 +0000

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

Sent: Friday, September 25, 2015 10:54 AM

Hi Daniele,
Please, see in line.

Igor

Cheers
Daniele

Daniele,

Cheers,
Igor

Thanks
Daniele

Pavan and Lou

Thanks.
Young

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

Young,

Thanks,
Lou

---

From: Daniele Ceccarelli <[email-masked]>
Date: Sat, 26 Sep 2015 18:57:38 +0000

I would like to just comment on the file name.

I would really appreciate keeping the ACTN name for the solution. The reason is probably futile, but now when I say ACTN to a customer or a colleague they would understand what I mean. There are publications, papers and also the ONF and ITUT refer to ACTN (see the incoming liaison), so unless the WG and the chairs strongly feel the need for a different name, I'd really appreciate it to be left unchanged.

That said, I see three options:
1. Widening the scope of the requirements work (hence finding a new name for it) and leaving ACTN as a solution for a sub-set of such requirements. I'm fine with that
2. Keeping the scope of the requirements and solution aligned and as broad as possible. I'm less comfortable with that but it's fine if it doesn't imply changing the name.
3. Not only improving but also changing the scope of the requirements and the solution...please don't do so.

From what you write below
> While this understanding lead us to name the requirements draft independently
> from the solution in an attempt to highlight why the requirements don't apply
> to existing work, perhaps it would be fine to tie the two directly together -- I'll
> talk off line with Pavan.

I tend to understand that you're in favor of option 2...

BR
Daniele

> Sent: giovedì 24 settembre 2015 14:37
> Subject: WG adoption and draft naming process (Re: [Teas] 答复: Poll on draft-
> lee-teas-actn-requirements-01 a WG documents)
> 
> 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.
> 
> > OK, I think we are converging. I personally have not seen any cases where
> WG chairs demanded the name change of the adopted work, but this may have
> been limited to my own experience.
> 
> Yes. It must be.  Perhaps because (a) it isn't an every day occurrence, and (b)
> I've never seen a set of authors balk to this level on a name change -- in fact I
> can't recall *ever* seeing authors protest a change by a chair.
> 
> replaced by draft-ospf-te-metric-extensions
> 
> If you/anyone else has questions about WG draft adoption process -- please ask
> them by replying to this thread.  It seems that there a more than a few
> confused on this.
> 
> > ...
> 
> WRT the draft filename:
> 
> To me the definition still reads as ACTN is a set of solutions (i.e., = "new
> methods and capabilities to support virtual network operations") .
> While this understanding lead us to name the requirements draft independently
> from the solution in an attempt to highlight why the requirements don't apply
> to existing work, perhaps it would be fine to tie the two directly together -- I'll
> talk off line with Pavan.

---

From: Daniele Ceccarelli <[email-masked]>
Date: Sat, 26 Sep 2015 19:29:11 +0000

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?

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 ☺

Cheers
Daniele

From: Leeyoung [mailto:[email-masked]]
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); [email-masked]
Subject: RE: [Teas] Proposed ACTN Definition Text (Re: 答复: Poll on draft-lee-teas-actn-requirements-01 a WG documents)

Hi Igor,

Regards,
Young

Cc: Lou Berger; TEAS WG; Varma, Eve L (Eve); [email-masked]<mailto:[email-masked]>

Hi Daniele,
Please, see in line.

Igor

To: Igor Bryskin <[email-masked]<mailto:[email-masked]>>; Vishnu Pavan Beeram <[email-masked]<mailto:[email-masked]>>; Leeyoung <[email-masked]<mailto:[email-masked]>>

Cheers
Daniele

Cc: Lou Berger; TEAS WG; Varma, Eve L (Eve); [email-masked]<mailto:[email-masked]>

Daniele,

Cheers,
Igor

Thanks
Daniele

Pavan and Lou

Thanks.
Young

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

Young,

Thanks,
Lou

---

From: Lou Berger <[email-masked]>
Date: Sat, 26 Sep 2015 16:17:44 -0400

Daniele,

On September 26, 2015 2:58:14 PM Daniele Ceccarelli 
<[email-masked]> wrote:

> I would really appreciate keeping the ACTN name for the solution.

We hadn't really discussed a renaming of the  solutions docs, only the 
requirements doc which read as pretty generic.

> The reason is probably futile, but now when I say ACTN to a customer or a 
> colleague they would understand what I mean. There are publications, papers 
> and also the ONF and ITUT refer to ACTN (see the incoming liaison), so 
> unless the WG and the chairs strongly feel the need for a different name, 
> I'd really appreciate it to be left unchanged.
>

I'm not sure that arguing for using a marketing name for a set of 
technology solutions helps your case much. But that said,  renaming the 
ACTN solution set isn't something we have discussed or been discussing.

I personally didnt expect a name change  on the solutions drafts,  but am 
ambivalent on the topic. If others hold counter opinions, they should 
express them.  Although,  please note that we have yet to consider any 
solutions documents for WG adoption.

Lou

> 1. Widening the scope of the requirements work (hence finding a new name 
> for it) and leaving ACTN as a solution for a sub-set of such requirements. 
> I'm fine with that
> 2. Keeping the scope of the requirements and solution aligned and as broad 
> as possible. I'm less comfortable with that but it's fine if it doesn't 
> imply changing the name.

---

From: Igor Bryskin <[email-masked]>
Date: Mon, 28 Sep 2015 12:34:26 +0000

Hi Daniele,

Please, see in line.
Cheers,
Igor

From: Daniele Ceccarelli [mailto:[email-masked]]
Sent: Saturday, September 26, 2015 3:29 PM
To: Leeyoung <[email-masked]>; Igor Bryskin <[email-masked]>; Vishnu Pavan Beeram <[email-masked]>
Cc: Lou Berger <[email-masked]>; TEAS WG <[email-masked]>; Varma, Eve L (Eve) <[email-masked]>; [email-masked]
Subject: RE: [Teas] Proposed ACTN Definition Text (Re: 答复: Poll on draft-lee-teas-actn-requirements-01 a WG documents)

Igor,

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?

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

Hi Igor,

Regards,
Young

Hi Daniele,
Please, see in line.

Igor

Cheers
Daniele

Daniele,

Cheers,
Igor

Thanks
Daniele

Pavan and Lou

Thanks.
Young

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

Young,

Thanks,
Lou

---

From: Vishnu Pavan Beeram <[email-masked]>
Date: Mon, 28 Sep 2015 21:58:56 -0400

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 <[email-masked]>
wrote:

> Hi Daniele,
>
>
>
> Please, see in line.
>
> Cheers,
>
> Igor
>
>
>
> *From:* Daniele Ceccarelli [mailto:[email-masked]]
> *Sent:* Saturday, September 26, 2015 3:29 PM
> *To:* Leeyoung <[email-masked]>; Igor Bryskin <
> [email-masked]>; Vishnu Pavan Beeram <[email-masked]>
> *Cc:* Lou Berger <[email-masked]>; TEAS WG <[email-masked]>; Varma, Eve
> L (Eve) <[email-masked]>;
> *Subject:* RE: [Teas] Proposed ACTN Definition Text (Re: 答复: Poll on
> 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:[email-masked] <[email-masked]>]
> *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);
> *Subject:* RE: [Teas] Proposed ACTN Definition Text (Re: 答复: Poll on
> 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.
>
>
>
> 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.
>
>
>
> *From:* Igor Bryskin [mailto:[email-masked]
> <[email-masked]>]
> *Sent:* Friday, September 25, 2015 10:54 AM
> *To:* Daniele Ceccarelli; Vishnu Pavan Beeram; Leeyoung
> *Cc:* Lou Berger; TEAS WG; Varma, Eve L (Eve);
> *Subject:* RE: [Teas] Proposed ACTN Definition Text (Re: 答复: Poll on
> *From:* Daniele Ceccarelli [mailto:[email-masked]
> <[email-masked]>]
> *Sent:* Friday, September 25, 2015 9:56 AM
> *To:* Igor Bryskin <[email-masked]>; Vishnu Pavan Beeram <
> [email-masked]>; Leeyoung <[email-masked]>
> *Cc:* Lou Berger <[email-masked]>; TEAS WG <[email-masked]>; Varma, Eve
> L (Eve) <[email-masked]>;
> *Subject:* RE: [Teas] Proposed ACTN Definition Text (Re: 答复: Poll on
> 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
>
> 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.
>
> 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:[email-masked]
> <[email-masked]>]
> *Sent:* venerdì 25 settembre 2015 15:04
> *To:* Daniele Ceccarelli; Vishnu Pavan Beeram; Leeyoung
> *Cc:* Lou Berger; TEAS WG; Varma, Eve L (Eve);
> *Subject:* RE: [Teas] Proposed ACTN Definition Text (Re: 答复: Poll on
> 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:[email-masked]] *On Behalf Of *Daniele
> Ceccarelli
> *Sent:* Friday, September 25, 2015 8:13 AM
> *To:* Vishnu Pavan Beeram <[email-masked]>; Leeyoung <
> [email-masked]>
> *Cc:* Lou Berger <[email-masked]>; TEAS WG <[email-masked]>; Varma, Eve
> L (Eve) <[email-masked]>;
> *Subject:* Re: [Teas] Proposed ACTN Definition Text (Re: 答复: Poll on
> 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:[email-masked]
> <[email-masked]>]
> *Sent:* giovedì 24 settembre 2015 22:06
> *To:* Leeyoung
> *Cc:* Lou Berger; Varma, Eve L (Eve); Daniele Ceccarelli; TEAS WG;
> *Subject:* Re: [Teas] Proposed ACTN Definition Text (Re: 答复: Poll on

---

From: Leeyoung <[email-masked]>
Date: Tue, 29 Sep 2015 16:11:56 +0000

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

Regards,
-Pavan (and Lou)

On Mon, Sep 28, 2015 at 8:34 AM, Igor Bryskin <[email-masked]>
wrote:

> *Cc:* Lou Berger <[email-masked]>; TEAS WG <[email-masked]>; Varma, 
> Eve L (Eve) <[email-masked]>; 
> 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?
>
>
>
> 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?
>
>
>
> 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
>
>
>
> 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
>
>
>
>
>
> 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.
>
>
>
> 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.
>
>
>
> 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
>
>
>
> *Cc:* Lou Berger <[email-masked]>; TEAS WG <[email-masked]>; Varma, 
> Eve L (Eve) <[email-masked]>; 
> inter=connected by abstract links), overlays supported, for example, 
> by provider native TE topology, could be configured by either 
> provider, client or both
>
> 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.
>
>
>
> infrastructure to connect the clients, e.g. L2VPN, L3VPN. The 
> customers asks for connectivity (with characteristics that will be 
> mapped intor the
> 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
>
>
>
> 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.
>
>
>
> 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
>
>
>
>
>
> *Cc:* Lou Berger <[email-masked]>; TEAS WG <[email-masked]>; Varma, 
> Eve L (Eve) <[email-masked]>; 
> 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

---

From: Vishnu Pavan Beeram <[email-masked]>
Date: Tue, 29 Sep 2015 20:16:51 -0400

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 <[email-masked]> 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?
>
> Cc: Daniele Ceccarelli; Leeyoung; Lou Berger; TEAS WG; Varma, Eve L (Eve);
> We (Lou and I) would like to propose the following additional language
> (see the text on etherpad towards the end of the ACTN definition -
> > connectivity constraints, but these factors may impact how to choose a
> destination of a TE connectivity from a source.
> >
> >
> >

---

From: Daniele Ceccarelli <[email-masked]>
Date: Wed, 30 Sep 2015 15:14:13 +0000

Hi Igor,

Interesting discussion. Sorry for taking so long to reply…very busy period.
Please see in line.

Cheers,
Daniele

From: Igor Bryskin [mailto:[email-masked]]
Sent: lunedì 28 settembre 2015 14:34
To: Daniele Ceccarelli; Leeyoung; Vishnu Pavan Beeram
Cc: Lou Berger; TEAS WG; Varma, Eve L (Eve); [email-masked]<mailto:[email-masked]>
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.
Cheers,
Igor

To: Leeyoung <[email-masked]<mailto:[email-masked]>>; Igor Bryskin <[email-masked]<mailto:[email-masked]>>; Vishnu Pavan Beeram <[email-masked]<mailto:[email-masked]>>

Igor,

DanCec>> Let me elaborate a bit more on this. There are situations in which traffic needs to be moved from one path to another, not only due to a failure, but also due to e.g. congestion or policies violation. I see two ways of moving the traffic, i) rerouting the infrastructure (i.e. LSP rerouting) or ii) remapping the client traffic to a different infrastructure (e.g. go to the ingress and egress nodes and dynamically do FEC (forwarding equivalence class…not forward error correction ☺ ) remapping of a give FEC to a different LSP. This is extremely useful in congestions situations, where offloading traffic from one LSP to a different LSP could help solving the congestion situation. I think this is traffic engineering. I also think that this is something that needs to be done extremely quickly.

DanCec>> It’s so cool to work for such a visionary company, isnt’ it ☺ Here I have to admit that it is a bit more complex to find a relationship with TEAS and Traffic Engineering in the network. Maybe the authors of the two drafts linked by Young below could help us shade some light on that otherwise we can possibly drop this part of the work (if everyone agrees) if we come to the conclusion that there is no room for it in TEAS.

Cheers
Daniele

Hi Igor,

Regards,
Young

Hi Daniele,
Please, see in line.

Igor

Cheers
Daniele

Daniele,

Cheers,
Igor

Thanks
Daniele

Pavan and Lou

Thanks.
Young

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

Young,

Thanks,
Lou