Re: [Actn] ACTN charter v1.0

["Y. Richard Yang" <[e-mail]>]

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 <[e-mail]> 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.
>
>
>
> Please see inline for my response.
>
>
>
> Regards,
>
> Young
>
>
>
> *From:* Daniele Ceccarelli [mailto:[e-mail]]
> *Sent:* Friday, September 12, 2014 9:27 AM
> *To:* Dhruv Dhody; Leeyoung; [e-mail]
> *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.
>
>
>
> 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….”
>
>
>
>
>
> 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.
>
>
>
> 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:[e-mail]] *On Behalf Of *Dhruv Dhody
> *Sent:* venerdì 12 settembre 2014 04:33
> *To:* Leeyoung; [e-mail]
> *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; [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.
>
>
>
>
>
> [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.”
>
>
>
> 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.
>
>
>
> [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.
>
>
>
> YOUNG>> Definitely. Thanks a lot for your review and great comments.
>
>
>
> Dhruv
>
>
>
>
>
> *From:* ACTN [mailto:[e-mail] <[e-mail]>] *On
> Behalf Of *Leeyoung
> *Sent:* 10 September 2014 04:53
> *To:* Leeyoung; [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]
> *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.
>
>
>
>
>
>
>
> _______________________________________________
> ACTN mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/actn
>
>


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