Subject: [Capwap] FW: Some Thoughts on WTP versus Centralized Encryption

From: <[email-masked]>
Date: Thu, 5 Apr 2007 23:58:52 -0500

Posting this on behalf of Bernard as it seems to have bounced off the WG
list..  

-Dorothy 

-----Original Message-----
From: ext Bernard Aboba [mailto:[email-masked]] 
Sent: Thursday, April 05, 2007 4:10 PM
To: [email-masked]
Cc: Gellert Dorothy (Nokia-SIR/MtView)
Subject: Some Thoughts on WTP versus Centralized Encryption

At IETF 68, Dorothy asked me to look at this issue and post some
thoughts.

One way to think about this issue is from the point of view of an IT
administrator who is considering the deployment of WTPs within the
enterprise.

One of the potential benefits of CAPWAP in such a situation is to
potentially provide the ability to replace the initially chosen
controller with a controller from another vendor at a future date,
without having to touch the WTPs.  Since much of the installation cost
involves the installation of the WTPs as opposed to the controller,
controller replacements are much simpler and less expensive than WTP
rollouts.

In such a situation, it is in the interest of the IT administrator to
maintain the greatest flexibility with respect to the choice of
controllers. 
   If the WTPs only support one particular mode (WTP encryption versus
central encryption), then the administrator will only be able to choose
a controller supporting the particular mode handled by the WTPs that
have been installed.

As a result, I believe it is quite important from the IT administrator
perspective that the WTPs support multiple modes, but it is less
important that controllers support multiple modes.

In making a decision on the modes to be supported, the CAPWAP WG needs
to think through the requirements for the WTPs and the controllers
separately.  
While it might be ok to only mandate that controllers support WTP
encryption, requiring that WTPs support one mode will remove much of the
value that CAPWAP was supposed to provide to IT administrators.

_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/capwap

Archives: http://lists.frascone.com/pipermail/capwap

---

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Fri, 6 Apr 2007 08:44:15 -0700

Sorry, I do not follow the logic.

Let me use an analogy. I want to replace my car, and I believe that air
bags are necessary. As I buyer, should I simply purchase any car and
assume air bags are included because my old one had it? I don't think
so.

Protocols in the IETF are riddled with MAYs, SHOULDs and MUSTs. This was
put in place to guarantee that vendors can interoperate with a certain
level of baseline features, yet provides flexibility for vendors to
innovate outside of the core features. Routing protocols have plenty of
optional features - and customers seem ok with that. Has anyone claimed
that all optional features in routing protocols must be MUSTs in order
to ensure that all vendors shipping boxes have the exact same feature
set? Absolutely not.

Here we have a scenario where the default behavior is Local MAC w/ no
tunneling. This behavior requires that the WTPs encrypt/decrypt the
data, which is necessary since packets are not tunneled back to the
controller. I would claim that a customer that makes a blind purchasing
decision is going to be much more surprised when he turns on a
controller that only supports Local MAC than the location of encryption
in Split MAC. So buyers need to be smart.

It is, btw, also the reason why the currently proposed text for issue
138 makes sense. Since Local MAC is the default, and it MUST support
local encryption in the WTP, then using this same scheme in Split MAC
simply makes sense. Not only does it guarantee compatibility with all
802.11 chipsets in the market, it guarantees support for any past and
future 802.11 extension.

Bernard's comment is interesting, but needs to be taken into context.
Some vendors ship Local MAC, some Split MAC and some have both. To pick
one specific segment of customers and say they are more important, and
therefore that deployment scenario is a MUST vs others cannot be done.
We need to create a protocol that provides value and ensures
interoperability. I believe we have done this.

I support the current proposed text for issue 138.

PatC

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Thursday, April 05, 2007 9:59 PM
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: [Capwap] FW: Some Thoughts on WTP versus Centralized Encryption

-Dorothy

---

From: "Sudhanshu" <[email-masked]>
Date: Fri, 6 Apr 2007 10:53:41 -0700

I think it is an interesting observation and should be considered to address
issues #138.

The whole paradigm of centralized WLAN is related to ease of deployment and
management. And we should not forget that CAPWAP WG is charted under O&M,
although we are trying to develop control plane and data plane besides
operation and management under single spec.

_Suds

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Thursday, April 05, 2007 9:59 PM
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: [Capwap] FW: Some Thoughts on WTP versus Centralized Encryption

-Dorothy