Re: [OPSAWG] Fwd: Alternate Tunnel Encapsulation for Data Frames in CAPWAP

[John Kaippallimalil <[e-mail]>]

Hi,
The problem this draft solves is described clearly, and I think that it fills a gap in the existing stds.

My questions on the previous version of the draft wrt tunnel failure, access router address, etc are all clarified here. 
I like the approach in 2.2 and 2.3 with respect to specifying the tunnel type/specification since it is simple enough and while providing sufficient flexibility.

Section 2.1 - the figure and text help, but it would be good as the draft progresses to have a bit more of detail/clarity in the description. 

Best Regards,
John 



> -----Original Message-----
> From: OPSAWG [mailto:[e-mail]] On Behalf Of Melinda
> Shore
> Sent: Tuesday, February 18, 2014 7:00 PM
> To: [e-mail]
> Subject: [OPSAWG] Fwd: Alternate Tunnel Encapsulation for Data Frames
> in CAPWAP
> 
> 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) <[e-mail]>
> To: 	[e-mail] <[e-mail]>
> 
> 
> 
> 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
> 
>