[j-nsp] Qfabric

[Chris Evans]

Agree. I was just stating that this architecture should be bought because
its low latency means nothing to most folks.  That is all :)
On Feb 24, 2011 11:15 AM, "Keegan Holley" <keegan.holley at sungard.com> wrote:
> I think we are all saying the same thing. Low-latency trading, and
> distributed computing are probably the most common uses for sub-ms
> forwarding. There are alot of organizations that use the technology, but
by
> and large most enterprises and NSP's don't have uses cases for it yet.
>
> On Thu, Feb 24, 2011 at 10:03 AM, Stefan Fouant <
> sfouant at shortestpathfirst.net> wrote:
>
>> Chris,
>>
>>
>>
>> No offense, but you are dead wrong on this issue. I come in contact with
>> organizations every single day who have mission critical data
requirements
>> and latency is a VERY big requirement for many of these organizations.
And
>> while this might not be your experience given the financial services
>> organization you work with, reduced latency was a key
>> enabler/differentiator
>> for the NYSE and one of the main reasons that they chose Juniper for
their
>> next-generation data centers.
>>
>>
>>
>> I am pretty sure there are a lot of others who would agree with me that
>> latency is more than just a "buzz" word.
>>
>>
>>
>> Stefan Fouant, CISSP, JNCIEx2
>> <http://www.shortestpathfirst.net/> www.shortestpathfirst.net
>> GPG Key ID: 0xB4C956EC
>>
>>
>>
>> From: Chris Evans [mailto:chrisccnpspam2 at gmail.com]
>> Sent: Wednesday, February 23, 2011 11:55 PM
>> To: Stefan Fouant
>> Cc: Juniper-Nsp List; Ben Dale
>> 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
>>
>>