[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