Re: [Actn] charter 1.4

[Kenji Kumaki <[e-mail]>]

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:[e-mail]] On Behalf Of Leeyoung
> Sent: Tuesday, December 09, 2014 8:19 AM
> To: [e-mail]
> 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.