Re: [OPSAWG] I-D Action: draft-ietf-opsawg-capwap-alt-tunnel-10.txt

Duzongpeng <duzongpeng@huawei.com> Mon, 18 September 2017 09:42 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 B2BA0132932 for <opsawg@ietfa.amsl.com>; Mon, 18 Sep 2017 02:42:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.221
X-Spam-Level:
X-Spam-Status: No, score=-4.221 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, 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 I-6TE8EMPYnl for <opsawg@ietfa.amsl.com>; Mon, 18 Sep 2017 02:42:19 -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 1EAB7129B7A for <opsawg@ietf.org>; Mon, 18 Sep 2017 02:42:18 -0700 (PDT)
Received: from 172.18.7.190 (EHLO LHREML714-CAH.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DVR30219; Mon, 18 Sep 2017 09:42:15 +0000 (GMT)
Received: from NKGEML413-HUB.china.huawei.com (10.98.56.74) by LHREML714-CAH.china.huawei.com (10.201.108.37) with Microsoft SMTP Server (TLS) id 14.3.301.0; Mon, 18 Sep 2017 10:42:14 +0100
Received: from NKGEML514-MBX.china.huawei.com ([fe80::40a8:f0d:c0f3:2ca5]) by NKGEML413-HUB.china.huawei.com ([10.98.56.74]) with mapi id 14.03.0235.001; Mon, 18 Sep 2017 17:42:09 +0800
From: Duzongpeng <duzongpeng@huawei.com>
To: "opsawg@ietf.org" <opsawg@ietf.org>
Thread-Topic: [OPSAWG] I-D Action: draft-ietf-opsawg-capwap-alt-tunnel-10.txt
Thread-Index: AQHTKJ8OvbFHcfxE/Ua8Ob5dckxENqK6cAcw
Date: Mon, 18 Sep 2017 09:42:10 +0000
Message-ID: <BAFEC9523F57BC48A51C20226A5589575FF4E755@nkgeml514-mbx.china.huawei.com>
References: <150487415301.17285.8385247668098511742@ietfa.amsl.com>
In-Reply-To: <150487415301.17285.8385247668098511742@ietfa.amsl.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.0A020203.59BF94F8.0075, 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: 3b0e55d6cc09f0b4faa741852daef97d
Archived-At: <https://mailarchive.ietf.org/arch/msg/opsawg/jwhw1BkPIE5Nel5DHhcmvCyMRo8>
Subject: Re: [OPSAWG] I-D Action: draft-ietf-opsawg-capwap-alt-tunnel-10.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, 18 Sep 2017 09:42:22 -0000

Hi, Everyone,

	We have submitted a new version for the "Alternate Tunnel Encapsulation for Data Frames in CAPWAP".

	It has been changed to an Experimental draft, and we have added a new section to introduce the History of the document.

1.3.  History of the document

   This document was started to accommodate Service Provider's need of a
   more flexible deployment mode with alternative tunnels [RFC7494].
   Experiments and tests have been done for this alt-tunnel network
   infrastructure.  However important, the deployment of relevant
   technology is yet to complete.  This experimental document is
   intended to serve as a historical reference for any future work as to
   the operational and deployment requirements.

	Welcome for comments. If no objection, please trigger the last call.

	This draft has gone through a last call last year. 
	After that, we have changed it according to the comments collected.

Best Regards
Zongpeng Du


-----Original Message-----
From: OPSAWG [mailto:opsawg-bounces@ietf.org] On Behalf Of internet-drafts@ietf.org
Sent: Friday, September 08, 2017 8:36 PM
To: i-d-announce@ietf.org
Cc: opsawg@ietf.org
Subject: [OPSAWG] I-D Action: draft-ietf-opsawg-capwap-alt-tunnel-10.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 WG 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-10.txt
	Pages           : 26
	Date            : 2017-09-08

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-10
https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-capwap-alt-tunnel-10

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-opsawg-capwap-alt-tunnel-10


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