[OPSAWG] LC request//RE: I-D Action: draft-ietf-opsawg-capwap-alt-tunnel-09.txt
Duzongpeng <duzongpeng@huawei.com> Mon, 15 May 2017 10:01 UTC
Return-Path: <duzongpeng@huawei.com>
X-Original-To: opsawg@ietfa.amsl.com
Delivered-To: opsawg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C49DD12717E for <opsawg@ietfa.amsl.com>; Mon, 15 May 2017 03:01:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.222
X-Spam-Level:
X-Spam-Status: No, score=-4.222 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 kKRkbRrw_j1d for <opsawg@ietfa.amsl.com>; Mon, 15 May 2017 03:01:20 -0700 (PDT)
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 E1EA41294FD for <opsawg@ietf.org>; Mon, 15 May 2017 02:56:40 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml702-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DGQ33326; Mon, 15 May 2017 09:56:39 +0000 (GMT)
Received: from NKGEML412-HUB.china.huawei.com (10.98.56.73) by lhreml702-cah.china.huawei.com (10.201.108.43) with Microsoft SMTP Server (TLS) id 14.3.301.0; Mon, 15 May 2017 10:56:37 +0100
Received: from NKGEML514-MBX.china.huawei.com ([fe80::40a8:f0d:c0f3:2ca5]) by nkgeml412-hub.china.huawei.com ([10.98.56.73]) with mapi id 14.03.0235.001; Mon, 15 May 2017 17:56:30 +0800
From: Duzongpeng <duzongpeng@huawei.com>
To: "opsawg@ietf.org" <opsawg@ietf.org>
Thread-Topic: LC request//RE: [OPSAWG] I-D Action: draft-ietf-opsawg-capwap-alt-tunnel-09.txt
Thread-Index: AQHSxIC10NjYo3J0mUK+cEaJNpt6yqH1OFNQ
Date: Mon, 15 May 2017 09:56:29 +0000
Message-ID: <BAFEC9523F57BC48A51C20226A5589575FECA9DE@nkgeml514-mbx.china.huawei.com>
References: <149386596579.4881.15914732299692111269@ietfa.amsl.com>
In-Reply-To: <149386596579.4881.15914732299692111269@ietfa.amsl.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-originating-ip: [10.111.149.226]
Content-Type: multipart/mixed; boundary="_006_BAFEC9523F57BC48A51C20226A5589575FECA9DEnkgeml514mbxchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A0B0203.59197B57.00D4, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: ce71689747be73e42bc17b5d8f6c8e00
Archived-At: <https://mailarchive.ietf.org/arch/msg/opsawg/Gkfsz-2iGI02aFhwy2Pc7UNsSkQ>
Subject: [OPSAWG] LC request//RE: I-D Action: draft-ietf-opsawg-capwap-alt-tunnel-09.txt
X-BeenThere: opsawg@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: OPSA Working Group Mail List <opsawg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/opsawg>, <mailto:opsawg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/opsawg/>
List-Post: <mailto:opsawg@ietf.org>
List-Help: <mailto:opsawg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/opsawg>, <mailto:opsawg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 15 May 2017 10:01:25 -0000
Hi All, I am happy to join the I-D draft-ietf-opsawg-capwap-alt-tunnel, and help to improve the document based on the comments received and recorded in this page (https://datatracker.ietf.org/doc/draft-ietf-opsawg-capwap-alt-tunnel). I revised the document and responded to all the existing comments as listed in the attachments. Also thanks Joe Touch's comments, which I have solved in the document. The major change include: 1. At the security aspect, we suggest using the IPSec to protect the data tunnel between WTP and AR. 2. Add a new sub-element, "minimum IPv6 MTU", according to the suggestion from Joe Touch. 3. Make it clear that "IEEE 802.11 WTP Alternate Tunnel Failure Indication" is carried in "CAPWAP Station Configuration Request message". 4. Make it clear that we define seven sub-elements (each with its corresponding type number). Three of them are specific for CAPWAP, one is specific for GRE, and others are common ones. Make it clear that they can only be used as sub-elements of "Alternate Tunnel Encapsulations Type message element" and "IEEE 802.11 WTP Alternate Tunnel Failure Indication message element". 5. Change the structure of the draft. Firstly, introduce the three new "message element"; secondly, introduce the three tunnel types; finnaly, introduce the seven sub-elements involved. 6. Give more explanations to the GRE tunnel type. Now I believe this document is ready to send to IESG. So I request for a WGLC. And I will also help to reply any comments/questions during the following procedure. Regards, Zongpeng -----Original Message----- From: OPSAWG [mailto:opsawg-bounces@ietf.org] On Behalf Of internet-drafts@ietf.org Sent: Thursday, May 04, 2017 10:46 AM To: i-d-announce@ietf.org Cc: opsawg@ietf.org Subject: [OPSAWG] I-D Action: draft-ietf-opsawg-capwap-alt-tunnel-09.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Operations and Management Area Working Group of the IETF. Title : Alternate Tunnel Encapsulation for Data Frames in CAPWAP Authors : Rong Zhang Rajesh S. Pazhyannur Sri Gundavelli Zhen Cao Hui Deng Zongpeng Du Filename : draft-ietf-opsawg-capwap-alt-tunnel-09.txt Pages : 26 Date : 2017-05-03 Abstract: Control and Provisioning of Wireless Access Points (CAPWAP) defines a specification to encapsulate a station's data frames between the Wireless Transmission Point (WTP) and Access Controller (AC). Specifically, the station's IEEE 802.11 data frames can be either locally bridged or tunneled to the AC. When tunneled, a CAPWAP data channel is used for tunneling. In many deployments encapsulating data frames to an entity other than the AC (for example to an Access Router (AR)) is desirable. Furthermore, it may also be desirable to use different tunnel encapsulation modes between the WTP and the Access Router. This document defines extension to CAPWAP protocol for supporting this capability and refers to it as alternate tunnel encapsulation. The alternate tunnel encapsulation allows 1) the WTP to tunnel non-management data frames to an endpoint different from the AC and 2) the WTP to tunnel using one of many known encapsulation types such as IP-IP, IP-GRE, CAPWAP. The WTP may advertise support for alternate tunnel encapsulation during the discovery and join process and AC may select one of the supported alternate tunnel encapsulation types while configuring the WTP. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-opsawg-capwap-alt-tunnel/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-opsawg-capwap-alt-tunnel-09 https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-capwap-alt-tunnel-09 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-opsawg-capwap-alt-tunnel-09 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
- [OPSAWG] I-D Action: draft-ietf-opsawg-capwap-alt… internet-drafts
- [OPSAWG] LC request//RE: I-D Action: draft-ietf-o… Duzongpeng
- Re: [OPSAWG] LC request//RE: I-D Action: draft-ie… Tianran Zhou
- Re: [OPSAWG] LC request//RE: I-D Action: draft-ie… Duzongpeng