[j-nsp] Qfabric

James S. Smith JSmith at WindMobile.ca
Thu Feb 24 18:47:32 EST 2011


I'm have the same question.  From the sounds of it, we could replace our SAN with this?  I know that wouLd be a hard sell to the SAN guys.

----- Original Message -----
From: juniper-nsp-bounces at puck.nether.net <juniper-nsp-bounces at puck.nether.net>
To: Derick Winkworth <dwinkworth at att.net>
Cc: juniper-nsp at puck.nether.net <juniper-nsp at puck.nether.net>
Sent: Thu Feb 24 17:32:39 2011
Subject: Re: [j-nsp] Qfabric

I honestly wonder how many caveats there is going to be.  Everything sounds
great on paper from every vendor....
On Feb 24, 2011 5:28 PM, "Derick Winkworth" <dwinkworth at att.net> 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?
>>> >>> _______________________________________________
>>> >>> juniper-nsp mailing list juniper-nsp at puck.nether.net
>>> >>> https://puck.nether.net/mailman/listinfo/juniper-nsp
>>> >> _______________________________________________
>>> >> juniper-nsp mailing list juniper-nsp at puck.nether.net
>>> >> https://puck.nether.net/mailman/listinfo/juniper-nsp
>>> >>
>>> >>
>>> >>
>>> > _______________________________________________
>>> > juniper-nsp mailing list juniper-nsp at puck.nether.net
>>> > https://puck.nether.net/mailman/listinfo/juniper-nsp
>>> >
>>>
>>>
>>> _______________________________________________
>>> juniper-nsp mailing list juniper-nsp at puck.nether.net
>>> https://puck.nether.net/mailman/listinfo/juniper-nsp
>>
>> _______________________________________________
>> juniper-nsp mailing list juniper-nsp at puck.nether.net
>> https://puck.nether.net/mailman/listinfo/juniper-nsp
> _______________________________________________
> juniper-nsp mailing list juniper-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
>
> _______________________________________________
> juniper-nsp mailing list juniper-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
> _______________________________________________
> juniper-nsp mailing list juniper-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
_______________________________________________
juniper-nsp mailing list juniper-nsp at puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

This message contains confidential information and is intended only for the individual named. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited.



More information about the juniper-nsp mailing list