Re: [Actn] ACTN charter v1.1 (and previous versions)

["King, Daniel" <[e-mail]>]

All, the latest version (1.1) is now available on the Wiki:

https://sites.google.com/site/actnbof/home/charter-proposal

Br, Dan.

From: ACTN [mailto:[e-mail]] On Behalf Of Leeyoung
Sent: 12 September 2014 22:25
To: [e-mail]
Subject: [Actn] ACTN charter v1.1

Hi,

We have had pretty good discussions on ACTN charter 1.0. Thanks to all who provided good comments and suggestions.

At the close of the week, I had chance to update the charter (v1.1) based on agree-upon discussion points (there are still some unresolved points).
Here's the output. Please refer to this version for any subsequent discussions. Also attached is the Word document that shows the diff marks. I may have missed some points you raised. Please raise them again if that is the case.

Thanks & have a good weekend!

Young

From: ACTN [mailto:[e-mail]] On Behalf Of Leeyoung
Sent: Friday, September 12, 2014 2:01 PM
To: Daniele Ceccarelli; Varma, Eve L (Eve); Dhruv Dhody; [e-mail]<mailto:[e-mail]>
Subject: Re: [Actn] ACTN charter v1.0

Hi Daniele,

I think Segment Routing is a TE technique that can improve MPLS-TE networks, but not sure if it in itself is a connection-oriented technologies. From a signaling standpoint, it may be regarded as a derivative of MPLS-TE. Please correct if I am wrong.

Thanks,
Young

From: Daniele Ceccarelli [mailto:[e-mail]]
Sent: Friday, September 12, 2014 9:27 AM
To: Varma, Eve L (Eve); Leeyoung; Dhruv Dhody; [e-mail]<mailto:[e-mail]>
Subject: RE: ACTN charter v1.0

Good catch Eve,

Could we include also segment routing into the list of connection oriented technologies? I don't know whether it could be considered as part of the MPLS-TE or not (don't think so).

BR
Daniele

From: ACTN [mailto:[e-mail]] On Behalf Of Varma, Eve L (Eve)
Sent: giovedì 11 settembre 2014 18:09
To: Leeyoung; Dhruv Dhody; [e-mail]<mailto:[e-mail]>
Subject: Re: [Actn] ACTN charter v1.0

Hi,

Just a quick terminology comment - the wording below infers OTN is only L1, when it is both L1 and L0 :)  So I would suggest to reword as "This implies that at least the following transport networks are in scope of the discussion of this draft: 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".

Best regards,
Eve

From: ACTN [mailto:[e-mail]] On Behalf Of Leeyoung
Sent: Thursday, September 11, 2014 11:17 AM
To: Dhruv Dhody; [e-mail]<mailto:[e-mail]>
Subject: Re: [Actn] ACTN charter v1.0

Hi Dhruv,

Thanks for providing your valuable comment.

Please see inline for my response. Thanks.

Young

From: Dhruv Dhody
Sent: Wednesday, September 10, 2014 10:48 PM
To: Leeyoung; Leeyoung; [e-mail]<mailto:[e-mail]>
Subject: RE: ACTN charter v1.0

Hi Young,

Please find some comments on the proposed charter.

* Do we need some text in charter also to specify what we consider as Transport networks?

YOUNG>> That may clarify the scope. Do you have any suggestion?  One definition from the Problem Statement draft (https://datatracker.ietf.org/doc/draft-leeking-actn-problem-statement/) is as follows. Would this be good enough or need more work?

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 in this document 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 of the
   discussion of this draft: Layer 1 (L1) optical networks (e.g.,
   Optical Transport Networks (OTN) and Wavelength Switched Optical
   Networks (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 or centralized signaling  for path setup and protection, and
-               Provide traffic engineering mechanism via centralized path computation."

Term 'centralized signaling' is confusing to me, do you mean, the use of NMS?

YOUNG>> Yes. We can reword the second point: "Allow for distributed signaling or an NMS-based centralized signaling for set up...."

* "The architecture work will lead to requirements for information models and protocol extensions between the virtual network controller and the physical network domain controllers and between the virtual network controller and multi-tenant customer controllers."

It would be nice to add "multi-domain coordinator" with "virtual network controller" to explicitly link them together. Also multi-tenant customer controllers doesn't convey the intention to have different customer controllers for each tenant, how about...

"The architecture work will lead to requirements for information models and protocol extensions between the virtual network controller (embedded in a multi-domain coordinator) and the physical network domain controllers and between the virtual network controller and multiple tenant customer controllers."

YOUNG>> This sounds good to me. Thanks.

* "The working group will determine if new protocol extensions are necessary. If the working group determines they are necessary, then it will develop the new protocols within the working group where necessary, while interacting with other working groups to enhance existing protocols where possible."

Suggest to re-word this as it's not clear - is it about extension to existing protocols or new protocol and where that work might be taken up. Also Protocol extensions is mentioned as a work item after re-chartering.

YOUNG>> New protocol extensions mean a brand new protocol (say, "ACTN" protocol per se) that cannot be extended from existing protocols. But there may be some areas where we need to expand from existing protocols. In such case, we need to interact with the corresponding WGs. Perhaps an analogy would be that CCAMP WG is chartered to work on OPSF-TE for specific technologies while OSPF WG needs to be informed of the protocol changes.

* You may want to do charter text formatting in RFC text format taking care of word-wraps and indentation
YOUNG>> Not sure what you meant here. Please clarify it for me.
Hope you find them useful in making the charter text crisp.

YOUNG>> Definitely. Thanks a lot for your review and great comments.

Dhruv


From: ACTN [mailto:[e-mail]] On Behalf Of Leeyoung
Sent: 10 September 2014 04:53
To: Leeyoung; [e-mail]<mailto:[e-mail]>
Subject: [Actn] ACTN charter v1.0

Sorry, I forgot the Subject of this email. Here's a retransmission with the subject.

From: Leeyoung
Sent: Tuesday, September 09, 2014 3:47 PM
To: [e-mail]<mailto:[e-mail]>
Subject:

Hi,

I hope your summer break was a good one.

We'd like to give you some updates and plans on the ACTN work. We are going to request a formal BoF in Honolulu IETF meeting. In doing so, we need a charter draft as part of the due diligence. Here's an initial charter draft developed by the small set of proponents of the work based on the discussions and use-cases and other published documents.  We hope this captures a workable ACTN scope.  This version 1.0 draft charter is also posted in the wiki: https://sites.google.com/site/actnbof/home/charter-propor

Your review and comment will be greatly appreciated to come up with a good charter developed by the community of interest.

Best regards,
Young (on behalf of the proponents)

-------------------------------draft charter 1.0 ----------------------------------------------------------------------------------------------------

Transport networks have a variety of mechanisms to:

-       Facilitate separation of data plane and control plane,

-       Allow for distributed 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. Abstraction of transport networks also allows operators to consolidate their network services into multi-tenant virtual transport 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 operation based on the abstraction of underlying technology and vendor domains.

Multi-domain network coordination function in ACTN is built on a control hierarchy where a multi-domain coordinator interacts with each domain controller (e.g., EMS/NMS, GMPLS/PCE control plane, SDN controller) for abstracting network resource information to provide virtual network control functions. This virtual network control functions are embedded in a multi-domain network coordinator to support various services/clients/applications to create and manage their own virtual networks that share the common transport network resources.


The ACTN working group will work to develop a high-level architecture for transport network abstraction and control that facilitates seamless vertical service coordination across multi-tenant customers (primarily internal service organizations with respect to a network operator), the virtual network control and the physical network domain controls as well as a horizontal E2E service coordination across multi-domain networks. It will identify key building components and the corresponding interfaces among these components.  The architecture work will lead to requirements for information models and protocol extensions between the virtual network controller and the physical network domain controllers and between the virtual network controller and multi-tenant customer controllers. Well-defined use cases from operators perspective with clearly stated need for transport network virtualization are critical in scoping the work and thus to achieve the deliverables of the working group.

The working group will work on the following items:

-       High-level architecture that describes the basic building blocks to enable transport network virtualization to support use cases.

-       Operator-driven use cases to address the following initial items:

o   Virtual network control and operation for core transport Packet Optical Integration (POI). (e.g., MPLS-TP, OTN/WSON)

o   Virtual network control and operation for mobile backhaul multi-technology transport (e.g., MPLS-TP and MPLS/OTN)

o   Data Center Operator's interconnection with optical transport network infrastructure providers to support dynamic virtual circuit services.

o   Multi-tenant support to allow virtual network information query, virtual network negotiation, creation/deletion and modification.

o   Synchronization of network resources view across physical domain controls and virtual network control.

o   Dynamic service control and monitoring across all entities.

Initial work within the working group will be limited to a single operator administrative domain with an exception for the Data Center operation use case.

-       Evaluation of Information model/data model to support the use cases.

-       Requirements to support APIs/protocols, encoding languages, and data models

-       Gap analysis of existing IETF and other protocols, encoding languages and data models to fulfill the requirements.

-       Protocol extensions (if necessary after re-chartering).

The working group will determine if new protocol extensions are necessary. If the working group determines they are necessary, then it will develop the new protocols within the working group where necessary, while interacting with other working groups to enhance existing protocols where possible.