Sign in / up

back to article The DCB world is not enough

As Fibre Channel (FC) SAN storage gets emulated on Ethernet as FCoE, it's becoming clear that enhanced Ethernet is not enough; we need TRILL as well before full FCoE becomes a reality. To make FCoE (Fibre Channel over Ethernet) practicable we need FC-using applications on servers and FC-accessed storage arrays to believe they …

COMMENTS

House rules Send corrections
This topic is closed for new posts.
  1. Chris Mellor 1

    A Cisco view

    This was sent to me by a Cisco employee:-

    Chris,

    This article is not accurate on a number of fronts. TRILL is not needed for FCoE. the reason is simple: Spanning Tree (STP) is NOT used for FCoE. at all, ever.

    Storage (FC) traffic (aka a VSAN) is mapped to a VLAN in the ethernet world (FCoE). VLAN(s) used for FCoE don't run STP at all. The FCoE switches themselves run a FC stack - just as they would if they were a FC switch - so provide all the typical FC services such as domain controller, FLOGI server, FC Nameserver etc. Among the things they run is FSPF - just as they would in a FC world - which provides the 'routing' topology for FC and any FCoE hops.

    IEEE DCB switches which provide both LAN (Ethernet) and SAN (FCoE) transport will typically run STP (or Cisco FabricPath or whatever) on 'LAN' VLANs, and FSPF on 'SAN' VLANs.

    Certainly there are possible advantages to running something 'newer' than Spanning Tree with blocked links - and this is what one can do in an evolutionary way today (e.g. Cisco virtual Port Channel aka vPC) and in a revolutionary manner in future (and this is the intent of what Cisco FabricPath is today and TRILL/Rbridges will be in future.)

    But to say "you can't do FCoE without TRILL" is wrong. To say that 'storage people need to know ethernet' is equally wrong as all that has actually changed is that the frame format is FCoE, but the storage protocols and concepts are identical to what they are today (E_Ports, ISLs, zoning, NPV etc)

    -----------------

    Chris.

    0 0
    1. Simon Parry
      Reply Icon

      A wider view

      Hi Chris,

      It is not true to say that TRILL is the only STP replacement out there. You also need to look at SPB (IEEE 802.1aq) which is already shipping on Extreme and Avaya switches. Although TRILL and SPB are similar in a number of respects, the important difference is that SPB uses vanilla Ethernet frames, whereas the TRILL frames are not Ethernet.

      It is nice to see that Cisco is pushing the vPC/VSS messgae, after a decade of trashing the idea when Nortel/Bay proposed it.

      0 0
      1. Chris Mellor 1
        Reply Icon

        Trilling about TRILL

        Brocade and NetApp mention TRILL a lot. Cisco mentions it in passing as it were. The three haven't mentioned SPB. I'll check it out.

        0 0
  2. Trevor_Pott Gold badge
    Unhappy

    Divergence

    A decade or more from now, we might see one standard for layer 2 automatic multi-link aggregation and pathing. Currently there are a few competing potential approaches, all backed by different consortiums. Each will of course big up their own preferred approach whilst paying lip service to the other "standards." They will probably not interoperate properly (in order to be able to tell your customers that it is your competitor's fault, and you really should just have bought all your gear from one vendor.)

    Everyone will ooo and ahh about what is achievable in a lab environment with perfect vendor technology. Meanwhile, because noone can agree on a standard, multi-vendor networks will have workarounds for the problem that become standard practice yet go against the holy grail of vendor certification best practice training manuals. In the real world, where people don’t have the money to buy everything constantly from one (exceptionally expensive) vendor, networks will get more and more congested.

    Storage folks will butt heads with network folks; the storage folks making “unreasonable demands” for things like low latency, ever increasing bandwidth and topologies that go against The Holy Grail. Network folks will continue to prance about arrogantly believing that storage folks are completely unnecessary.

    As with all standards and practice wars based on trying to artificially create and maintain a competitive advantage in a market that is rapidly becoming commoditised, someone will come out of nowhere and offer gear that does it all for dirt cheap, reliably, efficiently and properly obeys all available standards. The extant goliaths will flail about for a while, gnashing their teeth and trying to squash the impudent wretch.

    If they survive these first tenuous years, their business practices of listening to their customers and then offering what is asked without crippling interoperability or compliance with standards will force the various goliaths to play along and we will all get FCoE that works beautifully. Just in time for it to be completely irrelevant as someone invents a new way to move data around.

    The same story is told over and over, from FCoE to Wifi, HTML5 to LDAP. I’m sorry if this comment sounds bitter…but I’ve had a bellyful of “this cool new standard/technology/whatever will solve all your problems!” Either the Neat New Thing is bought and buried, sabotaged before the standard can be ratified, or there are so many conflicting implementations as to be functionally useless. Technology vendors have been playing these games for so long that I have no faith or trust in any of them.

    Or, TL;DR version:

    I’ll believe it when I see it working, and only then if I see equipment from multiple vendors interoperating.

    0 0
This topic is closed for new posts.