Re: [OPSAWG] LC request//RE: I-D Action: draft-ietf-opsawg-capwap-alt-tunnel-09.txt

Duzongpeng <duzongpeng@huawei.com> Wed, 17 May 2017 09:02 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 89A47128B88 for <opsawg@ietfa.amsl.com>; Wed, 17 May 2017 02:02:25 -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 rZagwhKc0itT for <opsawg@ietfa.amsl.com>; Wed, 17 May 2017 02:02:23 -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 6D064129409 for <opsawg@ietf.org>; Wed, 17 May 2017 01:57:56 -0700 (PDT)
Received: from 172.18.7.190 (EHLO LHREML710-CAH.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DNF01788; Wed, 17 May 2017 08:57:51 +0000 (GMT)
Received: from NKGEML411-HUB.china.huawei.com (10.98.56.70) by LHREML710-CAH.china.huawei.com (10.201.108.33) with Microsoft SMTP Server (TLS) id 14.3.301.0; Wed, 17 May 2017 09:57:50 +0100
Received: from NKGEML514-MBX.china.huawei.com ([fe80::40a8:f0d:c0f3:2ca5]) by nkgeml411-hub.china.huawei.com ([10.98.56.70]) with mapi id 14.03.0235.001; Wed, 17 May 2017 16:57:39 +0800
From: Duzongpeng <duzongpeng@huawei.com>
To: Tianran Zhou <zhoutianran@huawei.com>, "opsawg@ietf.org" <opsawg@ietf.org>
Thread-Topic: [OPSAWG] LC request//RE: I-D Action: draft-ietf-opsawg-capwap-alt-tunnel-09.txt
Thread-Index: AQHSzgtX+GS7jkaG6kuolOMD4c+33aH4OmCg
Date: Wed, 17 May 2017 08:57:39 +0000
Message-ID: <BAFEC9523F57BC48A51C20226A5589575FECEF39@nkgeml514-mbx.china.huawei.com>
References: <149386596579.4881.15914732299692111269@ietfa.amsl.com> <BAFEC9523F57BC48A51C20226A5589575FECA9DE@nkgeml514-mbx.china.huawei.com> <BBA82579FD347748BEADC4C445EA0F21A237CF6A@NKGEML515-MBX.china.huawei.com>
In-Reply-To: <BBA82579FD347748BEADC4C445EA0F21A237CF6A@NKGEML515-MBX.china.huawei.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.111.149.226]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020206.591C1090.007F, 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: 35b30b49bcfa5a528832b0be509f1d82
Archived-At: <https://mailarchive.ietf.org/arch/msg/opsawg/smTYgY_aUv3dOIVTR-jyYWzg-HU>
Subject: Re: [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: Wed, 17 May 2017 09:02:26 -0000

Hi Tianran,

Thanks for your question.

This draft describes the scenario that, on the date plane, the WTP is connected to an AR instead of AC by using some kind of tunnel mechanisms. And this I-D describes several tunnel options. It will benefit the interworking of WTP and AC when this alt-tunnel network infrastructure is used.

As far as I know, Huawei, Cisco and ALU partially implemented the proposed solution(please correct me if my information is wrong ;-)). I.e., each of the vendors supports one or more tunnel types, while the full set is not necessary.


Best Regards
Zongpeng Du

-----Original Message-----
From: Tianran Zhou 
Sent: Tuesday, May 16, 2017 2:12 PM
To: Duzongpeng; opsawg@ietf.org
Subject: RE: [OPSAWG] LC request//RE: I-D Action: draft-ietf-opsawg-capwap-alt-tunnel-09.txt

Hi Zongpeng,

Thank you very much for picking this work up. The new version has a significant improvement on addressing existing comments.
One more question that many people may be interested. Whether this I-D has been implemented or has plan to be implemented and deployed?

Best,
Tianran

> -----Original Message-----
> From: OPSAWG [mailto:opsawg-bounces@ietf.org] On Behalf Of Duzongpeng
> Sent: Monday, May 15, 2017 5:56 PM
> To: opsawg@ietf.org
> Subject: [OPSAWG] LC request//RE: I-D Action:
> draft-ietf-opsawg-capwap-alt-tunnel-09.txt
> 
> 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-tun
> nel-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