Subject: RE: Milestone dates was: RE: [Capwap] a necessary and sufficient capwap base protocol

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Mon, 27 Mar 2006 20:29:58 -0800

Dorothy, you state " meet the market's expectations". Do we have anyway
to quantify that statement?

Pat Calhoun
CTO, Wireless Networking Business Unit
Cisco Systems

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> Sent: Monday, March 27, 2006 3:39 PM
> To: Pat Calhoun (pacalhou); [email-masked]; 
> [email-masked]
> Subject: Milestone dates was: RE: [Capwap] a necessary and 
> sufficient capwap base protocol
> 
> Mani and I did have a chance to talk to the ADs briefly last 
> week about the milestone dates.  Their concerns are based on 
> meeting the market need for CAPWAP before it becomes obsolete.  
> 
> Can we have the WG weigh in on the mailing list as to how 
> urgent the need is to release the CAPWAP protocol to meet the market's
> expectations?   
> 
> Thanks,
> Dorothy 
> 
> 
> -----Original Message-----
> From: ext Pat Calhoun (pacalhou) [mailto:[email-masked]]
> Sent: Monday, March 27, 2006 2:03 PM
> To: Scott G Kelly; capwap
> Subject: RE: [Capwap] a necessary and sufficient capwap base protocol
> 
> I believe that rushing to provide a sub-optimal protocol is 
> not in the best interest of the Internet community. In fact, 
> I've been thinking about the comment made at the IETF about 
> perhaps not waiting for 802.11n, and get CAPWAP out the door. 
> My recollection of the reasoning was that we needed to 
> address market need while it still existed.
> However, I would claim that if we don't have a solution that 
> supports 802.11n, then all vendors will still end up with 
> proprietary solutions by the time the CAPWAP standard is 
> ready - as 802.11n will be mandatory for our customers. So if 
> interoperability is the key goal for CAPWAP, then I propose 
> we do it right.
> 
> More on Scott's proposals...
> 
> > - NAT traversal (IPsec working group did this as an add-on, 
> and since 
> > not all vendors care about this, it makes sense to consider that 
> > approach here)
> 
> Plenty of protocols are NAT-able, and my belief is that we 
> are chasing a problem that doesn't need to be. The protocol, 
> as it stands, already is NAT'ed in various customer deployments.
> 
> > 
> > - AC/WTP load balancing; different vendors have different 
> approaches, 
> > and it's not clear that we should be forcing one vendor's view on 
> > everyone else.
> 
> Going back to my comment above, it's all about 
> interoperability. If we can to design a protocol that scales, 
> then this feature is required.
> 
> > - split tunneling, where data channel terminates on a different 
> > endpoint than the control channel; this has definite security 
> > implications, and probably requires a secure inter-AC protocol, in 
> > addition to its own state machine loop(s). It's a corner case that 
> > many won't care about.
> 
> Same as previous comment. This is mandatory for large scale 
> deployments and the protocol supports it already.
> 
> Pat Calhoun
> CTO, Wireless Networking Business Unit
> Cisco Systems
> _________________________________________________________________
> To unsubscribe or modify your subscription options, please visit:
> http://lists.frascone.com/mailman/listinfo/capwap
> 
> Archives: http://lists.frascone.com/pipermail/capwap
> 
_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/capwap

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