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

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Mon, 27 Mar 2006 14:02:45 -0800

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

---

From: "Dorothy Stanley" <[email-masked]>
Date: Mon, 27 Mar 2006 14:46:31 -0800

Looking just at the a/b/g vs a/b/g/n question:
We know the a/b/g impacts on the CAPWAP protocol now. The unknown is when
will we know the .11n
impacts. July06? Jan 07? Sept 07 (.11n ratification)?  If .11n impacts are
not known until Sept 07, I
would definitiely support getting a "sub-optimal" protocol out, as we would
learn alot from the
intial deployments and implementation, and subsequent CAPWAP  .11n protocol
work could track the .11n ratification work.

One way to get resolution on the a/b/g vs a/b/g/n support question is to
answer the following questions
- What is the scope of changes to the CAPWAP protocol to support  .11n. Is
it just a few radio type changes?
Fundamental control protocol changes?
- When could we have changes needed for .11n integrated into the CAPWAP
protocol?
- Agree on a timeframe when it would be in/out. If our goal is completion is
July-September 06, we would need
to have the scope and most changes identified by say end June 06.

Do we need a sub-team/set of volunteers to go and look at this, and report
back? It sounds like we need to do some (home)work to be able to make an
informed
data-driven decision.

Dorothy Stanley

---

From: <[email-masked]>
Date: Mon, 27 Mar 2006 15:38:35 -0800

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

> - 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)

> 
> - 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.

> - 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.

Pat Calhoun