Subject: [Actn] ACTN charter v1.0

From: Leeyoung <[email-masked]>
Date: Tue, 9 Sep 2014 20:52:44 +0000

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

---

From: Dhruv Dhody <[email-masked]>
Date: Thu, 11 Sep 2014 03:47:56 +0000

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?

* "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?

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

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

* You may want to do charter text formatting in RFC text format taking care of word-wraps and indentation

Hope you find them useful in making the charter text crisp.

Dhruv

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

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

Hi,

Best regards,

---

From: Leeyoung <[email-masked]>
Date: Thu, 11 Sep 2014 15:17:11 +0000

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; [email-masked]
Subject: RE: ACTN charter v1.0

Hi Young,

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.

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

YOUNG>> This sounds good to me. Thanks.

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: Leeyoung

Hi,

Best regards,

---

From: "Varma, Eve L (Eve)" <[email-masked]>
Date: Thu, 11 Sep 2014 16:08:30 +0000

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:[email-masked]] On Behalf Of Leeyoung
Sent: Thursday, September 11, 2014 11:17 AM
To: Dhruv Dhody; [email-masked]
Subject: Re: [Actn] ACTN charter v1.0

Hi Dhruv,

Young

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

Hi Young,

Dhruv

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

From: Leeyoung

Hi,

Best regards,

---

From: Leeyoung <[email-masked]>
Date: Thu, 11 Sep 2014 21:55:54 +0000

Hi Eve,

Thanks always for being technically correct. I think your wording is fine with me.

Best regards,
Young

From: Varma, Eve L (Eve) [mailto:[email-masked]]
Sent: Thursday, September 11, 2014 11:09 AM
To: Leeyoung; Dhruv Dhody; [email-masked]
Subject: RE: ACTN charter v1.0

Hi,

Best regards,
Eve

Hi Dhruv,

Young

From: Dhruv Dhody

Hi Young,

Dhruv

From: Leeyoung

Hi,

Best regards,

---

From: Dhruv Dhody <[email-masked]>
Date: Fri, 12 Sep 2014 02:32:32 +0000

Hi Young,

Please see inline..

From: Dhruv Dhody

Hi Young,

[Dhruv]: Yes that would be good with Eve suggestion and removing 'in the document'/'of this draft'.

[Dhruv]: That works!

[Dhruv]: How about we reword this to - "The working group will determine if new protocol or extensions to existing protocols are necessary. If the working group determines they are necessary, then it will develop new protocols within the working group, on the other hand any extensions to existing protocols would be done  with interactions with other working groups where possible."

* 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.
[Dhruv]: Refer attachment, this format would help when we upload it to the data tracker and charter diff tool can help track it better.
This version has all the changes suggested by me and Eve.
Regards,
Dhruv
Hope you find them useful in making the charter text crisp.

Dhruv

From: Leeyoung

Hi,

Best regards,

---

From: Nico Wauters <[email-masked]>
Date: Fri, 12 Sep 2014 16:15:57 +0200

Lee,

I reviewed the charter and find it good.

I have 2 comments

Comment 1:

In 5th paragraph

YOUNG>>“It will identify key building components and the corresponding
interfaces among these components. “

WAUTERS>>“It will identify key building components and the corresponding
interfaces among these components. Key components can be future building
block or legacy components existing today“

Comment 2:

I don’t have a lot of experience with writing charters, but instead of “…
will work on …” isn’t the objective to come to conclusions or aim clear
recommendations ?

Note that my experience with IETF is not large enough to know whether what
I state here makes sense.

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

WAUTERS>> “*Propose* *a *high-level architecture ……

YOUNG>>  “Evaluation of Information model/data model to support the use
cases.

WAUTERS>>  “Evaluate *and agree* on Information model/data model to support
the use cases.

YOUNG>>  “Requirements to support APIs/protocols, encoding languages, and
data models

WAUTERS>>  “*Collect* requirements to support APIs/protocols, encoding
languages, and data models

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

WAUTERS>>*Perform* gap analysis of existing IETF and other protocols,
encoding languages and data models to fulfill the requirements.

YOUNG>> “Protocol extensions (if necessary after re-chartering).

WAUTERS>> “*Propose* protocol extensions (if necessary after re-chartering).

Regards

Nico

*From:* Dhruv Dhody [mailto:[email-masked]]
*Sent:* vrijdag 12 september 2014 4:33
*To:* Leeyoung; [email-masked]
*Subject:* Re: [Actn] ACTN charter v1.0

Hi Young,

Please see inline..

*From:* Dhruv Dhody
*Sent:* Wednesday, September 10, 2014 10:48 PM
*To:* Leeyoung; Leeyoung; [email-masked]
*Subject:* RE: ACTN charter v1.0

Hi Young,

* 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?

[Dhruv]: Yes that would be good with Eve suggestion and removing ‘in the
document’/’of this draft’.

* “Transport networks have a variety of mechanisms to:

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

[Dhruv]: That works!

* “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.”

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

[Dhruv]: How about we reword this to – “The working group will determine if
new protocol or extensions to existing protocols are necessary. If the
working group determines they are necessary, then it will develop new
protocols within the working group, on the other hand any extensions to
existing protocols would be done  with interactions with other working
groups where possible.”

* You may want to do charter text formatting in RFC text format taking care
of word-wraps and indentation

[Dhruv]: Refer attachment, this format would help when we upload it to the
data tracker and charter diff tool can help track it better.

Regards,

Dhruv

Dhruv

*From:* ACTN [mailto:[email-masked] <[email-masked]>] *On
Behalf Of *Leeyoung
*Sent:* 10 September 2014 04:53
*To:* Leeyoung; [email-masked]
*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:* [email-masked]
*Subject:*

Hi,

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,

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

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

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

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.

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.

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

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.

---

From: Daniele Ceccarelli <[email-masked]>
Date: Fri, 12 Sep 2014 14:26:32 +0000

Dhruv, Young,

Excellent progresses!
Let me just add some notes/questions.
I'm collecting them here and not inline as the reading of the whole thread is becoming pretty complex.

1.      On centralized signaling: We need to clearly state what centralized signaling means. NMS based is one of the possibilities but it's not limited to NMS. A network implementing e.g. Open Flow or any other similar protocol should be considered as well IMHO. Here I'm not sure whether we can speak about centralized signaling in both cases or not. In the case of NMS we use the management plane to dynamically provision connectivity (whatever protocol is used). In the case of e.g. Open Flow can we speak about management plane or is something else? Please note that I speak about OF as it's the only example that comes to my mind but any other possibility can/must be considered.

2.      On multidomain issues: One question here: How do we want to manage multi-domain? I see two ways:

a.      A coordinator of virtual network controllers - i.e. 1:1 relationship between virtual network controller and physical network controller plus a coordinator of virtual network controllers on top

b.      A coordinator of physical network controllers - i.e. a coordinator of physical network controllers (1:N relationship between coordinator and PNCs) with a virtual network controller on top? (1:1 relationship between PNC coordinator and the VNC)

Maybe we should consider both architectures, maybe pick one.

3.      Again on multiodomain: maybe we could improve the architecture draft saying what is centralized and what is distributed. E.g. VPN prefixes exchange could be distributed (controllers speaking MP-BGP with each other) while provisioning could be hierarchical (i.e. the coordinator asks controller A to provision a path with domain A and asks controller B to provide a path within B so to have an end to end path crossing domains A and B)...H-PCE like.

BR
Daniele

From: ACTN [mailto:[email-masked]] On Behalf Of Dhruv Dhody
Sent: venerdì 12 settembre 2014 04:33
To: Leeyoung; [email-masked]
Subject: Re: [Actn] ACTN charter v1.0

Hi Young,

Please see inline..

From: Dhruv Dhody

Hi Young,

[Dhruv]: That works!
----------------------------

Dhruv

From: Leeyoung

Hi,

Best regards,

---

From: Daniele Ceccarelli <[email-masked]>
Date: Fri, 12 Sep 2014 14:26:42 +0000

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:[email-masked]] On Behalf Of Varma, Eve L (Eve)
Sent: giovedì 11 settembre 2014 18:09
To: Leeyoung; Dhruv Dhody; [email-masked]
Subject: Re: [Actn] ACTN charter v1.0

Hi,

Best regards,
Eve

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

Hi Dhruv,

Young

From: Dhruv Dhody

Hi Young,

Dhruv

From: Leeyoung

Hi,

Best regards,

---

From: Leeyoung <[email-masked]>
Date: Fri, 12 Sep 2014 15:07:39 +0000

Hi Daniele,

Thanks for providing your good comments here. Some of your comment (1) is for charter discussion while the others (2 & 3) are architecture discussion. As a few folks are already working on the architecture document, we may start a new email thread on architecture discussion while developing the draft.

Please see inline for my response.

Regards,
Young

From: Daniele Ceccarelli [mailto:[email-masked]]
Sent: Friday, September 12, 2014 9:27 AM
To: Dhruv Dhody; Leeyoung; [email-masked]
Subject: RE: ACTN charter v1.0

Dhruv, Young,

Excellent progresses!

YOUNG>> The intention here was giving some overview of the tools that current transport networks have. Of course thing are quickly changing with other initiatives like OF and even PCE based signaling in a research circle that can be viewed as centralized signaling. Perhaps good compromise would be putting NMS based as an example. How about restating like:

Allow for distributed signaling or centralized signaling (e.g., an NMS-based, etc.) for set up...."

YOUNG>> These options seem to be detailed architecture that the upcoming architecture document should address in detail. My personal opinion is that both architectures need to be considered as a starting point. There may be other variations. Then we may narrow the scope as an initial baseline architecture.

YOUNG>> Good point. I agree that the architecture draft should discuss these dichotomy of control regimes (e.g., centralized vs. distributed). One question I have: are you assuming the coordinator also speaks MP-BGP with lower level PN controllers? If not, would the coordinator need to collect the VPN prefixes using the interface between the coordinator and each PNC (that speaks MP-BGP)? Then can this be viewed as a centralized component?

BR
Daniele

Hi Young,

Please see inline..

From: Dhruv Dhody

Hi Young,

[Dhruv]: That works!

Dhruv

From: Leeyoung

Hi,

Best regards,

---

From: "BELOTTI, SERGIO (SERGIO)" <[email-masked]>
Date: Fri, 12 Sep 2014 15:34:09 +0000

Hi Young, Daniele

Please see in line .

Thanks
Sergio

From: ACTN [mailto:[email-masked]] On Behalf Of Leeyoung
Sent: venerdì 12 settembre 2014 17:08
To: Daniele Ceccarelli; Dhruv Dhody; [email-masked]
Subject: Re: [Actn] ACTN charter v1.0

Hi Daniele,

Regards,
Young

From: Daniele Ceccarelli [mailto:[email-masked]]
Sent: Friday, September 12, 2014 9:27 AM
To: Dhruv Dhody; Leeyoung; [email-masked]<mailto:[email-masked]>
Subject: RE: ACTN charter v1.0

Dhruv, Young,

Excellent progresses!

SB> I have still problems with this definition. In my view when you think about to an NMS based path setup, I have a centralized station that is providing command towards managed equipment functions that are virtualized in a MIB , and these command provide the "resource reservation" phase (not only but just to make the comparison with normal signaling protocol) using a "vertical" management protocol .
There is no signaling in my view .
Another case is PCE: PCE is providing path computation phase , and can exploit on a distributed control plane to make a signaling of the setup calculated. But again , it is not a centralized signaling , signaling is distributed , it is the routing, if anything,  that is centralized in my view.

So I would suggest to delete the term signaling associated to centralized and change the sentence into:
"Allow for distributed signaling or centralized model (e.g.an NMS-based) for set up...."

BR
Daniele

Hi Young,

Please see inline..

From: Dhruv Dhody

Hi Young,

[Dhruv]: That works!

Dhruv

From: Leeyoung

Hi,

Best regards,

---

From: Leeyoung <[email-masked]>
Date: Fri, 12 Sep 2014 15:46:18 +0000

Hi Dhruv,

Thanks for providing a RFC text format of the charter. Now I understood what you meant in the previous email.

Please see inline for my comment.

Thanks,
Young

From: Dhruv Dhody
Sent: Thursday, September 11, 2014 9:33 PM
To: Leeyoung; [email-masked]
Subject: RE: ACTN charter v1.0

Hi Young,

Please see inline..

From: Dhruv Dhody

Hi Young,

YOUNG>> Oh yes.

[Dhruv]: That works!

YOUNG>> As discussed with Daniele, I proposed "Allow for distributed signaling or centralized signaling (e.g., an NMS-based, etc.) for set up...." Would this work for you?

YOUNG>> This is clearer to me. With some punctuation change, how about: "The working group will determine if new protocol or extensions to existing protocols are necessary. If the working group determines they are necessary, then it will develop new protocols within the working group; on the other hand, any extensions to existing protocols would be done with interactions with other working groups where possible."

YOUNG>> Agree.

Dhruv

From: Leeyoung

Hi,

Best regards,

---

From: Daniele Ceccarelli <[email-masked]>
Date: Fri, 12 Sep 2014 16:37:27 +0000

Good proposal Sergio, I like it.

BR
Daniele

From: BELOTTI, SERGIO (SERGIO) [mailto:[email-masked]]
Sent: venerdì 12 settembre 2014 17:34
To: Leeyoung
Cc: Daniele Ceccarelli; Dhruv Dhody; [email-masked]
Subject: RE: ACTN charter v1.0

Hi Young, Daniele

Please see in line .

Thanks
Sergio

From: ACTN [mailto:[email-masked]] On Behalf Of Leeyoung
Sent: venerdì 12 settembre 2014 17:08
To: Daniele Ceccarelli; Dhruv Dhody; [email-masked]<mailto:[email-masked]>
Subject: Re: [Actn] ACTN charter v1.0

Hi Daniele,

Regards,
Young

Dhruv, Young,

Excellent progresses!

BR
Daniele

Hi Young,

Please see inline..

From: Dhruv Dhody

Hi Young,

[Dhruv]: That works!

Dhruv

From: Leeyoung

Hi,

Best regards,

---

From: Leeyoung <[email-masked]>
Date: Fri, 12 Sep 2014 19:01:07 +0000

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:[email-masked]]
Sent: Friday, September 12, 2014 9:27 AM
To: Varma, Eve L (Eve); Leeyoung; Dhruv Dhody; [email-masked]
Subject: RE: ACTN charter v1.0

Good catch Eve,

BR
Daniele

Hi,

Best regards,
Eve

Hi Dhruv,

Young

From: Dhruv Dhody

Hi Young,

Dhruv

From: Leeyoung

Hi,

Best regards,

---

From: Leeyoung <[email-masked]>
Date: Fri, 12 Sep 2014 19:10:41 +0000

Hi Nico,

Comment 1 is acceptable to me as operators’ use-cases made it clear this point.

On Comment 2, I think it is a style issue and I believe the current text style is normative of IETF charter statement.

Thanks,
Young

From: Nico Wauters [mailto:[email-masked]]
Sent: Friday, September 12, 2014 9:16 AM
To: Dhruv Dhody; Leeyoung; [email-masked]
Subject: RE: [Actn] ACTN charter v1.0

Lee,

I have 2 comments

Comment 1:
In 5th paragraph
YOUNG>>“It will identify key building components and the corresponding interfaces among these components. “
WAUTERS>>“It will identify key building components and the corresponding interfaces among these components. Key components can be future building block or legacy components existing today“

Comment 2:
I don’t have a lot of experience with writing charters, but instead of “… will work on …” isn’t the objective to come to conclusions or aim clear recommendations ?
Note that my experience with IETF is not large enough to know whether what I state here makes sense.

YOUNG>>  “High-level architecture that describes the basic building blocks to enable transport network virtualization to support use cases.
WAUTERS>> “Propose a high-level architecture ……

YOUNG>>  “Evaluation of Information model/data model to support the use cases.
WAUTERS>>  “Evaluate and agree on Information model/data model to support the use cases.

YOUNG>>  “Requirements to support APIs/protocols, encoding languages, and data models
WAUTERS>>  “Collect requirements to support APIs/protocols, encoding languages, and data models

YOUNG>>Gap analysis of existing IETF and other protocols, encoding languages and data models to fulfill the requirements.
WAUTERS>>Perform gap analysis of existing IETF and other protocols, encoding languages and data models to fulfill the requirements.

YOUNG>> “Protocol extensions (if necessary after re-chartering).
WAUTERS>> “Propose protocol extensions (if necessary after re-chartering).

Regards
Nico

From: Dhruv Dhody [mailto:[email-masked]<mailto:[email-masked]>]
Sent: vrijdag 12 september 2014 4:33
To: Leeyoung; [email-masked]<mailto:[email-masked]>
Subject: Re: [Actn] ACTN charter v1.0

Hi Young,

Please see inline..

From: Dhruv Dhody

Hi Young,

[Dhruv]: Yes that would be good with Eve suggestion and removing ‘in the document’/’of this draft’.

* “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….”

[Dhruv]: That works!

* “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.”

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

[Dhruv]: How about we reword this to – “The working group will determine if new protocol or extensions to existing protocols are necessary. If the working group determines they are necessary, then it will develop new protocols within the working group, on the other hand any extensions to existing protocols would be done  with interactions with other working groups where possible.”

Dhruv

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

From: Leeyoung

Hi,

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

Best regards,

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

---

From: Leeyoung <[email-masked]>
Date: Fri, 12 Sep 2014 19:22:40 +0000

Hi Sergio,

I am OK with your suggested wording. Thanks.

Young

From: BELOTTI, SERGIO (SERGIO) [mailto:[email-masked]]
Sent: Friday, September 12, 2014 10:34 AM
To: Leeyoung
Cc: Daniele Ceccarelli; Dhruv Dhody; [email-masked]
Subject: RE: ACTN charter v1.0

Hi Young, Daniele

Please see in line .

Thanks
Sergio

Hi Daniele,

Regards,
Young

Dhruv, Young,

Excellent progresses!

BR
Daniele

Hi Young,

Please see inline..

From: Dhruv Dhody

Hi Young,

[Dhruv]: That works!

Dhruv

From: Leeyoung

Hi,

Best regards,

---

From: Luyuan Fang <[email-masked]>
Date: Fri, 12 Sep 2014 20:06:19 +0000

I would not categorize segment routing as connection oriented in general.
It can use IGP to distribute labels instead of LDP, RSVP, or BGP. In that case, the packet simply follows IGP routes.
When supporting TE, it may be considered as derivative or sub-set of MPLS-TE. It is not fully defined yet.
I'd say to leave it out for now.

Thanks,
Luyuan

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

Hi Daniele,

Thanks,
Young

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

Good catch Eve,

BR
Daniele

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

Hi,

Best regards,
Eve

Hi Dhruv,

Young

From: Dhruv Dhody

Hi Young,

Dhruv

From: Leeyoung

Hi,

Best regards,

---

From: Leeyoung <[email-masked]>
Date: Fri, 12 Sep 2014 21:25:22 +0000

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:[email-masked]] On Behalf Of Leeyoung
Sent: Friday, September 12, 2014 2:01 PM
To: Daniele Ceccarelli; Varma, Eve L (Eve); Dhruv Dhody; [email-masked]
Subject: Re: [Actn] ACTN charter v1.0

Hi Daniele,

Thanks,
Young

Good catch Eve,

BR
Daniele

Hi,

Best regards,
Eve

Hi Dhruv,

Young

From: Dhruv Dhody

Hi Young,

Dhruv

From: Leeyoung

Hi,

Best regards,

---

From: Leeyoung <[email-masked]>
Date: Fri, 12 Sep 2014 21:48:31 +0000

Hi Luyuan,

Good point. Thanks.

Young

From: Luyuan Fang [mailto:[email-masked]]
Sent: Friday, September 12, 2014 3:06 PM
To: Leeyoung; Daniele Ceccarelli; Varma, Eve L (Eve); Dhruv Dhody; [email-masked]
Subject: RE: ACTN charter v1.0

Thanks,
Luyuan

Hi Daniele,

Thanks,
Young

Good catch Eve,

BR
Daniele

Hi,

Best regards,
Eve

Hi Dhruv,

Young

From: Dhruv Dhody

Hi Young,

Dhruv

From: Leeyoung

Hi,

Best regards,

---

From: Aihua Guo <[email-masked]>
Date: Fri, 12 Sep 2014 22:26:12 +0000

Hi Sergio,

Regarding your comment,
"There is no signaling in my view .
Another case is PCE: PCE is providing path computation phase , and can exploit on a distributed control plane to make a signaling of the setup calculated. But again , it is not a centralized signaling , signaling is distributed , it is the routing, if anything,  that is centralized in my view.

"

Today with e.g. PCEP extensions carrying service related information, service provisioning requests may be issued from a centralized controller to all network elements vertically and in parallel. This is IMHO one form of centralized signaling.

Service provisioning can be made through NMS, and NMS may or may not include service related information in the management protocols. Hence I still see a difference between NMS based and centralized signaling. Would it be worth to reflect the difference in the wording with something like this: ?

"Allow for distributed signaling or centralized model (e.g.an NMS-based or centralized signaling) for set up...."

Thanks.
Aihua

From: ACTN [mailto:[email-masked]] On Behalf Of Leeyoung
Sent: Friday, September 12, 2014 3:23 PM
To: BELOTTI, SERGIO (SERGIO)
Cc: [email-masked]; Daniele Ceccarelli; Dhruv Dhody
Subject: Re: [Actn] ACTN charter v1.0

Hi Sergio,

Young

From: BELOTTI, SERGIO (SERGIO) [mailto:[email-masked]]
Sent: Friday, September 12, 2014 10:34 AM
To: Leeyoung
Cc: Daniele Ceccarelli; Dhruv Dhody; [email-masked]<mailto:[email-masked]>
Subject: RE: ACTN charter v1.0

Hi Young, Daniele

Please see in line .

Thanks
Sergio

Hi Daniele,

Regards,
Young

Dhruv, Young,

Excellent progresses!

BR
Daniele

Hi Young,

Please see inline..

From: Dhruv Dhody

Hi Young,

[Dhruv]: That works!

Dhruv

From: Leeyoung

Hi,

Best regards,

---

From: "Y. Richard Yang" <[email-masked]>
Date: Fri, 12 Sep 2014 18:46:38 -0400

Hi Young, all,

This sure is an active list and it is a bit hard to jump to the discussion!
I read charter v1.1 and the discussions followed on the changes. Here are
some early comments:

- The current version appears to trying to do both (1) imposing an
architecture and (2) leaving architecture to the architecture document. For
example, I see multiple types of controllers (physical controller for a
domain, coordinator for physical controllers, tenant controller for a
tenant, ...). I also already see how they may interact (e.g., the hierarchy
paragraph). Some email discussion start to touch on this issue. My
preference is that it is better to leave the architecture as much as
possible to the architecture document, to avoid confusion, because there
are so many possibilities (e.g., a controller might be represented by two
functions, one for abstraction, one for control), unless the mailing list
can reach some agreement soon.

- In the document, the word "abstraction" is a keyword, and it is different
from "control", which is the other keyword. I am fine with keeping the
meaning of abstraction somehow vague, but it may become confusing when
there is too much overloading. For example, according to this sentence,
"the creation of a virtualized environment allowing operators to view and
control multi-subnet, multi-technology, multi-vendor domain networks",
abstraction is similar to "view". Then, the following sentence "Abstraction
of transport networks also allows operators to consolidate their network
services into multi-tenant virtual transport networks." appears to assign
abstraction a much stronger meaning. I would suggest revision to keep the
meaning of the keywords simple.

- The charter uses the word "virtualized" quite a few times. I found that
they appear to have different meanings. For example, in this sentence,
"Well-defined use cases from operators perspective with
clearly stated need for transport network virtualization", does
"virtualization" mean abstraction? For this sentence, "a centralized
virtual network operation", I cannot fully understand the meaning of the
word "virtual". For this sentence, "Multi-tenant support to allow virtual
network information query", it appears that virtual means an overlay
network, right?

- Increasingly, "abstraction" in networking appears to mean (declarative)
information model/data models, and this is what I read from this document
as well. But abstraction can mean a lot more. A good starting point is the
wiki doc (http://en.wikipedia.org/wiki/Abstraction_(computer_science)). I
hope that the charter can be stated slightly more broadly (e.g., by stating
that the WG will document the challenges of abstracting complex behaviors
of transport networks, and identify potential related techniques).

Richard

On Fri, Sep 12, 2014 at 11:07 AM, Leeyoung <[email-masked]> wrote:

>  Hi Daniele,
>
>
>
> Thanks for providing your good comments here. Some of your comment (1) is
> for charter discussion while the others (2 & 3) are architecture
> discussion. As a few folks are already working on the architecture
> document, we may start a new email thread on architecture discussion while
> developing the draft.
>
>
>
> *From:* Daniele Ceccarelli [mailto:[email-masked]]
> *Sent:* Friday, September 12, 2014 9:27 AM
> *To:* Dhruv Dhody; Leeyoung; [email-masked]
> I’m collecting them here and not inline as the reading of the whole thread
> is becoming pretty complex.
>
>
>
> 1.      On centralized signaling: We need to clearly state what
> centralized signaling means. NMS based is one of the possibilities but it’s
> not limited to NMS. A network implementing e.g. Open Flow or any other
> similar protocol should be considered as well IMHO. Here I’m not sure
> whether we can speak about centralized signaling in both cases or not. In
> the case of NMS we use the management plane to dynamically provision
> connectivity (whatever protocol is used). In the case of e.g. Open Flow can
> we speak about management plane or is something else? Please note that I
> speak about OF as it’s the only example that comes to my mind but any other
> possibility can/must be considered.
>
>
>
> YOUNG>> The intention here was giving some overview of the tools that
> current transport networks have. Of course thing are quickly changing with
> other initiatives like OF and even PCE based signaling in a research circle
> that can be viewed as centralized signaling. Perhaps good compromise would
> be putting NMS based as an example. How about restating like:
>
>
>
> Allow for distributed signaling or centralized signaling (e.g., an
> NMS-based, etc.) for set up….”
>
>
>
>
>
> a.      A coordinator of virtual network controllers – i.e. 1:1
> relationship between virtual network controller and physical network
> controller plus a coordinator of virtual network controllers on top
>
> b.      A coordinator of physical network controllers – i.e. a
> coordinator of physical network controllers (1:N relationship between
> coordinator and PNCs) with a virtual network controller on top? (1:1
> relationship between PNC coordinator and the VNC)
>
> YOUNG>> These options seem to be detailed architecture that the upcoming
> architecture document should address in detail. My personal opinion is that
> both architectures need to be considered as a starting point. There may be
> other variations. Then we may narrow the scope as an initial baseline
> architecture.
>
>
>
> 3.      Again on multiodomain: maybe we could improve the architecture
> draft saying what is centralized and what is distributed. E.g. VPN prefixes
> exchange could be distributed (controllers speaking MP-BGP with each other)
> while provisioning could be hierarchical (i.e. the coordinator asks
> controller A to provision a path with domain A and asks controller B to
> provide a path within B so to have an end to end path crossing domains A
> and B)…H-PCE like.
>
>
>
> YOUNG>> Good point. I agree that the architecture draft should discuss
> these dichotomy of control regimes (e.g., centralized vs. distributed). One
> question I have: are you assuming the coordinator also speaks MP-BGP with
> lower level PN controllers? If not, would the coordinator need to collect
> the VPN prefixes using the interface between the coordinator and each PNC
> (that speaks MP-BGP)? Then can this be viewed as a centralized component?
>
>
>
> BR
> Daniele
>
>
>
> *From:* ACTN [mailto:[email-masked]] *On Behalf Of *Dhruv Dhody
> *Sent:* venerdì 12 settembre 2014 04:33
> https://datatracker.ietf.org/doc/draft-leeking-actn-problem-statement/)
> is as follows. Would this be good enough or need more work?
>
>
>
> *----------------------------*
>
>
>
> “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
> [Dhruv]: How about we reword this to – “The working group will determine
> if new protocol or extensions to existing protocols are necessary. If the
> 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
> 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
> network controller and multi-tenant customer controllers. Well-defined
> use cases from operators perspective with clearly stated need for transport
> -       High-level architecture that describes the basic building blocks
> o    Data Center Operator’s interconnection with optical transport
> network infrastructure providers to support dynamic virtual circuit
> services.
>
> _______________________________________________
> ACTN mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/actn
>
>

-- 
-- 
 =====================================
| Y. Richard Yang <[email-masked]>   |
| Professor of Computer Science       |
| http://www.cs.yale.edu/~yry/        |
 =====================================

---

From: "BELOTTI, SERGIO (SERGIO)" <[email-masked]>
Date: Mon, 15 Sep 2014 16:31:45 +0000

Hi Aihua,

could you kindly clarify for my knowledge what "PCEP extensions carrying service related information" you're referring to?
If you consider RFC 4655, I do not see any architecture hint that exclude distributed signaling as basic method to path setup in a PCE context.
On the other hand , the newly draft considering the possibility to use "other" path setup method (draft-sivabalan-pce-lsp-setup-type-02.txt) is introducing a specifc TLV that you need to add if you want to use another method in your architecture. In fact , the default value proposed for path Setup Type field is 0 , implicitly considering RSVP_TE as default  setup method.

I have difficult to understand what you mean with "service provisioning requests may be issued from a centralized controller to all network elements vertically and in parallel.". What you mean with vertical and in parallel?
On the other hand I do not see when an NMS does not carry service info, whether for service info you consider the path setup info.
So I'm still uncomfortable with the term "centralized signaling"  in this context.

Thanks
Sergio

From: Aihua Guo [mailto:[email-masked]]
Sent: sabato 13 settembre 2014 00:26
To: Leeyoung; BELOTTI, SERGIO (SERGIO)
Cc: [email-masked]; Daniele Ceccarelli; Dhruv Dhody
Subject: RE: ACTN charter v1.0

Hi Sergio,

Regarding your comment,

Thanks.
Aihua

Cc: [email-masked]<mailto:[email-masked]>; Daniele Ceccarelli; Dhruv Dhody

Hi Sergio,

Young

Hi Young, Daniele

Please see in line .

Thanks
Sergio

Hi Daniele,

Regards,
Young

Dhruv, Young,

Excellent progresses!

BR
Daniele

Hi Young,

Please see inline..

From: Dhruv Dhody

Hi Young,

[Dhruv]: That works!

Dhruv

From: Leeyoung

Hi,

Best regards,

---

From: "King, Daniel" <[email-masked]>
Date: Mon, 15 Sep 2014 18:45:02 +0000

Hi Richard,

Good comments. As with most complex proposals, having clear definitions, terminology, and conceptual view is fundamental to understanding the system and scope of work. My specific comments are inline (“DK>>”):

Br, Dan.

From: ACTN [mailto:[email-masked]] On Behalf Of Y. Richard Yang
Sent: 12 September 2014 23:47
To: Leeyoung
Cc: [email-masked]; Daniele Ceccarelli; Dhruv Dhody
Subject: Re: [Actn] ACTN charter v1.0

Hi Young, all,

This sure is an active list and it is a bit hard to jump to the discussion! I read charter v1.1 and the discussions followed on the changes. Here are some early comments:

- The current version appears to trying to do both (1) imposing an architecture and (2) leaving architecture to the architecture document. For example, I see multiple types of controllers (physical controller for a domain, coordinator for physical controllers, tenant controller for a tenant, ...). I also already see how they may interact (e.g., the hierarchy paragraph). Some email discussion start to touch on this issue. My preference is that it is better to leave the architecture as much as possible to the architecture document, to avoid confusion, because there are so many possibilities (e.g., a controller might be represented by two functions, one for abstraction, one for control), unless the mailing list can reach some agreement soon.

DK>> You make a good point, I think we became blinkered slightly and have maybe assumed a number of ACTN architectural principles. We can look to be less prescriptive in the charter text when we issue the next version.

- In the document, the word "abstraction" is a keyword, and it is different from "control", which is the other keyword. I am fine with keeping the meaning of abstraction somehow vague, but it may become confusing when there is too much overloading.

DK>> Ok. We can also check the charter against the use cases and problem statement to ensure constancy across I-Ds.

For example, according to this sentence, "the creation of a virtualized environment allowing operators to view and control multi-subnet, multi-technology, multi-vendor domain networks", abstraction is similar to "view". Then, the following sentence "Abstraction of transport networks also allows operators to consolidate their network services into multi-tenant virtual transport networks." appears to assign abstraction a much stronger meaning. I would suggest revision to keep the meaning of the keywords simple.

DK>> Agree, also this does appear to be a solution statement than a requirement or objective.

- The charter uses the word "virtualized" quite a few times. I found that they appear to have different meanings. For example, in this sentence, "Well-defined use cases from operators perspective with clearly stated need for transport network virtualization", does "virtualization" mean abstraction? For this sentence, "a centralized virtual network operation", I cannot fully understand the meaning of the word "virtual". For this sentence, "Multi-tenant support to allow virtual network information query", it appears that virtual means an overlay network, right?

DK>> Yes, we need to be careful with consistency and usage of terms. We must avoid interchanging terminology and should be clear on how we use “virtualization”, “abstraction” and” multi-tenant”. In an early version of the ACTN problem statement we included a survey of existing technologies. To help set context and what we mean by network overlay and network virtualization, it might be worth discussing these technologies again (e.g., VXLAN, et al.), and what is required for a network overlay versus network virtualization.

- Increasingly, "abstraction" in networking appears to mean (declarative) information model/data models, and this is what I read from this document as well. But abstraction can mean a lot more.

DK>> You made the same point at the BoF in Toronto and it is still relevant. A protocol/forwarding specific data model, and info model, is not a trivial matter. Other WG initiatives are investigating and developing solutions and as you suggest, we should document what would be required from an ACTN perspective and feed into those initiatives. We can probably state this more clearly in the charter text.

Br, Dan.

On Fri, Sep 12, 2014 at 11:07 AM, Leeyoung <[email-masked]<mailto:[email-masked]>> wrote:
Hi Daniele,

Regards,
Young

From: Daniele Ceccarelli [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Friday, September 12, 2014 9:27 AM
To: Dhruv Dhody; Leeyoung; [email-masked]<mailto:[email-masked]>
Subject: RE: ACTN charter v1.0

Dhruv, Young,

Excellent progresses!
Let me just add some notes/questions.
I’m collecting them here and not inline as the reading of the whole thread is becoming pretty complex.

1.      On centralized signaling: We need to clearly state what centralized signaling means. NMS based is one of the possibilities but it’s not limited to NMS. A network implementing e.g. Open Flow or any other similar protocol should be considered as well IMHO. Here I’m not sure whether we can speak about centralized signaling in both cases or not. In the case of NMS we use the management plane to dynamically provision connectivity (whatever protocol is used). In the case of e.g. Open Flow can we speak about management plane or is something else? Please note that I speak about OF as it’s the only example that comes to my mind but any other possibility can/must be considered.

Allow for distributed signaling or centralized signaling (e.g., an NMS-based, etc.) for set up….”

a.      A coordinator of virtual network controllers – i.e. 1:1 relationship between virtual network controller and physical network controller plus a coordinator of virtual network controllers on top

b.      A coordinator of physical network controllers – i.e. a coordinator of physical network controllers (1:N relationship between coordinator and PNCs) with a virtual network controller on top? (1:1 relationship between PNC coordinator and the VNC)

3.      Again on multiodomain: maybe we could improve the architecture draft saying what is centralized and what is distributed. E.g. VPN prefixes exchange could be distributed (controllers speaking MP-BGP with each other) while provisioning could be hierarchical (i.e. the coordinator asks controller A to provision a path with domain A and asks controller B to provide a path within B so to have an end to end path crossing domains A and B)…H-PCE like.

BR
Daniele

From: ACTN [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Dhruv Dhody
Sent: venerdì 12 settembre 2014 04:33
To: Leeyoung; [email-masked]<mailto:[email-masked]>
Subject: Re: [Actn] ACTN charter v1.0

Hi Young,

Please see inline..

From: Dhruv Dhody

Hi Young,

[Dhruv]: That works!

Dhruv

From: Leeyoung

Hi,

Best regards,

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

--
--
 =====================================
| Y. Richard Yang <[email-masked]<mailto:[email-masked]>>   |
| Professor of Computer Science       |
| http://www.cs.yale.edu/~yry/        |
 =====================================

---

From: Fatai Zhang <[email-masked]>
Date: Tue, 16 Sep 2014 09:45:25 +0000

Hi Sergio and Aihua,

I have the same feeling as Sergio , ie, I am not sure what is "centralized signaling".

Could someone point out where we can find the term about "centralized signaling"?

Let's have some brainstorm by giving an example. For example, when a MPLS-TE LSP is to be created by the Openflow controller, can we regard this  is "centralized signaling"?

Best Regards

Fatai

From: ACTN [mailto:[email-masked]] On Behalf Of BELOTTI, SERGIO (SERGIO)
Sent: Tuesday, September 16, 2014 12:32 AM
To: Aihua Guo; Leeyoung
Cc: [email-masked]; Daniele Ceccarelli; Dhruv Dhody
Subject: Re: [Actn] ACTN charter v1.0

Hi Aihua,

Thanks
Sergio

Hi Sergio,

Regarding your comment,

Thanks.
Aihua

Hi Sergio,

Young

Hi Young, Daniele

Please see in line .

Thanks
Sergio

Hi Daniele,

Regards,
Young

Dhruv, Young,

Excellent progresses!

BR
Daniele

Hi Young,

Please see inline..

From: Dhruv Dhody

Hi Young,

[Dhruv]: That works!

Dhruv

From: Leeyoung

Hi,

Best regards,

---

From: xuyunbin <[email-masked]>
Date: Tue, 16 Sep 2014 20:14:04 +0800

hi, Yong,

There are some comments for ACTN charter, thanks.

1）It is supposed for the ACTN charter to carry on research of the abstraction and modeling method for transport resources in multi-domain and multi-vender environment. The transport network resources modeling method should meet the requirements of each domain controller (e.g., EMS/NMS, GMPLS/PCE control plane, SDN controller), such as application oriented modeling method (from top to bottom) or network resources oriented modeling methods (from bottom to top).
2) For the dynamic service control and monitoring, the alarm and performance data  transfer between different controllers may be based on PUSH mode or PULL mode, analysis the applicability of these two modes for different controllers, the extension based on existing protocol (such as Restful/Openflow) may be developed.

Best Regards
-----------------------------------------------------------------
Xu Yunbin 徐云斌 
 
传送与接入研究部
工业和信息化部电信研究院通信标准研究所（原工业和信息化部电信传输研究所）
Research Institute of Telecommunications Transmission (RITT),
China Academy of Telecom. Research (CATR), MIIT
 
TEL: 86-10-62300112, 86-18601328841
E-mail: [email-masked] ,   [email-masked]
-----------------------------------------------------------------
 
From: Leeyoung
Date: 2014-09-11 23:17

 
Young
 
From: Dhruv Dhody 
 
Hi Young, 

 

 

 

 

 

Dhruv

 
From: Leeyoung 
 
Hi,

 
 
Best regards,

---

From: Aihua Guo <[email-masked]>
Date: Tue, 16 Sep 2014 16:36:05 +0000

Hi Sergio and Fatai,

What I consider for "centralized signaling" is in a scenario where there is a centralized service controller and a network consisting of multiple network elements (NEs). In this scenario, the centralized service controller issues "vertical" path setup requests from the controller to all NEs at the same time ("in parallel"). Each network element receives a segment of the path for NE itself. This can be done by using PCEP as a transport protocol carrying either standard or proprietary extensions for services, with other extensions e.g. draft-sivabalan-pce-lsp-setup-type-02.txt to specify alternatives other than RSVP-TE for each NE.

I am in line with you that there is no signaling with an NMS approach, and NMS for sure stores service information in some format. My question is if the above scenario or the similar is viewed as somewhat different from an NMS based approach.

And also the same question for the Openflow scenario Fatai raised.

Thanks.
Aihua

From: Fatai Zhang [mailto:[email-masked]]
Sent: Tuesday, September 16, 2014 5:45 AM
To: BELOTTI, SERGIO (SERGIO); Aihua Guo; Leeyoung
Cc: [email-masked]; Daniele Ceccarelli; Dhruv Dhody
Subject: RE: ACTN charter v1.0

Hi Sergio and Aihua,

Best Regards

Fatai

Hi Aihua,

Thanks
Sergio

Hi Sergio,

Regarding your comment,

Thanks.
Aihua

Hi Sergio,

Young

Hi Young, Daniele

Please see in line .

Thanks
Sergio

Hi Daniele,

Regards,
Young

Dhruv, Young,

Excellent progresses!

BR
Daniele

Hi Young,

Please see inline..

From: Dhruv Dhody

Hi Young,

[Dhruv]: That works!

Dhruv

From: Leeyoung

Hi,

Best regards,

---

From: Leeyoung <[email-masked]>
Date: Tue, 16 Sep 2014 17:34:43 +0000

Hi,

I think the issue is the term 'signaling' is used in two different context. There is definitely RSVP-TE like signaling which is hop by hop from ingress to egress, which is 'horizontal'. That is what most folks are familiar with and tend to understand signaling from that perspective. On the other hand, there are several ways to set up path in a 'vertical' fashion. As Aihua indicated, the centralized entity (e.g., PCE +, or SDN controller) can indeed invoke a path setup command to each NE along the path. This vertical element of path setup can be regarded as 'signaling' in a broader sense.

Nonetheless, this portion of the charter statement is not really a central issue. We are simply discussing some tools available for transport networks. This is just a background information. So I suggest we move on with the latest resolution proposed by Sergio. Will this be agreeable?

Thanks,
Young

From: Aihua Guo [mailto:[email-masked]]
Sent: Tuesday, September 16, 2014 11:36 AM
To: Fatai Zhang; BELOTTI, SERGIO (SERGIO); Leeyoung
Cc: [email-masked]; Daniele Ceccarelli; Dhruv Dhody
Subject: RE: ACTN charter v1.0

Hi Sergio and Fatai,

Thanks.
Aihua

Hi Sergio and Aihua,

Best Regards

Fatai

Hi Aihua,

Thanks
Sergio

Hi Sergio,

Regarding your comment,

Thanks.
Aihua

Hi Sergio,

Young

Hi Young, Daniele

Please see in line .

Thanks
Sergio

Hi Daniele,

Regards,
Young

Dhruv, Young,

Excellent progresses!

BR
Daniele

Hi Young,

Please see inline..

From: Dhruv Dhody

Hi Young,

[Dhruv]: That works!

Dhruv

From: Leeyoung

Hi,

Best regards,

---

From: Aihua Guo <[email-masked]>
Date: Tue, 16 Sep 2014 17:56:51 +0000

Agree. It's not a major topic and the clarification of signaling can be sought separately.

Aihua

From: Leeyoung [mailto:[email-masked]]
Sent: Tuesday, September 16, 2014 1:35 PM
To: Aihua Guo; Fatai Zhang; BELOTTI, SERGIO (SERGIO)
Cc: [email-masked]; Daniele Ceccarelli; Dhruv Dhody
Subject: RE: ACTN charter v1.0

Hi,

Thanks,
Young

Hi Sergio and Fatai,

Thanks.
Aihua

Hi Sergio and Aihua,

Best Regards

Fatai

Hi Aihua,

Thanks
Sergio

Hi Sergio,

Regarding your comment,

Thanks.
Aihua

Hi Sergio,

Young

Hi Young, Daniele

Please see in line .

Thanks
Sergio

Hi Daniele,

Regards,
Young

Dhruv, Young,

Excellent progresses!

BR
Daniele

Hi Young,

Please see inline..

From: Dhruv Dhody

Hi Young,

[Dhruv]: That works!

Dhruv

From: Leeyoung

Hi,

Best regards,

---

From: Leeyoung <[email-masked]>
Date: Wed, 17 Sep 2014 18:41:24 +0000

Hi Richard,

Thanks for great comments. I think Dan provided good responses to your comment. Please see below for further clarifications on some of your comments.

YOUNG>> Multiple types of controllers (as well as their functions) discussed in the charter are based on use-cases of various operators. When discussing info/data models and interfaces and protocol extensions, we ought to have entities of main interest. This gives contexts of relevant entities at a minimum level.

YOUNG>> Virtualization is to be differentiated from abstraction. Abstraction is a way of representing network resources and topology (hiding details from physical layer). Virtualization allows operators to make use of abstraction to simplify its network operation as well as to offer services to their customers which is known as network slicing. Here’s an attempt to define what is network virtualization from the problem statement draft https://datatracker.ietf.org/doc/draft-leeking-actn-problem-statement/ :

o Network Virtualization:

      Network virtualization, refers to allowing the customers to
      utilize a certain network resources as if they own them and thus
      allows them to control their allocated resources in a way most
      optimal with higher layer or application processes. This customer
      control facilitates the introduction of new applications (on top
      of available services) as the customers are given programmable
      interfaces to create, modify, and delete their virtual network
      services.

Overlay network is a form of virtual network. Overlay network in the context of transport networks arise in a multi-layer context where the packet layer is a client to the server transport layer.  Packet layer is given a topology comprised of virtual links and nodes (typically in a tunnel view) from transport layer.

Thanks,
Young

From: King, Daniel [mailto:[email-masked]]
Sent: Monday, September 15, 2014 1:45 PM
To: Y. Richard Yang; Leeyoung
Cc: [email-masked]; Daniele Ceccarelli; Dhruv Dhody
Subject: RE: [Actn] ACTN charter v1.0

Hi Richard,

Br, Dan.

Hi Young, all,

Br, Dan.

Regards,
Young

Dhruv, Young,

Excellent progresses!

BR
Daniele

Hi Young,

Please see inline..

From: Dhruv Dhody

Hi Young,

[Dhruv]: That works!

Dhruv

From: Leeyoung

Hi,

Best regards,

---

From: "King, Daniel" <[email-masked]>
Date: Wed, 17 Sep 2014 22:58:47 +0000

Hi Young and Richard,

Just to be clear then, the definition for an “overlay network” is as follows:

   Overlay Network: An overlay network runs independently on top of
   another network. The nodes in the overlay network may considered
   connected by virtual or logical links, each of which corresponds to
   a path. Virtual Extensible LAN (VXLAN) and Network Virtualization
   Using Generic Routing Encapsulation (NVGRE) are considered overlay
   network technologies.

Also, the definition of “network virtualization” below might be better phrased as “network virtualization interface”:

      Network virtualization *interface*, refers to allowing the customers to

Then we could update the definition of “network virtualization” to:

   Network virtualization is the process of virtualizing network
   resources and facilitating the network to be programed, administered and
   deployed or released, independently of the underlay transport mechanism,
   hardware or software, and operations, administration and management
   method.

Of course, just to make things more confusing, if you talk about network virtualization to a data center provider then it will probably include virtual network functions (firewall, WAN accelerator, et al.). So we may also want to make that clear for the NFV folks ;-)

Br, Dan.

From: Leeyoung [mailto:[email-masked]]
Sent: 17 September 2014 19:41
To: King, Daniel; Y. Richard Yang
Cc: [email-masked]; Daniele Ceccarelli; Dhruv Dhody
Subject: RE: [Actn] ACTN charter v1.0

Hi Richard,

Thanks,
Young

Hi Richard,

Br, Dan.

Hi Young, all,

Br, Dan.

Regards,
Young

Dhruv, Young,

Excellent progresses!

BR
Daniele

Hi Young,

Please see inline..

From: Dhruv Dhody

Hi Young,

[Dhruv]: That works!

Dhruv

From: Leeyoung

Hi,

Best regards,

---

From: Leeyoung <[email-masked]>
Date: Thu, 18 Sep 2014 21:27:56 +0000

Hi Dan,

Thanks. I think we need to be aware of the context to which overlay network applies. Your suggested definition of an overlay network has a broader context than the one I suggested for transport network. But this helps to see different ways of using the same term.

Regarding network virtualization “interface”, clearly “interface” is a part of network virtualization allowing some capability mentioned in the definition, there are other aspect in the definition I quoted. However interface alone does not cover the definition. Interface allows information to  conveyed that are necessary for control entities to perform their functions such as allocating resources, facilitating VNs, etc.

I like your attempt to define network virtualization as a process.

Regards,
Young

From: King, Daniel [mailto:[email-masked]]
Sent: Wednesday, September 17, 2014 5:59 PM
To: Leeyoung; Y. Richard Yang
Cc: [email-masked]; Daniele Ceccarelli; Dhruv Dhody
Subject: RE: [Actn] ACTN charter v1.0

Hi Young and Richard,

Br, Dan.

Hi Richard,

Thanks,
Young

Hi Richard,

Br, Dan.

Hi Young, all,

Br, Dan.

Regards,
Young

Dhruv, Young,

Excellent progresses!

BR
Daniele

Hi Young,

Please see inline..

From: Dhruv Dhody

Hi Young,

[Dhruv]: That works!

Dhruv

From: Leeyoung

Hi,

Best regards,

---

From: Zhenghaomian <[email-masked]>
Date: Fri, 19 Sep 2014 01:17:09 +0000

Hi, Dan and Young,

I agree with the discussion issue, but my concern is whether we already have a good consensus  on the definition of network virtualization. Based on my understanding, the virtualization is some kind of re-shaping a network, including both functionality and topology. This can be achieved by internal process (like abstraction) or via interface (for representation), with various approaches.

It’s okay to define network virtualization as a process. But when we mention the virtualization, we should better also specify what we are talking about, such as ‘virtualization interface’, ‘virtualization process’ and so on. As a procedure, the most important thing for virtualization is to give a clear description on ‘before and after’, i.e., what is virtualized into what, by whom, and how.

Please help correct me if anything wrong, thanks a lot.

Best wishes,
Haomian

发件人: Leeyoung [mailto:[email-masked]]
发送时间: 2014年9月19日 5:28
收件人: King, Daniel; Y. Richard Yang
抄送: [email-masked]; Daniele Ceccarelli; Dhruv Dhody
主题: Re: [Actn] ACTN charter v1.0

Hi Dan,

Regards,
Young

Hi Young and Richard,

Br, Dan.

Hi Richard,

Thanks,
Young

Hi Richard,

Br, Dan.

Hi Young, all,

Br, Dan.

Regards,
Young

Dhruv, Young,

Excellent progresses!

BR
Daniele

Hi Young,

Please see inline..

From: Dhruv Dhody

Hi Young,

[Dhruv]: That works!

Dhruv

From: Leeyoung

Hi,

Best regards,

---

From: "King, Daniel" <[email-masked]>
Date: Fri, 19 Sep 2014 08:34:45 +0000

Great, we agree. Obviously ACTN is firmly rooted in the transport domain and relevant technologies. I just wanted to highlight some well-established overlay network protocols.

Br, Dan.

Sent: 18 September 2014 22:28

Hi Dan,

Regards,
Young

Hi Young and Richard,

Br, Dan.

Hi Richard,

Thanks,
Young

Hi Richard,

Br, Dan.

Hi Young, all,

Br, Dan.

Regards,
Young

Dhruv, Young,

Excellent progresses!

BR
Daniele

Hi Young,

Please see inline..

From: Dhruv Dhody

Hi Young,

[Dhruv]: That works!

Dhruv

From: Leeyoung

Hi,

Best regards,