Vendor viability is a standard part of our process before entering into multi-year contracts. Note also that Chapter 11, while a bad sign, is not the end of the road. Some companies manage to pull themselves back from that brink; more get acquired by someone who can often make a business case for continuing to meet the needs of the existing customer base. Others may also see that as a business opportunity....
I would not want to be the only customer of a failed technology effort (which probably failed for lack of any other customers...), but I think the risks of buying from an outfit with reasonable financials and reference customers in our sector are pretty tolerable. (And there's nothing specific to wireless in that!) David Gillett > -----Original Message----- > From: Frank Bulk [mailto:[EMAIL PROTECTED] > Sent: Tuesday, June 27, 2006 4:49 AM > To: [email protected] > Subject: Re: [WIRELESS-LAN] Controller Architecture vs FAT APs > > That's why I believe vendor viability should be a key element > in the decision-making process for enterprise WLAN > infrastructure systems, unless a certain vendors technology > or pricing is so compelling that it's worth the risk. > > Frank > > -----Original Message----- > From: phanset [mailto:[EMAIL PROTECTED] > Sent: Monday, June 26, 2006 10:46 PM > To: [email protected] > Subject: Re: [WIRELESS-LAN] Controller Architecture vs FAT APs > > Here is an example of my concerns: > > I decide to buy an CBA system. > 3 years later the CBA system files chapter 11. Which APs will > I buy for that > > new > building that needs a Wi-Fi install? > I could live with the absence of code releases, but not the > absence of those > > APs > that do prorietary tunnels to their controllers. > In the switch world, if you use for instance 802.1q for > trunking and IGMP for multicasting you should be able to buy > from any switch vendor and support your infrastructure. In > today's CBA world it's more like using ISL and CGMP! > > > Philippe Hanset > University of Tennessee > > > >===== Original Message From "802.11 wireless issues listserv" > <[email protected]> ===== > >I agree that it will be just a matter of time before > CAPWAP/LWAPP or what > >ever they are going to call it will become a standard, how > long? About as > >long as it took for 802.11g to become one ;-) This same type > of issue has > >not just been in the WiFi technology but as well in the > switch technology. > >Can Cisco works or other switch vendor's management platform > manage other > >switch vendors equipment? Yes, but not all features of the > vendors switch. > >The list could go on. Fact is there are proprietary things > in all vendors > >management of equipment but as long as it does not affect the clients > >ability to use standards to do their work there should be no problem. > > > > > > > >bd > > > > > > > >Brian J David > > > >Network Systems Engineer > > > >Boston College > > > > _____ > > > >From: Emerson Parker [mailto:[EMAIL PROTECTED] > >Sent: Monday, June 26, 2006 5:15 PM > >To: [email protected] > >Subject: Re: [WIRELESS-LAN] Controller Architecture vs FAT APs > > > > > > > >please don't take this as a vendor point of view, it > certainly is NOT... > > > > > > > >"thin APs" are generally a software definition, not a > hardware definition. > >For instance, I can run openWRT on an aruba AP and have it > do whatever I > >want. You can get the aruba boot code from sourceforge and > practically > turn > >any ap into one that will tie to their central controller > (using openWRT). > > > > > > > >But the real issue here is what will be supported from > vendors. hopefully, > >when CAPWAP, LWAPP or whatever the heck it will be - should > allow APs to go > >both ways. APs that need to decrypt and then tunnel the data to the > >controller for further direction should be able to do this. APs that > tunnel > >everything back (for decrypt) should be able to do this as > well. But, as > we > >have seen in the past with standards.......... who knows! > > > > > > > >Central controllers provide an truly amazing set of features / > capabilities, > >not to mention making large wifi networks _extremely_ easy to > >config/manage/monitor. any vendor ;) > > > > > > > > > > > >-Emerson > > > > > > > > > > > > > > > > > > > > _____ > > > >From: Dave Molta [mailto:[EMAIL PROTECTED] > >Sent: Monday, June 26, 2006 2:43 PM > >To: [email protected] > >Subject: Re: [WIRELESS-LAN] Controller Architecture vs FAT APs > > > >I personally feel that traditional FAT AP's can be made to work > effectively, > >even in large environments, but it requires a considerable amount of > >integration and more staff expertise than controller-based > systems. In > >addition, since the industry as a whole is clearly moving towards the > >controller architecture, it's likely that most innovation and new > >functionality will appear on these new platforms. There are > a lot of Fat > >AP's out there in the field, and even significant demand for > new purchases, > >perhaps enough to prevent vendors from end-of-lifing these > offerings for > >several years and also to sustain a third-party market for management > tools. > > > > > > > > > >I disagree with Brian's point about whether these systems > are proprietary. > >Yes, they all adhere to 802.11 standards so you don't have > to worry too > much > >about whether they will be compatible with client devices > but the fact is > >that the interface between the AP's and the controllers is > proprietary to > >every vendor. Yes, there are some efforts to standardize > this interation > >(e.g., CAPWAP) but I personally think that is a bit of a > pipe dream. The > >interaction between AP's and controllers is very much > dependent on the > >architecture. For example, Aruba does centralized crypto while Cisco > handles > >it in the AP's. You can't make those systems interoperable just by > >standardizing the AP-to-controller protocol. > > > > > > > >For what it's worth, the surveys we have done indicate that IT > professionals > >want very much to see true interoperability, where you can > purchase AP's > >from one vendor and controllers from another and make them > work together. > >I'm not very optimistic this will happen. > > > > > > > >dm > > > > > > > > > > _____ > > > > > > >From: Brian J David [mailto:[EMAIL PROTECTED] > >Sent: Monday, June 26, 2006 1:44 PM > >To: [email protected] > >Subject: Re: [WIRELESS-LAN] Controller Architecture vs FAT APs > > > >Tom, > > > >I would like to start of by saying that we also are a big > Aruba networks > >shop. We replaced out FAT 802.11b AP's with Aruba a/b/g AP > 70's and it > could > >have been any easier if we tried. (2 people) Some here my lead you to > >believe that controllers are PC's but each company they quoted has a > >dedicated appliance. I know that the Aruba 5000/6000 controllers have > >dedicated processors for each wireless process for example Firewall, > >encryption, etc. Aruba also just announced a code upgrade > the will enable > >the controllers to handle and I quote here "A single Aruba > WLAN system is > >now capable of supporting up to 1000 simultaneous 802.1X > authentication > >transactions per second" They also have plans to handle > 802.11n as well. > >Don't be lead down the path that thin AP's are proprietary > that is just not > >the case, they adhere to the same standards as the FAT's. > IMHO the deep > >frying of AP's is going to be in the FAT AP's, just ask me I have 500 > >802.11b AP's ready to drop into the fry-O-lator. :-) > > > > > > > > > > > >Brian J David > > > >Network Systems Engineer > > > >Boston College > > > > > > _____ > > > > > >From: Zeller, Tom S [mailto:[EMAIL PROTECTED] > >Sent: Friday, June 23, 2006 9:43 AM > >To: [email protected] > >Subject: [WIRELESS-LAN] Controller Architecture vs FAT APs > > > > > > > >I would be interested in other opinions on the following > analysis of this > >issue: > > > > > > > > > > > >1. Using AirWave's AMP management platform has almost > eliminated the > >management advantage of the controller-based architecture (CBA). AMP > >monitors, reports, and updates Fat APs just fine. Also, > some CBAs don't > yet > >have a single management platform for multiple controllers. > >2. CBA is considerably more expensive, in the 1.5 - 2.0 x range > >compared to Fat APs > >3. The other advantages of CBA boil down to the following. > If others > >I'd like to hear. And if these are fictitious, also of interest: > > > >a. Roaming, theoretically across an entire campus, without > requiring a > >single vlan > >b. Significantly faster handoff between APs due to 802.1x > keys on the > >controller, important for voice support. > >c. Automagic dense AP deployment from radio feedback to > and adjustments > >from controller (or Meru's approach). > > > > > > > >Obviously I'm considering sticking with Fat APs for another > few years and > >allowing the CBA products to mature, but I ain't got no > religion here, and > >would welcome success/horror stories from large scale CBA > deployments. > > > > > > > >Tom Zeller > > > >Indiana University > > > >[EMAIL PROTECTED] > > > >812-855-6214 > > > > > > > >********** Participation and subscription information for > this EDUCAUSE > >Constituent Group discussion list can be found at > >http://www.educause.edu/groups/. ********** Participation > and subscription > >information for this EDUCAUSE Constituent Group discussion > list can be > found > >at http://www.educause.edu/groups/. > > > >********** Participation and subscription information for > this EDUCAUSE > >Constituent Group discussion list can be found at > >http://www.educause.edu/groups/. > > > >********** Participation and subscription information for > this EDUCAUSE > >Constituent Group discussion list can be found at > >http://www.educause.edu/groups/ > > > >********** Participation and subscription information for > this EDUCAUSE > >Constituent Group discussion list can be found at > >http://www.educause.edu/groups/. > > > >********** > >Participation and subscription information for this EDUCAUSE > Constituent > Group discussion list can be found at http://www.educause.edu/groups/. > > ********** > Participation and subscription information for this EDUCAUSE > Constituent > Group discussion list can be found at http://www.educause.edu/groups/. > > ********** > Participation and subscription information for this EDUCAUSE > Constituent Group discussion list can be found at > http://www.educause.edu/groups/. > ********** Participation and subscription information for this EDUCAUSE Constituent Group discussion list can be found at http://www.educause.edu/groups/.
