[j-nsp] EX4550 and MX104

[Pavel Lunin]

> Richard McGovern <rmcgovern at juniper.net>:
>
> I am not sure that the MX logic is from the 1990s. It should be first
>> released with the MX in... was it 2006 or 2007? While the first EX came
>> around in 2008. Not that big gap between the two.
>>
>
>
> ð  First came M before MX in mid-90s, I believe.
>

I might be wrong but if memory serves, M/T had no ethernet switching. So
all this bridge-domain machinery should have come around with the MX
series. It's not legacy but intentionally designed to be like this, as it's
SP-oriented.

And yeah, I forgot that MX also has two Ethernet switching config styles.
So... I am out of fingers to count the ether-switching config styles in
JUNOS. And it's OK, in fact. The point of this discussion is that adding
more instances is not the right way to reduce the number of them. And it's
arguable if it really needs to be reduced. JUNOS has always been known to
have multiple ways to do the same thing. And it's OK.



> While you are right about the fact that a given EX box supports either one
>> model or another and not both, this change has nothing to do with the
>> Marvel to Broadcom migration. It's purely software and, as you said, there
>> are some EoL boxes which have seen both. It rather looks like Juniper said
>> to themselves that they lost the enterprise market anyway, and for the DC
>> MX-like model should be a bit better.
>>
>
>
> ð  I repeat.  Agreed, and fortunately all those people are now gone
> within Juniper.
>

I am not sure that it's about people. I'd say it's more general story of
trying to repeat the M/T/MX/JUNOS success with other products.

Back in the early 2000s Juniper managed to revolutionize software design
for Service Provider routers. This is where the company feels safe and
knows what it does.

Look how much attention Juniper pays to user behavior consistency of the SP
products. I am too lazy to check but I am sure that there are still spare
parts for M/T available for purchase. This "per-packet" which is not really
per-packet but per-flow ECMP thing is pure legacy and could be changed
easily, but behavior consistency is the king. 64 bit RE for M7i when
everyone seemed to forget what M7i was. Lots of such examples in the M/T/MX
world. And it's good, it works.

However when it comes to the non-SP/DC world, it's just the opposite.
ScreenOS to SRX migration. WiFi. SSL VPN. Traffic Optimization. Space. J
Series. CDN caching. SRX media gateway. I am sure, I forgot something. I
doubt that it was the same people who killed those products.

It's not comparable with the MX as a business. So let's mess everything up
twice a year, because "JUNOS was a success at the beginning, we want a
single JUNOS for everything, it must be a success again". Or just because
"it doesn't sale". But yes, if you change the product behavior twice a
year, it won't sale. ScreenOS had a kind of 30% of the market and SRX...
you know... Not because it's a bad firewall but because it was a lot of
pain at the time of that ScreenOS->JUNOS migration.

BTW, a few months ago I've promenaded around in one of the major European
telco sites just to have a look at what people had in their racks. Oh Dear,
I've seen A LOT of Netscreen/SSG/ISG and even a couple of J-series. Racked,
powered, blinking LEDs. This should be some OOB in most cases, I think, but
anyway, they are still here! I was impressed.

--
Pavel