[j-nsp] Recommended Releases now posted for MX, M, T, QFX

[Paul Stewart]

One incredible frustration we're going through lately on the MX boxes is the
BRAS function as Mark mentioned briefly ..... we're up to "bleeding edge"
code now (11.4R1.14) just to get what we consider typical features of a BRAS
box.  Combine that with the first BRAS box I've seen that is picky about
Radius VSA's and it makes it really difficult to deploy.  We are not sure if
the word "stable" enters the equation yet as a BRAS neither - time will tell
as we're pushing out several of these boxes shortly despite concerns around
code.

Paul


-----Original Message-----
From: juniper-nsp-bounces at puck.nether.net
[mailto:juniper-nsp-bounces at puck.nether.net] On Behalf Of Mark Tinka
Sent: Tuesday, January 31, 2012 3:05 AM
To: James Jones
Cc: juniper-nsp at puck.nether.net
Subject: Re: [j-nsp] Recommended Releases now posted for MX, M, T, QFX

On Tuesday, January 31, 2012 12:32:26 AM James Jones wrote:

> I am just curious what issues you guys are having with the junos 
> releases?

Run through the archives to get a feel for what issues folk are facing. And
these are just the issues that folk have decided to share.

There are others that aren't shared, or folk that aren't sharing entirely.

> I am currently not having issues
> with any of my Juniper kit.

It's really dependent on how kinky you're running your boxes. If you look at
my route reflectors (M120's), 10.4R4.5 is solid, no issues. If you look at
my PE Aggregation routers (MX480's, M320's, T320's), you don't want to know.

If you look at the MX480 we're trying to make a BRAS, all bets are off :-).

> It would be interesting to
> understand the use cases in which you are seeing issues.

The problem is that since Junos 9.4, we've all been thinking and hoping that
the R4 release of that train (and all the ones following it) would be the
ideal one. The solid one. 
The one on which we can hang our boots on and kick back.

But alas, that was never to be the case, and given we're now literally
peeking at Junos 13 (or 14, or 15, whatever they decide to do after 12),
it's amazing that we're all still chasing that ever elusive dream of a
stable Junos.

Which, by the way, is not to discount all the good work that Juniper have
done, particularly since the debacle that was Junos 10.2, but given that
operators need to choose between:

	o Stable code.
	
	o Code that features you actually want.

	o Code that will be under Juniper EEOL program.

	o Code that will run new hardware.

	o Code that will fix all issues past without
	  bringing issues present.


... you can see where all the frustration is coming from.

What's worse, Junos 8 was a dream, so we all know what it's like to have
good code :-).

Mark.