Why FCoE Standards Matter

Mike Fratto at Network Computing recently wrote an article titled ‘FCoE: Standards Don’t Matter; Vendor Choice Does’ (http://www.networkcomputing.com/storage-networking-management/231002706.)

I definitely differ from Mike’s opinion on the subject.  While I’m no fan of the process of making standards (puts sausage making to shame), or the idea of slowing progress to wait on standards, I do feel they are an absolutely necessary part of FCoE’s future.  It’s all about the timing at which we expect them, the way in which they’re written, and most importantly the way in which they’re adhered to.

Mike bases his opinion on Fibre Channel history and accurately describes the strangle hold the storage vendors have had on the customer.  The vendor’s Hardware Compatibility List (HCL) dictates which vendor you could connect to, and which model and which firmware you can use.  Slip off the list and you lose support.  This means that in the FC world customers typically went with the Storage Area Network (SAN) their VAR or storage vendor recommended, and stuck with it.  While not ideal this worked fine in the small network environment of SAN with the specialized and dedicated purpose of delivering block data from array to server.  These extreme restrictions based on storage vendors and protocol compatibility will not fly as we converge networks.

As worried as storage/SAN admins may be about moving their block data onto Ethernet networks, the traditional network admins may be more worried because of the interoperability concept.  For years network admins have been able to intermix disparate vendors technology to build the networks that they desired, best-of-breed or not.  A load-balancer here, firewall there, data center switch here and presto everything works.  They may have had to sacrifice some features (proprietary value add-that isn’t compatible) but they could safely connect the devices.  More importantly they didn’t have to answer to an HCL dictated by some end-point (storage disk) or another on their network.

For converged networking to work, this freedom must remain.  Adding FCoE to consolidate infrastructure cannot lock network admins into storage HCLs and extreme hardware incompatibility.  This means that the standards must exist, be agreed upon, be specific enough, and be adhered to.  While Mike is correct, you probably won’t want to build multi-vendor networks day one, you will want to have the opportunity to incorporate other services, and products, migrate from one vendor to another, etc.  You’ll want an interoperable standard that allows you to buy 3rd party FCoE appliances for things like de-duplication, compression, encryption or whatever you may need down the road.  We’re not talking about building an Ethernet network dedicated to FCoE, we’re talking about building one network to rule them all (hopefully we never have to take it to Mordor and toss it into molten lava.)  To run one network we need the standards and compatibility that provide us flexibility.

There is no reason for storage vendors to hold the keys to what you can deploy any longer.  Hardware is stable, and if standards are in place the network will properly transport the blocks.  Customers and resellers shouldn’t accept lock in and HCL dictation just because that has been the status quo.  We’re moving the technology forward move your thinking forward.  The issue in the past has been the looseness with which IEEE FCBB-5 is written on some aspects since it’s inception.  This leaves room for interpretation which is where interoperability issues arise between vendors who are both ‘standards based.’  The onus is on us as customers, resellers and an IT community to demand that the standards be well defined, and that the vendors adhere to them in an interoperable fashion. 

Do not accept incompatibility and lack of interoperability in your FCoE switching just because we made the mistake of allowing that to happen with pure FC SANs.  Next time your storage vendor wants a few hundred thousand for your next disk array tell them it isn’t happening unless you can plug it into any standards compliant network without fear of their HCL and loss of support.

GD Star Rating
loading...
Why FCoE Standards Matter, 5.0 out of 5 based on 4 ratings

Comments

  1. What BS is this. Check with Cisco if they support connecting a Juniper switch in their network whilst maintaining end-to-end support with functionality as documented by both vendors.

    Furthermore network people have a horizontal view which basically means they receive a packet on one side and ship it to the receiver side without caring what it actually is. The rely 100% on upper level protocols like TCP to fix all garbage that has happened underway. When you do this with channel protocols like SCSI and Ficon you’re very sure you gonna have issues. When a user has to click again to retrieve some information this is annoying at most. When your database is screwed because your network is misbehaving all hell breaks loose.

    Example from a very recent problem I encountered:

    Mainframe connectivity to a remote storage box over multiple ISL links. No problem from a storage side when dark fiber was used. Customer implemented DWDM with TDM multiplexers without telling or notifying the storage or Mainframe people and all hell broke loose. Why, ficon want to have in order delivery and this was correctly configured on the storage switches, the moment TDM got involved it really screwed up things since frames from multiple channels got funneled into a single link in a way the TDM box seemed fit.
    Data got corrupted and took many days to figure out what happened. Even after being asked twice the network guys came back with the answer that the DWDM was configured in a passive way on these channels. After verifying the third time somebodies light-bulb went on and told us that there had been some modifications indeed.

    The same thing will happen in an FCoE environment. Storage people need an end-to-end view from application to the spindle hence they also manage the FC connectivity.

    FCoE should never have been invented. Standards or not. See my blog for all the reasons.

    GD Star Rating
    loading...
    • Erwin,

      Thanks for reading and taking the time to reply! Let’s start by breaking this down into a couple of chunks. First let’s get FICON off the table, FICON is a tircky beast on FC networks and nobody (to my knowledge) is talking about putting it on FCoE yet. Second dragging out-of-order frames on CWDM/DWDM links into the discussion isn’t applicable to FCoE, FCoE will have the same SAN extension pros and cons as FC as it will use the same concepts, when you’re storage hits the WAN your need adminsitrative design coordination. Interestingly Cisco’s MDS product line, and the Nexus FCoE product line will deliver all frames in-order by default without configuration based on FSPF routing (flow or node based) so FICON requirements would be met in that regard, although several other factors would have to be handled as well.

      The same concept will not apply in an FCoE environment because we are not relying on any upper layer flow control or routing protocols. The FCF (FCoE switches) utilize FSPF routing the same as FC switches, ensuring in-order delivery. The DCB PFC function ensures that delivery is lossless, voila we have FC like behavoir on a 10GE link with higher throughput due to protocol effeciency.

      I’ve looked through your blogs against FCoE and I think you need to check our market share numbers and protocol compatibility statements, especially where discussing 1GE and 10GE compatibility.

      Thanks for reading,

      Joe

      GD Star Rating
      loading...
      • Hi Joe,

        Thanks for taking the time to reply. The thing is that I’m not opposing FCoE from a technical perspective. I’m sure it all works during plugfests, vendor bootcamps and what have ya.

        They overall problem is that the storage industry is over-complicating things by stacking protocols upon protocols and different vendors having different interpretations of “standards”. In production environments this will inevitably lead to a significant increase in complication which, in troubleshooting situations, lead to elongated resolution times. I’ve made it clear, I hope, that from a storage perspective, administrators need to have a vertical view from application to spindle in order to guarantee performance, integrity and availability along with a whole range of other datamanagement issues.

        Secondly interoperability is a total no-go. Today we have two vendors with such significant marketshare that more or less renders others non-important. (I may have had my figures wrong but I had some old sources) In essence outside the standards bodies these two companies don’t talk to each other, they beat each other to death in marketing and sales and have a real hard issue when it comes to support when both of them are involved.

        My example of IOD over CWDM/DWDM was just to hint what will happen in an FCoE network. At some point in time a customer will have a significant issue when these two technologies are implemented.

        I work in support and see customer issues every day. Many of the customers have a real issue with operational management like keeping their environment up-2-date, and actually have some insight how their environment looks like. (Again some customers are really smart and have a good grip on this but many haven’t). Introducing a beast like FCoE will increase complexity to such an extent that major outages will become the norm. My question is how much time will support organizations get to solve a certain problem when interoperability, conflicting support matrices and two differently aligned organisations (network vs. storage) etc are existing. This is even true in a bare-bone FC environment let alone when you combine the two.

        Your remark on protocol efficiency hits no mark. Physical networking equipment on ISO0 and FC-PH layers grow towards each other as well as one or two layers up (encoding/decoding is the same, frame crc etc. )

        Anyway, fun part of this is that many people agree and disagree with me so I’ll just keep on preaching to avoid FCoE. :-)

        Cheers
        Erwin

        GD Star Rating
        loading...
  2. Joe,
    Standards and interoperability are not the same thing. FC has standards, but there was a lack of commitment from the vendors (even before Cisco was in the picture) for much interoperability. I’m having a hard time seeing the point of your article – FCoE puts FC into L2 Ethernet which will not disrupt existing solutions that work on Ethernet. We’re not looking to put all traffic over FCoE, simply FCoE traffic must coexist with other traffic (hence DCB). The standards are necessary, and in the early days, we need FCoE to FC interoperability (which we have across multiple vendors), not FCoE FCF to FCoE FCF.
    Cheers,
    Stu

    GD Star Rating
    loading...
    • Stu,

      The point of the article is that interoperability matters and the standards are the basis for how that happens. While FC can be ‘interoperable’ it doesn’t typically work well that way. Vendor support, feature, functionality etc. become problems. Allowing that to carry into FCoE is a mistake, and taking the ‘It doesn’t matter my storage vendor will tell me what to do’ attitude is ludicrous. I understand we’re not putting everything in FCoE, and that FCoE can ride side by side happily with typical Ethernet data, but what we don’t want to end up with is data center networking choices dictated by our storage vendors, and I see standards as a means to prevent that.

      Joe

      GD Star Rating
      loading...
      • Good response Joe – the silos need to be broken so that storage and network can work together to make sure to have a good environment for all. For virtual environments, it’s the personnel as much as technology that determines if NFS, iSCSI, FC or FCoE make sense.

        GD Star Rating
        loading...
        • I agree that FCoE is an extension of Ethernet that is aiming to deliver the same functionality/guarantees that are supplied by FC. FCoE should coexist with all the other Ethernet traffic types (LAN, iSCSI, NFS etc.).
          However it is very clear that all vendors have their own set of implementation details/restrictions that clearly makes them NOT interoperable – just look at the debate of multihop FCoE and TRILL between Brocade and Cisco and you will see how opinions and implementations differ.

          The idea that vendors are not holding the key to what you deploy is a nice target, but somehow I doubt we are on our way there.
          Amnon

          GD Star Rating
          loading...
          • Amnon,

            I agree that it’s a lot to ask for true interoperability but it will be a requirement moving forward. Additionally we need to be careful to seperate out standards and protocols not required for FCoE such as TRILL and QCN.

            Joe

            GD Star Rating
            loading...
            • Chris Young says:

              Hey Joe,

              You had me until you said that QCN has nothing to do with FCoE. :)

              I agree with you on TRILL not necessarily been related, but I believe that QCN will be a critical ingredient in DCB which will allow FCoE or any other lossless protocol to be implemented.

              GD Star Rating
              loading...
  3. Moving day can feel more like chaos than order, especially when there
    are half a dozen movers running around your home, packing up your belongings, and carrying
    out your furniture. Just keep your eyes and ears open because
    you never know when the right transport company will show up.
    If you do not seal your items effectively then there is a prospect of breakage.

    GD Star Rating
    loading...
  4. -The test was done incorrectly for example perhaps the test was not
    saturated entirely in urine.    Once you are on the calorie restricted diet and when the
    body demands energy, the HCG hormone will ensure that that
    energy is released from the stored fats and not from your lean muscle mass.
    A typical HCG program involves combining a low calorie diet and HCG usage.

    GD Star Rating
    loading...
  5. Estimating the price of a kitchen improvement project will also involve negotiations using
    the skilled workers. Will any walls, especially load bearing walls, have to be knocked down.
    If the cost estimates are too low, the project will go over budget –
    sometimes significantly so.

    GD Star Rating
    loading...
  6. All you have to do is transport the items from point A to point B.
    But also, the comments have affirmed that many are where I
    was before; in a place where they are putting on the
    happy face and hiding their fears from those around them.

    The expense apart from covering the vehicle also involves in spending
    for the moving boxes.

    GD Star Rating
    loading...
  7. They break down fats easily and do not allow them to accumulate.
    The supplement actively makes the proper utilization of nutrients
    in the body and makes it more healthy and flexible.

    As far as results go in week 3, my body still gets sore
    in target areas.

    GD Star Rating
    loading...

Trackbacks

  1. [...] Channel over Ethernet (FCoE). There are a number of ongoing discussions on how the FCoE standards do and do not matter. I would edge on the side of them not mattering in terms of one vendor selection [...]

Speak Your Mind

*