| Re: FW: Some Thoughts on WTP versus Centralized Encryption | <– Date –> <– Thread –> |
|
From: Pat Calhoun (pacalhou) (pcalhoun |
|
| Date: Fri, 6 Apr 2007 08:44:24 -0700 (PDT) | |
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: Dorothy.Gellert [at] nokia.com [mailto:Dorothy.Gellert [at] nokia.com] Sent: Thursday, April 05, 2007 9:59 PM To: capwap [at] frascone.com Cc: margaret [at] thingmagic.com; dave [at] frascone.com Subject: [Capwap] FW: Some Thoughts on WTP versus Centralized Encryption Posting this on behalf of Bernard as it seems to have bounced off the WG list.. -Dorothy -----Original Message----- From: ext Bernard Aboba [mailto:bernard_aboba [at] hotmail.com] Sent: Thursday, April 05, 2007 4:10 PM To: capwap [at] frascone.com 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
-
FW: Some Thoughts on WTP versus Centralized Encryption Dorothy.Gellert, April 5 2007
- Re: FW: Some Thoughts on WTP versus Centralized Encryption Pat Calhoun (pacalhou), April 6 2007
- Re: FW: Some Thoughts on WTP versus Centralized Encryption Sudhanshu, April 6 2007
Results generated by Tiger Technologies using MHonArc.