[j-nsp] Qfabric

[Chuck Anderson]

This all sounds like ATM LAN Emulation with MPOA shortcuts.  Let's 
hope the implementation is better than the LANE/MPOA I had to deal 
with in the 90s.

On Thu, Feb 24, 2011 at 01:21:06PM -0800, Derick Winkworth wrote:
> Also integrated L2/L3 forwarding so that you don't hairpin traffic through a 
> node where the L2/L3 pieces meet (like VPLS to a node where the IRB interface 
> is..)
> 
> 
> 
> 
> ________________________________
> From: Doug Hanks <dhanks at juniper.net>
> To: Chris Evans <chrisccnpspam2 at gmail.com>; Stefan Fouant 
> <sfouant at shortestpathfirst.net>
> Cc: Juniper-Nsp List <juniper-nsp at puck.nether.net>
> Sent: Thu, February 24, 2011 11:15:53 AM
> Subject: Re: [j-nsp] Qfabric
> 
> A lot of our customers require low latency:  financial, higher education, HPC 
> environments and utility.
> 
> Juniper has taken the time to solve more than just the low latency problem.  
> We're trying to solve larger problems such as how do you manage an entire campus 
> or data center as one logical device; that's able to scale; and delivers 
> performance and low latency.
> 
> Doug
> 
> -----Original Message-----
> From: juniper-nsp-bounces at puck.nether.net 
> [mailto:juniper-nsp-bounces at puck.nether.net] On Behalf Of Chris Evans
> Sent: Wednesday, February 23, 2011 8:55 PM
> To: Stefan Fouant
> Cc: Juniper-Nsp List
> Subject: Re: [j-nsp] Qfabric
> 
> Low latency is a buzz word. Who really needs it? Very few applications
> really need it. I work in the financial industry and the only place we have
> a use case for low latency is in the investment bank context.. its like 20
> switches out of the thousands we have. retail, treasury, card etc. Couldnt
> care.
> 
> Also keep in mind that Juniper is one of the last to meet the low latency
> game.They are talking the game finally and people are buying into it.
> Everyone else is or has already  built lower latency switches than even
> these boxes already using the same merchant silicon.
> 
> All in all I sure hope juniper gets this one right. The ex platforms still
> have a lot of catching up to do just to match Cisco and  brocade features..
> I don't care about latency I care about the features that I need to run my
> business.
> On Feb 23, 2011 10:11 PM, "Stefan Fouant" <sfouant at shortestpathfirst.net>
> wrote:
> > Remember, a key differentiator is that TRILL solutions still require
> > forwarding table lookups on each node; as such, end-to-end latencies are
> > much higher.
> >
> > Another thing to point out is that QFabric allows exponential scaling in
> > that each device added to the fabric contributes additional switching
> > capacity, whereby we can achieve n^2 scaling benefits. It is interesting
> to
> > see the n-squared problem turned on its head - usually meshes are complex
> > and cumbersome - here, it only makes things better :)
> >
> > Stefan Fouant, CISSP, JNCIEx2
> > www.shortestpathfirst.net
> > GPG Key ID: 0xB4C956EC
> >
> >> -----Original Message-----
> >> From: juniper-nsp-bounces at puck.nether.net [mailto:juniper-nsp-
> >> bounces at puck.nether.net] On Behalf Of Ben Dale
> >> Sent: Wednesday, February 23, 2011 9:41 PM
> >> To: Juniper-Nsp List
> >> Subject: Re: [j-nsp] Qfabric
> >>
> >> My understanding of the Brocade VDX is that they use their own
> >> proprietary flavour of TRILL in order to handle the management of the
> >> switches? Happy for someone to correct me on this though.
> >>
> >> As Stefan pointed out - where the TRILL-based solutions fall down is
> >> controlling oversubscription - for every customer-facing revenue port,
> >> you need uplink(s) of equal capacity on *every* switch between point A
> >> and point B, which gets a bit hairy when your customer wants 10GB.
> >>
> >> Even on it's own though, the QFX looks like a pretty sweet box, but I
> >> don't think I've ever seen a Juniper Data Sheet with as many roadmap
> >> asterisks ; )
> >>
> >> It'll be interesting to see if Juniper offer a half-sized QFabric down
> >> the road once they realise that not everyone wants / needs 128x 40GB
> >> attached switches
> >>
> >> Interesting times!
> >>
> >> On 24/02/2011, at 12:11 PM, Keegan Holley wrote:
> >>
> >> > I think Brocade released nearly the same technology a couple of
> >> months ago
> >> > in their VDX product. Cisco can't be far behind. Although, their
> >> solution
> >> > will most likely be proprietary. As far as the technology I think
> >> > spanning-tree and the current way of doing ethernet has not been
> >> ideal for
> >> > some time.
> >> >
> >> >
> >> > On Wed, Feb 23, 2011 at 9:04 PM, Stefan Fouant <
> >> > sfouant at shortestpathfirst.net> wrote:
> >> >
> >> >> It's more than just a competitive offering to compete with the likes
> >> of the
> >> >> Nexus switches from Cisco, and its also quite a bit different from
> >> Cisco's
> >> >> FabricPath or other similar TRILL offerings. With FabricPath and
> >> TRILL we
> >> >> solve the problem of wasted revenue ports associated with complex 3-
> >> Tier
> >> >> architectures and blocked Spanning Tree ports, but you still have a
> >> >> forwarding table lookup taking place on each node along the path.
> >> With
> >> >> QFabric we have a set of devices which combine to form a singular
> >> unified
> >> >> fabric, all sharing a single control plane and managed via a single
> >> pane of
> >> >> glass, but more importantly achieving reduced latency as a result of
> >> a
> >> >> single forwarding table lookup taking place on the ingress node.
> >> With such a
> >> >> configuration we can achieve end-to-end Data Center latency on the
> >> order of
> >> >> 5 microseconds.
> >> >>
> >> >> There is a lot more to it which is obviously covered in the
> >> whitepapers,
> >> >> but this is truly something which is going to revolutionize data
> >> centers as
> >> >> we know it for some time to come.
> >> >>
> >> >> Stefan Fouant, CISSP, JNCIEx2
> >> >> GPG Key ID: 0xB4C956EC
> >> >>
> >> >> Sent from my HTC EVO.
> >> >>
> >> >> ----- Reply message -----
> >> >> From: "Chris Evans" <chrisccnpspam2 at gmail.com>
> >> >> Date: Wed, Feb 23, 2011 7:28 pm
> >> >> Subject: [j-nsp] Qfabric
> >> >> To: "Keegan Holley" <keegan.holley at sungard.com>
> >> >> Cc: "juniper-nsp" <juniper-nsp at puck.nether.net>
> >> >>
> >> >>
> >> >> Its junipers answer to nexus 5k 2k soltuion with larger scalability
> >> >> essentially.
> >> >> It has a big fabric interconnect at the core and some routing
> >> engines that
> >> >> control edge switches acting like remote line cards.
> >> >>
> >> >> On Feb 23, 2011 7:23 PM, "Keegan Holley" <keegan.holley at sungard.com>
> >> >> wrote:
> >> >>> Does anyone know what Qfabric is yet? After the video where Pradeep
> >> >> Sindhu
> >> >>> spends 1:45 talking about how they are going to change the world
> >> and 0:45
> >> >>> talking about the technology I gave up trying to cut through the
> >> >> marketing
> >> >>> buffer. It sounds like their implementation or answer to trill with
> >> some
> >> >> of
> >> >>> the virtual chassis stuff you see from the nexus thrown in. Anyone
> >> else
> >> >> get
> >> >>> more than that?