On Merchant Silicon and Lawnmowing
Custom or Merchant Silicon?
Hello there!
I've been on a bit of a vacation the past couple of weeks, so sorry for the slow-down in posting frequency. But now, I am back at my desk, with a decent speed Internet connection, and too many ideas on what to write about.
---------
Chance had it that today a friend of mine sent me an email reminding me of a blog post I wrote about a year and a half ago titled - 'On Merchant Silicon and Mowing my Yard.' It was a piece, purposefully a bit inflammatory, designed to have a bit of a go at the guys who were drawing some interesting comparisons to product lines I worked on.
As often happens, times change.
Reading this email which spoon-fed my prior writings back to me, I had to reflect a bit. Does merchant silicon matter? Is it a sell out? What creates customer value in a networking product? Is it the silicon, the software, the system as a whole, how it operates with other adjacent products, etc...
Realistically, to me, what most people seem to care about in a switch is that it works, at the performance rates necessary, and that the software is stable and has the features they need to accomplish the networking task at hand.
Inside this system there is a collection of silicon, some of which may be custom, some which comes from vendors other than the systems manufacturer. The PHYs are almost always 3rd party, the CPUs as well, most every part is always 'merchant silicon' except the switch fabric and the packet processor. These are custom in some switches, or merchant in others depending on that specific vendors goals for that particular product.
Ethernet continues to evolves and offers lots of opportunities for innovation and improvement - some of these will require new silicon, some will require new software. Using merchant silicon sometimes will affect a vendors ability to control the pace and order they bring features to market that require new silicon. However, with the breadth of silicon available in the market today there are several viable silicon choices.
Custom chips create their own set of challenges - most vendors doing their own chips actually do their own logic and rely on a third party to actually build the chips and fab them out, deal with the process challenges, etc. The vendors doing full custom take on a high cost burden up front and hope they get enough market traction to enable future R&D in their ASIC teams. In this period of compressed budgets these programs tend to be one of the first things to get financial focus. What do you think- is one better than the other, or is a healthy mix appropriate for our maturing industry?
P.S. Oh, and I outsourced yard mowing... too time consuming and others did a better job than I ever could.
The Year of 10Gb Ethernet?
When will 10Gb become 'default' on servers and data center hosts?
Since 2002 I have been attending trade-shows like Interop and answering the same question, "Is this the year of 10Gb Ethernet?"
I never really understood the question, but after perennially trying to answer, and usually being inaccurate to what that individual questioner wanted to hear I started thinking about this a lot more, at least so I could have a reasonably rehearsed answer. Running into Bruce Tolley from SolarFlare today, who hosted the panel I was on for at least the last couple of years, reminded me that we are still not quite in 'the year of 10GbE' so I started wondering why, and when it would be.
What's it going to take? What will it take for 10GbE to take off on the same growth pace that GbE had?
In no particular order, I will start with density. When I was first asked this in 2002 there was a single-port 10Gb Ethernet module shipping in the Catalyst 6500 and a roadmap to deliver a four-port module the next year. Density matters, and how dense a network device is can allow different use-cases for the nascent technology. I remember making a PowerPoint slide once that said essentially the following:
Single Port- nice demo
Two Ports- very expensive, nice for metro connections and dark-fiber long hauls
Four Ports- useful in Distribution to Core switch interconnection
Eight Ports- starts aggregating access layer switches
Sixteen Ports- a good density of campus wiring closet aggregation
Twenty-Four Ports- high performance server aggregation
Forty-Eight Ports- server aggregation
Not surprisingly as silicon densities increase, port densities tend to increase and costs can come down through volumes, value engineering, and better utilization of common equipment.
Orthogonal Upgrades. Not all budget cycles align. Sometimes you get budget for a server refresh, other times you have have budget for physical plant upgrades, and on others you have some room for new network equipment. Most 10Gb implementations today require 'symmetric upgrades' i.e. you have to uplift the cabling, the servers, and the switches all at the same time in a coordinated manner. This is usually a pretty big inhibitor. You need to be able to add switches that support past, present, and future speeds, on top of existing cable plant, then allow the servers to upgrade when their budget cycle allows and computational/transport demands require it.
Price. Yes, it always matters and many times it all comes down to price. Let's set a magic mark of 10% and 3-4x depending on how you look at this. It strikes me that when the price of a complete system (servers, NICs, cabling, switching) at speed X*10 is only 10% more than speed X the market moves pretty quickly to connecting the hosts at X*10. The other way to look at it is that when X*10 is 3-4x the price of X in a myopic pricing arrangement the technology also tends to rapidly shift.
In many cases across most major vendors you can get two or all three of the above today. The outlier for data center host conversion and 'cross-over' from GbE to 10GbE is 'LAN on Main Board'. When all other factors align this tends to come out, and then the world changes and in the span of 12-24 months the new transport closes the gap and then starts passing its predecessor.
When do I think we will see the transition and cross-over (caveat- in the data center. I see no current trajectory towards demands for 10GbE to the desktop or phone in a campus. For all that video is the vaunted next wave of upgrades I can put several HDTV signals over 100Mb pretty effectively and it won't make a dent in GbE much less 10Gb to the desktop) I saw some data recently showing 100% growth in 10Gb to the server quarter over quarter, although largely driven by HP Blades with their virtual connect and flex-10 offerings. Given this trajectory and the desire for the server manufacturers to have a compelling value proposition against HP and Cisco's UCS I would imagine they are rapidly moving to offering 100/1G/10G LOM offers on their bladed and stand-alone server systems over the next twelve months. Then we finally, after seven years of speculation, can have a 'Year of 10Gb.'
Will Virtualization Commoditize the Network and Threaten Network Vendors
This is Greg, he likes DNS and DHCP, IP Address Management, Fine Scotches, and Infrastructure 2.0
Just a quick link and shout-out to Greg Ness of Infoblox and Twitter fame for a nice piece in SeekingAlpha that just hit here.
As I have said often enough to have been quoted and mis-quoted a few times there is a potential value-shift in enterprise IT given the increased business value many enterprises are realizing from virtualization which in some cases takes the network for granted or as one rather esteemed company once stated, "just dumb plumbing."
I don't want to be just a dumb plumber, and I think there are a set of very strategic activities the networking vendors can do to ensure that the network continues to deliver high-value and business-relevant services that enable the networking team within IT to keep their place in the pecking order.
dg
a smaller company, a big job, a great opportunity
Chief Development Officer and Chairman, Andy Bechtolsheim
As many people guessed on the poll that was ran in early July on NetworkWorld I could not relax for too long -- today I started my new job as the vice president of marketing at Arista Networks. In the spirit of any good marketing executive I prepared a bit of a messaging doc and FAQ sheet to help me out in case I get questions by industry press, friends, my favorite bloggers, or the legions of Twitter-bots that follow my life's twists and turns...
Who is Arista?
Arista Networks is an early-stage start-up in Silicon Valley, re-launched in 2008, that is building networking platforms that enable our customers to build network systems optimized for high-performance computing, virtualization, and cloud deployments. Arista has a seasoned executive team including many industry veterans and successful entrepreneurs.
Why did I go to Arista?
Candidly I was not looking to go to a start-up when I left Cisco. I was expecting to land at a mid-cap since my friends tell me I am a bit of a 'big company guy'. I also had many friends in venture capital tell me that if I wanted to go that route it would be best to do an operating role as a senior executive at a start-up. This caused a bit of a quandary- I looked at many opportunities and it was amazing that, as I hoped, even in this market and economy there was an amazing amount of opportunities available. When I looked at Arista I found a few things very intriguing:
1) I knew the executive team very well having worked with Andy and Jayshree for over ten years each, there was a comfort level there.
2) I usually can pick apart many networking start-ups architectures for making a series of 'rookie moves' that they later have to throw more money into fixing - I didn't find any of those at Arista.
3) I was very excited about the opportunity to build a software company that delivers the software through a network hardware platform - the core intelligence is the operating system.
4) I didn't see much, if any, VC investment in IT infrastructure companies yet every time Ethernet went through a major speed/function transition there were always 2-3 mid-cap companies created.
Ok, so Arista makes a switch? I don't think I would be happy at a company that just had one or two product lines. Arista has a solid vision for changing the way IT infrastructure addresses the new wave of IT architectures coming to the forefront today - But also remember the core value is the operating system, it is much more than just the hardware.
Ok, so what's the real story? Let me give an example, I met with Ken Duda who leads the software development team. I mentioned some features that focused on network and IT operations and would make life simpler for the network team, add value to the network, and enable the network to be far more 'real time' provisioned at scale. I have been a public proponent of this particular capability for the last eight years, but was never able to get it shipping. I saw a demo of it last week.
I like designing products, I like watching the things I work with customers and build to solve their problems ship and become a reality.
What did I learn at Cisco that will help me at Arista? I have to say the last three years at Cisco were a phenomenal learning experience and veritable PhD in Marketing with great teachers like Paul McNab (perseverence, and technical marketing/solutions development - importance of verticals), Alan Cohen (thought leadership) Peter Linkin (rational, believable, and most importantly understandable messaging), Tom Keenan (operational management at scale, how to hire people that complement you but never compliment you), Hoff (hiring people WAY smarter than you are), and Anne Plese (social media maven, scary good marketing execution).
What will I do at Arista? I am a little daunted by the scope of the role. Things that I used to manage cross-functionally and always have a ready opinion about I now have to either manage, or do. I think I will be learning a lot over the next few years. A few things I want to do though are build great products, and use every available marketing vehicle to ensure our customers have visibility to them and most importantly use them successfully in the right places. Short version, and to quote the inimitable Justin Timberlake, 'We're bringing sexy back' - to switching.
This will probably be the last post I put up here about Arista and my role there. I intend to keep this blog as neutral as possible and have it reflect my own opinion while respecting my position at my employer.
dg
The Network’s Role in Cloud Computing
It's all happy up in the cloud, right?
For networking companies cloud computing could be the biggest boon or the biggest bane, or as is sometimes quoted - the road to (shareholder) hell is paved with good intentions.
Network companies have been relatively and somewhat strangely quiet about cloud computing. Sure we've seen some partnerships, some demonstrations, and a lot of rhetoric- but there really hasn't been a lot of action. There certainly has not been purposeful, planned, development. One of the reasons may be the school of thought that the network is an inherent beneficiary of cloud computing - certainly anything that spits more bits out and drives larger pipes is a win for networking, right? The darker side is that at scale cloud computing represents a fundamental shift in the balance of purchasing power and a massive consolidation of computing, and thus purchasing capability into a smaller number of larger companies.
We've already heard about search companies building their own servers and even rumors of them building their own networking equipment. When you have that much domain expertise consolidated and there is that degree of specificity about the features and capabilities required saving capex while lowering the power consumption reducing your overall operating costs against one of your biggest expense line-items is worth it to large enough providers. Plus many of these providers know exactly what features they do and do not need - and there is variability between providers based on their respective philosophies about redundancy, fault tolerance, accounting, traffic engineering, etc. Is this model for everyone? Certainly not. But for those with enough chutzpah, mass and the technical wherewithal, it seems to be working.
Now fast forward seven to ten years. (like when Bill Gates once famously proselytized a vision based on unlimited bandwidth and limitless computing power - what would you do?) Imagine 50% of the world's compute capacity is owned by five companies. The purchasing power would be immense, the value to a vendor of winning the deal is a make/break proposition to many start-ups and even mid-caps. The ability to squeeze margin out of the vendors and define the exact requirements for what needed to be built, unparalleled. High margins? Doubtful.
Where would the network be? Let's see, certainly my 'glass half full' self sees that there would be a large WAN opportunity and Internet core upgrades required to support the increase in mobile workloads and mix of elastic and real-time network traffic. Ideally there would be a way of consistently signaling a particular packet's requirement for real-time, lossless, or an elastic traffic profile across multiple network providers with some guarantee they adhere to the marking. Although with net-neutrality I doubt this will ever happen in any end-to-end consistent manner and the owners of the end-stations and clouds will over-provision capacity and use clever over-the-top mechanisms to solve this issue further reducing the carrier's value.
The main change for the network will be static and physical definitions of service bound to location shifting to much more dynamic addressing
and embracing workload mobility. The network needs to be able to move workloads to run on the server and in the location that can service that workloads performance and processing requirement in the most effective and efficient way possible. This will enable and drive demand for follow-the-sun, follow-the-kilowatt, and follow-the-tax-code portability and mobility requirements. This is not just moving a workload around the data center, this could be moving it from one continent to another, and not a one-time move, but a dynamic and elastic environment where resources are constantly being re-balanced to achieve operational efficiencies, meet customer SLAs, scale to add new customers or divest customers quickly, and ensure security/segmentation where appropriate.
As I have said before today's networks are not ready for this. The static addressing model is broken, the routing protocols are not designed for the scale or the change-rate, and the need for abstraction and management is different than any networking vendor has embraced yet.
Let's assume that the technical hurdles get solved, that really smart people who solved the addressing problems for mobile phone systems, local number portability, and global roaming can use some of the same principles and solve the issues around globalization of IP addressing, /32 host route mobility, and really large scale routing tables. Let's focus on what makes a networking system "cloud-ready" that is a bit more complicated than even these rather sizable network and routing architecture challenges- Religion. Politics. Business. Control.
Here's the big 'gap' in everyone's story. Right now each vendor views their own system at the core of this cloud. It's all about the network, server, VM, SAN, etc depending whom you are talking to. Everyone wants to take their castle and put it on a cloud, without giving the keys to above-said-castle to anyone else. This means a strong desire in every major player to keep business as usual and extend the current value proposition and operational models to the cloud as best possible, see what sticks, adjust, go from there.
I believe, depending how 'evolved' the segment is, this could be a major failure if the core capabilities of the technology are not designed around the principles needed in cloud environments: elasticity, self-provisioning, open APIs, programmability, trust, control, interoperability, etc.
Where are networking vendors failing and flailing? Largely around the management and configuration interfaces to their systems -- The CLI is dead to the new world order. Take every feature in a network operating system and write down the ones you use. Put them on individual note-cards on a desk and then put the ones that are machine-readable, software controlled/instantiated, centrally provisioned, and globally scalable in a box we call 'Cloud Ready' and put everything else in the 'Old World' box. If the Cloud Ready box is pretty empty, that vendor will be left with one thing to differentiate - PRICE.
Everything in the networking world is instantiated by a CLI. Every cloud operator I know wants a machine readable interface, they want their devices to plug into a common management framework, they want a single point of administration and control. For some this is home-grown, for some this will be VMware's vSphere, for others it may be another offering. This 'Cloud OS' does job macro-scheduling, enforces work flows, and provides elastic scaling and depends on machine readable interfaces into switches, routers, firewalls, servers, storage, and so on. It also will depend on consistency between managed devices - i.e. if stuff doesn't work identically between products the outliers are not likely to be adopted.
Many vendors are reticent to give their 'keys' to someone else's Cloud OS - i.e. if it can't be their own, they don't want to open the system up, to the operator this means now having to install multiple management systems when what they really want is one that can work with multiple vendors. The message I heard one cloud operator tell me was, "Be Open or Die."
Make the shift to building planned systems architectures, and intelligently using networking protocols to provide a consistent abstraction to a cloud OS, there is a chance to win big. Miss it, build fragmented systems with no management abstraction or not tie into the right eco-system of partners and risk rapid commoditization as the core value of your product can actually never be expressed to a customer/operator in a way they could use it. Unused features is simply higher cost with no incremental value.
America’s Data Center Top 40 for QoS Implementations
a rainbow of fruit flavors for the network
Do you really use network quality of service within the glass house data center? This is a question I have been pondering pretty much all day- I get that on the costly WAN links we almost all use it. I also completely acknowledge that most engineers plan to use some of the QoS features within the data center, but what do we really use? Which features are necessary and which are just... well... extraneous?
Here's my thought- I think there are some QoS 'hit songs' implemented in the data center, and some that just are not that appropriate for this iMix.
Bad Boy Bad Boy, whatcha gonna queue....
No matter how many security products we surround ourselves with we all have the 'time out queue' for traffic that just isn't, well, good. It's for those pesky control plane DoS attacks, the misbehaving broadcast storm NIC, or that one application that just won't shut up.
Voices Carry
For some reason I have the 80's Til Tuesday song in my head by the same name- but most engineers I have talked with seem to set up, by default, a strict priority queue for voice traffic, then never,ever touch it again because it just works.
Marky Mark and the Funky Bunch
We all use markers, especially at the edge where we can have maximum visibility to what comes from a single host, and mark it up appropriately so that we don't have to continuously re-inspect and re-apply policy everywhere. Tag at the edge, queue in the core, shape on the WAN or point of massive congestion/cost.
(Don't) Drop it like it's Hot
No matter what religious SCSI encapsulation you love- FibreChannel, FibreChannel over Ethernet, iSCSI or even file based alternatives such as NFS or CIFS storage just performs better when is is not dropped. As much as I love technologies like Aspera for moving large files from A-to-B, until it is integrated in my host stack (which would monumentally rock for copying my iTunes library to S3 btw, hint...) the world will be dependent on TCP-guaranteed or PFC/BCN guaranteed storage delivery for a while - so we need a "lossless don't-drop-me-please" queue.
Shape ya Tailfeather
As we hit congestion and contention for bandwidth in a well designed data center this happens at the cost-center link, i.e. the edge router: this is where I apply large buffers, shapers, and policers to ensure that traffic can en-queue long enough to get onto the link, we can also adhere to Peter Lothberg's long-time rule of providing enough buffer to handle a round-trip-response of around the world or ~300ms. Shaping the previously marked-up traffic onto the link while trying to get all the right traffic on the link is the job of the core routers, usually not fixed switches.
That's it for now, any songs I should also think about including into the Data Center QoS Playlist?
dg
Tagging Redux – Curse of the Bifurcated Standards Bodies
Moooo-re Siloes Please!
I have received a few private comments that I was unduly critical of tagging mechanisms in my recent post about the VN-Tag/VN-Link debate between Cisco and HP. I don't have a problem with tagging mechanisms, in fact I am a fan of them - however, I have an issue with too many tagging mechanisms. There ends up being a tag for about everything - we have Security Group Tags, MPLS Tags, VLAN Tags, QoS Tags at L2 and separate ones at L3, we also now have tags that identify the Virtual Machine or the NIC on the Virtual Machine so we can create new NICs in software.
Let's just own up to it for a second that there are way too many tags; however, the problem is not always the industry and companies that want to create a new tag. Now before I go offering a solution that is highly likely to not be flame-retardant let me get on my proverbial soapbox for a second, so bear with me...
I think a root cause problem is that there is a schism in the relevant standards bodies. I have to go to one standards group for Ethernet (IEEE), another to work at the IP layers (IETF), yet a third if I want to carry storage traffic (ANSI T.11) - and this is the tip of the iceberg. It is hard enough to shepherd a great idea through the bureaucratic morass that are created anytime you put that many strongly opinionated, diametrically opposed, and discretely compensated individuals on a board/council/committee and try to get them working together but now with things getting 'blurry' between the once rigid lines between siloed standards bodies it is near impossible.
So while I often catch the brunt of 'why isn't this done in the standards bodies' question and have fielded it for years I don't think we have done a fair job of analyzing how efficient the standards bodies are and whether they should look at reorganizing around how their customers use the technologies they ratify. The world is changing from 20 years ago - are the standards bodies changing with it? Are they part of the legacy of siloed information technology that needs to change with the new world order where lines are crossed, borders are blurred, and service is more important than boxes?
As far as how to solve this embedded multi-vectored tagging problem I don't think there is one 'right' answer. But one thing I always with was available was a single extensible tagging structure, that could be layered/embedded, that could be re-purposed for different functions and the first few bits (say 8 or so) delimited what 'kind' of tag it is (QoS, App Descriptor, Segmentation, Forwarding, Cloud Storage Access Rights, etc), and the next 16-24 bits were used to delimit something relevant within that kind of tag. Done in an extensible fashion we could keep the extended header short of 128-256 bits which would mean it could pretty easily be parsed with one of the more advanced stream processing methods on the market.
One standard to rule them all, one to bind them...
Yes, it is sort of 'too simple' and is probable a bit like Dark Lord Sauron forging the 'One Ring to Rule them All, One Ring to Bind Them' (and the fact that I am doing that from memory should be a strong signal that I missed ComicCon) but a tagging construct that 'crossed party lines' between IEEE, IETF, ANSI, ISO, W3C, etc could be quite interesting. It's a shame there is not standards body to run it through....
dg
HP versus Cisco: to tag VM’s or not to tag VM’s
Tag, you're it!
Recently there has been some eloquent flaming back and forth between Cisco and HP over the VN-Tag, of course I have an opinion and figured I would vocalize it. Scott Lowe has a good piece on this as well, focused more broadly on the implications to the unified computing system.
First off, I do not think there is a lot of innovation that comes directly out of the standards bodies. However, i firmly believe that in today's mature networking market in order for a technology to get a decent traction and following it must at least be inserted into the standards process and be on a trajectory towards being multi-vendor and open/interoperable.
Secondly, I believe that innovation should be rewarded. "To the innovator go the spoils" I say. Innovation is risky, there should be a bit of light at the end of the tunnel. I am not-so-subtly reminded of a conversation with about 20 customers I led a few months back. I was getting a lot of pressure from a university customer to stop any development on anything that was not an industry standard- the gentleman from a large manufacturing company interrupted him and said, "I don't care what standard they support, as long as they solve business problems for me I will vote with my wallet. My CIO doesn't care if its PAGP or LACP, he cares that the network runs."
Lastly, and somewhat controversially, I think there are enough tagging formats out there already, and worse: most of them have no interoperability plan or architectural tie-in with each other.
Let's look at VN-Tag with these three lenses now....
1) VN-Tag was jointly developed by Cisco and VMWare to address a problem their customers were having: they could not bind a policy to a VM and have that policy move with the VM in a DRS or VMotion environment. They also felt that traffic could go from one VM to another, bypassing any network policy for governance or regulatory compliance and thus have a tail-end/hop-off type of attack possibility for VMs on the same physical host.
2) It was submitted to the IEEE, but is not a standard yet, thus to be binary it is 'proprietary' although it seems the companies are not holding onto the IP specifically, they just want to execute on a time-to-market advantage. (this is no worse and the ongoing CEE vs. DCE debate (note: there both are proprietary... DCB is the IEEE standard))
3) It is 'yet another' tagging format. If you trust that MAC addresses will not change dynamically the same problem-set could have been solved by binding network policy to the MAC address of a host.
Was VN-Tag necessary? maybe...maybe not. Personally, I think many of the same problems could have been solved if the MAC address was used to instantiate policy. There is a legitimate concern that the MAC address could be spoofed, but then again so could a multi-byte tag structure too unless it has signing/authentication/etc.
Is it proprietary? Yes. Although all indications are Cisco and VMWare are working to shape an industry 'de jure' standard and are trying to gain a time to market advantage over merchant silicon based players. (I would argue that innovation should be rewarded so a time to market advantage in silicon is not out of the question and probably shouldn't be demonized).
Is it well implemented? Here is the rub of the whole thing. Implemented broadly this is a promising capability for a network to have. VM's are, after all, the building block of many leading edge new data centers. However, VN-Tagging does not seem to be broadly embraced across the portfolio of products in the data center. At least I can see no indications of shipping products or announcements of how this capability is going to be brought into the security products, application networking products, routing products, rest of the Nexus line, etc. Broadly implemented in a coordinated fashion- this would be a powerful capability. Sporadically implemented in one or two products will lead to little impact.
This will probably get flamed a bit, so am finding the nearest asbestos store...dg
Personal, Business, and Government Travel
a view the tax receiver rarely sees
I read an interesting article last night on Cisco System's travel policies. Having lived through this change at first I thought it a bit onerous, but the savings were marked and it quickly reduced the T&E component of my departmental budget freeing up funds for other, more compelling activities.
Companies like Cisco are pretty smart about travel policy- they try to book every ticket through one travel agent, and that travel agent uses one central credit card for all billing of air-travel. They strongly recommend a 14 to 21-day advance purchase for the ticket and anything less than that takes pretty senior approval. We were also requiring that the ticket purchased be non-refundable because the change fees (varying between $75 and $150) were much less than the price of a full-fare refundable ticket.
For our government officials and workers though life is quite different. Many times over the past years I have been on trips where the government employee I am talking to in the gate area lines up and flies business class while I am not-so-comfortably ensconced in coach. Like the next guy I am all for using points, miles, and about anything possible to get upgraded to the more humane seat widths and leg space that is available in business or even better the lie-flat seat/sofas offered to the elite in first class.
While the taxpayer is flying in coach, the bourgeois US government staffers, politicians, appointees, and rank and file can often travel in much better accommodations. In principle alone this is somewhat wrong, but the ways the government employees get their business class fares is even worse than that - they purchase full-fare refundable coach tickets, the kind that are almost always automatically upgraded to business class by the airlines. On a recent trip this was the difference between $800 for my ticket versus $5500 for the refundable upgraded fare. Our tax dollars at work.
I've seen several airlines extend policies to their corporate partners that gave automatic business class upgrades to full-fare paying coach ticketed executives. What happened was the execs always tried to get the last-minute full-fare tickets, thus policies like Cisco's trying to head that off at the pass because the airlines were dangling incentives that encouraged frivolous spending.
Our government should do the following: 1) Centralize all government travel under one contract. 2) require lowest priced airfare be purchased and a 14-21 day advance ticket be required without senior approval. 3) Publish a list of all elected official and appointed official travel and costs in arrears as well, if not classified, the purpose of the trip. 4) under no circumstances should a public official be flying in business or first class unless they personally pay for it with cash, miles, or some personally earned upgrade plan.
EDIT - just a few days after I initially wrote this Congress decided that flying in full-fare coach wasn't enough of a burden on the tax-payer, but they needed several Boeing Business Jets, and a handful of Gulfstream G5s. For those of you unfamiliar with the Gulfstream G5 it is a favorite subject of rap musicians and I think Roger Federer uses one too. But hey, nothing's too good for our representatives.
dg
Networking and Operations Focus
Again, suitably sub-titled, "things I'd like to change 3/N."
the day Altiris was installed... (client retrospective)
When networking was in its hey-day growth phase in the mid-late 1990's through the dot-com crash of 2001 we were a nerdy group of people. We didn't have to worry about change control when the systems were not mission critical, we could use the classic "I tripped over the power cord" emergency change-control procedure. The advanced and automated ticketing systems were not in place, there was only one enable password, and we router jocks loved the fact that we were our own masters of the universe.
The features developed, delivered, and sold by the networking vendors catered to us, the operators, admin, engineers, etc. Think about them- the features we all remember and still tend to use were designed to make our jobs easier, not harder. Features like EtherChannel, speed/duplex auto-negotiation (although for many vendors that was a big #fail), IGRP/EIGRP (turn it on, it just works, for three desktop protocols, on one process!), VTP - okay, we all remember the VTP Bomb, but the concept of auto-propagation of VLAN ID and auto-pruning of unnecessary VLANs was nice although the initial implementation was rather like a liquid-center flourless chocolate cake.
What happened?
Why, since 2001 and the dot-com bust have networking vendors stepped away from supporting and embracing the loyal network operators and delivering features and capabilities that make their jobs easier and simpler and instead seem to focus on things that in many cases make the job harder. I mean, how many encapsulation types do I need? How many differing non-interoperable segmentation mechanisms? How many security tags/constructs/products with little integration? How many differing UIs and code-trains?
I like building things that make peoples jobs easier. It's a personal passion of mine, because they tend to get used and deployed, and heck- they make people happy! (as I write this 'Sweet Child o' Mine' comes on the overhead speakers and I have to pause a minute during one of the most memorable guitar solos ever...) ok, back on track... umm, where was I?
Oh yeah- features that make network operators lives easier?
One I always wanted to do was a global port profile. Basically an object oriented port based configuration that is synced across a reasonably sized autonomous system of network devices. Then I can make changes to the port object and have it sweep across the switches and be swiftly implemented. All the ports map to the object, the object is the point of change. This gets very interesting when it is integrated between physical and virtual devices so that I can have a policy that moves as I execute a P2V operation and maintains consistency regardless of where the workload runs.
Just a thought. I am sure there are more... any other things you wish your network did? (I also wish there were native Opsware agents on my network devices... for more food for thought...)
dg
interaction
- Carrie on Interop 2010
- Chalon on Interop 2010
- nohype on Interop 2010
- SFoskett on Interop 2010
- Danny on Validating Some Power/Cooling Cost Assertions
texthibition
- @cxi let me know how Chicago goes, I have some new VM stuff would love to present up there if they have a good group! in reply to cxi 1 day ago
- pulling together another cool product/sw launch - been working on this one for last year. Excited... 6 days ago
- @vTrooper @vTrooper I need a few linecards in there too :) in reply to vTrooper 1 week ago
- @theosison Yes, Arista Networks :) in reply to theosison 1 week ago
- RT @yogeshmalik: SUN, CISCO and GOOGLE guys company Arista Networks show chassis switch, running 10,000 servers for $140k http://ht.ly/2em1s 1 week ago
- More updates...
Posting tweet...
coffee fund
default gateway
- A bet on BBCs and VM Mobility July 26, 2010
- Innovations - something I love in networking... July 21, 2010
- Why Data Centers Must Fundamentally Change -- Part 2.2 May 18, 2010
- Why Data Centers Must Fundamentally Change -- Part 2.1 May 17, 2010
- Why Data Center Networks Must Fundamentally Change May 10, 2010