Re: [Actn] charter 1.4

[<[e-mail]>]

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 <[e-mail]>
 To: "[e-mail]" <[e-mail]>; "[e-mail]" <[e-mail]> 
 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:[e-mail]]On Behalf Of [e-mail]
Sent: Tuesday, December 09, 2014 9:11 AM
To: Leeyoung; [e-mail]
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 <[e-mail]>
To: "[e-mail]" <[e-mail]> 
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
[e-mail]
https://www.ietf.org/mailman/listinfo/actn