Subject: RE: [Capwap] A simpler approach to CAPWAP

From: "Yang, Lily L" <[email-masked]>
Date: Wed, 9 Mar 2005 10:32:10 -0800

Partha -

Interoperability provides two aspects of benefits in my mind:
Interoperability provides better choice for the customers because now
they can choose different vendors for AC and WTP; interoperability also
provides lower development cost for vendors because now they don't have
to work with each individual vendor of the other end to make it work.
While the former is the most visible benefit for the end users, the
latter also offer economic incentives to the vendors that should not be
overlooked. 

While the simper approach you suggested can still provide the former, it
does not at all address the latter, so I am hesitant to agree with your
statement that "the interoperability achievable by the secure download
approach is no worse than what is possible with a full-blown control
protocol."

Lily

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Partha Narasimhan
Sent: Wednesday, March 09, 2005 8:59 AM
To: [email-masked]
Subject: [Capwap] A simpler approach to CAPWAP

The primary reason for the existence of the CAPWAP group is to solve
an interoperability problem between ACs and WTPs from different
vendors so that an end-user/customer has the choice of purchasing WTPs
and ACs from different vendors. The existing marketplace is full of
single-vendor solutions. To that extent, if an end-user is able to
purchase a WTP from a vendor that is different than the vendor
supplying the AC, but get them to interoperate with each other to
create a functioning WLAN, then the end-user's objective is largely
accomplished.

Based on existing single-vendor WLAN solutions, it is obvious that the
AC is where most of the control and management intelligence
resides. It is not far from the truth to state the AC determines what
functions are turned on at the WTPs and, hence, what features are
available in the WLAN. Arguably, the interoperability problem can be
restated as a customer's need to find WTPs that interoperate with
his/her choice of AC. Or at a minimum, the WTPs need to follow and
interoperate with the AC rather than the other way around. 

Interoperability can be achieved at multiple levels. In most of the
current discussion on the CAPWAP mailing list, the primary assumption
seems to be that interoperability requirement seems to be between the
individual software that both the WTP and the AC ship with and/or boot
up with. Once both the devices are up and running with their images,
the WTPs discover one or more ACs and, assuming everything is set up
right, one of the discovered ACs will configure and bring up the WTP
as part of the customer's WLAN using a protocol that will be defined
as part of the CAPWAP WG's work.

Interoperability can also be achieved using a simpler mechanism where
a WTP boots up, discovers one or more ACs to create an association
with. As part of the discovery process, the WTP identifies itself
(vendor ID, hardware version, software version, etc.). One of the
discovered ACs can then instruct the WTP to download a firmware image
that the WTP should boot itself with at the end of the download
process. Upon booting itself with this downloaded image, the WTP runs
a protocol, quite possibly proprietary to the AC vendor, contained in
the downloaded image to create an association with an AC and get
configured to be a member of the WLAN. An AC from one vendor might
download an image to a WTP that is completely different than an AC
from another vendor. This does solve the end-user's requirement of
getting interoperability between WTPs and ACs from different
vendors. The control protocol used to get the WTP to become a member
of the WLAN controlled and managed by the AC is totally upto the AC
vendor's choice.

Essentially, the solution becomes a simple protocol for the WTP to
discover one or more ACs, identify itself to the ACs, and download an
image from the AC, if possible, that it will boot itself with - a
secure download problem rather than a WLAN configuration problem from
an interoperability perspective. This solves the CAPWAP problem of
interoperability without requiring a full-fledged, new control
protocol that all the WTP and AC vendors have to implement for
interoperability. It is sufficient to implement the simpler secure
download protocol to get to interoperability. This removes the
necessity to negotiate capabilities (split MAC vs local MAC, one
person's split may not suit another but we cannot have infinite
permutations of a split, etc.) since the WTP assumes capabilities that
are contained in the image that the AC vendor chooses to build for
it. Another benefit of this approach is the extensibility of this
simpler approach to future wireless technologies or extensions to
existing technologies since these are folded into the downloaded image
and hence are transparent to the secure download protocol itself.

What are the issues with such a secure download protocol? This
requires an AC to have a bootable image for every single WTP that the
AC wants to interoperate with. Which could be a matter of
differentiation for the AC vendors. If one vendor supports 2 models of
WTPs, while another one decides to support 10, then the marketplace
could choose if they like the feature set of the former enough that
they dont mind the reduced set of interoperable WTPs or whether they
like the greater interoperability of the latter AC. Secondly, we need
a mechanism for the WTP and the AC, soon after the discovery process,
to create a trust relationship between each other so that the WTP is
sure it is not downloading code from a malicious entity masquerading
as an AC and the AC is sure it is not supplying code to an entity
masquerading as a WTP. 

The secure download approach shifts the burden of interoperability to
the AC vendors and lowers the barrier for the WTP vendors that strive
for interoperability. This shift is fine since the AC is the center of
control and management for a WLAN and it is in the AC vendor's
interests to get to wider interoperability, if they so chose to
do. This is also aligned with the current market reality where the AC
vendors' capabilities determine what features are available on the
WLAN. The WTP vendors are required to implement a simpler protocol to
get to interoperability with multiple AC vendors. The level of
interoperability is always determined by individual choices by the
vendors. For example, an AC that only supports split MAC may not
interoperate with a WTP that only suppports the local MAC. Arguably,
the interoperability achievable by the secure download approach is no
worse than what is possible with a full-blown control protocol. Not to
mention the simplicity of the protocol that the CAPWAP WG needs to
work on.

We intend to submit a proposal along these lines to the CAPWAP WG. It
will involve a simple process as follows:
- a WTP discovers one or more ACs,
- the WTP identifies itself to the ACs that it discovered,
- the WTP and one of the ACs create a mutual trust relationship, and
- the WTP downloading an image from an AC.
The details will be present in the draft that will follow soon.

This approach is quite different from what has been discussed in the
WG so far. It probably also has implications on the objectives
draft. I would like to initiate some discussion on whether all the
mandatory objectives as stated in the current objectives draft are
still valid. I understand that the objectives were stated with a
full-fledged, open and/or externally verifiable protocol in mind. If a
certain set of objectives precludes such a simpler solution then we
may need to re-visit and discuss that set of objectives. In other
words, if a set of objectives as they currently stand are unnecessary
for solving the problem that we started out to address, then we should
discuss these now.

Thanks
partha
_______________________________________________
Capwap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/capwap
_______________________________________________
Capwap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/capwap

---

From: "Partha Narasimhan" <[email-masked]>
Date: Wed, 9 Mar 2005 11:02:15 -0800

Lily,

Interoperability does not come for free. At a minimum, each vendor needs to make a choice whether they want to make their boxes interoperate with other vendors' boxes. It is not sufficient to define a control protocol and expect interoperability if the individual vendors choose not to implement the protocol at their end. This will be important especially in the case where the WTP vendors do not want to be burdened with the implementation of a complex protocol in order to claim interoperability. 

If none of the WTP vendors choose to implement this control protocol because it is seen as too much work (not to mention participation in interoperability plugfests and certification programs), then the CAPWAP group would have failed and we would have no interoperability. This approach moves the burden of interopreability to one side (the AC vendors) and requires the WTP vendors to implement a much simpler protocol.

Thanks
partha

-----Original Message-----
From:	Yang, Lily L [mailto:[email-masked]]
Sent:	Wed 3/9/2005 10:32 AM
To:	Partha Narasimhan; [email-masked]
Cc:	
Subject:	RE: [Capwap] A simpler approach to CAPWAP
Partha -

Lily

-----Original Message-----

Thanks
partha

---

From: "Partha Narasimhan" <[email-masked]>
Date: Wed, 9 Mar 2005 11:06:18 -0800

Just to clarify....

This moves the onus of interoperability onto the AC vendors. They make images for a set of WTPs that they want to interoperate with. The WTP vendors just have to implement a protocol where they discover ACs, identify themselves, and have the ability to download an image and boot themselves with it. The original image on WTP could do other things (the WTP vendor's choice) with their installed images in an environment where they are unable to discover an AC. 

We are not calling for specifying how a WTP is built or with what components. Once it is built, every AC vendor that wants that particular model of WTP to work with needs to work with that WTP vendor and create their own version of a downloadable image for that board. 

Thanks
partha

-----Original Message-----
From:	Michael Vakulenko [mailto:[email-masked]]
Sent:	Wed 3/9/2005 10:45 AM
To:	Partha Narasimhan
Cc:	[email-masked]
Subject:	Re: [Capwap] A simpler approach to CAPWAP
Partha,

I don't see how your suggestion makes things simpler. If CAPWAP would 
follow your approach, this WG had to define standard APIs that needs to be 
supported by all interoperable WTPs. These APIs will have to be quite 
low-level and detailed to provide interface to 802.11 chipset, Ethernet 
driver and operating system of the WTPs.

Moreover, different WTP models may use different processor cores and 
therefore firmware object code cannot be the same for all WTPs. (We are not 
talking about Java here, are we?.. :-) )

The real complexity of what you have proposed is in fact higher than 
traditional approach to protocol design, if you consider practicalities of 
achieving interoperability, stability and predictable performance for 
downloadable firmware.

-- Michael V.
    http://www.WaveCompass.com

>for solving the problem that we started out to address, then we should

-- Michael Vakulenko
         Phone:  +972-54-776-2269

---

From: "Paul Lambert" <[email-masked]>
Date: Wed, 9 Mar 2005 13:17:15 -0800

> From: Partha Narasimhan [mailto:[email-masked]] 

> 
> To add to Dan's comments, if we look at the landscape of AC 
> vendors today, there is a non-trivial amount of feature 
> differentiation that is offered by them. To imagine that a 
> CAPWAP proposal could create hooks to turn on or off a union 
> of this feature set is unthinkable. Unless we are willing to 
> spend lots and lots of time on it, we are limited to 
> specifying a CAPWAP feature set that would look more like the 
> intersection of the individual feature sets offered by all 
> the AC vendors today - essentially, the bare minimum. If the 
> marketplace requires more than that bare minimum, it is 
> forced to go with a single-vendor solution. 

No!  The minimum set can provide basic interoperability. Additional
features  are readily provided by extensions in protocol signaling.
Worked examples include SNMP and IEEE 802.11 (the IEs).

Paul

---

From: "Paul Lambert" <[email-masked]>
Date: Wed, 9 Mar 2005 13:33:43 -0800

> From: Dan Harkins [mailto:[email-masked]] 
> Sent: Wednesday, March 09, 2005 1:15 PM
> To: Paul Lambert
> Cc: Michael Vakulenko; [email-masked]; Partha Narasimhan
> On Wed, 09 Mar 2005 11:54:21 PST you wrote
> > 
> > So, we already have this 'Hundred Flower Blooming' market.  Every 
> > vendor has their own set of protocols.  I can already sell hardware 
> > with different firmware images to various AC vendors.
> 
>   But then you support different firmware images for 
> different venders.
> What a pain. Why not just support one that speaks a standard 
> discovery-and-download protocol? 

But you would still need differnet firmware for each different
AC vendor.  There is no diffierence except a slightly different 
boot sequence.

>   Now we're talking! I haven't seen this kind of attitude 
> since the OTP working group! The alternative is yet another 
> indefinite working group that sews new limbs on the 
> frankenstein monster as new options and new technologies emerge.

Thanks :-)  It was supposed to be sarcasm...  I see having only this
download/bootstrap process as equivalent to throwing away the CAPWAP
requirements.

On a positive note, having a simple secure bootstrapping protocol would
be great for this type of product market.  It would be a useful result
for the committee; it just would not provide an open playing field that
a true set of open signaling would create.  

Discovery and bootstrapping the firmware is at least an interesting
stating point.  I'd hope that the same process could also provide some
manner of control signaling.

And yes, the current requirements of the working group could become a
multi-armed monster protocol.  

Paul

---

From: "Victor Lin" <[email-masked]>
Date: Wed, 9 Mar 2005 15:37:06 -0800

I agree with James. I think standard protocol enables different venders
focus on different technologies. In CAPWAP case, AC venders can focus
more on networking (security, mobility, management, etc.) while WTP
venders can try to bring up the latest communication and other
technologies (MIMO, special antenna, different form factor, etc.). This
will give user more flexibility on picking the right products for their
network. Of course, venders will put out "standard with vender
enhancement" products which enable special features if you buy AC and
WTP from the same vender. At the end, the market will decide which one
wins.

Victor

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of James Kempf
Sent: Wednesday, March 09, 2005 2:49 PM
To: Partha Narasimhan; Michael Vakulenko
Cc: Dan Harkins; Paul Lambert; [email-masked]
Subject: Re: [Capwap] A simpler approach to CAPWAP

> These are all very valid comments. It's indeed going to be very
difficult
> to design a protocol allowing vendor differentiation. IMHO,
non-commodity
> ACs will have to go with single vendor approach in any case.
>

I don't know that this is the case. In the UMTS world where the RAN
protocols are standardized, the RAN vendors differentiate themselves
based
on their network managment systems. Many operators buy single vendor in
order to get a particular set of network management features. Others
(typically the more technically savvy) buy multivendor and roll their
own
network management software. If the protocol is standarized, the vendors
will find other areas to distinguish their products.

            jak

---

From: "Sadot, Emek (Emek)" <[email-masked]>
Date: Fri, 11 Mar 2005 11:32:00 -0500

Jak,

I do not argue the completion of the CAPWAP group upon satisfying the
charter, the point I was trying to make relates to the fact that
Partha's proposal may obsolete the need for re-chartering or make any
enhancement to the protocol/arch moving forward.

Regards,
Emek

-----Original Message-----
From: James Kempf [mailto:[email-masked]] 
Sent: Wednesday, March 09, 2005 5:21 PM
To: Sadot, Emek (Emek); Dan Harkins; Michael Vakulenko
Cc: Partha Narasimhan; [email-masked]
Subject: Re: [Capwap] A simpler approach to CAPWAP 

Whether or not we standardize a WTP control protocol or a code
downloading protocol has nothing to do with whether CAPWAP is an ongoing
process. When the CAPWAP charter is complete, the group can disband
(this is what we did with SEND). Or not (other WGs like DNSEXT do this).
It depends on what the WG members want to do and whether the IESG
agrees.

            jak

----- Original Message -----
From: "Sadot, Emek (Emek)" <[email-masked]>
To: "Dan Harkins" <[email-masked]>; "Michael Vakulenko"
<[email-masked]>
Cc: "Partha Narasimhan" <[email-masked]>;
<[email-masked]>
Sent: Wednesday, March 09, 2005 2:09 PM
Subject: RE: [Capwap] A simpler approach to CAPWAP

Partha's proposal introduces a great advantage related to future
enhancement either within the 802.11 realm or associated to other
technologies (e.g. 802.16). Bear in mind that defining a signaling
protocol with particular embedded identifiers/object will required
extensive extensions to maintain interoperability for any new
feature/technology. Although I assume we cherish the CAPWAP group do we
really want it to be an ongoing process?

Emek

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Dan Harkins
Sent: Wednesday, March 09, 2005 2:12 PM
To: Michael Vakulenko
Cc: Partha Narasimhan; [email-masked]
Subject: Re: [Capwap] A simpler approach to CAPWAP

  On the contrary. If the CAPWAP protocol defines a full control plane
and data frame encapsulation it will have to define standard APIs that
need to be supported by all interoperable WTPs. If Partha's approach is
taken then all that is defined is a discovery and download protocol. The
WTC runs the downloaded image and that contains the (not-defined by
CAPWAP) control and data frame protocols.

  No we're not talking about Java.

  The practicalities of achieving interoperability are solely on
implementation of the discovery and download protocol. It is simple and
therefore acheiving interoperability would not be hard. The
practicalities of achieving stability and predictable performance are
borne by the AC vendors who will guarantee that the image they provide
to a WTP is stable and has predictable performance.

  Dan.

On Wed, 09 Mar 2005 20:45:25 +0200 you wrote
> follow your approach, this WG had to define standard APIs that needs
> to be supported by all interoperable WTPs. These APIs will have to be
> quite low-level and detailed to provide interface to 802.11 chipset,
> Ethernet driver and operating system of the WTPs.
>
> therefore firmware object code cannot be the same for all WTPs. (We
> are not talking about Java here, are we?.. :-) )
>
> traditional approach to protocol design, if you consider
> practicalities of achieving interoperability, stability and
> predictable performance for downloadable firmware.
>
> -- Michael V.
> >vendors so that an end-user/customer has the choice of purchasing
> >WTPs and ACs from different vendors. The existing marketplace is full

> >of single-vendor solutions. To that extent, if an end-user is able to

> >Based on existing single-vendor WLAN solutions, it is obvious that
> >the AC is where most of the control and management intelligence

> >individual software that both the WTP and the AC ship with and/or
> >boot up with. Once both the devices are up and running with their
> >images, the WTPs discover one or more ACs and, assuming everything is

> >set up right, one of the discovered ACs will configure and bring up
> >the WTP as part of the customer's WLAN using a protocol that will be
> >defined as part of the CAPWAP WG's work.
> >

> >getting interoperability between WTPs and ACs from different vendors.

> >The control protocol used to get the WTP to become a member of the
> >WLAN controlled and managed by the AC is totally upto the AC vendor's

> >choice.

> >permutations of a split, etc.) since the WTP assumes capabilities
> >that are contained in the image that the AC vendor chooses to build
> >for it. Another benefit of this approach is the extensibility of this

> >existing technologies since these are folded into the downloaded
> >image and hence are transparent to the secure download protocol
itself.

> >differentiation for the AC vendors. If one vendor supports 2 models
> >of WTPs, while another one decides to support 10, then the
> >marketplace could choose if they like the feature set of the former
> >enough that they dont mind the reduced set of interoperable WTPs or
> >whether they like the greater interoperability of the latter AC.
> >Secondly, we need a mechanism for the WTP and the AC, soon after the
> >discovery process, to create a trust relationship between each other
> >so that the WTP is sure it is not downloading code from a malicious
> >entity masquerading as an AC and the AC is sure it is not supplying
> >code to an entity masquerading as a WTP.
> >

> >for interoperability. This shift is fine since the AC is the center
> >of control and management for a WLAN and it is in the AC vendor's
> >interests to get to wider interoperability, if they so chose to do.
> >This is also aligned with the current market reality where the AC

> >worse than what is possible with a full-blown control protocol. Not
> >to mention the simplicity of the protocol that the CAPWAP WG needs to

> >WG so far. It probably also has implications on the objectives draft.

> >I would like to initiate some discussion on whether all the mandatory

> >objectives as stated in the current objectives draft are still valid.

> >I understand that the objectives were stated with a full-fledged,
> >open and/or externally verifiable protocol in mind. If a certain set
> >of objectives precludes such a simpler solution then we may need to
> >re-visit and discuss that set of objectives. In other words, if a set

> >of objectives as they currently stand are unnecessary for solving the

> >problem that we started out to address, then we should discuss these
> >now.
> >
> >Thanks
> >partha

---

From: "Mani, Mahalingam (Mahalingam)" <[email-masked]>
Date: Fri, 11 Mar 2005 11:31:01 -0700

Secure firmware download is a worthy objective (which is already in).
But it is only one of the objectives. As a protocol

The taxonomy study has not indicated an architectural trend towards what
is being proposed. That exercise was undertaken to normalize
architectural variants. It had proved to be a challenge and was well
handled.

That does not mean the challenge has passed. That is why we wish to nail
it down in the Objectives - without discouraging non-normative
implementations.

CAPWAP WG is not here to dictate a new architectural mandate - or make
presumptions on how WTPs and ACs should shape up in hardware and
firmware to work with each other. 

Our goal in IETF is to define an interoperable protocol interface for
such already identified class of architectures that works. That was the
architecture taxonomy exercise (and the ongoing liaison with IEEE 802.11
to further clarify & validate as much as it can and as needed).

Its goal is to design a protocol to address the normalized architectural
framework and address the problems explicitly described in RFC3990 (and
more).

Here is what CAPWAP WG work was founded on:

To address the problem of managing a large number of (wireless) devices
of a class (WLAN APs) whose primary functions are to

(a) discover (and associate with)
(b) configure (as often)/provision (one-time)
(c) monitor (unsolicited or solicited)
(d) control
(e) secure
    1. the mgmt. communication to it
    2. the network (from possible rogue instances among other things) by
authent., admission, authorization
    3. the client (from possible rogue controllers)

And to be able to do so in specific determinate ways verifiable for
interoperability. If we left the above communications to the
machinations of the individual implementations - that does not meet our
objectives.
Nor is there much of a need for IETF - for CAPWAP or many other
protocols.

So, setting aside the implied architectural mandate of the proposal
below;

We welcome proposals addressing the RFC3990 stated-problems and
Objectives.

Regards,
-mani
======
-----Original Message-----

Thanks
partha

---

From: "Mani, Mahalingam (Mahalingam)" <[email-masked]>
Date: Fri, 11 Mar 2005 14:01:07 -0700

Further on this...inline.

-mani
======

-----Original Message-----
[...]
> 
> You ruling something out, means nothing to me. I am disappointed that
> the chairs fail to recognize the real issues and continue to pursue
> academic objectives without regard to market realities.
> 
> [Mani, Mahalingam (Mahalingam)] this is not an academic objective. If
it
> turns out to achieve something in the academic realm as well - I am
sure
> the erudite ones in the WG will be glad to have contributed.
> 
> The chairs have no intentions to tolerate proposals that make a
mockery
> of IETF or CAPWAP objectives and charter.
> 

If questioning objectives is a mockery of the IETF or  CAPWAP, then I
fail to see how this is in the spirit of open debate which the IETF
has always stood for.

[Mani, Mahalingam (Mahalingam)] to clarify - we are not assuming mockery
yet. We are just forewarning that it does not become one.
On Openness: it still does. That's why we are still debating in this
list. It perhaps also shows openness to discussing the protocol in
anticipation of further details and clarification without presupposing
that it only means what it says now.

The fact remains that there is not a single substantive argument which
says a download protocol does not meet the market objective of
interoperability between ACs and WTPs. The arguments seem to center

[Mani, Mahalingam (Mahalingam)] 
[Mani, Mahalingam (Mahalingam)] that is the non-mockery component.

around the fact that the method of communication seem proprietary but
never the fact that an AC and a WTP from different vendors can be made
interoperable.

However, we continue to proceed without accepting this as an alternative
to the
heavy duty protocols that have been submitted today. I agree that it
does not deliver interoperability of the kind this group seems to
prefer. But customers are NOT asking for this. They are asking for
interoperability. Full Stop. Not of a specific kind.

[Mani, Mahalingam (Mahalingam)] if customers are NOT asking for this -
having contributed to this group this Partha's current inputs (along
with earlier ones) as well as other constituents' - which includes
customers - (and we are consciously making an attempt to explicitly poll
many - as those who have followed the WG activities have been notified
in earlier sessions) - including yours in proxy of customers.

As chairs We will continue to always listen. [We also are responsible to
filter spurious ones].

[If there's WG consensus they *are asking for this* as has been the
vector indication so far - the WG will continue on identifying protocol
solution based on the charter.]

-mani
> Nor proposals for the sake of one.
> 
> Nor to detract from charter goals the WG has shown consensus
(including
> the current proponent-s) on; while still being open to arguments on
> serious validation issues, if any, including the charter; this will
> require more than mere assertions.
> 
> I would urge, finally, to keep the debate, discussions and objective
> statements focusing on problems and/or issues at hand and not mix
> unjustifiable rhetoric.
> 
> > As an AC vendor, the last thing that I really want to do is to have
to
> [Mani, Mahalingam (Mahalingam)] [...]
> 
> Keerti Melkote
> Founder
> Aruba Networks
> 
> > Pat R Calhoun
> > CTO/Founder
> > Airespace, Inc.
> >
> [Mani, Mahalingam (Mahalingam)] -mani

---

From: "Pat R. Calhoun" <[email-masked]>
Date: Fri, 11 Mar 2005 13:32:22 -0800

Can you tell me how the CAPWAP group is going to address the
multi-BSSID issue that was raised by Partha or for that matter other
new capabilities that will inevitably emerge? We perform packet
captures on our APs, will there be another information element that
takes care of that too.

Lets not obfuscate the real issue here.

A standard for the sake of a standard is not necessarily a good thing.
Especially one that is designed to curb innovation in the name of
interoperability.

<PRC> A WTP can specify how many BSSIDs it can handle, and the AC acts
accordingly. This is nothing that even your proposal can really do
anything about. If a vendor comes to you with a WTP whose MAC can only
handle a single MAC address, then you have that restriction as wel.

What is being proposed is a very simple way to achieve
interoperability between WTPs and ACs without requiring a heavy-duty
protocol that attempts to accommodate every innovation that might
occur and create a bloated proposal that does not achieve the desired
end goal of interoperability.

<PRC> At a huge cost. This is not interoperability. This is restricting
which vendors in the market will be able to be successful, based solely
on their relationship with the AC vendors.

<PRC> I would argue that your approach harms the market even more.

Pat - you and I both know that a protocol does not solve your business
issue. A vendor is either committed to interoperability or not. And it
takes money to achieve this.

I can't comment on the particulars of your business issues. We are
committed to interoperability and it does mean having a staff that
works on achieving interoperability.

The advantage is to the customer. They get to mix and match ACs and
WTPs.

<PRC> ok, so let me ask the question a different way. Say a new start-up
comes up with the latest and greatest MAC that solves world hunger. They
recognize that CAPWAP is required, so they start to partner up. Now in
order for this vendor to be able to play in this space, they would have
to share some of their intellectual property with the AC vendor, because
ultimately, the AC vendor has not disclosed their proprietary protocol. 

<PRC> Again, I honestly don't see this approach as a viable one. If
everyone had the exact (or close) hardware design and MAC, then this
would be a possibility.

Interesting point of view. Lets say a WTP vendor comes up with some
unique value added feature set. The AC vendors do not support it. How
does your proposal help the WTP vendor exactly?
<PRC> The proposal that I have been proposing would, because the AC
really doesn't care how antennas or MACs are handled. It just wants
access to the MAC management portion of the 802.11 protocol - which is a
standard to begin with.
 
The solution is the same regardless of whether you have a control
protocol or a download protocol. The WTP vendor comes up with their
extensions and has a business discussion with AC vendors to support
their value add. I think both proposals solve this business problem.
The download protocol does this more expeditiously for the WTP vendor,
the AC vendor and the customer.
<PRC> This assumes that vendor wants to share their intellectual
property... something I don't accept so easily.

Lets take your example and say a vendor decides to get out of this
business (many enterprise customers are in this state now as we
speak). The customer is now stuck with an expensive deployment of WTPs
and ACs that are now obsolete. All the customer has to do is simply
swap out the obsolete ACs with one that supports the deployed WTPs and
the WLAN is back in action. The brain transplant provides investment
protection to the customer assuming an enterprising AC vendor decides
to take the burden of getting the installed WTPs to work with their
ACs.
<PRC> hmmm... ok. Not sure that's what people expected for an answer. If
a new WTP comes out, then one would assume that as long as it complies
with the standard, it will be supported - no need to swap out AC gear.