Apr 5, 2011 10:26 PM
Any commants for that staff will be more then appreciated???
When is a Fabric not a Fabric?
On March 30, Cisco announced an update to their data center “vision.” We are pleased to see that they have endorsed our view of the problem—that the legacy multi-tiered data center network architecture must change to enable a truly virtualized data center. This evolution will begin with the architecture, where hierarchical tree structures will give way to flat fabrics. We at Juniper have been promoting this vision for the last two years and Cisco has now joined the chorus. Where we fundamentally differ is in our view of what constitutes a fabric and how one implements that fabric. Whereas Cisco is attempting to build a flatter, non-blocking network using their existing and evolving Nexus switches, we have focused on building a fabric by rethinking the concept of the switch.
These different approaches are best illustrated by how each company expresses the “key principles of a fabric.” In the column on the left in the table below, I have listed the seven key principles of a fabric as defined in a paper published in February by Pradeep Sindhu, the founder of Juniper Networks and the architect behind QFabric. In the column on the right are Cisco’s five key principles of a “Unified Fabric” as presented on slide 32 during the March 30 announcement.
1. Any-to-any connectivity with fairness and full non-blocking behavior for all traffic in a data center
1. Virtual Switches
2. Low latency and jitter
2. Hybrid Switches
3. No packet drops under congestion
3. Storage over Ethernet
4. Linear cost and power scaling
4. Flattening the network
5. Support of virtual network and services
5. A new set of network management capabilities
6. Modular, distributed implementation that is highly scalable
7. Single logical device
Notice that the list of principles on the left speaks to how a fabric should behave while the list on the right is more about “building” a fabric from specific existing components or capabilities. This is a very clear delineation between the approaches each company has taken towards building a fabric. The question is whether customers should care about these differences. I would argue the answer is yes. Here are three reasons why.
1. The last principle on each list attempts to speak to operational simplicity. Cisco specifies “a new set of network management capabilities” that, per slide 8 in their announcement, delivers “single pane of glass visibility across LAN and SAN.” “Single pane of glass” is the term used to describe the ability to monitor and/or manage multiple separate devices from a single user client. This does not necessarily make it simpler, just more convenient. In Juniper’s case, QFabric is a single logical device that behaves like and is managed as such. This is simpler and, we believe, fundamental to a fabric. For customers, simpler is always better as it lowers OPEX and improves availability.
2. Cisco introduced their new Broadcom-based Nexus 3000 for “low latency” deployments, primarily because all Nexus 5000s are notoriously slow. However, the Nexus 3000 is not compatible with FabricPath or UCS, it does not support FCoE to FC gateway functionality, and it does not support their physical or virtual FEXs. Thus you can be fast or you can be in a Cisco fabric, but you can’t be both. We believe it is not a fabric unless it has low latency and low jitter. For customers, faster is always better as it improves application behavior.
3. Cisco announced their new ability to transport FCoE packets across a Nexus 7000. However, that ability cannot use the FabricPath protocol. Thus they offer a “unified fabric” for Layer 2 Ethernet traffic, a different fabric for FCoE traffic, and yet another distinct fabric for Layer 3 traffic. It is not clear what part of the term "unified" they do not understand. With QFabric, all traffic is inherently supported by the data path of the fabric and, for customers, one fabric is better as it simplifies operations and reduces cost.
The most important take away from the March 30 announcement is the reaffirmation that the fundamental architecture of the network must and will change in order to enable the promise of the virtualized data center. Even Cisco now acknowledges that this evolution will require a wholesale replacement of most of the existing switching infrastructure as customers move from trees to fabrics. The existing installed base of Catalyst switches in the data center will be replaced over the next five to 10 years. The good news is that customers will have a rich set of alternatives to consider as they retool for the future.
million thanks chen