Subject: Re: [OPSAWG] CAPWAP Control and Data Plane Separation Draft -draft-zhang-opsawg-capwap-cds

From: "Rajesh Pazhyannur (rpazhyan)" <[email-masked]>
Date: Mon, 29 Jul 2013 12:00:42 +0000

Hello Satoru

Thanks for the email. 
Yes, you are right that the AP requires the IP address of the AC-DP (for the separate/new CAPWAP Data-Channel). 
We expect this IP address to be  provided by the AC-CP using an existing CAPWAP control channel. As you can imagine this would require extensions to CAPWAP (specifically, RFC 5416)

Regards

Rajesh 
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Satoru Matsushima
Sent: Sunday, July 28, 2013 9:41 PM
To: Cao,Zhen
Cc: [email-masked]
Subject: Re: [OPSAWG] CAPWAP Control and Data Plane Separation Draft - draft-zhang-opsawg-capwap-cds

Hi Zhen,

That's sound interesting draft. Just one clarification about AP configuration.
It looks that AP is required an IP address information which is configured to identify separated CAPWAP-DATA. Otherwise AP send both of channel packet to single IP address, make sense?

cheers,
--satoru

On 2013/07/19, at 5:36, "Cao,Zhen" <[email-masked]> wrote:

> Hello Everyone,
> 
> The draft-zhang-opsawg-capwap-cds-00.txt is an update/subvert of
> draft-zhang-opsawg-capwap-eap-00 (which we presented on Orlando) with 
> a new title and a new methodology, based on review of multiple experts 
> recommended by OPS ADs.
> 
> Here is a highlight of the update in this version:
> 
> The current draft proposes to split data and control plane by having 
> two elements AC-CP and AC-DP. AC-DP handles all user payload with the 
> exception of layer 2 management frames between the AC and use such as 
> IEEE 802.11 association, authentication, probe, Action Frame. AC-CP 
> handles all control messages between the WTP and AC.  In addition, the 
> AC-CP will handle user payload related to layer-2 management frames 
> such as those mentioned above. The WTP will have one set of Control 
> and Data Tunnel to AC-CP and another data-tunnel to AC-DP.
> 
> The key difference from  the previous version is that the previous 
> draft suggested
> 1) AC-CP has a control and data channel (instead of only a control 
> channel in current draft)
> 2) EAP messages were sent on Control Channel (instead of Data channel 
> in current draft)
> 
> We also do an analyze of CAPWAP local bridge model to support such 
> scenarios, as recommended by Dorothy.
> 
> Thank ALL that reviewed the draft and looking forward to your new comments.
> 
> Best regards,
> -cz
> 
> On Mon, Jul 15, 2013 at 11:02 PM, Cao,Zhen <[email-masked]> wrote:
>> FYI.
>> 
>> 
>> ---------- Forwarded message ----------
>> From:  <[email-masked]>
>> Date: Sun, Jul 14, 2013 at 8:50 PM
>> Subject: I-D Action: draft-zhang-opsawg-capwap-cds-00.txt
>> To: [email-masked]
>> 
>> 
>> 
>> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>> 
>> 
>>        Title           : Separation of CAPWAP Control and Data Plane:
>> Scenarios, Requirements and Solutions
>>        Author(s)       : Rong Zhang
>>                          Zhen Cao
>>                          Hui Deng
>>                          Rajesh S. Pazhyannur
>>                          Sri Gundavelli
>>        Filename        : draft-zhang-opsawg-capwap-cds-00.txt
>>        Pages           : 8
>>        Date            : 2013-07-14
>> 
>> Abstract:
>>   This document describes the scenarios and requirements of separating
>>   CAPWAP Data and Control plane.  This specification provides a CAPWAP
>>   extension to allow two distinct AC component: AC-DP (AC-Data Plane)
>>   and AC-CP (AC-Control Plane).  AC-DP handles all user payload with
>>   the exception of layer 2 management frames between the AC and user
>>   such as IEEE 802.11 association, authentication, probe, Action Frame.
>>   AC-CP handles all control messages between the WTP and AC.  In
>>   addition, the AC-CP wil handle user payload related to layer-2
>>   management frames such as those mentioned above.
>> 
>> 
>> The IETF datatracker status page for this draft is:
>> https://datatracker.ietf.org/doc/draft-zhang-opsawg-capwap-cds
>> 
>> There's also a htmlized version available at:
>> http://tools.ietf.org/html/draft-zhang-opsawg-capwap-cds-00
>> 
>> 
>> Internet-Drafts are also available by anonymous FTP at:
>> ftp://ftp.ietf.org/internet-drafts/
>> 
>> _______________________________________________
>> I-D-Announce mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/i-d-announce
>> Internet-Draft directories: http://www.ietf.org/shadow.html or 
>> ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> _______________________________________________
> OPSAWG mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/opsawg

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

---

From: "Cao,Zhen" <[email-masked]>
Date: Mon, 29 Jul 2013 15:06:29 +0200

For the local bridge approach, there is no need of this configuration.

For the two data tunnels approach, IP address would be informed to the
WTP, CAPWAP extension is one approach, but it is also possible to do
that via the existing discovery process in CAPWAP.

---

From: Satoru Matsushima <[email-masked]>
Date: Mon, 29 Jul 2013 15:45:02 +0200

> that via the existing discovery process in CAPWAP.

But existing WTP assumes that the indicated IP address is AC which is not c-d separated, right?
It would be nice to see some text in the draft for those should be clarified.

cheers,
--satoru

---

From: "Cao,Zhen" <[email-masked]>
Date: Mon, 29 Jul 2013 17:22:26 +0200

> But existing WTP assumes that the indicated IP address is AC which is not c-d > separated, right?

At least not specified in the RFC 5416.

> It would be nice to see some text in the draft for those should be clarified.

We will add that.

Thanks,
-z