[j-nsp] Going Juniper

[Saku Ytti]

On 23 April 2018 at 11:34,  <adamv0025 at netconsultings.com> wrote:

> Well first of all juniper made it this far only because it's a cheap
> alternative to cisco, and you always get what you pay for.

I and lot others on the list would disagree. Juniper was and still is
fundamentally automation friendly, where as even IOS-XR is not, as
there is no single source of truth from which CLI and machine
presentation is built. IOS-XR also has very contrived commit process,
as there is no 'configuration' or 'commit' component team, commit for
tunnels is owned by tunnel component team, commit for BGP is owned by
BGP component team. The commit working as well as it does in IOS-XR is
surprising. Commit/configuration process should not be of any concern
to say BGP developer, it should be free magic provided by the
infrastructure. You have very one-dimensional view to this.
In the RFPs I've been involved there never has been any significant
price advantage in JNPR to CSCO, both been available at similar
commercial terms to us.

> In HW MX-es internal architecture will *never be as solid as ASR9k's one.

This is matter of debate. I'd view Trio next-generation to EZChip. I'd
expect for example NPU class device to support fragmentation in HW
(crucial in many mobile deployments) which ASR9k does not do. For me
also punt architecture in ASR9k is inferior to MX. However CSCO has
something very very interesting in HW pipeline, and I have high trust
they can execute the HW, but I have very little hopes IOS-XR will be
fixed in meaningful manner. My feeling is, internally no hard problems
can be fixed in IOS-XR, because if problem touches >1 component team,
there seem no process to do that, it's more desirable to add
technological debt and do massive hacks to get problem fixed inside
single component, rather than fix some architectural problem which
requires multicomponent fixes.
The clear benefit I see in ASR9k HW architecture is multicast, but
that's never been relevant to me.

> 1) In general Junos is trailing XR in development (the gap seem to be around
> a year or little over), so if you need a new feature it'll be cutting edge
> on Junos while old news in XR.

I think it's easy to show examples in both direction. IOS-XR was over
decade later with flowspec?

> 2) Junos is truly suffering from its monolithic nature (everything in RPD),
> in XR you can install only what you need reducing the bug surface, and the
> modularity allows for faster development.

This is heavily contested opinion. Yes, on paper IOS-XR architecture
is more elegant. In practice I have more customer effecting defects in
IOS-XR than JunOS customers, more BGP scaling issues, more
configuration size issues. The flip side in multiprocess architecture
like IOS-XR is that you end up state duplicating as some state simply
isn't fast enough in the IPC design, and once you end up state
duplicating you expose yourself to state sync problems.

> 3) In XR installing SMUs or PIEs to fix bugs is business as usual right, but
> how many of you are familiar with JSUs to do the same in Junos -the
> framework is so rarely used by customers that it's buggy in itself.

The SMU is fallacy in my opinion, the SMUs are marketed as spot fixes
to specific DDTS, while they really are just shipping newer version
for set of binaries. So you get into this confusing state where to
install DDTSx you must uninstall DDDTSy and install DDTSz. It would be
far easier if they didn't have so much marketing pixie dust, if they
didn't call SMUs DDTS, but just call SMUs by the version of binaries
you ship, and say DDTS requires BGP 4.2 and RIB 2.2 or newer, then no
one would find it confusing you don't need older versions of BGP and
RIB installed and that anything 4.1 BGP fixes, 4.2 BGP fixes.
But even if they do fix this communication problem, the whole SMU is
almost always useless complexity for vendor, as for us router is
mostly BGP control plane, if update flaps BGP there is no upsize to
reload for us. It would be so much simpler to engineer router which
boots in 30seconds and supports 0 patching, than to do this. I would
prefer the former. Obviously the best solution would be router where I
can update everything without reloading or flapping anything in
control-plane, (why can I do that in my irssi, but not in my IOS-XR
BGP?) but I can't see that happening any time soon, and I'm not going
to pay vendor premium to make it happen, I'm good restarting router
2-4 times a year, as long as the update process doesn't take 3-4
hours.

> Anyhow, I'm glad you, and I'm sure many others on the list, have a positive
> experience with Juniper boxes, having Juniper on the market as a strong and
> healthy competitor to Cisco is essential for the whole industry.

Doesn't look so healthy to me, low volumes, low market cap, low
investor interest. JNPR is less than half of PANW market cap, and PANW
is 100% COTS no HW innovation, only security portfolio and there are
probably 10 viable firewall vendors on the market. Doesn't make any
sense to me, and it worries me how small time JNPR is.

-- 
  ++ytti