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

From: "Paul Lambert" <[email-masked]>
Date: Wed, 9 Mar 2005 11:54:21 -0800

An interesting perspective...  

Open standards allow products to be created without establishing direct
business relationships with other participating vendors.  Products
should be able to interoperate in a system, based solely on the
signaling defined in the standard.  

For example, my mail reader can connect by SMTP or IMAP to a large
number of standards compliant servers.  This download approach is more
like web-based applications that download code to the target
workstation.  You can read mail using proprietary communication
protocols because you've downloaded a special proprietary applet.

This sort-of works because there are standard in the execution
environment (Java, JavaScript, ActiveX, Explorer, etc.) that allows some
commonality in the downloaded application.

For the WPT, this is a more difficult and diverse environment.  These
embedded systems run various operating systems and hardware
architectures.  If the proposal included the use of J2ME or some other
standardized execution environment, then there might be merit in the
concept.  This environment would then also need to be extended to
provide APIs for the appropriate WTP functionality.  I am not hearing
any such detail in the proposal.

Proprietary downloads create chameleon WTPs.  This is effectively allows
the re-branding of devices by changing the firmware.  In the field, this
would provide little value.  It's unlikely that such a WTP would switch
identities after it was first installed.  You might as well just load
the appropriate firmware in the factory.  

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.  If this is the only
requirement for CAPWAP, then we're done and should declare success and
disband the committee.

Paul     

> -----Original Message-----
> From: Dan Harkins [mailto:[email-masked]] 
> Sent: Wednesday, March 09, 2005 11:23 AM
> To: Paul Lambert
> Cc: Partha Narasimhan; Michael Vakulenko; [email-masked]
> Subject: Re: [Capwap] A simpler approach to CAPWAP 
> 
>   Paul,
> 
>   I don't think it's designed to replace other control functionality.
> The point is that it is not necessary to standardize that 
> control functionality. The control functionality (and how and 
> where to split a MAC, for instance) is all contained in the 
> code running on the AC and the code in the image the AC 
> provides to the WTP. How the control plane and data 
> encapsulation are defined is up to the AC vendor (who wrote 
> the code for running on the AC and also the code in the image 
> provided to the WTC) and not to the IETF.
> 
>   Let a Hundred Flowers Bloom!
> 
>   Dan.
> 
> On Wed, 09 Mar 2005 11:14:39 PST you wrote
> > 
> > This 'simpler' approach would never work as propoposed to replace 
> > other control functioanlity.
> > 
> > A software upgrade mechanism might be desireable.  This upgrade 
> > process would never replace a fuller set of control protocols.
> > 
> > 
> > > -----Original Message-----
> > > From: [email-masked]
> > > [mailto:[email-masked]] On Behalf Of Partha Narasimhan
> > > Sent: Wednesday, March 09, 2005 11:06 AM
> > > To: Michael Vakulenko
> > > Cc: [email-masked]
> > > Subject: RE: [Capwap] A simpler approach to CAPWAP
> > > 
> > > 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 AC vendor may not have the desire or the bandwidth to make WTP 
> > images.
> > 
> > Unless the WTP are on standardized hardwar, how would a AC vendor 
> > build an image?
> > 
> > >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.
> > 
> > This is NOT the nature of open interoperable standards.  A Company 
> > should not have to work directly with every other vendor to create 
> > interoperable systems.
> > 
> > Paul
> > _______________________________________________
> > 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: Dan Harkins <[email-masked]>
Date: Wed, 09 Mar 2005 13:15:05 -0800

On Wed, 09 Mar 2005 11:54:21 PST you wrote
> 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? 

  At the start of this working group people were talking about the
commoditization of APs and how they'd be sold by for low margins in
bulk. The discover-and-download idea fits perfectly in with that.

  It also enables innovation and product differentiation. It allows for
extensibility in a way than the alternative (define a huge, generic
control plane and data encapsulation that encompasses all possible
architectures in the taxonomy draft) cannot handle.

>                                                  If this is the only

  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.

  Dan.