Monday, July 30, 2012

Vendors Need To Focus on Creating Value for Customers and Making Great Products


Have you heard of ‘Maslow’s Hammer’? This phrase originated with Abraham Maslow in his book, The Psychology of Science, in 1966. The saying goes something like this:

If the only tool you have is a hammer, everything looks like a nail.

Sometimes, actually quite often, technology vendors seem to fall into this trap. A trap where they get so enamored with what they’ve already built, which filled a previous need, that they forget that customer need are always changing and their solutions need to continue to adapt. (BTW, I hate to throw around the term ‘innovation’ in such scenarios. I believe true innovation is rare, and the term gets used way too often. So, I’ve dropped innovation from my vocabulary… mostly.)

Often times this adaptation requires critical thinking and a fundamentally new approach in order to solve a new problem. But change is hard. Vendors who get stuck in this trap attempt to take the path of least resistance, which often means incremental improvement of existing products that only half-solve the problem. There could be any number of reasons for this: too few development resources, constraint of existing product (e.g. painted themselves into a corner), time to market, lack of expertise on staff to truly understand and solve the problem (which is ultimately just a failure to invest and hire additional resources), or possibly the worst one of all – market dominance where short-term sales likely won’t suffer. However, long-term sales will definitely suffer if this problem becomes systemic and they continue to lag behind competitors. For reference look at what happened to DEC, Xerox, IBM (twice), and what is currently happening to both HP and Microsoft if they don’t pull it together.

This quote from Steve Jobs – The Lost Interview touched on precisely this:

If you were a product person at IBM or Xerox, so you make a better copy or a better computer, so what? When you have a monopoly market share the company is not any more successful. So the people that can make the company more successful are sales and marketing people and they end up running the companies and the product people get driven out of decision making forums. And the companies forget what it means to make great products.

So how does this relate to Wi-Fi? The rapid market evolution and change is hard to deny in the network industry these days, and the rate of change is especially staggering in Wi-Fi. Demand for new solutions and capabilities to enable both businesses and consumers abound.

Unfortunately, some vendor features are shoe-horned solutions into existing products in ways that just don’t make sense for customers. Essentially, viewing the problem as a nail so they can use their existing hammer (instead of realizing the problem is really a bolt and they need to develop a bolt-driver). What do I mean? Here are some examples of late:
  • Meraki  Layer 3 Roaming – using their MX firewall security appliances to facilitate Wi-Fi layer 3 roaming. Why would I want to hitch my WLAN architecture and design to a firewall appliance? They have completely different objectives and scope of deployment in the network. What this really does is allows Meraki to offer layer 3 roaming on a feature list, and try to sell more firewalls.
  • Cisco Bonjour Support – relies on existing multicast support and VLAN Select to facilitate Apple Bonjour service discovery across subnet boundaries. There are many reasons why I don’t like this implementation approach, including: requiring multicast expertise to enable Bonjour in the network, limitation of a single Bonjour source VLAN rather than any-to-any connectivity across subnets (tell me, what organization can aggregate all Bonjour devices that should be accessed into a single VLAN? Very few small networks), lack of Bonjour protocol intelligence which means they can’t filter services or tie access to defined policy, and requiring all Bonjour subnets to flow through the controller which prevents all edge wired subnets throughout the network from accessing Bonjour services (and edge wireless subnets if using Cisco’s FlexConnect / H-REAP architecture).

Do these implementations add features that they can list in their product marketing material? Yes.
Do these implementations really address customer needs or create value for customers? Only partially, in my opinion.

Hopefully this post will enlighten customers on this issue and make clear the need to thoroughly examine vendor offerings and their approach to solving your needs. Don’t simply take vendor marketing material at face value. Sure, they may have a check box next to a feature buried in a laundry list of other features, but that abstracts how they implement the feature, how robust their capability actually is, and what caveats/drawbacks exist. This is NOT a land of black and white, folks. Lines are blurred, shades of gray exist, and deciphering all this and making an informed decision are tough.

As a customer, you will not be able to go into the depth required on every product feature to make a 100% informed decision. But you SHOULD be able to identify the critical features for your specific environment. Go into depth on those features, find out the nitty-gritty details, and make a decision that makes sense for your business. Vendors have various strengths and weaknesses, areas where they are leading the market and areas where they provide only the basics. Often a customer decision comes down to a few key features that really make a difference and create value for their business. Focus on those items.

My point here is NOT to call out any one vendor on this topic; I think every vendor is guilty of it to some degree. Rather it is to call on vendors to step up their game; to focus on creating value for customers rather than selling them a bill-of-goods. I don’t think this is always happening, and quite-frankly it’s frustrating to see poorly implemented solutions being sold on the market to customers. It’s likely that this will never be eliminated – market competition and dynamics dictate some level of this to continue happening. But customer influence and buying pressure can minimize the frequency.

In short :
Vendors –  let’s build great products!
Customers – let’s be informed to ensure the solutions purchased create value relative to the business needs!

Cheers,
Andrew vonNagy


Full Disclosure
Most of my readers should know that I work for a vendor now, Aerohive Networks. If you didn’t, now you do. Are we perfect? By no means. But I do think that Aerohive has a greater focus on creating value for customers and solving their business needs than most other vendors (e.g. Bonjour Gateway for BYOD, MDM integration for mobile device support whether BYOD or corporate issued, TeacherView for education, SIP2 integration for libraries).

Am I biased? Yes, partially. But I also believe that everyone is biased for or against certain products or companies based on their experiences.

Am I independent? Yes, partially. But I form my opinions based on my experiences as an engineer, not as vendor-drone who recites marketing material verbatim.

I only speak or write what I truly believe to be true based on my own personal analysis. I try to be as objective as possible, with sound evidence and engineering behind my positions. And I’m open to discussion, which I think is key. I will change my opinion of sufficiently convinced based on evidence (not conjecture). I will admit that I’m wrong. Heck, I’m wrong all the time. But that realization and openness to change on a personal level is why I still consider myself of independent thought. I hope you value my opinion, whether you agree or disagree with my positions. And if you disagree, let’s have a meaningful discourse on the topic. 

Monday, July 16, 2012

Education Institutions want Apple Bonjour Improvements

Members of the Educause community are drafting a petition to Apple for improvements in Bonjour network services for enterprise environments with larger and more complex networking needs than consumer home networks. Specifically, they want the applications to work across routed layer 3 networks natively instead of being limited to the local subnet.

A well-respected blogger, Lee H. Badman, who works for Syracuse University writes about the petition over on Network Computing:

BYOD hype tends to center on the likes of smartphones and tablets. These self-owned devices usually do just fine on the network from the technical perspective, while causing a policy ruckus that has spawned new product markets. But Apple has a family of popular devices and protocols that are decidedly sub-par enterprise network clients, and higher education network administrators want Apple to provide some relief. 
... 
Apple has built this market niche on the extremely limited Bonjour protocol, which is non-routable and extremely difficult to scale and administer on large wireless networks. Users want to make use of these very slick living-room-oriented devices at work, as they have a lot of potential cool uses. Network admins want to help, but not at the expense of wholesale network redesign. 
So what's Apple's answer thus far to individual pleas for a change in paradigm? Find a workaround.

Solutions exist out in the market, but only from 3rd party Wi-Fi vendors. Aerohive Networks is leading the charge with the only currently available solution in Bonjour Gateway. Aruba networks has announced a solution with AirGroup, but it will not be available for quite a while yet (rumored Q1 2013 September 2012).

Apple has turned into a computing behemoth with the rapid adoption of their iOS and OS X platforms in enterprise environments. Whether it's BYOD or corporate issued mobile devices, enabling services like Bonjour across the enterprise network in a simple and scalable fashion will only become of greater importance. 


It will be interesting to see how Apple's growth in the enterprise coupled with the greater demands on devices in such environments will be reflected in Apple's product development moving forward. Will they listen to the Educasue community and the larger enterprise demands? Or will they rely on 3rd party vendor partners to continue to pick up the slack?


Andrew




P.S. - Updated the AirGroup release timing information based on feedback from Aruba.

Monday, July 9, 2012

IPv6 Unicast Address Allocation

Continuing in Chapter 2 of “Deploying IPv6 Networks” (Cisco Press, 2005)

In my last post, I provided an overview of IPv6 unicast addressing, which includes link-local addresses (LLAs), unique-local addresses (ULAs), and global unique addresses (GUAs). As previously described, GUAs must be globally unique and globally routable. GUA addresses are identified with the 3 high-order bits set to ‘001’ (2000::/3) with addresses ranging from 2000::/4 to 3000::/4.

In this post, we will dive a bit deeper on GUAs address allocation policies. Strong IPv6 address allocation and prefix aggregation policies must be implemented and enforced to prevent impact to routing process through longer lookups (remember that modern 64-bit processors require 4 cycles to process IPv6 SA and DA addresses, compared to 1 cycle for IPv4 addresses), reduce global routing table size (which is already becoming a problem with IPv4), and larger routing updates between peers because many more networks are possible with the increased addressing space.

Therefore, strong IPv6 allocation and prefix aggregation policies are meant to provide efficiencies by reducing the global routing table size and keeping routing updates to a manageable size. Cost of routing hardware also likely plays a large part in this equation, since routers with enough horsepower and memory to handle IPv6 routing updates and lookups without strong aggregation policies would come at such a huge cost that it would prohibit IPv6 adoption.

The IANA is responsible for managing and allocating the global IPv6 address space. Address allocation is strictly hierarchical from the IANA to Regional Internet Registries (RIRs), and subsequently to National Internet Registries (NIRs), Internet Service Providers (ISPs) or Local Internet Registries (LIRs), and finally individual organizations. At each step in allocation the larger address space is assigned in subsequently smaller pieces to customers. This allows hierarchical routing and prefix aggregation, which significantly reduces the size of the global routing table.

IPv6 Prefix Allocation Process

In Figure 1, you can see an example of this allocation process for the 2001::/3 prefix. The IANA allocates pieces of this prefix to RIRs and NIRs anywhere in size from /3 to /32 (however, it is typically /16 to /22 in size). These blocks are then subdivided and allocated to ISP and LIR customers, ranging in size from /32 to /35. Finally, individual organizations are allocated one or more /48 prefixes. This leaves 16-bits for use within the organization for internal subnetting and network design.

Using this allocation policy provides prefix aggregation capability at each organizational boundary (Organization, ISP, LIR, NIR, RIR, IANA). ISPs and LIRs must also allocate addresses to customers in a manner that prevents segmentation and allows for optimal use of aggregation (using the Host Density ratio defined in RFC 3194).

A complete list of IPv6 allocations by the IANA is available at the following link:

Such strict allocation and aggregation practices don’t come without detractions, however. Individual organizations no longer own their own address space directly from the RIRs (as they do with IPv4 prefixes today). Instead, IPv6 prefixes are acquired from specific ISPs or LIRs and represent a subset of their larger address allocation. Therefore, organizations will need to renumber their entire network when switching between ISPs. IPv6 does include features that make renumbering easier, but this results in an operational impact to organizations.

Renumbering can be made simpler by assigning multiple unique unicast addresses to each host interface during the transition period between ISPs, where both address spaces coexist within the organization. Additionally, the use of unique-local addressing (ULAs) within the organization can ensure internal communication is not disrupted during an ISP transition. However, IPv6 renumbering is still a major concern for medium-to-large size organizations.

Cheers,
Andrew


P.S. – Please follow or get involved in the discussion on IPv6 architecture, design, and implementation on Twitter with the #IPv6Mission hashtag.