Re: [j-nsp] Qfabric

[Chris Cappuccio]

This sounds more like a configuration problem than a latency problem.

Windows Vista/2008 and higher will auto-tune TCP window size to take advantage 
of available bandwidth, even if the latency creeps up.  (So will all other 
modern operating systems at this point)

You can always manually increase the default window size in older Windows 
servers and clients, through the registry.

Adjusting the registry is a lot cheaper than deploying NYSE-euronext grade 
switches.  But I guess if you first make a profit selling the switches, then 
make more installing them, it's a great deal for everyone, including me.  I'll 
end up buying your old switches for 10% of the original sale price :)

Jensen Tyler [jty...@fiberutilities.com] wrote:
> In my tests I have seen as much as a 30% drop in Windows file sharing 
> performance with 2 ms of latency vs <1ms. This was in a large radiology 
> application. Applications like FTP work without any issues. Some applications 
> are more sensitive(SMB). Low latency to me is measure in microseconds not 
> milliseconds(mostly layer 2). 
> 
> -Original Message-
> From: juniper-nsp-boun...@puck.nether.net 
> [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Jeff Cadwallader
> Sent: Thursday, February 24, 2011 11:31 AM
> To: Doug Hanks
> Cc: Juniper-Nsp List
> Subject: Re: [j-nsp] Qfabric
> 
> I deal with a lot of those issues also and usually when I ask what do they
> mean by low latency the response comes back with sub-25ms. My data center is
> all 1-2ms max on an aging platform.
> 
> The other question I have is what happens to that entire logical device when
> it fails in spectacular ways.
> 
> I also agree that a sub-ms approach is needed in certain areas, however a
> tiered approach has its advantages also.
> 
> We are looking and evaluating replacing our aging platform in the data
> center and will be following this closely.
> 
> Jeff Cadwallader
> 
> On Thu, Feb 24, 2011 at 11:15 AM, Doug Hanks  wrote:
> 
> > 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
> >
> >
> ___
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
> 
> ___
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp

-- 
the preceding comment is my own and in no way reflects the opinion of the Joint 
Chiefs of Staff
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Qfabric

[Joel Jaeggli]

On 2/24/11 2:31 PM, Saku Ytti wrote:
> On (2011-02-24 14:59 -0600), Richard A Steenbergen wrote:
> 
>> latency in and of itself, just that you are "better than the other guy" 
>> so you can out-trade him). When it comes to microseconds of latency in 
>> the forwarding plane of a switch/router, I'm far less convinced that 
>> this is a real issue.
> 
> I've also argued about this, while I have no experience in high frequency
> trading networks. So it would be nice to hear from someone more experience
> how they capitalize on the low latency switches in high frequency trading.
> 
> It takes light about 5ns to travel 1m in fibre. Your average router MX80 is
> about 8000ns latency, low latency switch is under 1000ns.
> So we're talking for non low-latency run of the mill router introducing
> latency matching 1.6km of fibre and low-latency switch introducing 250m
> worth of latency.
> 
> Now where is this information going? How near physically is the end
> consumer of the information in high frequency trading?

the trading platform and the actors in question for a particular north
american market are located in the same facility in Mahwah New Jersey.

> What about the final application making trading decision? This is my own high
> frequency trading software, it is highly optimized:

> I have jitter of over 100ns between trading iterations. I'm guessing that
> real-life trading software is slightly more elaborate than this, and thus has
> higher jitter.

that activity can be simple as front-running large orders (which take
longer to fill) with small ones, an elaborate algorithm is not
necessarily a requirement. I'm kind of down on the market utility of
such activity but it's not presently illegal.

joel
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Qfabric

[James S. Smith]

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-boun...@puck.nether.net 
To: Derick Winkworth 
Cc: juniper-nsp@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"  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 
> To: Chris Evans ; Stefan Fouant
> 
> Cc: Juniper-Nsp List 
> 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-boun...@puck.nether.net
> [mailto:juniper-nsp-boun...@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" 
> 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-boun...@puck.nether.net [mailto:juniper-nsp-
>>> boun...@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 <
>>> > sfou...@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

[j-nsp] M7i IQ2 tpid translation or tag manipulation

[Kevin Wormington]

Hi,

I was wondering if it's possible to take in q-in-q traffic with outer tpid 0x9100 on an iq2 gige 
interface and be able to make a cross-connect (layer 2) to another iq2 gige interface but using tpid 
0x8100 on the outer tag?  Or, alternatively, strip/rewrite the 0x9100 outer tag and send it out 
same/another iq2 interface?


I have been able to terminate q-in-q traffic with different tpids but got the idea that I might be 
able to use the box to translate between different carriers tpids.


Any examples would be greatly appreciated.

Thanks,

Kevin
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Qfabric

[Chris Evans]

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"  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 
> To: Chris Evans ; Stefan Fouant
> 
> Cc: Juniper-Nsp List 
> 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-boun...@puck.nether.net
> [mailto:juniper-nsp-boun...@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" 
> 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-boun...@puck.nether.net [mailto:juniper-nsp-
>>> boun...@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 <
>>> > sfou...@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

Re: [j-nsp] Qfabric

[Saku Ytti]

On (2011-02-24 14:59 -0600), Richard A Steenbergen wrote:

> latency in and of itself, just that you are "better than the other guy" 
> so you can out-trade him). When it comes to microseconds of latency in 
> the forwarding plane of a switch/router, I'm far less convinced that 
> this is a real issue.

I've also argued about this, while I have no experience in high frequency
trading networks. So it would be nice to hear from someone more experience
how they capitalize on the low latency switches in high frequency trading.

It takes light about 5ns to travel 1m in fibre. Your average router MX80 is
about 8000ns latency, low latency switch is under 1000ns.
So we're talking for non low-latency run of the mill router introducing
latency matching 1.6km of fibre and low-latency switch introducing 250m
worth of latency.

Now where is this information going? How near physically is the end
consumer of the information in high frequency trading?

What about the final application making trading decision? This is my own high
frequency trading software, it is highly optimized:

[ytti@compasssion ~]% cat >> moi.c
int main(void) {
  return 0;
}
[ytti@compasssion ~]% gcc -o moi moi.c
[ytti@compasssion ~]% time ./moi
./moi  0.00s user 0.00s system 0% cpu 0.001 total
[ytti@compasssion ~]% time ./moi
./moi  0.00s user 0.00s system 0% cpu 0.002 total

I'm running it on 560M@2.67GHz.

I have jitter of over 100ns between trading iterations. I'm guessing that
real-life trading software is slightly more elaborate than this, and thus has
higher jitter.
I wonder how it would be actually possible via this software to experience if
I'm running run of the mill router or if I'm running low latency swicthing? I'm
introducing local jitter orders of magnitude more, masking the performance of
network.
If possible, we can save good dime on testing gear.

-- 
  ++ytti
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Qfabric

[Derick Winkworth]

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 
To: Chris Evans ; Stefan Fouant 

Cc: Juniper-Nsp List 
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-boun...@puck.nether.net 
[mailto:juniper-nsp-boun...@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" 
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-boun...@puck.nether.net [mailto:juniper-nsp-
>> boun...@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 <
>> > sfou...@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

Re: [j-nsp] Qfabric

[Richard A Steenbergen]

On Thu, Feb 24, 2011 at 10:55:10AM -0500, Jared Mauch wrote:
> 
> I heard about someone building a microwave link btw CHI and NYC due to 
> the lower latency compared to fiber and technology that they are able 
> to attain.  This is valuable for the high frequency traders, which 
> while they operate networks,
> 
> These might care about the latency, but people suffering from other 
> services that are not latency sensitive (eg: TCP) esp when using 
> modern IP stacks, this is less of an issue for 95% of the people out 
> there.

You're talking about multiple miliseconds of propagation latency, and 
one very very specific application (which doesn't even demand a specific 
latency in and of itself, just that you are "better than the other guy" 
so you can out-trade him). When it comes to microseconds of latency in 
the forwarding plane of a switch/router, I'm far less convinced that 
this is a real issue.

I'm sure you can find people who will vehemently testify that their quad 
shielded 4" thick $300 Monster HDMI cable makes their tv's picture 
noticably better too, but that doesn't make it true.

-- 
Richard A Steenbergenhttp://www.e-gerbil.net/ras
GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] 2x EX4200 Virtual Chassis Layer2/3 - Which JunOS Version ?

[Rafael Rodriguez]

Hi Tore,

Can't speak on the EX4500s as I've not had the chance to worked with them.

No experience on the EX4500s

On Thu, Feb 24, 2011 at 8:44 AM, Tore Anderson <
tore.ander...@redpill-linpro.com> wrote:

> * Rafael Rodriguez
>
> > software upgrades on EX4200 VCs are NOT hitless - the whole VC is
> > down for the duration of the upgrade (sometimes 15+ mins). VC !=
> > redundancy/HA, VC = less switches to manage.
>
> Hi Rafael,
>
> Do you know if this limitation applies to the EX 4500 as well?
>
> Best regards,
> --
> Tore Anderson
> Redpill Linpro AS - http://www.redpill-linpro.com
> Tel: +47 21 54 41 27
>
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Qfabric

[Doug Hanks]

Sounds like the bandwidth-delay product really hampered SMB.

From: Jensen Tyler [mailto:jty...@fiberutilities.com]
Sent: Thursday, February 24, 2011 11:31 AM
To: Chris Evans
Cc: Juniper-Nsp List; Doug Hanks; Jeff Cadwallader
Subject: RE: [j-nsp] Qfabric

This test was over our Private Fiber WAN. Data center was a 150-200 miles from 
Hospital. The gear we were using has less than 4us per hop.

Was also able to replicate this in the lab using the linux network emulation 
software.

The end user in this example is a doctor waiting to look at an x-ray. 
Performance is perception.


From: Chris Evans [mailto:chrisccnpsp...@gmail.com]
Sent: Thursday, February 24, 2011 1:11 PM
To: Jensen Tyler
Cc: Juniper-Nsp List; Doug Hanks; Jeff Cadwallader
Subject: Re: [j-nsp] Qfabric


I don't know what hardware you are using but even our older gear isn't much 
higher than 20micros per hop..  within the DC even old gear is fine for smb..
On Feb 24, 2011 1:11 PM, "Jensen Tyler" 
mailto:jty...@fiberutilities.com>> wrote:
> In my tests I have seen as much as a 30% drop in Windows file sharing 
> performance with 2 ms of latency vs <1ms. This was in a large radiology 
> application. Applications like FTP work without any issues. Some applications 
> are more sensitive(SMB). Low latency to me is measure in microseconds not 
> milliseconds(mostly layer 2).
>
> -Original Message-
> From: 
> juniper-nsp-boun...@puck.nether.net
>  
> [mailto:juniper-nsp-boun...@puck.nether.net]
>  On Behalf Of Jeff Cadwallader
> Sent: Thursday, February 24, 2011 11:31 AM
> To: Doug Hanks
> Cc: Juniper-Nsp List
> Subject: Re: [j-nsp] Qfabric
>
> I deal with a lot of those issues also and usually when I ask what do they
> mean by low latency the response comes back with sub-25ms. My data center is
> all 1-2ms max on an aging platform.
>
> The other question I have is what happens to that entire logical device when
> it fails in spectacular ways.
>
> I also agree that a sub-ms approach is needed in certain areas, however a
> tiered approach has its advantages also.
>
> We are looking and evaluating replacing our aging platform in the data
> center and will be following this closely.
>
> Jeff Cadwallader
>
> On Thu, Feb 24, 2011 at 11:15 AM, Doug Hanks 
> mailto:dha...@juniper.net>> wrote:
>
>> 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
>>
>>
> ___
> juniper-nsp mailing list 
> juniper-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
>
> ___
> juniper-nsp mailing list 
> juniper-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Qfabric

[Jensen Tyler]

This test was over our Private Fiber WAN. Data center was a 150-200 miles from 
Hospital. The gear we were using has less than 4us per hop.

Was also able to replicate this in the lab using the linux network emulation 
software.

The end user in this example is a doctor waiting to look at an x-ray. 
Performance is perception.


From: Chris Evans [mailto:chrisccnpsp...@gmail.com]
Sent: Thursday, February 24, 2011 1:11 PM
To: Jensen Tyler
Cc: Juniper-Nsp List; Doug Hanks; Jeff Cadwallader
Subject: Re: [j-nsp] Qfabric


I don't know what hardware you are using but even our older gear isn't much 
higher than 20micros per hop..  within the DC even old gear is fine for smb..
On Feb 24, 2011 1:11 PM, "Jensen Tyler" 
mailto:jty...@fiberutilities.com>> wrote:
> In my tests I have seen as much as a 30% drop in Windows file sharing 
> performance with 2 ms of latency vs <1ms. This was in a large radiology 
> application. Applications like FTP work without any issues. Some applications 
> are more sensitive(SMB). Low latency to me is measure in microseconds not 
> milliseconds(mostly layer 2).
>
> -Original Message-
> From: 
> juniper-nsp-boun...@puck.nether.net
>  
> [mailto:juniper-nsp-boun...@puck.nether.net]
>  On Behalf Of Jeff Cadwallader
> Sent: Thursday, February 24, 2011 11:31 AM
> To: Doug Hanks
> Cc: Juniper-Nsp List
> Subject: Re: [j-nsp] Qfabric
>
> I deal with a lot of those issues also and usually when I ask what do they
> mean by low latency the response comes back with sub-25ms. My data center is
> all 1-2ms max on an aging platform.
>
> The other question I have is what happens to that entire logical device when
> it fails in spectacular ways.
>
> I also agree that a sub-ms approach is needed in certain areas, however a
> tiered approach has its advantages also.
>
> We are looking and evaluating replacing our aging platform in the data
> center and will be following this closely.
>
> Jeff Cadwallader
>
> On Thu, Feb 24, 2011 at 11:15 AM, Doug Hanks 
> mailto:dha...@juniper.net>> wrote:
>
>> 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
>>
>>
> ___
> juniper-nsp mailing list 
> juniper-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
>
> ___
> juniper-nsp mailing list 
> juniper-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Qfabric

[Chris Evans]

I don't know what hardware you are using but even our older gear isn't much
higher than 20micros per hop..  within the DC even old gear is fine for
smb..
On Feb 24, 2011 1:11 PM, "Jensen Tyler"  wrote:
> In my tests I have seen as much as a 30% drop in Windows file sharing
performance with 2 ms of latency vs <1ms. This was in a large radiology
application. Applications like FTP work without any issues. Some
applications are more sensitive(SMB). Low latency to me is measure in
microseconds not milliseconds(mostly layer 2).
>
> -Original Message-
> From: juniper-nsp-boun...@puck.nether.net [mailto:
juniper-nsp-boun...@puck.nether.net] On Behalf Of Jeff Cadwallader
> Sent: Thursday, February 24, 2011 11:31 AM
> To: Doug Hanks
> Cc: Juniper-Nsp List
> Subject: Re: [j-nsp] Qfabric
>
> I deal with a lot of those issues also and usually when I ask what do they
> mean by low latency the response comes back with sub-25ms. My data center
is
> all 1-2ms max on an aging platform.
>
> The other question I have is what happens to that entire logical device
when
> it fails in spectacular ways.
>
> I also agree that a sub-ms approach is needed in certain areas, however a
> tiered approach has its advantages also.
>
> We are looking and evaluating replacing our aging platform in the data
> center and will be following this closely.
>
> Jeff Cadwallader
>
> On Thu, Feb 24, 2011 at 11:15 AM, Doug Hanks  wrote:
>
>> 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
>>
>>
> ___
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
>
> ___
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Qfabric

[Jensen Tyler]

Not an option. Deeply integrated into MS stack. This vendor had a mini-web 
based version that performed better then the thick client due to using HTTP.

From: Keegan Holley [mailto:keegan.hol...@sungard.com]
Sent: Thursday, February 24, 2011 12:44 PM
To: Jensen Tyler
Cc: Jeff Cadwallader; Doug Hanks; Juniper-Nsp List
Subject: Re: [j-nsp] Qfabric

I would have taken that as an excuse to use NFS.  I've never done such testing 
but 30% is horrendous.

On Thu, Feb 24, 2011 at 1:00 PM, Jensen Tyler 
mailto:jty...@fiberutilities.com>> wrote:
In my tests I have seen as much as a 30% drop in Windows file sharing 
performance with 2 ms of latency vs <1ms. This was in a large radiology 
application. Applications like FTP work without any issues. Some applications 
are more sensitive(SMB). Low latency to me is measure in microseconds not 
milliseconds(mostly layer 2).

-Original Message-
From: 
juniper-nsp-boun...@puck.nether.net 
[mailto:juniper-nsp-boun...@puck.nether.net]
 On Behalf Of Jeff Cadwallader
Sent: Thursday, February 24, 2011 11:31 AM
To: Doug Hanks
Cc: Juniper-Nsp List
Subject: Re: [j-nsp] Qfabric
I deal with a lot of those issues also and usually when I ask what do they
mean by low latency the response comes back with sub-25ms. My data center is
all 1-2ms max on an aging platform.

The other question I have is what happens to that entire logical device when
it fails in spectacular ways.

I also agree that a sub-ms approach is needed in certain areas, however a
tiered approach has its advantages also.

We are looking and evaluating replacing our aging platform in the data
center and will be following this closely.

Jeff Cadwallader

On Thu, Feb 24, 2011 at 11:15 AM, Doug Hanks 
mailto:dha...@juniper.net>> wrote:

> 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
>
>
___
juniper-nsp mailing list 
juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

___
juniper-nsp mailing list 
juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Qfabric

[Keegan Holley]

I would have taken that as an excuse to use NFS.  I've never done such
testing but 30% is horrendous.


On Thu, Feb 24, 2011 at 1:00 PM, Jensen Tyler wrote:

> In my tests I have seen as much as a 30% drop in Windows file sharing
> performance with 2 ms of latency vs <1ms. This was in a large radiology
> application. Applications like FTP work without any issues. Some
> applications are more sensitive(SMB). Low latency to me is measure in
> microseconds not milliseconds(mostly layer 2).
>
> -Original Message-
> From: juniper-nsp-boun...@puck.nether.net [mailto:
> juniper-nsp-boun...@puck.nether.net] On Behalf Of Jeff Cadwallader
> Sent: Thursday, February 24, 2011 11:31 AM
> To: Doug Hanks
> Cc: Juniper-Nsp List
> Subject: Re: [j-nsp] Qfabric
>
> I deal with a lot of those issues also and usually when I ask what do they
> mean by low latency the response comes back with sub-25ms. My data center
> is
> all 1-2ms max on an aging platform.
>
> The other question I have is what happens to that entire logical device
> when
> it fails in spectacular ways.
>
> I also agree that a sub-ms approach is needed in certain areas, however a
> tiered approach has its advantages also.
>
> We are looking and evaluating replacing our aging platform in the data
> center and will be following this closely.
>
> Jeff Cadwallader
>
> On Thu, Feb 24, 2011 at 11:15 AM, Doug Hanks  wrote:
>
> > 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
> >
> >
> ___
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
>
> ___
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
>
>
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] pxe boot-file from SRX

[Chris Adams]

Once upon a time, Charlie Allom  said:
> Hello,
> 
> has anyone had an Intel PXE booter work with a stanza like so:
> 
> 94.228.69.77 ("untrust" zone tftp server)
> 94.228.69.144 ("trust" zone Dell PC)
> 
> char...@fw0.rst# top show system services dhcp static-binding 
> 00:13:20:d4:b9:3f 
> fixed-address {
> 94.228.69.144;
> }
> boot-file pxelinux.0;
> boot-server 94.228.69.77;

On an old J-series (running packet JUNOS), I have "next-server", not
"boot-server".  I would expect that to be the same for SRX.

-- 
Chris Adams 
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Qfabric

[Doug Hanks]

This isn't designed to be placed as an aggregated PE device.  I would 
definitely say use an MX in this situation ;)

From: Keegan Holley [mailto:keegan.hol...@sungard.com]
Sent: Thursday, February 24, 2011 9:56 AM
To: Doug Hanks
Cc: Chris Evans; Juniper-Nsp List
Subject: Re: [j-nsp] Qfabric

The problem with that is that there are only 25 of them.  I've got thousands of 
customers that just want 1G with sub 500M internet and private line with little 
or no concern for latency that isn't excessive.  I'm not saying there's no 
money to be made here, but the majority of the consumers of network equipment 
don't have a need or a budget for something this advanced.  Just my 2 cents.

On Thu, Feb 24, 2011 at 12:34 PM, Doug Hanks 
mailto:dha...@juniper.net>> wrote:
All of my large Fortune 25 customers have a large investment in 10Gb not only 
in the core, but access as well.  This is because virtualization is driving the 
need for higher speed.  I generally see 4x10Gb connections per server chassis 
if not more in large virtualized environments.

If you need a 100% copper solution, we have the EX today.

>From what I see on the QMX data sheet it supports 18 ports of copper and 36 
>ports of 1Gb fiber today.

Doug

From: Chris Evans 
[mailto:chrisccnpsp...@gmail.com]
Sent: Thursday, February 24, 2011 9:24 AM
To: Doug Hanks
Cc: Juniper-Nsp List; Stefan Fouant
Subject: Re: RE: [j-nsp] Qfabric


Yeah and that's great.  As 90% of the installs are still gige copper where is 
that offering? :)
On Feb 24, 2011 12:17 PM, "Doug Hanks" 
mailto:dha...@juniper.net>>>
 wrote:
> 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-boun...@puck.nether.net>
>  
> [mailto:juniper-nsp-boun...@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" 
> mailto:sfou...@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-boun...@puck.nether.net>
>>>  
>>> [mailto:juniper-nsp->
>>> boun...@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 managem

Re: [j-nsp] Qfabric

[Jensen Tyler]

In my tests I have seen as much as a 30% drop in Windows file sharing 
performance with 2 ms of latency vs <1ms. This was in a large radiology 
application. Applications like FTP work without any issues. Some applications 
are more sensitive(SMB). Low latency to me is measure in microseconds not 
milliseconds(mostly layer 2). 

-Original Message-
From: juniper-nsp-boun...@puck.nether.net 
[mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Jeff Cadwallader
Sent: Thursday, February 24, 2011 11:31 AM
To: Doug Hanks
Cc: Juniper-Nsp List
Subject: Re: [j-nsp] Qfabric

I deal with a lot of those issues also and usually when I ask what do they
mean by low latency the response comes back with sub-25ms. My data center is
all 1-2ms max on an aging platform.

The other question I have is what happens to that entire logical device when
it fails in spectacular ways.

I also agree that a sub-ms approach is needed in certain areas, however a
tiered approach has its advantages also.

We are looking and evaluating replacing our aging platform in the data
center and will be following this closely.

Jeff Cadwallader

On Thu, Feb 24, 2011 at 11:15 AM, Doug Hanks  wrote:

> 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
>
>
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

[j-nsp] pxe boot-file from SRX

[Charlie Allom]

Hello,

has anyone had an Intel PXE booter work with a stanza like so:

94.228.69.77 ("untrust" zone tftp server)
94.228.69.144 ("trust" zone Dell PC)

char...@fw0.rst# top show system services dhcp static-binding 00:13:20:d4:b9:3f 
fixed-address {
94.228.69.144;
}
boot-file pxelinux.0;
boot-server 94.228.69.77;

[edit security policies]
char...@fw0.rst# 

Hosts are using this SRX as a DHCP server already, and the tftp ALG
works if I run it from the trust->untrust zone. There is no NAT.

I found this http://tinyurl.com/6dzon79 which says "For J Series
Services Routers and EX Series switches only." Seems odd to me, but
wanted to verify it.

Regards,
   C.
-- 
 +442077294797
 http://mediaserviceprovider.com/
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Qfabric

[Keegan Holley]

The problem with that is that there are only 25 of them.  I've got thousands
of customers that just want 1G with sub 500M internet and private line with
little or no concern for latency that isn't excessive.  I'm not saying
there's no money to be made here, but the majority of the consumers of
network equipment don't have a need or a budget for something this advanced.
 Just my 2 cents.

On Thu, Feb 24, 2011 at 12:34 PM, Doug Hanks  wrote:

> All of my large Fortune 25 customers have a large investment in 10Gb not
> only in the core, but access as well.  This is because virtualization is
> driving the need for higher speed.  I generally see 4x10Gb connections per
> server chassis if not more in large virtualized environments.
>
> If you need a 100% copper solution, we have the EX today.
>
> From what I see on the QMX data sheet it supports 18 ports of copper and 36
> ports of 1Gb fiber today.
>
> Doug
>
> From: Chris Evans [mailto:chrisccnpsp...@gmail.com]
> Sent: Thursday, February 24, 2011 9:24 AM
> To: Doug Hanks
> Cc: Juniper-Nsp List; Stefan Fouant
> Subject: Re: RE: [j-nsp] Qfabric
>
>
> Yeah and that's great.  As 90% of the installs are still gige copper where
> is that offering? :)
> On Feb 24, 2011 12:17 PM, "Doug Hanks"  dha...@juniper.net>> wrote:
> > 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-boun...@puck.nether.net juniper-nsp-boun...@puck.nether.net> [mailto:
> juniper-nsp-boun...@puck.nether.net juniper-nsp-boun...@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"  >
> > 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-boun...@puck.nether.net juniper-nsp-boun...@puck.nether.net> [mailto:juniper-nsp- juniper-nsp->
> >>> boun...@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

Re: [j-nsp] Qfabric

[Doug Hanks]

All of my large Fortune 25 customers have a large investment in 10Gb not only 
in the core, but access as well.  This is because virtualization is driving the 
need for higher speed.  I generally see 4x10Gb connections per server chassis 
if not more in large virtualized environments.

If you need a 100% copper solution, we have the EX today.

>From what I see on the QMX data sheet it supports 18 ports of copper and 36 
>ports of 1Gb fiber today.

Doug

From: Chris Evans [mailto:chrisccnpsp...@gmail.com]
Sent: Thursday, February 24, 2011 9:24 AM
To: Doug Hanks
Cc: Juniper-Nsp List; Stefan Fouant
Subject: Re: RE: [j-nsp] Qfabric


Yeah and that's great.  As 90% of the installs are still gige copper where is 
that offering? :)
On Feb 24, 2011 12:17 PM, "Doug Hanks" 
mailto:dha...@juniper.net>> wrote:
> 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-boun...@puck.nether.net
>  
> [mailto:juniper-nsp-boun...@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" 
> mailto:sfou...@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-boun...@puck.nether.net
>>>  [mailto:juniper-nsp-
>>> boun...@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 <
>>> > sfou...@shortestpathfirst.net> 
>>> > wrote:
>>> >
>>> >> It's more than just a competit

Re: [j-nsp] Qfabric

[Jeff Cadwallader]

I deal with a lot of those issues also and usually when I ask what do they
mean by low latency the response comes back with sub-25ms. My data center is
all 1-2ms max on an aging platform.

The other question I have is what happens to that entire logical device when
it fails in spectacular ways.

I also agree that a sub-ms approach is needed in certain areas, however a
tiered approach has its advantages also.

We are looking and evaluating replacing our aging platform in the data
center and will be following this closely.

Jeff Cadwallader

On Thu, Feb 24, 2011 at 11:15 AM, Doug Hanks  wrote:

> 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
>
>
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Qfabric

[Chris Morrow]

On 02/24/11 12:24, Chris Evans wrote:
> Yeah and that's great.  As 90% of the installs are still gige copper where
> is that offering? :)
> On Feb 24, 2011 12:17 PM, "Doug Hanks"  wrote:
>> 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.

it's 2011, where's my v6 firewall on the loopback?
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Qfabric

[Doug Hanks]

I'm more than happy to share, but first I need to know what I am allowed to 
disclose publically without a NDA.  We've been keeping this under wraps for the 
past 2 years for a good reason.  This _isn't_ a response to Nexus or any other 
technology out there.  Stratus is in a league of its own.

Doug

From: Chris Evans [mailto:chrisccnpsp...@gmail.com]
Sent: Wednesday, February 23, 2011 5:05 PM
To: Doug Hanks
Cc: juniper-nsp; Keegan Holley
Subject: Re: [j-nsp] Qfabric


I think its a sexy solution however it falls short in areas to meet our needs. 
I think Juniper has something going for them, however its misses on a lot of 
contexts so far.

1. We no longer install structured copper in our data centers as we have gone 
fully top of rack. The edge Qfabric devices require a copper connection back to 
the routing engine complex. It needs to option to use sfp optics so we can do 
fiber for this link.

2. We still like most people deploy 90% GigE and will for the next year or so 
at least. Stratus needs a copper GigE offering. Even if we went full 10Gig for 
production interfaces, servers still need management connectivity which iare 
copper based and also 100Meg most times. Our account team suggested that we 
deploy EX devices to meet these needs, however that is a hack solution and 
something we won't entertain. Deploying EX's gets us back to the original issue 
of having remote devices all managed individually.

3. Stratus needs a smaller fabric offering. Scaling a network infrastructure 
with such a large risk, fault, change domain brings big concerns. It'd be nice 
to have a smaller fabric offering to compartmentalize the network a bit.

Doug it'd be nice if you could comment on my comments above if you have some 
insider info :) It'd also be nice if you could take this feedback to the 
engineering teams for their input. We already have our account team doing so, 
but another path of contact is always beneficial.


On Feb 23, 2011 7:35 PM, "Doug Hanks" 
mailto:dha...@juniper.net>> wrote:
> First phase of Stratus. It's awesome.
>
> -Original Message-
> From: 
> juniper-nsp-boun...@puck.nether.net
>  
> [mailto:juniper-nsp-boun...@puck.nether.net]
>  On Behalf Of Keegan Holley
> Sent: Wednesday, February 23, 2011 4:10 PM
> To: juniper-nsp
> Subject: [j-nsp] Qfabric
>
> 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@puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
>
> ___
> juniper-nsp mailing list 
> juniper-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Qfabric

[Chris Evans]

Yeah and that's great.  As 90% of the installs are still gige copper where
is that offering? :)
On Feb 24, 2011 12:17 PM, "Doug Hanks"  wrote:
> 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-boun...@puck.nether.net [mailto:
juniper-nsp-boun...@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" 
> 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-boun...@puck.nether.net [mailto:juniper-nsp-
>>> boun...@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 <
>>> > sfou...@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,
>>> 

Re: [j-nsp] Qfabric

[Doug Hanks]

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-boun...@puck.nether.net 
[mailto:juniper-nsp-boun...@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" 
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-boun...@puck.nether.net [mailto:juniper-nsp-
>> boun...@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 <
>> > sfou...@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 -
>> >> F

Re: [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"  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 <
> sfou...@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
>>  www.shortestpathfirst.net
>> GPG Key ID: 0xB4C956EC
>>
>>
>>
>> From: Chris Evans [mailto:chrisccnpsp...@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" 
>> 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-boun...@puck.nether.net [mailto:juniper-nsp-
>> >> boun...@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 <
>> >> > sfou...@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 

Re: [j-nsp] Qfabric

[Keegan Holley]

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 <
sfou...@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
>   www.shortestpathfirst.net
> GPG Key ID: 0xB4C956EC
>
>
>
> From: Chris Evans [mailto:chrisccnpsp...@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" 
> 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-boun...@puck.nether.net [mailto:juniper-nsp-
> >> boun...@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 <
> >> > sfou...@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 ta

Re: [j-nsp] Qfabric

[Chris Evans]

You are entitled to your opinion but I still disagree.  In general its a
thing people think they need because they don't really understand their
application. 95% of the market doesn't care.

If latency is absolutely critical then you would be chosing Arista for
example. Even with this new hardware there are still faster platforms out
there... Also just because NYSE chose them doesn't mean anything.. They've
been a Juniper shop for years. I don't know about your company but we chose
vendors based on political reasons most times. Its high above my pay grade
where this happens so I have no control. Most companies are this way
unfortunately...
On Feb 24, 2011 10:03 AM, "Stefan Fouant" 
wrote:
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Qfabric

[Jared Mauch]

On Feb 24, 2011, at 10:42 AM, Richard A Steenbergen wrote:

> On Thu, Feb 24, 2011 at 10:03:30AM -0500, Stefan Fouant wrote:
>> 
>> 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.
> 
> That doesn't actually make it important, it just means there are some 
> customers out there who believe the hype. :)

I heard about someone building a microwave link btw CHI and NYC due to the 
lower latency compared to fiber and technology that they are able to attain.  
This is valuable for the high frequency traders, which while they operate 
networks, 

These might care about the latency, but people suffering from other services 
that are not latency sensitive (eg: TCP) esp when using modern IP stacks, this 
is less of an issue for 95% of the people out there.

Now all the people still running broken IP stacks, they just need to dump their 
OS choice down the toilet until they learn how to properly use their equipment. 
 I have no pity on them, it's their own fault/doing.  They can push out better 
than those default options to fix things, or just upgrade to a modern OS.  
(This includes anyone running MSIE6 as well that mistakenly wedded themselves 
to that proprietary technology).

- Jared
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Qfabric

[Richard A Steenbergen]

On Thu, Feb 24, 2011 at 10:03:30AM -0500, Stefan Fouant wrote:
> 
> 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.

That doesn't actually make it important, it just means there are some 
customers out there who believe the hype. :)

-- 
Richard A Steenbergenhttp://www.e-gerbil.net/ras
GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Qfabric

[Keegan Holley]

I agree, forwarding table lookups have been done in CAM/TCAM for years now.
 No one is really complaining about the speed of the current technology.
 Also, infiniband would be more useful than ethernet with lower latency.


On Thu, Feb 24, 2011 at 10:03 AM, Stefan Fouant <
sfou...@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
>   www.shortestpathfirst.net
> GPG Key ID: 0xB4C956EC
>
>
>
> From: Chris Evans [mailto:chrisccnpsp...@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" 
> 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-boun...@puck.nether.net [mailto:juniper-nsp-
> >> boun...@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 <
> >> > sfou...@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.
> >> Wi

Re: [j-nsp] Qfabric

[Stefan Fouant]

Chris,

 

I couldn't agree with you more wholeheartedly - and apparently the
developers at Juniper are also of similar mindset.  

 

Basically, the control plane services are provided by the QF/Director,
QF/Node, and the  QF/Interconnect devices in the QFabric architecture.  This
is a highly distributed system which actually consists of redundant control
planes (fully independent so as to eliminate fate-sharing mind you) and
redundant components within each control plane.  The distributed nature of
this implementation provides tremendous reliability since it eliminates any
single point of failure in the system.

 

Hope that helps to clarify things a bit more. There is a tremendous amount
of information which can be found in the whitepapers, I would suggest
reading them if you want to learn more about the QFabric architecture.

 

Best Regards,

 

Stefan Fouant, CISSP, JNCIEx2
  www.shortestpathfirst.net
GPG Key ID: 0xB4C956EC

 

From: Chris Evans [mailto:chrisccnpsp...@gmail.com] 
Sent: Thursday, February 24, 2011 12:15 AM
To: Stefan Fouant
Cc: juniper-nsp; Keegan Holley
Subject: Re: [j-nsp] Qfabric

 

We are deploying nexus kit at this point as it meets our needs. Vpc concepts
brings fully active forwarding paths to all links just in a different way. 

Being able to manage a fabric from a single control plane has its positives
but also has huge negatives. Having a single control plane for the whole dc
reduces you to one fault, one change and one risk domain.. all can bring
very bad consequences. This is why I'd like to see a smaller fabric offering
so that I can build the same solution just on a smaller scale without having
to waste the space the current interconnect requires.. tiers are not a bad
thing..

The new fabric topologies are very interesting and will bring design changes
i'm sure.. 

On Feb 23, 2011 9:04 PM, "Stefan Fouant" 
wrote:

___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Qfabric

[Stefan Fouant]

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
  www.shortestpathfirst.net
GPG Key ID: 0xB4C956EC

 

From: Chris Evans [mailto:chrisccnpsp...@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" 
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-boun...@puck.nether.net [mailto:juniper-nsp-
>> boun...@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 <
>> > sfou...@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 th

Re: [j-nsp] Qfabric

[Abhi]

Now what i know about VDX it does not do  "single forwarding table lookup" to 
decide the egress node.

 Regards
Abhijeet.C




From: Stefan Fouant 
To: Chris Evans ; Keegan Holley 

Cc: juniper-nsp 
Sent: Thursday, February 24, 2011 7:34 AM
Subject: Re: [j-nsp] Qfabric

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" 
Date: Wed, Feb 23, 2011 7:28 pm
Subject: [j-nsp] Qfabric
To: "Keegan Holley" 
Cc: "juniper-nsp" 


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"  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@puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] 2x EX4200 Virtual Chassis Layer2/3 - Which JunOS Version ?

[Tore Anderson]

* Rafael Rodriguez

> software upgrades on EX4200 VCs are NOT hitless - the whole VC is
> down for the duration of the upgrade (sometimes 15+ mins). VC !=
> redundancy/HA, VC = less switches to manage.

Hi Rafael,

Do you know if this limitation applies to the EX 4500 as well?

Best regards,
-- 
Tore Anderson
Redpill Linpro AS - http://www.redpill-linpro.com
Tel: +47 21 54 41 27
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] NSR+GRES vs Graceful restart

[Richard A Steenbergen]

On Wed, Feb 23, 2011 at 10:19:14AM -0800, Doug Hanks wrote:
> GRES+NSR+ISSU works just fine with DPCs.  The ISSU for Trio is still 
> roadmap.

For some definition work "works just fine", where "works" equals 
"doesn't work" perhaps. :) I haven't been able to successfully ISSU an 
MX/DPC for over 2 years, and Juniper has all but given up trying to fix 
it.

But GRES+NSR is typically going to be a much better idea than GRES+GR. 
GR is actually pretty darn flawed in its design, as it assumes that all 
failures are graceful, even the non-graceful ones. If you don't want to 
blackhole a lot of traffic, NSR is a MUCH better alternative. Of course 
I have yet to encounter an RE failure in the wild where GRES+anything 
actually saves the day, but doing a hitless NSR switchover has been 
surprisingly helpful as a way to kick the box in response to a large 
number of random/obnoxious bugs, without actually having to disrupt 
forwarding.

-- 
Richard A Steenbergenhttp://www.e-gerbil.net/ras
GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] NSR+GRES vs Graceful restart

[Pekka Savola]

On Wed, 23 Feb 2011, Doug Hanks wrote:
GRES+NSR+ISSU works just fine with DPCs.  The ISSU for Trio is still 
roadmap.


In theory, yes.

In practise, even with just DPCs, a large amount of PRs and issues 
have come up that have been caused by NSR or ISSU upgrades.  To 
minimize weird protocol issues, we had to switch back to plain GRES.


--
Pekka Savola "You each name yourselves king, yet the
Netcore Oykingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp