Subject: [Actn] charter 1.4

From: Leeyoung <[email-masked]>
Date: Mon, 8 Dec 2014 23:19:09 +0000

Dear all,

Here's a charter revision (v.1.4) for your comment. Your comment will be appreciated. If there are any key missing items for the WG to work that you feel should be included in the charter or any other discussions on terminology and clarify, please share your views  to the list. We look forward to seeing your active participation.

Best regards,
Young

---------------------------------------------------------------------------------------------
Last Updated: December 5, 2014

Draft Charter V1.4

Abstraction and Control of Transport Networks (ACTN)

Transport networks are defined as network infrastructure that provides
connectivity and bandwidth for customer services. They are characterized
by their ability to support server layer provisioning and traffic
engineering for client layer services, such that resource guarantees may
be provided to their customers. Transport networks here refer to a set
of different type of connection-oriented networks, which include
Connection-Oriented Circuit Switched (CO-CS) networks and Connection-
Oriented Packet Switched (CO-PS) networks. This implies that at least
the following transport networks are in scope: Layer 1 (L1) and Layer 0
(L0) optical networks (e.g., OTN, ODU, OCh/WSON), MPLS-TP, MPLS-TE, as
well as other emerging network technologies with connection-oriented
behavior.

Transport networks have a variety of mechanisms to:

- Facilitate separation of data plane and control plane,

- Allow for distributed signaling or centralized models (e.g., NMS-
  based or centralized signaling) for path setup and protection, and

- Provide traffic engineering mechanism via centralized path
  computation.

These represent key technologies for enabling flexible and dynamic
networking, and efficient control and recovery of resources. Although
these technologies provide significant benefits within a single domain
control boundary, they do not meet the growing need for transport
network virtualization in multi-domain transport networks. More and more
network operators are building and operating on multi-domain transport
networks. These domains (collections of links and nodes) may be each of
a different technology, administrative zones, or vendor-specific
islands. Establishment of end-to-end connections spanning multiple
domains is a perpetual problem for operators because of both operational
concerns (control plane and management plane) and interoperability
issues (control plane and data plane).  Due to these issues, new
services that require connections that traverse multiple domains need
significant planning and often manual operations to interface different
vendor equipment and technology.

The aim of Abstraction and Control of Transport Networks (ACTN) is to
facilitate a centralized virtual network operation: the creation of a
virtualized environment allowing operators to view and control multi-
subnet, multi-technology, multi-vendor domain networks. This will enable
rapid service deployment of new dynamic and elastic services, and will
improve overall network operations and scaling of existing services.
Discussion with operators has also highlighted a need for
virtual network coordination based on the abstraction of underlying
technology and vendor domains as well as virtual service coordination
based on service-related knowledge. Abstraction of transport networks
also allows operators to consolidate their network services into
multi-tenant virtual transport networks.

Virtual network coordination function in ACTN is built on a control
hierarchy where a multi-domain coordinator interacts with the control
mechanism for each domain (e.g., EMS/NMS, GMPLS/PCE control plane, SDN
controller) to represent abstraction of network resources and to provide
control functions for virtual networks. These control functions enable
various services/clients/applications to create and manage their own
virtual networks that share the common transport network resources.

Virtual service coordination function in ACTN incorporates
customer's service-related knowledge in virtual network operation in order to
seamlessly operate virtual networks while meeting customer's service
requirements.

The ACTN facilitates seamless vertical service coordination across
multi-tenant customers (primarily internal service organizations with
respect to a network operator), the control of virtual and physical
network domains, as well as a horizontal E2E service coordination
across multi-domain networks.

The ACTN working group works to develop a high-level architecture that
describes the basic building-blocks necessary to enable the multi-domain
virtual service coordination. It will identify key building components and
the corresponding interfaces among these components. The Key components can
be future building block or legacy components existing today. It will
clearly show the  interaction between the customer controller
and the virtual network controller, and the virtual network controller and
the physical network controllers with possibility for recursion.

The ACTN working group will develop the requirements for these interfaces
and extend existing protocols and data models if necessary with coordination
with other WGs  or to develop new protocols and data models uniquely identified
in scope of ACTN WG.

The ACTN WG will coordinate with the following working groups:

- With the TEAS WG regarding TE architecture and generic TE
   Information and Data Model. ACTN will extend these models
   for its use cases.

- With the CCAMP WG regarding abstraction of technology specific Data
  Models

- With the PCE WG on uses of a PCE in the ACTN architecture.

- With the IDR WG on the use of BGP-LS in ACTN.

In doing this work, the WG will cooperate with external SDOs as
necessary.

The working group will work on the following items:

- Develop an applicability document based on use cases. This work will
  support the architecture and serve as the repository of requirement
  sets that include: support of APIs/protocols and information models.

- Complete architecture that describes the basic building blocks to
  enable virtual network and service coordination.

- Evaluate gap of existing IETF and other protocols, encoding languages
  and data models to fulfill the requirements. Where the need for data
  models is identified, the working group will first examine data models
  already developed by other working groups.

- Work on data models that are uniquely identified in the scope of ACTN.
  It is envisioned to work on issues of security, privacy, and trust in
  mechanisms that provide abstraction across domain boundaries
 (and therefore across trust boundaries) and the abstraction of
  customer's service-specific models.

- Develop protocol extensions as deemed necessary to support unique
  requirements of controller interfaces.

Milestones

May 2015   Adopt the WG draft on the Applicability of ACTN.
Aug 2015   Adopt the WG draft on the ACTN Architecture.
Sep 2015   Adopt the WG draft on Gap Analysis and YANG models.
Nov 2015   Adopt the WG drafts on Protocol Extensions for basic models.
Feb 2016   Submit the Applicability of ACTN to IESG as an informational
           RFC.
                      Adopt the WG drafts on Protocol Extensions for advanced
           models.
Apr 2016   Submit the ACTN Architecture to IESG for review as an
           informational RFC.
May 2016   Submit the Gap Analysis and YANG model(s) document to IESG for
           review as Proposed Standards RFC.
Jul 2016   Submit the Protocol Extensions for basic models to IESG for
           review as Proposed Standards RFCs.
Sep 2016   Submit the Protocol Extensions for advanced models to IESG for
           Review as Proposed Standard RFCs.
Nov 2016   recharter or conclude the WG.

---

From: Zhenghaomian <[email-masked]>
Date: Tue, 9 Dec 2014 02:42:27 +0000

Hi, Young and all,

Great to see the updated charter with description on relationship with other WGs. Please find my comments as follow:

1.       Two terms ‘Virtual network coordination function’ and ‘virtual service coordination function’ in ACTN are described in the charter. It seems to me both individual terms were properly described together with their benifits, however it is not clear to me what is the relationship with ACTN. Are we aim on developing such functions? Are these the only function(s) we need to consider (I don’t have other in my mind, just confirm)?

2.       It was mentioned “It will clearly show the  interaction between the customer controller and the virtual network controller, and the virtual network controller and the physical network controllers with possibility for recursion”.

I don’t know whether there was a change on the terminology ‘customer network controller (CNC)’, it was mentioned in the charter as ‘customer controller’. May need to revise it or skip if the terminology is already changed. Besides, between CNC and VNC, is it limited to 1-to-1? N-to-1 may also be considered, if so, please consider changing to ‘contollers’, just like ‘between VNC and PNCs’.

3.       - With the TEAS WG regarding TE architecture and generic TE  Information and Data Model. ACTN will extend these models  for its use cases.

Should better be ‘ACTN may extend these models for its use cases.’

4.       - With the PCE WG on uses of a PCE in the ACTN architecture.

Should better be ‘With the PCE WG on the uses of PCEs and PCEP in the ACTN architecture.’ My understanding is PCEP MAY be a candidate protocol on related interfaces if we consider any controller as PCE.

Thanks a lot.

Best wishes,
Haomian

发件人: Leeyoung [mailto:[email-masked]]
发送时间: 2014年12月9日 7:19
收件人: [email-masked]
主题: [Actn] charter 1.4

Dear all,

Here’s a charter revision (v.1.4) for your comment. Your comment will be appreciated. If there are any key missing items for the WG to work that you feel should be included in the charter or any other discussions on terminology and clarify, please share your views  to the list. We look forward to seeing your active participation.

Best regards,
Young

Draft Charter V1.4

Milestones

---

From: Leeyoung <[email-masked]>
Date: Tue, 9 Dec 2014 04:13:27 +0000

Hi Haomian,

Thanks for your comment. Please see inline my response.

Best regards,
Young

From: Zhenghaomian
Sent: Monday, December 08, 2014 8:42 PM
To: Leeyoung; [email-masked]
Subject: 答复: [Actn] charter 1.4

Hi, Young and all,

YOUNG>> Yes, these two functions are one of the key functions ACTN solution will develop among other functions. These functions are control functions and the VNC is expected to provide on its interfaces with CNC/PNCs. The core design team is working on the updated framework document and will be made available soon to describe these in details.

YOUNG>> Thanks for pointing this --- it should have been “customer network controller”. It was a typo. CNC-VNC should be N-to-1. Your suggestion clarifies: will change the term to CNCs.

YOUNG>>  I think “will” is a bit more assertive/definitive while “may” is a bit uncertain and ambiguous. I think ACTN “will” most likely extend date models to support its use cases.

YOUNG>> Good point! Some of the debates are if PCEP can be used to support the interface functionality required on VNC-PNCs. At this moment from a requirement perspective, it looks like we need more than what PCEP can support today. Let put on this hold for now until we see full requirement discussion.

Thanks a lot.

Best wishes,
Haomian

Dear all,

Best regards,
Young

Draft Charter V1.4

Milestones

---

From: Kenji Kumaki <[email-masked]>
Date: Tue, 9 Dec 2014 13:33:41 +0900

Hi Young,

Thank you for your update for the charter.
It seems good that the charter includes the context of our draft.

https://tools.ietf.org/html/draft-kumaki-actn-multitenant-vno-00

Thanks,
Kenji

> -----Original Message-----
> From: ACTN [mailto:[email-masked]] On Behalf Of Leeyoung
> Sent: Tuesday, December 09, 2014 8:19 AM
> To: [email-masked]
> Subject: [Actn] charter 1.4
> 
> Dear all,
> 
> 
> 
> Here's a charter revision (v.1.4) for your comment. Your comment will be appreciated. If there are any key missing items
> for the WG to work that you feel should be included in the charter or any other discussions on terminology and clarify,
> please share your views  to the list. We look forward to seeing your active participation.
> 
> 
> 
> Best regards,
> 
> Young
> 
> 
>

---

From: Leeyoung <[email-masked]>
Date: Tue, 9 Dec 2014 14:07:21 +0000

Hi Kenji,

It is great to hear from you. Thanks for pointing to KDDI's use-case. Indeed your use-case draft has been an important draft from which we extracted many requirements for ACTN and even some wording for this charter. 

Best regards,
Young

-----Original Message-----
From: Kenji Kumaki [mailto:[email-masked]] 
Sent: Monday, December 08, 2014 10:34 PM
To: Leeyoung; [email-masked]
Subject: RE: [Actn] charter 1.4

Hi Young,

Thanks,
Kenji

> Here's a charter revision (v.1.4) for your comment. Your comment will 
> be appreciated. If there are any key missing items for the WG to work 
> that you feel should be included in the charter or any other discussions on terminology and clarify, please share your views  to the list. We look forward to seeing your active participation.
> 
> 
> 
> Best regards,
> 
> Young
> 
> 
>

---

From: <[email-masked]>
Date: Tue, 9 Dec 2014 15:11:28 +0000 (UTC)

Dear Young,
Very well written Charter proposal.  Here are a couple of my input.
1.  The charter mentioned traffic engineering and resource guarantee.   I would like to add performance guarantee to the mix as well.  The most critical performance guarantee is latency.2.  Another aspect of the transport network control is location control.  Abstraction, presentation, and the use of location information to make path placement decisions can be a valuable addition to the traditional traffic engineering path placement tools such as "include" "exclude".  
I understand my input might not be crystal clear for people because I do not have a requirement and use case draft describing them clearly.  I can still hope that I will eventually get to it soon :)  
The current charter is quite long and detailed, which is good to demonstrate the valuable work ahead, but I am afraid you might be roughed up to cut the scope in half if not more.  That's the reality of focus vs. vision at work :)   Ning So972-955-0914
      From: Leeyoung <[email-masked]>
 To: "[email-masked]" <[email-masked]> 
 Sent: Monday, December 8, 2014 5:19 PM
 Subject: [Actn] charter 1.4
   
 <!--#yiv0505864247 _filtered #yiv0505864247 {font-family:"Cambria Math";panose-1:2 4 5 3 5 4 6 3 2 4;} _filtered #yiv0505864247 {font-family:Calibri;panose-1:2 15 5 2 2 2 4 3 2 4;}#yiv0505864247 #yiv0505864247 p.yiv0505864247MsoNormal, #yiv0505864247 li.yiv0505864247MsoNormal, #yiv0505864247 div.yiv0505864247MsoNormal {margin:0in;margin-bottom:.0001pt;font-size:11.0pt;font-family:"Calibri", "sans-serif";}#yiv0505864247 a:link, #yiv0505864247 span.yiv0505864247MsoHyperlink {color:blue;text-decoration:underline;}#yiv0505864247 a:visited, #yiv0505864247 span.yiv0505864247MsoHyperlinkFollowed {color:purple;text-decoration:underline;}#yiv0505864247 span.yiv0505864247EmailStyle17 {font-family:"Calibri", "sans-serif";color:windowtext;}#yiv0505864247 .yiv0505864247MsoChpDefault {} _filtered #yiv0505864247 {margin:1.0in 1.0in 1.0in 1.0in;}#yiv0505864247 div.yiv0505864247WordSection1 {}-->Dear all,     Here’s a charter revision (v.1.4) for your comment. Your comment will be appreciated. If there are any key missing items for the WG to work that you feel should be included in the charter or any other discussions on terminology and clarify, please share your views  to the list. We look forward to seeing your active participation.    Best regards, Young     --------------------------------------------------------------------------------------------- Last Updated: December 5, 2014    Draft Charter V1.4    Abstraction and Control of Transport Networks (ACTN)    Transport networks are defined as network infrastructure that provides connectivity and bandwidth for customer services. They are characterized by their ability to support server layer provisioning and traffic engineering for client layer services, such that resource guarantees may be provided to their customers. Transport networks here refer to a set of different type of connection-oriented networks, which include Connection-Oriented Circuit Switched (CO-CS) networks and Connection- Oriented Packet Switched (CO-PS) networks. This implies that at least the following transport networks are in scope: Layer 1 (L1) and Layer 0 (L0) optical networks (e.g., OTN, ODU, OCh/WSON), MPLS-TP, MPLS-TE, as well as other emerging network technologies with connection-oriented behavior.    Transport networks have a variety of mechanisms to:    - Facilitate separation of data plane and control plane,    - Allow for distributed signaling or centralized models (e.g., NMS-   based or centralized signaling) for path setup and protection, and    - Provide traffic engineering mechanism via centralized path   computation.    These represent key technologies for enabling flexible and dynamic networking, and efficient control and recovery of resources. Although these technologies provide significant benefits within a single domain control boundary, they do not meet the growing need for transport network virtualization in multi-domain transport networks. More and more network operators are building and operating on multi-domain transport networks. These domains (collections of links and nodes) may be each of a different technology, administrative zones, or vendor-specific islands. Establishment of end-to-end connections spanning multiple domains is a perpetual problem for operators because of both operational concerns (control plane and management plane) and interoperability issues (control plane and data plane).  Due to these issues, new services that require connections that traverse multiple domains need significant planning and often manual operations to interface different vendor equipment and technology.    The aim of Abstraction and Control of Transport Networks (ACTN) is to facilitate a centralized virtual network operation: the creation of a virtualized environment allowing operators to view and control multi- subnet, multi-technology, multi-vendor domain networks. This will enable rapid service deployment of new dynamic and elastic services, and will improve overall network operations and scaling of existing services. Discussion with operators has also highlighted a need for  virtual network coordination based on the abstraction of underlying technology and vendor domains as well as virtual service coordination based on service-related knowledge. Abstraction of transport networks also allows operators to consolidate their network services into multi-tenant virtual transport networks.    Virtual network coordination function in ACTN is built on a control hierarchy where a multi-domain coordinator interacts with the control mechanism for each domain (e.g., EMS/NMS, GMPLS/PCE control plane, SDN controller) to represent abstraction of network resources and to provide control functions for virtual networks. These control functions enable various services/clients/applications to create and manage their own virtual networks that share the common transport network resources.    Virtual service coordination function in ACTN incorporates  customer's service-related knowledge in virtual network operation in order to seamlessly operate virtual networks while meeting customer's service requirements.     The ACTN facilitates seamless vertical service coordination across multi-tenant customers (primarily internal service organizations with respect to a network operator), the control of virtual and physical network domains, as well as a horizontal E2E service coordination across multi-domain networks.     The ACTN working group works to develop a high-level architecture that describes the basic building-blocks necessary to enable the multi-domain virtual service coordination. It will identify key building components and the corresponding interfaces among these components. The Key components can be future building block or legacy components existing today. It will clearly show the  interaction between the customer controller and the virtual network controller, and the virtual network controller and the physical network controllers with possibility for recursion.    The ACTN working group will develop the requirements for these interfaces and extend existing protocols and data models if necessary with coordination with other WGs  or to develop new protocols and data models uniquely identified in scope of ACTN WG.      The ACTN WG will coordinate with the following working groups:    - With the TEAS WG regarding TE architecture and generic TE     Information and Data Model. ACTN will extend these models    for its use cases.      - With the CCAMP WG regarding abstraction of technology specific Data   Models     - With the PCE WG on uses of a PCE in the ACTN architecture.    - With the IDR WG on the use of BGP-LS in ACTN.    In doing this work, the WG will cooperate with external SDOs as necessary.    The working group will work on the following items:    - Develop an applicability document based on use cases. This work will   support the architecture and serve as the repository of requirement   sets that include: support of APIs/protocols and information models.   - Complete architecture that describes the basic building blocks to   enable virtual network and service coordination.    - Evaluate gap of existing IETF and other protocols, encoding languages   and data models to fulfill the requirements. Where the need for data   models is identified, the working group will first examine data models   already developed by other working groups.    - Work on data models that are uniquely identified in the scope of ACTN.   It is envisioned to work on issues of security, privacy, and trust in   mechanisms that provide abstraction across domain boundaries  (and therefore across trust boundaries) and the abstraction of   customer's service-specific models.     - Develop protocol extensions as deemed necessary to support unique   requirements of controller interfaces.     Milestones    May 2015   Adopt the WG draft on the Applicability of ACTN. Aug 2015   Adopt the WG draft on the ACTN Architecture. Sep 2015   Adopt the WG draft on Gap Analysis and YANG models. Nov 2015   Adopt the WG drafts on Protocol Extensions for basic models. Feb 2016   Submit the Applicability of ACTN to IESG as an informational            RFC.                       Adopt the WG drafts on Protocol Extensions for advanced            models.  Apr 2016   Submit the ACTN Architecture to IESG for review as an            informational RFC. May 2016   Submit the Gap Analysis and YANG model(s) document to IESG for            review as Proposed Standards RFC. Jul 2016   Submit the Protocol Extensions for basic models to IESG for            review as Proposed Standards RFCs.  Sep 2016   Submit the Protocol Extensions for advanced models to IESG for            Review as Proposed Standard RFCs.  Nov 2016   recharter or conclude the WG. 
_______________________________________________
ACTN mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/actn

---

From: "Andrew G. Malis" <[email-masked]>
Date: Tue, 9 Dec 2014 10:31:33 -0500

Young,

This is a very good looking charter. I have one comment on the following
paragraph:

> seamlessly operate virtual networks while meeting customer's service
Given that ongoing operation (not just (virtual) network or service
provisioning) would be in charter, should there be an explicit mention of
operational OAM coordination across domain boundaries, and also
architectural, modeling, and protocol coordination with the LIME WG?

Cheers,
Andy

---

From: Leeyoung <[email-masked]>
Date: Tue, 9 Dec 2014 15:56:25 +0000

Hi Ning,

Your two points are excellent points. Although it was said implicitly with the term, “customer’s service requirement” the term you coined, performance guarantee captures well with latency. Please see the below suggested text that includes “performance guarantee”.

Location control is captured as part of customer’s location profile and policy in the upcoming framework revision in details. We can be a bit more explicit when discussing customer’s service requirement. Please see the following paragraph in which your suggested text is shown in bold and italic.

Virtual service coordination function in ACTN incorporates
customer's service-related knowledge in virtual network operation in order to
seamlessly operate virtual networks while meeting customer's service
requirements (e.g., performance guarantee such as latency, etc.).
Customer service-related knowledge includes customer’s endpoint
location information and its specific policy that affects path placement decision.

As for the length of the charter, do you have any suggestion as to how to the charter statement? Perhaps, we can cut some of the introduction paragraph if you will. Let us know.

Thanks,
Young
From: ACTN [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Tuesday, December 09, 2014 9:11 AM
To: Leeyoung; [email-masked]
Subject: Re: [Actn] charter 1.4

Dear Young,

1.  The charter mentioned traffic engineering and resource guarantee.   I would like to add performance guarantee to the mix as well.  The most critical performance guarantee is latency.
2.  Another aspect of the transport network control is location control.  Abstraction, presentation, and the use of location information to make path placement decisions can be a valuable addition to the traditional traffic engineering path placement tools such as "include" "exclude".

The current charter is quite long and detailed, which is good to demonstrate the valuable work ahead, but I am afraid you might be roughed up to cut the scope in half if not more.  That's the reality of focus vs. vision at work :)

Ning So
972-955-0914

________________________________

Dear all,

Best regards,
Young

Draft Charter V1.4

Milestones

_______________________________________________
ACTN mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/actn

---

From: Leeyoung <[email-masked]>
Date: Tue, 9 Dec 2014 16:32:39 +0000

Hi Andy,

Very good point you are raising. Actually as for the LIME WG coordination, Carlos (LIME WG’s co-chair) and I have touched base already in Honolulu to ensure there will be a close coordination between LIME and ACTN.

How about, adding another dashed item at the end of this text (in bold and italic)

-With the LIME WG on architectural, modeling, and protocol coordination for OAM.

As for your suggestion to include operational OAM coordination across domain boundaries, I agree with you.
Will you be able to suggest specific text perhaps to the quoted paragraph?

Thanks,
Young

From: Andrew G. Malis [mailto:[email-masked]]
Sent: Tuesday, December 09, 2014 9:32 AM
To: Leeyoung
Cc: [email-masked]
Subject: Re: [Actn] charter 1.4

Young,

This is a very good looking charter. I have one comment on the following paragraph:

Given that ongoing operation (not just (virtual) network or service provisioning) would be in charter, should there be an explicit mention of operational OAM coordination across domain boundaries, and also architectural, modeling, and protocol coordination with the LIME WG?

Cheers,
Andy

---

From: AshwoodsmithPeter <[email-masked]>
Date: Tue, 9 Dec 2014 16:52:39 +0000

Thanks Young,

After a very quick reading have things:

1-      Minor point:
       “control multi-subnet, multi-technology, multi-vendor domain networks”

      Suggest that “subnet” is a not the right term given its explicit meaning for L3 .. unless that’s what you meant?
      Perhaps just spell it out “sub-network”

2-      Quick question:

“other emerging network technologies with connection-oriented
behavior.”

Would that include Segment Routing?

Peter

From: ACTN [mailto:[email-masked]] On Behalf Of Leeyoung
Sent: Monday, December 08, 2014 11:13 PM
To: Zhenghaomian; [email-masked]
Subject: Re: [Actn] charter 1.4

Hi Haomian,

Best regards,
Young

From: Zhenghaomian
Sent: Monday, December 08, 2014 8:42 PM
To: Leeyoung; [email-masked]<mailto:[email-masked]>
Subject: 答复: [Actn] charter 1.4

Hi, Young and all,

Thanks a lot.

Best wishes,
Haomian

发件人: Leeyoung [mailto:[email-masked]]
发送时间: 2014年12月9日 7:19
收件人: [email-masked]<mailto:[email-masked]>
主题: [Actn] charter 1.4

Dear all,

Best regards,
Young

Draft Charter V1.4

Milestones

---

From: <[email-masked]>
Date: Tue, 9 Dec 2014 16:54:09 +0000 (UTC)

Young,
I am good with the change proposed.  
I actually like the longer version of the charter statement.  Let it stand as is and see.   Ning So972-955-0914
      From: Leeyoung <[email-masked]>
 To: "[email-masked]" <[email-masked]>; "[email-masked]" <[email-masked]> 
 Sent: Tuesday, December 9, 2014 9:56 AM
 Subject: RE: [Actn] charter 1.4
   
#yiv0075716402 #yiv0075716402 -- _filtered #yiv0075716402 {font-family:Helvetica;panose-1:2 11 6 4 2 2 2 2 2 4;} _filtered #yiv0075716402 {panose-1:2 4 5 3 5 4 6 3 2 4;} _filtered #yiv0075716402 {font-family:Calibri;panose-1:2 15 5 2 2 2 4 3 2 4;} _filtered #yiv0075716402 {font-family:Tahoma;panose-1:2 11 6 4 3 5 4 4 2 4;}#yiv0075716402 #yiv0075716402 p.yiv0075716402MsoNormal, #yiv0075716402 li.yiv0075716402MsoNormal, #yiv0075716402 div.yiv0075716402MsoNormal {margin:0in;margin-bottom:.0001pt;font-size:12.0pt;}#yiv0075716402 a:link, #yiv0075716402 span.yiv0075716402MsoHyperlink {color:blue;text-decoration:underline;}#yiv0075716402 a:visited, #yiv0075716402 span.yiv0075716402MsoHyperlinkFollowed {color:purple;text-decoration:underline;}#yiv0075716402 p.yiv0075716402msonormal, #yiv0075716402 li.yiv0075716402msonormal, #yiv0075716402 div.yiv0075716402msonormal {margin-right:0in;margin-left:0in;font-size:12.0pt;}#yiv0075716402 p.yiv0075716402msonormal1, #yiv0075716402 li.yiv0075716402msonormal1, #yiv0075716402 div.yiv0075716402msonormal1 {margin:0in;margin-bottom:.0001pt;font-size:11.0pt;}#yiv0075716402 span.yiv0075716402msohyperlink {}#yiv0075716402 span.yiv0075716402msohyperlinkfollowed {}#yiv0075716402 span.yiv0075716402emailstyle17 {}#yiv0075716402 span.yiv0075716402msohyperlink1 {color:blue;text-decoration:underline;}#yiv0075716402 span.yiv0075716402msohyperlinkfollowed1 {color:purple;text-decoration:underline;}#yiv0075716402 span.yiv0075716402emailstyle171 {color:windowtext;}#yiv0075716402 span.yiv0075716402EmailStyle25 {color:#1F497D;}#yiv0075716402 .yiv0075716402MsoChpDefault {font-size:10.0pt;} _filtered #yiv0075716402 {margin:1.0in 1.0in 1.0in 1.0in;}#yiv0075716402 div.yiv0075716402WordSection1 {}#yiv0075716402 Hi Ning,    Your two points are excellent points. Although it was said implicitly with the term, “customer’s service requirement” the term you coined, performance guarantee captures well with latency. Please see the below suggested text that includes “performance guarantee”.    Location control is captured as part of customer’s location profile and policy in the upcoming framework revision in details. We can be a bit more explicit when discussing customer’s service requirement. Please see the following paragraph in which your suggested text is shown in bold and italic.    Virtual service coordination function in ACTN incorporates customer's service-related knowledge in virtual network operation in order to seamlessly operate virtual networks while meeting customer's service requirements(e.g., performance guarantee such as latency, etc.).  Customer service-related knowledge includes customer’s endpoint location information and its specific policy that affects path placement decision.    As for the length of the charter, do you have any suggestion as to how to the charter statement? Perhaps, we can cut some of the introduction paragraph if you will. Let us know.     Thanks, Young 

From: ACTN [mailto:[email-masked]]On Behalf Of [email-masked]
Sent: Tuesday, December 09, 2014 9:11 AM
To: Leeyoung; [email-masked]
Subject: Re: [Actn] charter 1.4    Dear Young,    Very well written Charter proposal.  Here are a couple of my input.    1.  The charter mentioned traffic engineering and resource guarantee.   I would like to add performance guarantee to the mix as well.  The most critical performance guarantee is latency. 2.  Another aspect of the transport network control is location control.  Abstraction, presentation, and the use of location information to make path placement decisions can be a valuable addition to the traditional traffic engineering path placement tools such as "include" "exclude".      I understand my input might not be crystal clear for people because I do not have a requirement and use case draft describing them clearly.  I can still hope that I will eventually get to it soon :)      The current charter is quite long and detailed, which is good to demonstrate the valuable work ahead, but I am afraid you might be roughed up to cut the scope in half if not more.  That's the reality of focus vs. vision at work :)     Ning So 972-955-0914    From: Leeyoung <[email-masked]>
To: "[email-masked]" <[email-masked]> 
Sent: Monday, December 8, 2014 5:19 PM
Subject: [Actn] charter 1.4    Dear all,   Here’s a charter revision (v.1.4) for your comment. Your comment will be appreciated. If there are any key missing items for the WG to work that you feel should be included in the charter or any other discussions on terminology and clarify, please share your views  to the list. We look forward to seeing your active participation.   Best regards, Young   --------------------------------------------------------------------------------------------- Last Updated: December 5, 2014   Draft Charter V1.4   Abstraction and Control of Transport Networks (ACTN)   Transport networks are defined as network infrastructure that provides connectivity and bandwidth for customer services. They are characterized by their ability to support server layer provisioning and traffic engineering for client layer services, such that resource guarantees may be provided to their customers. Transport networks here refer to a set of different type of connection-oriented networks, which include Connection-Oriented Circuit Switched (CO-CS) networks and Connection- Oriented Packet Switched (CO-PS) networks. This implies that at least the following transport networks are in scope: Layer 1 (L1) and Layer 0 (L0) optical networks (e.g., OTN, ODU, OCh/WSON), MPLS-TP, MPLS-TE, as well as other emerging network technologies with connection-oriented behavior.   Transport networks have a variety of mechanisms to:   - Facilitate separation of data plane and control plane,   - Allow for distributed signaling or centralized models (e.g., NMS-   based or centralized signaling) for path setup and protection, and   - Provide traffic engineering mechanism via centralized path   computation.   These represent key technologies for enabling flexible and dynamic networking, and efficient control and recovery of resources. Although these technologies provide significant benefits within a single domain control boundary, they do not meet the growing need for transport network virtualization in multi-domain transport networks. More and more network operators are building and operating on multi-domain transport networks. These domains (collections of links and nodes) may be each of a different technology, administrative zones, or vendor-specific islands. Establishment of end-to-end connections spanning multiple domains is a perpetual problem for operators because of both operational concerns (control plane and management plane) and interoperability issues (control plane and data plane).  Due to these issues, new services that require connections that traverse multiple domains need significant planning and often manual operations to interface different vendor equipment and technology.   The aim of Abstraction and Control of Transport Networks (ACTN) is to facilitate a centralized virtual network operation: the creation of a virtualized environment allowing operators to view and control multi- subnet, multi-technology, multi-vendor domain networks. This will enable rapid service deployment of new dynamic and elastic services, and will improve overall network operations and scaling of existing services. Discussion with operators has also highlighted a need for virtual network coordination based on the abstraction of underlying technology and vendor domains as well as virtual service coordination based on service-related knowledge. Abstraction of transport networks also allows operators to consolidate their network services into multi-tenant virtual transport networks.   Virtual network coordination function in ACTN is built on a control hierarchy where a multi-domain coordinator interacts with the control mechanism for each domain (e.g., EMS/NMS, GMPLS/PCE control plane, SDN controller) to represent abstraction of network resources and to provide control functions for virtual networks. These control functions enable various services/clients/applications to create and manage their own virtual networks that share the common transport network resources.   Virtual service coordination function in ACTN incorporates customer's service-related knowledge in virtual network operation in order to seamlessly operate virtual networks while meeting customer's service requirements.   The ACTN facilitates seamless vertical service coordination across multi-tenant customers (primarily internal service organizations with respect to a network operator), the control of virtual and physical network domains, as well as a horizontal E2E service coordination across multi-domain networks.   The ACTN working group works to develop a high-level architecture that describes the basic building-blocks necessary to enable the multi-domain virtual service coordination. It will identify key building components and the corresponding interfaces among these components. The Key components can be future building block or legacy components existing today. It will clearly show the  interaction between the customer controller and the virtual network controller, and the virtual network controller and the physical network controllers with possibility for recursion.   The ACTN working group will develop the requirements for these interfaces and extend existing protocols and data models if necessary with coordination with other WGs  or to develop new protocols and data models uniquely identified in scope of ACTN WG.    The ACTN WG will coordinate with the following working groups:   - With the TEAS WG regarding TE architecture and generic TE    Information and Data Model. ACTN will extend these models    for its use cases.     - With the CCAMP WG regarding abstraction of technology specific Data   Models   - With the PCE WG on uses of a PCE in the ACTN architecture.   - With the IDR WG on the use of BGP-LS in ACTN.   In doing this work, the WG will cooperate with external SDOs as necessary.   The working group will work on the following items:   - Develop an applicability document based on use cases. This work will   support the architecture and serve as the repository of requirement   sets that include: support of APIs/protocols and information models.   - Complete architecture that describes the basic building blocks to   enable virtual network and service coordination.   - Evaluate gap of existing IETF and other protocols, encoding languages   and data models to fulfill the requirements. Where the need for data   models is identified, the working group will first examine data models   already developed by other working groups.   - Work on data models that are uniquely identified in the scope of ACTN.   It is envisioned to work on issues of security, privacy, and trust in   mechanisms that provide abstraction across domain boundaries  (and therefore across trust boundaries) and the abstraction of   customer's service-specific models.   - Develop protocol extensions as deemed necessary to support unique   requirements of controller interfaces.   Milestones   May 2015   Adopt the WG draft on the Applicability of ACTN. Aug 2015   Adopt the WG draft on the ACTN Architecture. Sep 2015   Adopt the WG draft on Gap Analysis and YANG models. Nov 2015   Adopt the WG drafts on Protocol Extensions for basic models. Feb 2016   Submit the Applicability of ACTN to IESG as an informational            RFC.                       Adopt the WG drafts on Protocol Extensions for advanced            models. Apr 2016   Submit the ACTN Architecture to IESG for review as an            informational RFC. May 2016   Submit the Gap Analysis and YANG model(s) document to IESG for            review as Proposed Standards RFC. Jul 2016   Submit the Protocol Extensions for basic models to IESG for            review as Proposed Standards RFCs. Sep 2016   Submit the Protocol Extensions for advanced models to IESG for            Review as Proposed Standard RFCs. Nov 2016   recharter or conclude the WG. 
_______________________________________________
ACTN mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/actn

---

From: Leeyoung <[email-masked]>
Date: Tue, 9 Dec 2014 17:01:30 +0000

Hi Peter,

Thanks for your comment. Both are very good points.

Yes, subnet is L3 lingo. We meant sub-network. Will correct.

As for Segment Routing, there have been some debate if Segment Routing is a connection-oriented technology or not. Some disagreed and we have taken the term out of the charter and other ACTN document.
Do you have a strong opinion about Segment Routing to be included here? We are less concerned about domain control technology (whether it is MPLS-TE/TP or Segment Routing), but do you see any implication that may affect the way ACTN will operate?

Thanks,
Young

From: AshwoodsmithPeter
Sent: Tuesday, December 09, 2014 10:53 AM
To: Leeyoung; Zhenghaomian; [email-masked]
Subject: RE: [Actn] charter 1.4

Thanks Young,

1-      Minor point:

2-      Quick question:

Peter

Hi Haomian,

Best regards,
Young

From: Zhenghaomian

Hi, Young and all,

Thanks a lot.

Best wishes,
Haomian

Dear all,

Best regards,
Young

Draft Charter V1.4

Milestones

---

From: "Andrew G. Malis" <[email-masked]>
Date: Tue, 9 Dec 2014 12:31:12 -0500

Young,

Good addition for the LIME WG reference.

With regards to the quoted paragraph, how about:

customer's service-related knowledge in virtual network operation in order
to

requirements. This may require OAM coordination across domain boundaries.

Cheers,

Andy

On Tue, Dec 9, 2014 at 11:32 AM, Leeyoung <[email-masked]> wrote:

>  Hi Andy,
>
>
>
> Very good point you are raising. Actually as for the LIME WG coordination,
> Carlos (LIME WG’s co-chair) and I have touched base already in Honolulu to
> ensure there will be a close coordination between LIME and ACTN.
>
>
>
> *-With the LIME WG on **architectural, modeling, and protocol
> coordination for OAM.*
>
>
>
> *From:* Andrew G. Malis [mailto:[email-masked]]
> *Sent:* Tuesday, December 09, 2014 9:32 AM
> *To:* Leeyoung
> *Cc:* [email-masked]
> *Subject:* Re: [Actn] charter 1.4
>
>
>
> Young,
>
>
>

---

From: AshwoodsmithPeter <[email-masked]>
Date: Tue, 9 Dec 2014 18:40:29 +0000

Hey Young,

IMHO – Segment Routing when you are strict with the Segments (ie no loose hops) is pretty much equivalent to MPLS-TP/TE in its ability to precisely steer traffic and is therefore “Connection Oriented”.

Personally I see a lot of value in similar logic to control a hierarchy of CO tunnels:

L0 Lambda or fiber/space
L1 Time
L2.5 (MPLS-TE/TP/Strict Segment)

So perhaps the answer is if we include L2.5, then Strict Segment routing is included, otherwise MPLS-TE/TP drop out too?

However I can imagine there is a lot of politics around this which must also be factored in.

Peter

From: Leeyoung
Sent: Tuesday, December 09, 2014 12:02 PM
To: AshwoodsmithPeter; Zhenghaomian; [email-masked]
Subject: RE: [Actn] charter 1.4

Hi Peter,

Thanks,
Young

From: AshwoodsmithPeter
Sent: Tuesday, December 09, 2014 10:53 AM
To: Leeyoung; Zhenghaomian; [email-masked]<mailto:[email-masked]>
Subject: RE: [Actn] charter 1.4

Thanks Young,

1-      Minor point:

2-      Quick question:

Peter

From: ACTN [mailto:[email-masked]] On Behalf Of Leeyoung
Sent: Monday, December 08, 2014 11:13 PM
To: Zhenghaomian; [email-masked]<mailto:[email-masked]>
Subject: Re: [Actn] charter 1.4

Hi Haomian,

Best regards,
Young

From: Zhenghaomian

Hi, Young and all,

Thanks a lot.

Best wishes,
Haomian

Dear all,

Best regards,
Young

Draft Charter V1.4

Milestones

---

From: AshwoodsmithPeter <[email-masked]>
Date: Tue, 9 Dec 2014 19:43:47 +0000

Young,

I offer up a slightly more compact but mostly equivalent first few sentences for your consideration. I also think its cleaner if you describe the services as being CO rather than the network being CO.

"Transport networks are defined as network infrastructure that provides connection oriented,  bandwidth guaranteed and resilient connectivity as client layer services. Both Connection-Oriented Circuit Switched (CO-CS) and Connection-Oriented Packet Switched services are in scope. This implies that at least the following transport networks are in scope...."

Peter

Transport networks are defined as network infrastructure that provides
connectivity and bandwidth for customer services.

They are characterized

Milestones

---

From: Khuzema Pithewan <[email-masked]>
Date: Tue, 9 Dec 2014 22:08:03 +0000

Hi,

Need for OAM co-ordination across domain boundaries leads me to think about

·         need for protection aspect of services from flexibility standpoint for multi-layer network i.e. ability to choose layers for protection in a multi-layer environment for a given end-2-end service.

Another important aspect of network operation is achieving efficiency in network utilization. This may mean re-grooming of existing services from time to time. May be this aspect is part of service elasticity to an extent (not sure though).

One more point, may not be part of charter. Since ACTN framework will contain multiple components which would work with each other in tandem, the coherency of operation of ACTN framework should be ensured.

To generalize, reliability aspect need to captured in the charter.

Thanks
Khuzema

From: ACTN [mailto:[email-masked]] On Behalf Of Andrew G. Malis
Sent: Tuesday, December 09, 2014 9:31 AM
To: Leeyoung
Cc: [email-masked]
Subject: Re: [Actn] charter 1.4

Young,

Cheers,
Andy

On Tue, Dec 9, 2014 at 11:32 AM, Leeyoung <[email-masked]<mailto:[email-masked]>> wrote:
Hi Andy,

Thanks,
Young

From: Andrew G. Malis [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Tuesday, December 09, 2014 9:32 AM
To: Leeyoung
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [Actn] charter 1.4

Young,

Cheers,
Andy

---

From: Leeyoung <[email-masked]>
Date: Wed, 10 Dec 2014 03:39:34 +0000

Hi Peter,

I support your more compact description of transport networks.

Let's wait if there are other opinions.

Thanks,
Young

From: AshwoodsmithPeter
Sent: Tuesday, December 09, 2014 1:44 PM
To: Leeyoung; Zhenghaomian; [email-masked]
Subject: RE: [Actn] charter 1.4

Young,

Peter

They are characterized

Milestones

---

From: Leeyoung <[email-masked]>
Date: Thu, 11 Dec 2014 01:45:21 +0000

Hi Khuzema,

Thanks for brining interesting discussion points.

Please see inline for my comment.

Thanks,
Young

From: Khuzema Pithewan [mailto:[email-masked]]
Sent: Tuesday, December 09, 2014 4:08 PM
To: Andrew G. Malis; Leeyoung
Cc: [email-masked]
Subject: RE: [Actn] charter 1.4

Hi,

YOUNG>> Your first point on the ability to choose multi-layer protection, are you referring to CNC’s (customer) policy or the VNC’s (multi-domain coordinator) policy, or both?

-          There is a requirement for a VN survivability from customers. But customer may not be aware of multi-layer aspect of operator’s networks. In such case, the VNC has to determine the proper protection mechanism to meet this customer’s VN survivability requirement.

-          Or you are talking about operator’s ability to coordinate packet/optical protection mechanism from a network control perspective?

YOUNG>>  If I understand correctly, you are saying we need a way to re-optimize existing connections to achieve a better network utilization. To achieve this, we need a periodic network performance statistics across PNC, VNC and CNC to allow seamless and consistent policy decision. If this is what you are talking about, there is a use-case: please check if this use-case fits what you are referring to: https://datatracker.ietf.org/doc/draft-xu-actn-perf-dynamic-service-control/ (This is in scope of ACTN).

YOUNG>>  Are you talking about the need for seamless operation for multi-domain networks from a control plane perspective or data plane perspective? If the latter, that is out of scope of ACTN; if the former, then, we need to consider that aspect. One requirement from an operator is the multi-domain coordinator (VNC) would enforce policies to ensure operational consistency in all domains. If you can give a bit more concrete example of operational coherency, that will be helpful.

Thanks
Khuzema

Young,

Cheers,
Andy

Thanks,
Young

Young,

Cheers,
Andy

---

From: Khuzema Pithewan <[email-masked]>
Date: Fri, 12 Dec 2014 17:54:50 +0000

Hi Young,

On protection : There will be multiple things in this area. You did pointed out some of the most important aspects (both of them) of it. ACTN framework should support finer control of protection like

·         Co-ordination of protection among packet/OTN/optical layers

o   This can be automatic governed by rules/policy or user can intervene based on events/alarm triggered

·         Health checks for protection availability for various layers involved in end-2-end circuit

·         Order or priorities, when and which protection kicks on faults. This can either be policy driven or user can intervene depending on changing environment

·         Protection has implication on path computation (diversity/SRLG etc), which would need co-ordination among layers.

·         Protection planning through different layers, as different layers may offer different types of protection like 1+1, 1:1, m:n, shared protection.

·         :
Having this in charter opens up this essential area for investigation/analysis of existing work and its applicability to ACTN

Network Efficiency : the draft you pointed out does talk about monitoring of service. My point is geared towards achieving network efficiency by ability to bulk/one-by-one regroom services.  Now there are 2 aspects here :

·         Trigger to initiate re-groom services

o   Can be through service monitoring, as discussed in draft

o   Can be through some policy, i.e. time or fiber capacity based

o   Can be through external trigger

·         APIs which can facilitate orchestration of regrooming.

o   VPI / CVI should be able to export such APIs and info model should support such actions from user

Reliability :  I am talking about control plane reliability. Control plane and multi-domain coherency may not be just a matter of policy enforcement. This aspect has to be taken care explicitly by developing mechanism/protocol across controllers.

Thanks
Khuzema

From: Leeyoung [mailto:[email-masked]]
Sent: Wednesday, December 10, 2014 5:45 PM
To: Khuzema Pithewan; Andrew G. Malis
Cc: [email-masked]
Subject: RE: [Actn] charter 1.4

Hi Khuzema,

Thanks,
Young

Hi,

Thanks
Khuzema

Young,

Cheers,
Andy

Thanks,
Young

Young,

Cheers,
Andy

---

From: "BELOTTI, SERGIO (SERGIO)" <[email-masked]>
Date: Sun, 14 Dec 2014 17:58:21 +0000

Hi Young, I agree on the need for coordination with LIME for OAM, but take into account that at least for L0-L1-L2 , ITU-T is working on OAM as well for both info and data model.
So I would suggest to complete the coordination steps  in the charter, and  adding , when you’re talking about cooperation with external SDOs , a specific sentence like :
“In doing this work, the WG will cooperate with ITU-T SG 15 regarding, e.g.,architectural and unified OAM for L0-L2 and generic transport network resource information modeling, and other external SDOs as necessary.”

Thanks
Sergio

From: ACTN [mailto:[email-masked]] On Behalf Of Leeyoung
Sent: martedì 9 dicembre 2014 17:33
To: Andrew G. Malis
Cc: [email-masked]
Subject: Re: [Actn] charter 1.4

Hi Andy,

Thanks,
Young

Young,

Cheers,
Andy

---

From: Leeyoung <[email-masked]>
Date: Tue, 16 Dec 2014 04:31:28 +0000

Hi Khuzema,

Here’s my response inline.

Thanks,
Young

From: Khuzema Pithewan [mailto:[email-masked]]
Sent: Friday, December 12, 2014 11:55 AM
To: Leeyoung; Andrew G. Malis
Cc: [email-masked]
Subject: RE: [Actn] charter 1.4

Hi Young,

·         :

YOUNG>>  Virtual service operation (VSO) is defined in the charter and has been elaborated in the 05 version of the framework document just published. Basically, with the VSO notion, customer’s policy can be enforced dynamically with a feedback loop (with event/alarm trigger). Some policy can be static while others dynamic.

YOUNG>> But the last two bullets seem purely network-oriented. What makes do you think they are unique to ACTN? ACTN architecture can definitely help in coordinating protection level in multi-layer networks. But do you think there are areas TEAS or CCAMP might not be able to provide solutions for multi-layer protection coordination?

YOUNG>> This is an interesting point. You are basically saying that re-grooming policy should be supported, whether that is time-based, dynamically triggered by service monitoring, etc. What is fiber capacity based policy? What is external trigger?

YOUNG>> The MDSC (Multi-domain Service Controller, which is used to be called VNC) redundancy can be a starting point as it interfaces different controllers. Of course, PNCs and CNCs are also factored in for end-to-end control plane reliability. I believe there are independent server redundant protocols out there. Do you think ACTN protocol should support controller redundancy as part of it?

Thanks
Khuzema

Hi Khuzema,

Thanks,
Young

Hi,

Thanks
Khuzema

Young,

Cheers,
Andy

Thanks,
Young

Young,

Cheers,
Andy