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

From: "Paul Lambert" <[email-masked]>
Date: Fri, 11 Mar 2005 12:06:30 -0800

>> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Keerti Melkote

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

What if I'm an AP/WTP vendor.  Without very close cooporation with the
AC vendor, it would be impossible to create a compatible AP/WTP.

This meets my definition of a 'closed' and proprietary system.

If I'm an AC vendor, I can only field a 'brain transplant' if I have a
very close relationship with the WTP vendor.  The relationship must
either include full documentation of the WTP hardware interfaces, OS and
board level information for the AC vendor to write code, or a full set
of protocol signaling that includes the data encapsulation techniques
and control signaling.

This required level of coorporation also meets my definition of a
'closed' and proprietary system. Note that open publishing of the data
encapsulation and control signaling suddenly opens the system to anyone
and creates a true interoperable marketplace. 

Brain transplants may have some interesting capabilites, but the brain
still needs to speak a known and common language to be useful.  If the
WTP-to-AC signaling is proprietary, the system is proprietary.  

Paul

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

---

From: Dan Harkins <[email-masked]>
Date: Fri, 11 Mar 2005 12:50:04 -0800

Paul,

  I don't want to get into a symantic game about whose private definition
of the word "proprietary" is more correct but something here deserves
a comment.

On Fri, 11 Mar 2005 12:06:30 PST you wrote
> of protocol signaling that includes the data encapsulation techniques

You're right. The relationship would probably include all the information
necessary for an AC vendor to port his code to a WTP vendor's platform.
Contrary examples exist (netbsd runs on a playstation2) but that is,
as you have pointed out, not "easy".

Or, you say, "a full set of protocol signaling that includes the data
encapsulation techniques and control signalling." That's exactly why the
all-encompasing control plane and data encapsulation option is so
unappealing. Either your set is the same as everyone else's set (in which
case it wouldn't appear in your argument so let's just dismiss that
fiction immediately) or something in someone's set of control
signaling-- perhaps your's!-- is going to be left out of the "standard". 

Put yourself in that place. Your chipset has some whippy-dippy feature
that no one else's has but the "standard" doesn't allow for control or
management of it. Whaddya do?

  Dan.

---

From: "Cheng Hong" <[email-masked]>
Date: Mon, 14 Mar 2005 23:20:27 +0800

Hi Dan

> Put yourself in that place. Your chipset has some 
> whippy-dippy feature that no one else's has but the 
> "standard" doesn't allow for control or management of it. Whaddya do?

Please note that the extensibilty is also one of the objective inlcuded in
the draft. If a new feature needs to be supported, some extension could be
created, and published. AC or WTP vender that wants to support that feature
could just inlcue the extension if they want. This has nothing different
from that RADIUS or Diameter is doing.

This is much easier than asking WTP vendor go to all the AC vendors to have
that feature incorporated into the new image. I guess the pure "brain
transplant" method will make the problem of matching 1:n permutations into
matching n:n permutations. 

cheers

Cheng 

> -----Original Message-----
> [mailto:[email-masked]] On Behalf Of Dan Harkins
> Sent: Saturday, March 12, 2005 4:50 AM
> To: Paul Lambert
> Cc: Keerti Melkote; Pat R. Calhoun; [email-masked]
> Subject: Re: [Capwap] A simpler approach to CAPWAP 
> 
> 
>   Paul,
> 
>   I don't want to get into a symantic game about whose 
> private definition of the word "proprietary" is more correct 
> but something here deserves a comment.
> 
> > either include full documentation of the WTP hardware 
> interfaces, OS 
> > and board level information for the AC vendor to write 
> code, or a full 
> > set of protocol signaling that includes the data encapsulation 
> > techniques and control signaling.
> 
> You're right. The relationship would probably include all the 
> information necessary for an AC vendor to port his code to a 
> WTP vendor's platform. Contrary examples exist (netbsd runs 
> on a playstation2) but that is, as you have pointed out, not "easy".
> 
> Or, you say, "a full set of protocol signaling that includes 
> the data encapsulation techniques and control signalling." 
> That's exactly why the all-encompasing control plane and data 
> encapsulation option is so unappealing. Either your set is 
> the same as everyone else's set (in which case it wouldn't 
> appear in your argument so let's just dismiss that fiction 
> immediately) or something in someone's set of control
> Put yourself in that place. Your chipset has some 
> whippy-dippy feature that no one else's has but the 
> "standard" doesn't allow for control or management of it. Whaddya do?
> 
>   Dan.
> 
> [email-masked] http://mail.frascone.com/mailman/listinfo/capwap
> 
>

---

From: Dan Harkins <[email-masked]>
Date: Mon, 14 Mar 2005 09:09:08 -0800

RADIUS is a bad example. How long did it take to get RFC3580 out
the door? Because of this problem what people do is come up with
VSAs. Talk about a n:n problem! You'll have to know what set of
proprietary extensions each WTP vendor has added to this "standard"
protocol. 

  Dan.

On Mon, 14 Mar 2005 23:20:27 +0800 you wrote

---

From: Matt Holdrege <[email-masked]>
Date: Mon, 14 Mar 2005 17:11:52 -0800

There is no shortage of bad things to say about RADIUS and many have done 
just that over the years on WG email lists. However you can't say it hasn't 
been wildly successful for service providers. They absolutely love it. 
Would they switch if something better came along? Yes. Has anything better 
come along? No.

Sorry to digress, but maybe this has a bit of relevance?

-Matt