Re: [Actn] charter 1.4
AshwoodsmithPeter <Peter.AshwoodSmith@huawei.com> Tue, 09 December 2014 18:40 UTC
Return-Path: <Peter.AshwoodSmith@huawei.com>
X-Original-To: actn@ietfa.amsl.com
Delivered-To: actn@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D56F11A87A6 for <actn@ietfa.amsl.com>; Tue, 9 Dec 2014 10:40:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.76
X-Spam-Level:
X-Spam-Status: No, score=-1.76 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DRKjY9FyQv9V for <actn@ietfa.amsl.com>; Tue, 9 Dec 2014 10:40:43 -0800 (PST)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B90C1A87A4 for <actn@ietf.org>; Tue, 9 Dec 2014 10:40:42 -0800 (PST)
Received: from 172.18.7.190 (EHLO lhreml406-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BMR11358; Tue, 09 Dec 2014 18:40:40 +0000 (GMT)
Received: from DFWEML701-CHM.china.huawei.com (10.193.5.50) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 9 Dec 2014 18:40:39 +0000
Received: from DFWEML703-CHM.china.huawei.com ([10.193.5.130]) by dfweml701-chm ([10.193.5.50]) with mapi id 14.03.0158.001; Tue, 9 Dec 2014 10:40:30 -0800
From: AshwoodsmithPeter <Peter.AshwoodSmith@huawei.com>
To: Leeyoung <leeyoung@huawei.com>, Zhenghaomian <zhenghaomian@huawei.com>, "actn@ietf.org" <actn@ietf.org>
Thread-Topic: [Actn] charter 1.4
Thread-Index: AQHQE2jR9bKtMelSj0u9Gy+4l6qfu5yHeGBQgACKeAD//5PL8A==
Date: Tue, 09 Dec 2014 18:40:29 +0000
Message-ID: <7AE6A4247B044C4ABE0A5B6BF427F8E20A459E4B@dfweml703-chm>
References: <7AEB3D6833318045B4AE71C2C87E8E1729C6825A@dfweml706-chm> <E0C26CAA2504C84093A49B2CAC3261A438C45579@SZXEMA504-MBX.china.huawei.com> <7AEB3D6833318045B4AE71C2C87E8E1729C683F3@dfweml706-chm> <7AE6A4247B044C4ABE0A5B6BF427F8E20A459DC4@dfweml703-chm> <7AEB3D6833318045B4AE71C2C87E8E1729C68744@dfweml706-chm>
In-Reply-To: <7AEB3D6833318045B4AE71C2C87E8E1729C68744@dfweml706-chm>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.193.60.107]
Content-Type: multipart/alternative; boundary="_000_7AE6A4247B044C4ABE0A5B6BF427F8E20A459E4Bdfweml703chm_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: http://mailarchive.ietf.org/arch/msg/actn/UvGTh4s3K_Nwjks0Zx3TUvA01y8
Subject: Re: [Actn] charter 1.4
X-BeenThere: actn@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Abstraction and Control of Transport Networks \(ACTN\)" <actn.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/actn>, <mailto:actn-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/actn/>
List-Post: <mailto:actn@ietf.org>
List-Help: <mailto:actn-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/actn>, <mailto:actn-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 09 Dec 2014 18:40:52 -0000
Hey Young, IMHO ¨C Segment Routing when you are strict with the Segments (ie no loose hops) is pretty much equivalent to MPLS-TP/TE in its ability to precisely steer traffic and is therefore ¡°Connection Oriented¡±. Personally I see a lot of value in similar logic to control a hierarchy of CO tunnels: L0 Lambda or fiber/space L1 Time L2.5 (MPLS-TE/TP/Strict Segment) So perhaps the answer is if we include L2.5, then Strict Segment routing is included, otherwise MPLS-TE/TP drop out too? However I can imagine there is a lot of politics around this which must also be factored in. Peter From: Leeyoung Sent: Tuesday, December 09, 2014 12:02 PM To: AshwoodsmithPeter; Zhenghaomian; actn@ietf.org Subject: RE: [Actn] charter 1.4 Hi Peter, Thanks for your comment. Both are very good points. Yes, subnet is L3 lingo. We meant sub-network. Will correct. As for Segment Routing, there have been some debate if Segment Routing is a connection-oriented technology or not. Some disagreed and we have taken the term out of the charter and other ACTN document. Do you have a strong opinion about Segment Routing to be included here? We are less concerned about domain control technology (whether it is MPLS-TE/TP or Segment Routing), but do you see any implication that may affect the way ACTN will operate? Thanks, Young From: AshwoodsmithPeter Sent: Tuesday, December 09, 2014 10:53 AM To: Leeyoung; Zhenghaomian; actn@ietf.org<mailto:actn@ietf.org> Subject: RE: [Actn] charter 1.4 Thanks Young, After a very quick reading have things: 1- Minor point: ¡°control multi-subnet, multi-technology, multi-vendor domain networks¡± Suggest that ¡°subnet¡± is a not the right term given its explicit meaning for L3 .. unless that¡¯s what you meant? Perhaps just spell it out ¡°sub-network¡± 2- Quick question: ¡°other emerging network technologies with connection-oriented behavior.¡± Would that include Segment Routing? Peter From: ACTN [mailto:actn-bounces@ietf.org] On Behalf Of Leeyoung Sent: Monday, December 08, 2014 11:13 PM To: Zhenghaomian; actn@ietf.org<mailto:actn@ietf.org> Subject: Re: [Actn] charter 1.4 Hi Haomian, Thanks for your comment. Please see inline my response. Best regards, Young From: Zhenghaomian Sent: Monday, December 08, 2014 8:42 PM To: Leeyoung; actn@ietf.org<mailto:actn@ietf.org> Subject: ´ð¸´: [Actn] charter 1.4 Hi, Young and all, Great to see the updated charter with description on relationship with other WGs. Please find my comments as follow: 1. Two terms ¡®Virtual network coordination function¡¯ and ¡®virtual service coordination function¡¯ in ACTN are described in the charter. It seems to me both individual terms were properly described together with their benifits, however it is not clear to me what is the relationship with ACTN. Are we aim on developing such functions? Are these the only function(s) we need to consider (I don¡¯t have other in my mind, just confirm)? YOUNG>> Yes, these two functions are one of the key functions ACTN solution will develop among other functions. These functions are control functions and the VNC is expected to provide on its interfaces with CNC/PNCs. The core design team is working on the updated framework document and will be made available soon to describe these in details. 2. It was mentioned ¡°It will clearly show the interaction between the customer controller and the virtual network controller, and the virtual network controller and the physical network controllers with possibility for recursion¡±. I don¡¯t know whether there was a change on the terminology ¡®customer network controller (CNC)¡¯, it was mentioned in the charter as ¡®customer controller¡¯. May need to revise it or skip if the terminology is already changed. Besides, between CNC and VNC, is it limited to 1-to-1? N-to-1 may also be considered, if so, please consider changing to ¡®contollers¡¯, just like ¡®between VNC and PNCs¡¯. YOUNG>> Thanks for pointing this --- it should have been ¡°customer network controller¡±. It was a typo. CNC-VNC should be N-to-1. Your suggestion clarifies: will change the term to CNCs. 3. - With the TEAS WG regarding TE architecture and generic TE Information and Data Model. ACTN will extend these models for its use cases. Should better be ¡®ACTN may extend these models for its use cases.¡¯ YOUNG>> I think ¡°will¡± is a bit more assertive/definitive while ¡°may¡± is a bit uncertain and ambiguous. I think ACTN ¡°will¡± most likely extend date models to support its use cases. 4. - With the PCE WG on uses of a PCE in the ACTN architecture. Should better be ¡®With the PCE WG on the uses of PCEs and PCEP in the ACTN architecture.¡¯ My understanding is PCEP MAY be a candidate protocol on related interfaces if we consider any controller as PCE. YOUNG>> Good point! Some of the debates are if PCEP can be used to support the interface functionality required on VNC-PNCs. At this moment from a requirement perspective, it looks like we need more than what PCEP can support today. Let put on this hold for now until we see full requirement discussion. Thanks a lot. Best wishes, Haomian ·¢¼þÈË: Leeyoung [mailto:leeyoung@huawei.com] ·¢ËÍʱ¼ä: 2014Äê12ÔÂ9ÈÕ 7:19 ÊÕ¼þÈË: actn@ietf.org<mailto:actn@ietf.org> Ö÷Ìâ: [Actn] charter 1.4 Dear all, Here¡¯s a charter revision (v.1.4) for your comment. Your comment will be appreciated. If there are any key missing items for the WG to work that you feel should be included in the charter or any other discussions on terminology and clarify, please share your views to the list. We look forward to seeing your active participation. Best regards, Young --------------------------------------------------------------------------------------------- Last Updated: December 5, 2014 Draft Charter V1.4 Abstraction and Control of Transport Networks (ACTN) Transport networks are defined as network infrastructure that provides connectivity and bandwidth for customer services. They are characterized by their ability to support server layer provisioning and traffic engineering for client layer services, such that resource guarantees may be provided to their customers. Transport networks here refer to a set of different type of connection-oriented networks, which include Connection-Oriented Circuit Switched (CO-CS) networks and Connection- Oriented Packet Switched (CO-PS) networks. This implies that at least the following transport networks are in scope: Layer 1 (L1) and Layer 0 (L0) optical networks (e.g., OTN, ODU, OCh/WSON), MPLS-TP, MPLS-TE, as well as other emerging network technologies with connection-oriented behavior. Transport networks have a variety of mechanisms to: - Facilitate separation of data plane and control plane, - Allow for distributed signaling or centralized models (e.g., NMS- based or centralized signaling) for path setup and protection, and - Provide traffic engineering mechanism via centralized path computation. These represent key technologies for enabling flexible and dynamic networking, and efficient control and recovery of resources. Although these technologies provide significant benefits within a single domain control boundary, they do not meet the growing need for transport network virtualization in multi-domain transport networks. More and more network operators are building and operating on multi-domain transport networks. These domains (collections of links and nodes) may be each of a different technology, administrative zones, or vendor-specific islands. Establishment of end-to-end connections spanning multiple domains is a perpetual problem for operators because of both operational concerns (control plane and management plane) and interoperability issues (control plane and data plane). Due to these issues, new services that require connections that traverse multiple domains need significant planning and often manual operations to interface different vendor equipment and technology. The aim of Abstraction and Control of Transport Networks (ACTN) is to facilitate a centralized virtual network operation: the creation of a virtualized environment allowing operators to view and control multi- subnet, multi-technology, multi-vendor domain networks. This will enable rapid service deployment of new dynamic and elastic services, and will improve overall network operations and scaling of existing services. Discussion with operators has also highlighted a need for virtual network coordination based on the abstraction of underlying technology and vendor domains as well as virtual service coordination based on service-related knowledge. Abstraction of transport networks also allows operators to consolidate their network services into multi-tenant virtual transport networks. Virtual network coordination function in ACTN is built on a control hierarchy where a multi-domain coordinator interacts with the control mechanism for each domain (e.g., EMS/NMS, GMPLS/PCE control plane, SDN controller) to represent abstraction of network resources and to provide control functions for virtual networks. These control functions enable various services/clients/applications to create and manage their own virtual networks that share the common transport network resources. Virtual service coordination function in ACTN incorporates customer's service-related knowledge in virtual network operation in order to seamlessly operate virtual networks while meeting customer's service requirements. The ACTN facilitates seamless vertical service coordination across multi-tenant customers (primarily internal service organizations with respect to a network operator), the control of virtual and physical network domains, as well as a horizontal E2E service coordination across multi-domain networks. The ACTN working group works to develop a high-level architecture that describes the basic building-blocks necessary to enable the multi-domain virtual service coordination. It will identify key building components and the corresponding interfaces among these components. The Key components can be future building block or legacy components existing today. It will clearly show the interaction between the customer controller and the virtual network controller, and the virtual network controller and the physical network controllers with possibility for recursion. The ACTN working group will develop the requirements for these interfaces and extend existing protocols and data models if necessary with coordination with other WGs or to develop new protocols and data models uniquely identified in scope of ACTN WG. The ACTN WG will coordinate with the following working groups: - With the TEAS WG regarding TE architecture and generic TE Information and Data Model. ACTN will extend these models for its use cases. - With the CCAMP WG regarding abstraction of technology specific Data Models - With the PCE WG on uses of a PCE in the ACTN architecture. - With the IDR WG on the use of BGP-LS in ACTN. In doing this work, the WG will cooperate with external SDOs as necessary. The working group will work on the following items: - Develop an applicability document based on use cases. This work will support the architecture and serve as the repository of requirement sets that include: support of APIs/protocols and information models. - Complete architecture that describes the basic building blocks to enable virtual network and service coordination. - Evaluate gap of existing IETF and other protocols, encoding languages and data models to fulfill the requirements. Where the need for data models is identified, the working group will first examine data models already developed by other working groups. - Work on data models that are uniquely identified in the scope of ACTN. It is envisioned to work on issues of security, privacy, and trust in mechanisms that provide abstraction across domain boundaries (and therefore across trust boundaries) and the abstraction of customer's service-specific models. - Develop protocol extensions as deemed necessary to support unique requirements of controller interfaces. Milestones May 2015 Adopt the WG draft on the Applicability of ACTN. Aug 2015 Adopt the WG draft on the ACTN Architecture. Sep 2015 Adopt the WG draft on Gap Analysis and YANG models. Nov 2015 Adopt the WG drafts on Protocol Extensions for basic models. Feb 2016 Submit the Applicability of ACTN to IESG as an informational RFC. Adopt the WG drafts on Protocol Extensions for advanced models. Apr 2016 Submit the ACTN Architecture to IESG for review as an informational RFC. May 2016 Submit the Gap Analysis and YANG model(s) document to IESG for review as Proposed Standards RFC. Jul 2016 Submit the Protocol Extensions for basic models to IESG for review as Proposed Standards RFCs. Sep 2016 Submit the Protocol Extensions for advanced models to IESG for Review as Proposed Standard RFCs. Nov 2016 recharter or conclude the WG.
- [Actn] charter 1.4 Leeyoung
- [Actn] 答复: charter 1.4 Zhenghaomian
- Re: [Actn] charter 1.4 Leeyoung
- Re: [Actn] charter 1.4 Kenji Kumaki
- Re: [Actn] charter 1.4 Leeyoung
- Re: [Actn] charter 1.4 ningso
- Re: [Actn] charter 1.4 Andrew G. Malis
- Re: [Actn] charter 1.4 Leeyoung
- Re: [Actn] charter 1.4 Leeyoung
- Re: [Actn] charter 1.4 AshwoodsmithPeter
- Re: [Actn] charter 1.4 ningso
- Re: [Actn] charter 1.4 Leeyoung
- Re: [Actn] charter 1.4 Andrew G. Malis
- Re: [Actn] charter 1.4 AshwoodsmithPeter
- Re: [Actn] charter 1.4 AshwoodsmithPeter
- Re: [Actn] charter 1.4 Khuzema Pithewan
- Re: [Actn] charter 1.4 Leeyoung
- Re: [Actn] charter 1.4 Leeyoung
- Re: [Actn] charter 1.4 Khuzema Pithewan
- Re: [Actn] charter 1.4 BELOTTI, SERGIO (SERGIO)
- Re: [Actn] charter 1.4 Leeyoung
- Re: [Actn] charter 1.4 Khuzema Pithewan