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

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

Well, I must admit that I was a little surprised about a proposal to
create a non-standard. I agree with James and others that the CAPWAP WG
must really create a complete protocol, one that is well documented, and
is available for the network operators to use during the troubleshooting
process.

Seriously, what exactly is being proposed here? We already have several
vendors with various protocols - the only difference is to allow a brain
transplant of WTPs.

As an aside, I recollect ruling this out of the problem statement very
early on, so this whole discussion appears to be out of scope.

As an AC vendor, the last thing that I really want to do is to have to
have a staff of people that have to understand the various WTP HW
architectures,  not to mention the MACs which they all use, who spend
their time porting their code to different HW. Seriously, what's the
advantage to the AC vendor? It's a huge cost burden, and it really
doesn't solve the end problem. Sure, I can hear the "market advantage of
supporting more WTPs", but let's be fair here, we also have to provide a
solution that allows companies to be fiscally responsible.

You can imagine the scenario where a WTP vendor creates some significant
value, but is unable to get the most popular AC vendor to want to
support their platform - so this proposal actually stifles innovation,
IMHO. Even if the AC vendor does port to this platform, won't all the
additional value be lost, as the standard code from the AC vendor is
downloaded?  Won't this stifle innovation by WTP vendors, rather than
encourage it?  Won't all the innovation have to come from AC vendors,
only?

Furthermore, this proposal does not provide any form of capital
investment. Imagine a scenario where an AC vendor decides to get out of
this business. The customers would have an AC with no way to get new WTP
technologies supported (e.g., 802.11n). OK, so I assume we are not going
to try to define a process where one can also do a brain transplant on
the AC. So in this case, a customer merely needs to swap out their old
ACs for ones from a new vendor?  Oops!  The overlap of supported WTPs
between the two AC vendors may not cover all the WTPs in the legacy
network.

So to close I don't understand why the CAPWAP WG would be willing to
accept a non-standard. Frankly, since AC vendors would have to create
the WTP's images themselves, there is no reason why they cannot work
with the WTP vendors directly to provide them with their own download
mechanism. As I believe a few people stated already - this is the state
we are in already.

Pat R Calhoun
CTO/Founder
Airespace, Inc.

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

---

From: Dan Harkins <[email-masked]>
Date: Fri, 11 Mar 2005 10:14:08 -0800

On Fri, 11 Mar 2005 08:08:03 PST you wrote
> is available for the network operators to use during the troubleshooting

There are complete and well-documented protocols that are available for
network operators to use during troubleshooting that are simple. A
non-standard? I know that isn't a serious comment since your next paragraph
begins with "seriously".

> early on, so this whole discussion appears to be out of scope.

That was before there was even a WG and the WG that came out after that
"ruling" (makes it sound so official) was just supposed to come up with
a taxonomy of architectures, nothing more. And your rulings carry no weight
anyway.

> solution that allows companies to be fiscally responsible.

What's the benefit to the AC vendor? An operator can replace your switch
with mine without having to chuck the couple hundred WTPs he purchased
since my AC will happily give them all brain transplants. It's a compelling
option to offer a customer and has obvious benefits to AC vendors.

> encourage it?  Won't all the innovation have to come from AC vendors,

Let's take your premise-- WTP vendor creates some significant value-- and
see how it works with the all-encompassing control plane and data encaps
idea. Since this new value was not part of the specification for the
protocol it cannot be used. All he can do is send someone to the next IETF
who will make a presentation to this WG, which will never die, that in the
best case will take a year (that's assuming the other WTP vendors don't
try to delay things in this highly-politicized IETF we have these days)
before it appears as part of the standard. 

That is a serious disincentive to innovate.

With the discovery and image download protocol innovation would not just
come from AC vendors. The new value added by the WTP vendor would make his
WTP more in demand and therefore AC vendors would be pressured to either
support that WTP (in the event they don't already) or use the new feature
just innovated (if they do). 

It has already been stated on this list that if the all-encompassing
control plane plus data encapsulation route is taken that vendors can
"differentiate themselves based on their network management system....
If the protocol is standardized, the vendors will find other areas to
distinguish their products." By the way, that's "other areas" than the
new value the WTP vendor came up with, to use your example.

So we can differentiate ourselves on our network management system?
Wow, that sounds really, really bad. It will constrain technological
innovation but we can all become java programmers to make our GUI
more pretty! Thanks but no thanks.

> investment. 

Protocols do not provide capital investments. So proposals for protocols
will necessarily not provide them either.

>             Imagine a scenario where an AC vendor decides to get out of

In the scenario you describe the customer would purchase an AC from a
vendor that provided a greater "overlap", ideally one that supported all
the legacy network.

Also your mention of 11n is a non-sequitur.

> mechanism. As I believe a few people stated already - this is the state

Yes, that is what we have today. And a plethora of "download mechanisms"
is a pain. It is a problem today that needs a standard from the IETF to
solve.

Having a single standard (real standard, not "non-standard" by the way)
method of discovery and image download will make it much easier to support
the scenario that prompted the formation of this WG.

The all-encompassing control plane plus data encapsulation protocol idea
will necessarily constrain development and stifle technological innovation
(you can only configure what the protocol knows about, you can only gather
statistics on things the protocol knows about, you can only monitor what
the protocol knows about, etc). Either that or it will be a hideously
complex and unimplementable nightmare.

  Dan.

---

From: Keerti Melkote <[email-masked]>
Date: Fri, 11 Mar 2005 11:34:25 -0800

> is available for the network operators to use during the troubleshooting

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.

> vendors with various protocols - the only difference is to allow a brain

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.

Do I need to remind folks of the ATM Forum?

> early on, so this whole discussion appears to be out of scope.

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.

> solution that allows companies to be fiscally responsible.

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.

> encourage it?  Won't all the innovation have to come from AC vendors,

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?

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.

> between the two AC vendors may not cover all the WTPs in the legacy

Interesting theory. In capitalism, where there is opportunity, usually
there is someone to take it.

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.

> mechanism. As I believe a few people stated already - this is the state

The goal is not a non-standard. It is a simpler standard that delivers
the key objective of interoperability without locking down innovation.

Keerti Melkote
Founder
Aruba Networks