[j-nsp] Qfabric

[Joel Jaeggli]

On 2/26/11 5:53 AM, Clarke Morledge wrote:
> Guys, I know we've probably beaten this thread to death, but I'd like to
> get back to Keegan's original question on the thread:  so what exactly
> is Qfabric?
> 
> Stefan's description that it improves on TRILL by eliminating the
> forwarding table lookup along the path is intriguing. Doug's suggestion
> that L2/L3 forwarding is integrated to avoid the hairpin turns along an
> IRB interface as in VPLS is very helpful.  Another comment is this is a
> lot like ATM with MPOA shortcuts.

Leaving aside for the monent the physical layout and  the mechanics of
the implmentation consider what the topology of your datacenter would
look like if it were one giant l2/l3 ethernet switch instead of for
example a tiered core/aggretation/edge hierarchy of switches....

There are a lot of precursors to the is approach particularly when it
comes to core router design (think CRS or TX Matrix). but what it comes
down to is that while that IO is distributed the whole thing is
basically one box with a single coherent view of all the ports.

I sat through my first presentation of this sometime last year, and
while I can imagine what I'd use it for, the current ex82xx virtual
chassis builds a large enough diameter core for my immediate needs.
Getting rid of blade server chassis  and their idiot switches since
especially hp and cisco can't be bothered to play nice anymore is a
project for another day.

> All of this is great, but as I am wading through the marketing material
> and the whitepapers, I find myself trying to remember to lookup what
> "fungible" is instead of getting a good idea on how Juniper is actually
> solving the problem.
> 
> We have a good twenty plus years of work on things ranging from ATM/MPOA
> to MPLS/VPLS to now IETF's TRILL and IEEE's Shortest Path Bridging.  The
> solutions offered in these standards have their pluses and minuses, but
> at least there are (relatively) well understood published details.
> 
> Frankly, I am quite annoyed over the whole flap between IETF TRILL and
> IEEE Shortest Path Bridging.  This type of bickering in the standards'
> community doesn't help matters, and it only encourages folks like
> Juniper to take a different approach.
> 
> It seems like we are left with these proprietary solutions like QFabric,
> which comes across like "Virtual Chassis on Steroids".  But I've seen
> Virtual Chassis do some weird things, and trying to get intelligent
> information out of Juniper to try to explain them is difficult.

think about the RE moving out of the virtual chassis xre style and
that's part of it.

> Perhaps there are some good white papers or documentation out there that
> I am missing.  Can anyone direct me to the really good ones?  Anything
> in George Varghese's, Radia Perlman's, an MPLS writer's, or someone
> else's generally accessible printed work that can help enlighten?  How
> does QFabric really solve the forwarding lookup delay issue and the
> L2/L3 hairpin turn problem, without the yada-yada?  What about
> multipath? What about multicast replication?  What about failure
> recovery within the QFabric cloud?  I don't mean to be a
> stick-in-the-mud and I am interested to learn, but cloudy proprietary
> solutions just make me nervous.

The number of people who've gotten to kick the tires is pretty small. I
expect that will change but that fact that giant hanging ethernet switch
will remain a single vendor solution from which-ever vendor you choose
to buy it from is not likely to change.

> Clarke Morledge
> College of William and Mary
> Information Technology - Network Engineering
> Jones Hall (Room 18)
> Williamsburg VA 23187
> 
> _______________________________________________
> juniper-nsp mailing list juniper-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
>