Re: [OPSAWG] Fwd: Alternate Tunnel Encapsulation for Data Frames in CAPWAP
Sheng Jiang <jiangsheng@huawei.com> Mon, 24 February 2014 06:41 UTC
Return-Path: <jiangsheng@huawei.com>
X-Original-To: opsawg@ietfa.amsl.com
Delivered-To: opsawg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D0031A0339 for <opsawg@ietfa.amsl.com>; Sun, 23 Feb 2014 22:41:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.747
X-Spam-Level:
X-Spam-Status: No, score=-4.747 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] 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 uuyNDWCue7yV for <opsawg@ietfa.amsl.com>; Sun, 23 Feb 2014 22:41:46 -0800 (PST)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 42C491A0103 for <opsawg@ietf.org>; Sun, 23 Feb 2014 22:41:45 -0800 (PST)
Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BDX11868; Mon, 24 Feb 2014 06:41:43 +0000 (GMT)
Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 24 Feb 2014 06:41:39 +0000
Received: from NKGEML408-HUB.china.huawei.com (10.98.56.39) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 24 Feb 2014 06:41:42 +0000
Received: from NKGEML512-MBX.china.huawei.com ([169.254.7.206]) by nkgeml408-hub.china.huawei.com ([10.98.56.39]) with mapi id 14.03.0158.001; Mon, 24 Feb 2014 14:41:38 +0800
From: Sheng Jiang <jiangsheng@huawei.com>
To: Liu Dapeng <maxpassion@gmail.com>, Melinda Shore <melinda.shore@gmail.com>
Thread-Topic: [OPSAWG] Fwd: Alternate Tunnel Encapsulation for Data Frames in CAPWAP
Thread-Index: AQHPMQgR475fkAHdo0+HxltF0idFF5rD9Log
Date: Mon, 24 Feb 2014 06:41:37 +0000
Message-ID: <5D36713D8A4E7348A7E10DF7437A4B923AE0AF70@nkgeml512-mbx.china.huawei.com>
References: <4ED2E36A22261145861BAB2C24088B4320F5A67C@xmb-aln-x09.cisco.com> <53040210.4090709@gmail.com> <CAKcc6AcgY59X5+6MNyikXSuE0zfeo4VC+Ru-6AJ3YexTjJb8mQ@mail.gmail.com>
In-Reply-To: <CAKcc6AcgY59X5+6MNyikXSuE0zfeo4VC+Ru-6AJ3YexTjJb8mQ@mail.gmail.com>
Accept-Language: en-GB, zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.111.98.145]
Content-Type: multipart/alternative; boundary="_000_5D36713D8A4E7348A7E10DF7437A4B923AE0AF70nkgeml512mbxchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: http://mailarchive.ietf.org/arch/msg/opsawg/UUMuLES_fv2ujJ5XgoG40x54r9U
Cc: "opsawg@ietf.org" <opsawg@ietf.org>
Subject: Re: [OPSAWG] Fwd: Alternate Tunnel Encapsulation for Data Frames in CAPWAP
X-BeenThere: opsawg@ietf.org
X-Mailman-Version: 2.1.15
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: <http://www.ietf.org/mail-archive/web/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, 24 Feb 2014 06:41:48 -0000
+1, support adoption. Sheng From: OPSAWG [mailto:opsawg-bounces@ietf.org] On Behalf Of Liu Dapeng Sent: Monday, February 24, 2014 10:28 AM To: Melinda Shore Cc: opsawg@ietf.org Subject: Re: [OPSAWG] Fwd: Alternate Tunnel Encapsulation for Data Frames in CAPWAP Hello all, The control/data channel separation of CAPWAP is a very useful deployment use case for operators. In that sense, I support the adoption of this draft and I do not see there is overlap/conflict with the already adopted CAPWAP extension drafts. Cheers, Dapeng Liu 2014-02-19 9:00 GMT+08:00 Melinda Shore <melinda.shore@gmail.com<mailto:melinda.shore@gmail.com>>: Please note that Rajesh is planning to ask for working group adoption of this document. Please give it a read and provide feedback on this mailing list. Particularly interested in the question of how well it meshes with CAPWAP documents we've already adopted. Melinda -------- Original Message -------- Subject: [OPSAWG] Alternate Tunnel Encapsulation for Data Frames in CAPWAP Date: Tue, 18 Feb 2014 22:10:10 +0000 From: Rajesh Pazhyannur (rpazhyan) <rpazhyan@cisco.com<mailto:rpazhyan@cisco.com>> To: opsawg@ietf.org<mailto:opsawg@ietf.org> <opsawg@ietf.org<mailto:opsawg@ietf.org>> Hello We have a submitted a new version of Alternate Tunnel Encapsulation for Data Frames in CAPWAP,_http://datatracker.ietf.org/doc/draft-zhang-opsawg-capwap-cds/_. Abstract In centralized IEEE 802.11 Wireless Local Area Network (WLAN) architecture, the Access Controller (AC) isn't intelligent enough actually to aggregate all the wireless frames, even the bandwidth requirement in the access point is increasing. Thus it is a general case in the existing operator's network that WTPs forward the wireless frames directly to Access Router (AR) to avoid overload on the AC. In this scenario, CAPWAP Control Channel and CAPWAP Data Channel are separated from each other. This document extends CAPWAP for applicability of CAPWAP Control and Data Channel separation. We received some questions and suggestions from Dan Romascanu and John Kaippallimalil on the mailing list on the previous draft. We have attempted to address them in this draft. Specifically, 1. How does this draft address signaling, discovery mechanisms related to setting up alternate tunnel. (ans. Tunneling protocols like L2TPv3, IP/GRE (PMIPv6) already have a signaling mechanism. This draft focuses on specifying the tunnel type and provides a container to hold message elements) 2. Need for alternate tunnel encapsulation (given the existence of defined mode with local bridging) We would like to get it adopted as a working group item and would like feedback on whether we are on track. thanks Regards Rajesh _______________________________________________ OPSAWG mailing list OPSAWG@ietf.org<mailto:OPSAWG@ietf.org> https://www.ietf.org/mailman/listinfo/opsawg -- ------ Best Regards, Dapeng Liu
- [OPSAWG] Alternate Tunnel Encapsulation for Data … Rajesh Pazhyannur (rpazhyan)
- [OPSAWG] Fwd: Alternate Tunnel Encapsulation for … Melinda Shore
- Re: [OPSAWG] Fwd: Alternate Tunnel Encapsulation … Fan, Peng
- Re: [OPSAWG] Fwd: Alternate Tunnel Encapsulation … Liu Dapeng
- Re: [OPSAWG] Fwd: Alternate Tunnel Encapsulation … Sheng Jiang
- Re: [OPSAWG] Fwd: Alternate Tunnel Encapsulation … Melinda Shore
- Re: [OPSAWG] Fwd: Alternate Tunnel Encapsulation … Romascanu, Dan (Dan)
- Re: [OPSAWG] Fwd: Alternate Tunnel Encapsulation … John Kaippallimalil
- Re: [OPSAWG] Alternate Tunnel Encapsulation for D… Hui Deng