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

From: "Scott G. Kelly" <[email-masked]>
Date: Mon, 27 Mar 2006 14:59:22 -0800 (GMT-08:00)

Comments inline below...

-----Original Message-----
>From: "Pat Calhoun (pacalhou)" <[email-masked]>
>Sent: Mar 27, 2006 2:02 PM
>To: Scott G Kelly <[email-masked]>, capwap <[email-masked]>
>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. 

I don't think anyone suggested rushing to provide a sub-optimal protocol, but I think all vendors save the incumbent have a strong interest in getting something interoperable out there expeditiously. Delaying deployment of useful and interoperable implementations in the interest of designing a massive everything-plus-the-kitchen-sink monolith does nothing to benefit 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.

With a well-designed (read: extensible) base protocol, why can't 11n functionality be modularly added? Why must it be in the base spec?

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

Historically, new _tunneling_ protocols are not NAT-able until either the protocols are somehow extended or the market reaches a critical mass, and middlebox vendors are forced by their customers to accommodate the protocols.

LWAPP, as it stands, already runs over one port with a MUX header. This, in conjunction with the built-in heartbeat (echo request/reply), suggests that it should work as-is in some simple NAT scenarios. However, the IPsec group dedicated 2 RFCs to this problem, suggesting that it is not really all that simple. Still, if you could share the details of the scenarios in which it *is* currently working, that might help to clarify how much remains to be done. If we are willing to stick with one channel and a mux header, maybe we can deal with simple nat-t in the base spec, and worry about more complex scenarios in follow-on work.

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

I don't disagree that we can design such a protocol, given enough time, but load balancing is a complex topic, and getting everyone to agree on the details may take significant discussion. The point wasn't that load balancing is not a worthy objective, the point was that there are short-term ways to resolve it without complicating the base protocol. 

For example, I would argue that the controller, not the wtp, should make such decisions, and it could do so by simply not responding to a discover request (or the JOIN which follows, if you prefer) when it is too busy to be bothered. After all, it is the _controller_, is it not? This does not require any special protocol elements, and is arguably sufficient for a base protocol. More complex approaches can be layered on top of this, and need not delay advancement of the base protocol.

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

By what rationale is this mandatory? In any event,  this implies a (secure) inter-AC protocol, which is not currently in scope, and is not currently specified. If this functionality is truly mandatory, we need to expand our wg charter to include secure inter-AC communications.

Scott

_________________________________________________________________
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: Tue, 28 Mar 2006 07:09:06 -0800

> With a well-designed (read: extensible) base protocol, why 
> can't 11n functionality be modularly added? Why must it be in 
> the base spec?

The 802.11n spec is in letter ballot, and some early products are coming
out
next year. This is not the moving target that folks seem to think it is.
There is
significant pressure to get the spec out on time. If we were to push
CAPWAP out
without support for 802.11n, we will end up with a proposal that doesn't
match the
realities of 802.11, and therefore will have limited applicability.

Dorothy stated that we need to have a spec that is shipped in time to
match market
need, but I would counter this by stating that the spec must be capable
of matching
market feature needs as well.

> Historically, new _tunneling_ protocols are not NAT-able 
> until either the protocols are somehow extended or the market 
> reaches a critical mass, and middlebox vendors are forced by 
> their customers to accommodate the protocols.

Umm... L2TP was absolutely NAT-able from day one without any ALGs
required
on the NAT device. LWAPP used many of the concepts from this protocol in
its early designs.

> 
> LWAPP, as it stands, already runs over one port with a MUX 
> header. This, in conjunction with the built-in heartbeat 
> (echo request/reply), suggests that it should work as-is in 
> some simple NAT scenarios. However, the IPsec group dedicated 
> 2 RFCs to this problem, suggesting that it is not really all 
> that simple. Still, if you could share the details of the 
> scenarios in which it *is* currently working, that might help 
> to clarify how much remains to be done. If we are willing to 
> stick with one channel and a mux header, maybe we can deal 
> with simple nat-t in the base spec, and worry about more 
> complex scenarios in follow-on work.

I don't argue that IPSec had multiple specs for this purpose, but again,
L2TP designed their
protocol from the get-go with NAT in mind - and it does work. If we
decide to push this off,
then we will end up with the multiple specs defining possible changes to
the base spec to
support NAT environments.

NAT was a recommendation by the eval team that I agree we need to
pursue.

> For example, I would argue that the controller, not the wtp, 
> should make such decisions, and it could do so by simply not 
> responding to a discover request (or the JOIN which follows, 
> if you prefer) when it is too busy to be bothered. After all, 
> it is the _controller_, is it not? This does not require any 
> special protocol elements, and is arguably sufficient for a 
> base protocol. More complex approaches can be layered on top 
> of this, and need not delay advancement of the base protocol.

How does a controller know whether it is any busier than the other
controllers? Seems like you end up in a scenario where a WTP can end
up being stranded. While it is an example, I don't think it's the best
one.

That said, we need to design a protocol that allows systems to scale.
If that means we have to do real engineering work to solve this issue,
then by all means.

> By what rationale is this mandatory? In any event,  this 
> implies a (secure) inter-AC protocol, which is not currently 
> in scope, and is not currently specified. If this 
> functionality is truly mandatory, we need to expand our wg 
> charter to include secure inter-AC communications.

Allows vendors to innovate and provide scalable solutions - has always
been in the LWAPP spec, and I'm not supportive of removing this feature.

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