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

From: "Rajesh Pazhyannur (rpazhyan)" <[email-masked]>
Date: Tue, 18 Feb 2014 22:10:10 +0000

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

---

From: Melinda Shore <[email-masked]>
Date: Tue, 18 Feb 2014 16:00:00 -0900

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) <[email-masked]>
To: 	[email-masked] <[email-masked]>

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

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

---

From: "Fan, Peng" <[email-masked]>
Date: Fri, 21 Feb 2014 19:17:13 +0800

Hi Melinda,

This document and the other capwap drafts in opsawg serve different
purposes: new Model, new air-interface support and new control function
support. After reading it I believe this document has evolved into a stable
version with a straightforward solution, and is ready for adoption.

Regards,
Peng

> -----Original Message-----
> From: OPSAWG [mailto:[email-masked]] On Behalf Of Melinda Shore
> Sent: Wednesday, February 19, 2014 9:00 AM
> To: [email-masked]
> 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
> 
> 
> 
Data
> Frames in
attempted to
> address them in this draft. Specifically,
> 
feedback
> on whether we are on track.
> 
> 
> thanks
> 
> Regards
> 
> Rajesh
> 
>

---

From: Liu Dapeng <[email-masked]>
Date: Mon, 24 Feb 2014 10:28:00 +0800

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 <[email-masked]>:

> _______________________________________________
> OPSAWG mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/opsawg
>
>

-- 

------
Best Regards,
Dapeng Liu

---

From: Sheng Jiang <[email-masked]>
Date: Mon, 24 Feb 2014 06:41:37 +0000

+1, support adoption.

Sheng

From: OPSAWG [mailto:[email-masked]] On Behalf Of Liu Dapeng
Sent: Monday, February 24, 2014 10:28 AM
To: Melinda Shore
Cc: [email-masked]
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 <[email-masked]<mailto:[email-masked]>>:

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) <[email-masked]<mailto:[email-masked]>>
To:     [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>

Hello

Abstract

thanks

Regards

Rajesh

_______________________________________________
OPSAWG mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/opsawg

--

------
Best Regards,
Dapeng Liu

---

From: Melinda Shore <[email-masked]>
Date: Sun, 23 Feb 2014 21:43:41 -0900

We have not yet put out a call for adoption.  At this point we're
trying to get a handle on relevance and quality.  To that end,
discussion is very useful, statements of support less so.

Melinda

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Mon, 24 Feb 2014 09:02:55 +0000

Hi,

I understand the need and I support discussing this work in OPSAWG. 

This being said - the change proposed by this document looks like a significant addition to the CAPWAP architecture. I personally need to do more reading to understand how it fits into the current architecture, how it impacts existing WTPs and ARs, and whether there is a need for a migration or coexistence plans in existing deployments of CAPWAP (if such deployments exist). Function of the responses this may or may not represent more the usual 'incremental development' we do in OPSAWG. I would like to hear also the opinions of IEEE 802.11 experts and of folks who were involved in the original CAPWAP work ( I copied Dorothy and Mani, there are more)

Thanks and Regards,

Dan

> Sent: Monday, February 24, 2014 8:44 AM
> To: [email-masked]
> We have not yet put out a call for adoption.  At this point we're trying to get a
> handle on relevance and quality.  To that end, discussion is very useful,
> statements of support less so.
> 
> Melinda
>

---

From: John Kaippallimalil <[email-masked]>
Date: Tue, 25 Feb 2014 00:13:17 +0000

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 

> Sent: Tuesday, February 18, 2014 7:00 PM
> To: [email-masked]
> 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
> 
> 
> 
> Data Frames in CAPWAP,_http://datatracker.ietf.org/doc/draft-zhang-
> opsawg-capwap-cds/_.
> 
> Abstract
>