IETF Logo Mail Archive

Re: [OPSAWG] Seeking discussion on "Alternate Tunnel Encapsulation for Data Frames in CAPWAP"

"Romascanu, Dan (Dan)" <dromasca@avaya.com> Tue, 29 October 2013 15:26 UTC

Return-Path: <dromasca@avaya.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 A8B1721F9EC8 for <opsawg@ietfa.amsl.com>; Tue, 29 Oct 2013 08:26:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.8
X-Spam-Level:
X-Spam-Status: No, score=-102.8 tagged_above=-999 required=5 tests=[AWL=-0.202, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2HHeyvdSoVIh for <opsawg@ietfa.amsl.com>; Tue, 29 Oct 2013 08:26:08 -0700 (PDT)
Received: from p-us1-iereast-outbound.us1.avaya.com (p-us1-iereast-outbound.us1.avaya.com [135.11.29.13]) by ietfa.amsl.com (Postfix) with ESMTP id 9B35811E82CE for <opsawg@ietf.org>; Tue, 29 Oct 2013 08:26:08 -0700 (PDT)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AsQNAN3Sb1KHCzI1/2dsb2JhbABZgkMjIThUqk2CO4lmiEeBKhZ0giUBAQEBAxIbXAIBCA0EAQMBAQsdBzIUAwYIAQEEARIIEweHZQEMnGCdFBePFjcBBoMZgQ0DmTmFNIslgWiBPoIq
X-IronPort-AV: E=Sophos; i="4.93,593,1378872000"; d="scan'208,217"; a="34472452"
Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 29 Oct 2013 11:26:07 -0400
Received: from unknown (HELO AZ-FFEXHC01.global.avaya.com) ([135.64.58.11]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 29 Oct 2013 11:16:27 -0400
Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC01.global.avaya.com ([135.64.58.11]) with mapi id 14.03.0146.000; Tue, 29 Oct 2013 16:26:06 +0100
From: "Romascanu, Dan (Dan)" <dromasca@avaya.com>
To: "Rajesh Pazhyannur (rpazhyan)" <rpazhyan@cisco.com>, "opsawg@ietf.org" <opsawg@ietf.org>
Thread-Topic: [OPSAWG] Seeking discussion on "Alternate Tunnel Encapsulation for Data Frames in CAPWAP"
Thread-Index: Ac7SqIs8II5D0brnRoyCTVQ6wZ7WWACEPwyw
Date: Tue, 29 Oct 2013 15:26:05 +0000
Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA1291C9C0@AZ-FFEXMB04.global.avaya.com>
References: <4ED2E36A22261145861BAB2C24088B4320ED015B@xmb-aln-x09.cisco.com>
In-Reply-To: <4ED2E36A22261145861BAB2C24088B4320ED015B@xmb-aln-x09.cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [135.64.58.46]
Content-Type: multipart/alternative; boundary="_000_9904FB1B0159DA42B0B887B7FA8119CA1291C9C0AZFFEXMB04globa_"
MIME-Version: 1.0
Subject: Re: [OPSAWG] Seeking discussion on "Alternate Tunnel Encapsulation for Data Frames in CAPWAP"
X-BeenThere: opsawg@ietf.org
X-Mailman-Version: 2.1.12
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: Tue, 29 Oct 2013 15:26:15 -0000

Hi,

I read the I-D and I have some clarification questions:

-          If tunneling using the new modes described in this document is going to be possible to endpoints different from the AC, is it expected for these endpoints to run all the discovery and advertising protocols? This seems to be a change from the traditional CAPWAP architecture that may have scalability and security implications - at least this needs to be prompted and discussed. At this point the document does not even mention that it updates RFC 5415 and RFC 5416.

-          What is the advantage of tunneling non-management data frames using the new encapsulation modes vs. bridging them using the local bridging mode in RFC 5416? The document needs to explain this.

-          Why does the document take the approach of defining a new alternate tunnel encapsulation message? Would it not be possible to define new values in the Tunnel Mode enumeration defined in Section 6.1 of RFC 5416?

Thanks and Regards,

Dan


From: opsawg-bounces@ietf.org [mailto:opsawg-bounces@ietf.org] On Behalf Of Rajesh Pazhyannur (rpazhyan)
Sent: Sunday, October 27, 2013 2:08 AM
To: opsawg@ietf.org
Subject: [OPSAWG] Seeking discussion on "Alternate Tunnel Encapsulation for Data Frames in CAPWAP"

Hello

We have resubmitted a new version of the draft titled "Alternate Tunnel Encapsulation for Data Frames in CAPWAP", http://datatracker.ietf.org/doc/draft-zhang-opsawg-capwap-cds/.
The previous version was titled: "Separation of CAPWAP Control and Data Plane: Scenarios, Requirements and Solutions". Based on discussion in the last IETF, we reworked the draft.

The draft provides a reason for the need for WTP to have additional tunnel (beyond CAPWAP) encapsulations for user traffic. It enables a WTP to advertise the capability to support such alternate tunnel encapsulation and the AC to configure such tunnel encapsulation on the WTP.  The alternate tunnel encapsulation allows 1) the WTP to tunnel non-management data frames to an endpoint different from the AC and 2) allows the WTP to tunnel using one of many known ecapsulation types such as IP-IP, IP-GRE, CAPWAP.

We would like to get it adopted as a working group item and would like feedback on whether we are on track.

Regards

Rajesh

v2.23.0 | Report a Bug | By Email