[Actn] 答复: Status and plans for ACTN

Fatai Zhang <zhangfatai@huawei.com> Mon, 01 December 2014 11:14 UTC

Return-Path: <zhangfatai@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 66D261A1B3B for <actn@ietfa.amsl.com>; Mon, 1 Dec 2014 03:14:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.078
X-Spam-Level: **
X-Spam-Status: No, score=2.078 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CHARSET_FARAWAY_HEADER=3.2, CN_BODY_35=0.339, MIME_8BIT_HEADER=0.3, 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 Ch8SkNPZJvuv for <actn@ietfa.amsl.com>; Mon, 1 Dec 2014 03:14:09 -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 D082B1A1B38 for <actn@ietf.org>; Mon, 1 Dec 2014 03:14:08 -0800 (PST)
Received: from 172.18.7.190 (EHLO lhreml403-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BPK89359; Mon, 01 Dec 2014 11:14:07 +0000 (GMT)
Received: from SZXEMA412-HUB.china.huawei.com (10.82.72.71) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 1 Dec 2014 11:14:06 +0000
Received: from SZXEMA504-MBS.china.huawei.com ([169.254.8.50]) by SZXEMA412-HUB.china.huawei.com ([10.82.72.71]) with mapi id 14.03.0158.001; Mon, 1 Dec 2014 19:13:59 +0800
From: Fatai Zhang <zhangfatai@huawei.com>
To: "adrian@olddog.co.uk" <adrian@olddog.co.uk>, "actn@ietf.org" <actn@ietf.org>
Thread-Topic: [Actn] Status and plans for ACTN
Thread-Index: AdAKZXaf8QAOhEndRl+d8uEiSoAkjgC6ZP/w
Date: Mon, 01 Dec 2014 11:13:59 +0000
Message-ID: <F82A4B6D50F9464B8EBA55651F541CF85CBAC33F@SZXEMA504-MBS.china.huawei.com>
References: <039201d00a65$7a6d6a30$6f483e90$@olddog.co.uk>
In-Reply-To: <039201d00a65$7a6d6a30$6f483e90$@olddog.co.uk>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.47.81.149]
Content-Type: text/plain; charset="gb2312"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: http://mailarchive.ietf.org/arch/msg/actn/RmXkEqJsvjMfsPodz2xPtawY2OY
Cc: "akatlas@gmail.com" <akatlas@gmail.com>
Subject: [Actn] 答复: Status and plans for ACTN
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: Mon, 01 Dec 2014 11:14:11 -0000

Thanks Adrian.

I think the task of ACTN is to facilitate providing the Virtual Network services to the customers, and the use cases are quite clear as you said. 

To focus on some of the open questions you raised and trigger more discussions, I would like to share some my initial thoughts:

Q: What is entirely new and needs the focus of a WG?

[Fatai]: How to provide the Virtual Network to the customers respectively is totally new for the IETF community, even though some of the work like Lx VPN (especially L1VPN) had been defined/discussed in IETF. I think  the Virtual Network in the scope of ACTN is clearly beyond of L1 VPN, which provides L1 VPN services/connections between CE devices. Therefore, from the functionality perspective, I see some new things. firstly, I think the L1 VPN (concluded) + L0 VPN could fit part of the *new* work. Secondly, how to return the Virtual Network to the customer (e.g, creation and query) and how to manage the Virtual Network (e.g., deletion, modification) is totally new, which needs policy/business constraints. Thirdly, how to provision the service/connection over the Virtual Network might be different from the provisioning connection over the physical networks. Fourthly, data Model for the Virtual Network might be another new thing. More new things might come later, :-)

Q: What is new but likely to be worked on in other WGs may be needing review and guidance from an ACTN WG?

[Fatai]: Setup the *Virtual* connection over the Virtual Network is new, but could be defined in CCAMP/TEAS by extending RSVP-TE protocols or any other WGs including ACTN itself by other means (e.g., centralized provisioning). Something new related to routing might be worked in OSPF WG. 

Q: What is a delta on work done in other WGs that needs cooperative development? 

[Fatai]: I don’t see clear boundary between this question and the above question (the second one). Clarification would be much appreciated. 

Q: What already exists but needs an applicability statement to demonstrate its use?

[Fatai]:No answer, :-) 





-----邮件原件-----
发件人: ACTN [mailto:actn-bounces@ietf.org] 代表 Adrian Farrel
发送时间: 2014年11月28日 1:14
收件人: actn@ietf.org
抄送: akatlas@gmail.com
主题: [Actn] Status and plans for ACTN

Hello again,

As promised here are some more thoughts on the progress of ACTN.

I had a call today with the BoF chairs: Sergio and Dhruv were also there. We discussed the details of the interfaces between the ACTN components a bit more because my main thrust is to understand what work needs doing in a protocol sense.

My message is that I recognise the energy and use cases behind ACTN, but I do not want to charter a working group to work on use cases and requirements. From where I sit, that would be a huge waste of time and effort. We already understand the use cases, so while it would be just fine to continue to work on them, they are no longer a hurdle for forming a WG or for developing solutions.
What is more, the requirements work can be developed quickly and efficiently by a small team and then discussed and reviewed on this mailing list.

The intention, therefore, is to take the current framework draft and:
- refine it to make the architecture clearer
   - there is at least the question of recursion to be dealt with
- expand on exactly what the client is asking for
   - is it "just" abstract topology and connectivity, or is it also 
      related to "services"?
- add a lot more detail to the description of the functional interfaces
    - what are the primitives?
    - what i the information carried on the primitives?

Young, Daniele, Sergio, and Dhruv already have some of this material in slides and in notes as well as in their heads. So I'm hoping that it will not be a huge effort for them to start to share this on the list and to add to the I-D.

I'm hoping that this will serve to make it much clearer what work is actually involved in delivering ACTN. What is entirely new and needs the focus of a WG?
What is new but likely to be worked on in other WGs may be needing review and guidance from an ACTN WG? What is a delta on work done in other WGs that needs cooperative development? What already exists but needs an applicability statement to demonstrate its use?

The answers to these questions will help us understand the value of a new working group, and will form the basis of the deliverables and work items if one is chartered.

Young and Daniele have promised to try to bring their thoughts to this list in the form of emails and a revised I-D. I really hope that we can build on the energy that was in the room in Honolulu by having active discussion of the issues they raise and by getting detailed and constructive reviews (e.g. suggest
text!) of the drafts they post.

Thanks,
Adrian

_______________________________________________
ACTN mailing list
ACTN@ietf.org
https://www.ietf.org/mailman/listinfo/actn