Cisco Motion Sickness

Sorry for the word choice, but Cisco Motion vision marketing can make you dizzy;)

The marketing folks at Cisco have been busy creating a mobility vision, in response to real enterprise challenges of Hyperconnectivity. The formula is all too familiar. Identify all the right user challenges... Spin a vision story around a not-so-exciting product announcement.... Usually add a five phase picture (magically you're already at phase 3!) and .... Create industry buzz around the works.

But Cisco's recent Motion vision announcement (and related 'phase 0' product announcement of a glorified location-based WiFi controller) raises more questions than it answers.

For example:
Why would enterprises want to invest in a network-centric approach at the expense of application agility?
What if you want to deploy best-of-breed wireless intrusion prevention from another vendor?
Will you be constrained in your RFID or UWB vendor selection under Motion?
How does a WiFi-centric appliance 'unify disparate networks' and 'facilitate collaboration'?

But the biggest question in my mind is that Motion is an architectural no-man's land (or is it sea?).

Cisco says that their vision 'abstracts the application layer from the network layer'. This sounds like SOA but it's not! SOA is software centric and network agnostic. Application developers don't want to know about appliances.

Cisco has introduced a network embedded appliance that is specific to the in-building wireless- actually to the WiFi- network. This sounds like SONA, but it's not- maybe Cisco is giving up on SONA, which has had minimal traction anyway!).

Application developers tell us they want a SOA-enabled framework into which to work, that is totally independent of the underlying infrastructure, whether wired or wireless, enterprise or carrier. For example, does it make any sense to bring public network location-based information into the enterprise via a WiFi appliance? Among other things, this seems to create a bottleneck for application innovation and scalability.

There are already solutions that offer context/location aware services, roaming and FMC, end point security and wireless IPS. A key differentiator in our approach to Communications Enabled Applications, is the Nortel Agile Communication Environment (ACE).

Nortel ACE truly abstracts the application layer from the network layer; supports aggregated presence, and in-building and wide area context (location, policy, identity) services; has adaptors to various network infrastructures (including Nortel and Cisco Call Manager), and is built on SOA (in fact, integrating IBM's Websphere today and other frameworks in the near future).

Are you starting to feel a little queasy about Cisco's Motion vision marketing?

| 2 Comments | 0 TrackBacks

Listed below are links to sites that reference Cisco Motion Sickness:

Cisco Motion Sickness TrackBack URL : http://blog.tmcnet.com/mt/mt-tb.cgi/36278

Around TMCnet:

2 Comments

Tony, I just submitted the following to Omar Sultan on his BLOG regarding Cisco's diffussion of Nortel's energy claimes @ http://blogs.cisco.com/datacenter/comments/power_pickups_and_polar_bears/

I submitted this with the intent to negate Omar's assertion that the 6509's increased power requirements were due to the 8600's lack of PoE.

Without PoE, obviously the increased power draws were due to the numerous "daughter board" requirements on both line cards and Supervisor modules for the 6509 not needed with a Nortel solution. Wanted to take the opportunity to highlight other ROI facets as well.

If of value, please distribute.

***********************************
Omar,

This blog is interesting. You gave an example of a Ford Focus versus a Ford F-150. The problem is this analogy uses the same manufacturer although different vehicles with different capabilities meeting different demands. If you were to compare a Catalyst 3750 with a 6509, this would be more applicable.

However, keeping with your example, let's assume a 6509 is a Ford F-150. In 2 x wheel drive, the 6509 line cards are capable of layer 2 switching. All routing and QoS functions are centrally performed by the Supervisor module potentially causing bottlenecks and delayed responses. In order to perform routing and QoS on each line card, a DFC daughter card is required per line card module (per Cisco documentation). This would require the Ford F-150 to have another engine per wheel to enable 4 x wheel drive. Using a 9 x slot 6509 comparison, if the F-150 had 7 x wheels (assuming 2 x wheels are used for redundant Supervisor modules/main engine), this would be 7 x additional engines that each consume gas.

The problem doesn't stop at the additional gas used. If I upgraded my Ford F-150 from a stock 4.2-liter V6 (Sup32) to a 4.6-liter V8 (Sup256), I have to purchase all new engines for all 7 x tires. Same holds true when upgrading from a 4.6-liter V8 (Sup256) to a 4.8-liter V8 (Sup720).

If I put my F-150 into 4 x wheel drive and wanted to cross mud, that would require a specific set of tires (DFC modules). However, next time I may want to cross rocks, sand or other terrain. That would require a different set of tires (DFC, DFC2, DFC3A, DFC3B, DFC3BXL, DFC3C, DFC3XL). An additional problem exists in that not all tires (DFC modules) work with the main engine (Supervisor module).

Even the main engine (Supevisor module) has a second engine (PFC module daughter card) that consumes gas and needs to be upgraded when adding fog lamps, rear window defrosters, etc.. The main engine's second engine upgrades can cause the air conditioning or radio to stop working, depending on the tire engine in use, and require tire engine upgrades.

I think if the CxO's had more understanding of technology, the 6509 would have not seen the success it has had with or without power consumption savings. Unfortunately, most buying decisions occur at lower levels where Cisco certification rule and commands a higher pay grade mostly to understand the complexities of deploying Cisco products vs. the actual technology itself.

Nortel, Foundry, Extreme and others don't share the same design flaw exacerbated by the importance of keeping Cisco IOS alive, through CPU driven approaches and proprietary ASIC design. As society itself continues to become more astute technologically, we'll find ourselves adopting more open standards based technology that breaks the barriers of proprietary vendor architectures and relagates vendor proprietary approaches to "features" that make the vendor stand out among others in an open medium.

Networking should be viewed as an intelligent highway. When the car driven on that highway is dictated by the manufacturer of the highway, progress for anyone other than the manufacturer of the highway is lost. Take a look into SONA vs. SOA and you'll see a glimpse into where the future of the supposed "open" highway is being defined.

You can check out http://www.usedcisco.org for more used cisco products that are indeed cheap and already tested

Around TMCnet Blogs

Latest Whitepapers

TMCnet Videos