The tunneling Kool-Aid

In a comment to my Data Center Interconnect article my friend Ronald (who once certified me as a Bovine Professional) wrote:

I don't drink this Cisco Kool Aid about interconnecting data centres using an IP backbone. Rather use FC directly over DWDM instead of FCIP on MPLS.

This time I could agree with him wholeheartedly ... assuming you already have DWDM gear (or infinite budget to buy some) and you can get dark fiber when and where you need it. Unfortunately not everyone is so lucky and/or rich, so we have to compromise.

His comment also reminded me of the comments I’ve heard from SNA gurus more than 15 years ago when Cisco introduced SDLC-over-IP and later LLC2-over-IP tunneling. We’ve spent years trying to persuade them to drink the DLSw Kool-Aid … and in the end they all gave up their precious SDLC leased lines and Front-End Processors as the market realities forced them to consolidate their infrastructure and migrate to routed networks. Not to mention that most of the gear they supported (including ATM machines) got replaced by newer models supporting IP (or even having IP as the only connectivity option).

A similar story played out in the Service Provider world, where the idea of offering Frame Relay or ATM service on top of an IP backbone was a heresy … until it became cheaper to migrate the legacy services to a router-based network than to pay the maintenance fees for the Frame Relay gear.

Moral of the story: whenever you propose to tunnel a well-established protocol using a new entrant in a particular technology area, people will tell you that it’s all a marketing plot and that they prefer to stick with the tested scenario … until the business pressures force them to change their mind. The tricky part is figuring out the right time to jump: if you’re too early, you could get burnt; if you’re too late, you might have lost a fortune.

Last but not least, don’t forget that not all tunneling scenarios were worth pursuing: IP-over-APPN never really took hold.

7 comments:

  1. It's worth considering that FC is what I would consider to be a stateful protocol. We have had many stateful protocols over the years such as RSVP, ATM, Frame Relay, RTSP Streaming, SNA, Time Division Multiplexing, Telephony etc etc, the list goes on and on.

    All stateful protocols have failed comprehensively and never last more than a few years after an alternative exists.

    On this basis, FC is a 'dead man walking'. FCoE is merely a migration technology for what is overpriced 'storage technology' that hasn't been fully depreciated. Yet.

    ReplyDelete
  2. I don't think it is appropriate to extrapolate the SNA experience to storage. Storage is no green screen.

    This not withstanding, IP is not destined to be an I/O bus technology. Is the hypothesis here that you'll attach your IP hard disk with a CAT5 cable to your IP hard disk controller on your server?

    ReplyDelete
  3. Ronald: I do this every time I connect iSCSI storage with iSCSI HBA inside server. It works. And it's nice. :)

    ReplyDelete
  4. Ivan: Landon Dyer (Atari then Commodore veteran) wrote this about your ATM/FEP/SDLC guy:

    Lucifer: “Listen up! (…) Money lenders and financial industry employees, you’re in the ‘Taco Bell’ line for the rest of eternity; pray you don’t reach the counter. (…)
    http://www.dadhacker.com/blog/?p=1115

    ReplyDelete
  5. and the bus connecting your disks inside your iSCSI storage is FC.

    ReplyDelete
  6. ... which is where it was designed to be used ... and then someone decided it's a good idea to pull it out of the box :-P

    ReplyDelete
  7. I guess it helps the "converged" networking salespeople to try to perpetuate "DWDM is prohibitively expensive".
    If you have access to "dark" (i.e. you light it) fiber leased or self owned then DWDM gear is affordable (e.g. MRV www.mrv.com). It is an enabler. You can hang on to your FC investment. You can mux analog video over it. You can provision any type of service for which there is a DWDM service card or device available.
    A passive MUX / DEMUX does not care what gear is connected to it, it only cares that it is the right lambda.

    ReplyDelete

You don't have to log in to post a comment, but please do provide your real name/URL. Anonymous comments might get deleted.

Ivan Pepelnjak, CCIE#1354, is the chief technology advisor for NIL Data Communications. He has been designing and implementing large-scale data communications networks as well as teaching and writing books about advanced technologies since 1990. See his full profile, contact him or follow @ioshints on Twitter.