[j-nsp] Going Juniper

[adamv0025 at netconsultings.com]

> Saku Ytti [mailto:saku at ytti.fi]
> Sent: Monday, April 23, 2018 10:20 AM
> 
> 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.
> 
Well I envy you then :).  
But was it for more-less like to like HW? -say modular card in both cases -similar physical/logical BW to fabric and similar modules with similar port count? 
Was it just one time RPF discount or a pricing framework for future deals. 
But price is just one part of it there's the whole ecosystem as well and with Juniper I feel like they actually listen while with Cisco you need to be at&t size to get meaningful attention. 
 

> > 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.
> 
Now with the knob available in 17 Junos the benefit of A9k architecture is reduced to the ability to protect high priority traffic when NPU is overloaded down to 10GE entity level whereas on Juniper it's just per NPU as a whole.


> > 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?
> 
That's why I say in general, sure there are exceptions.

> > 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.
> 
Interesting, just curious how may VRFs/prefixes you ran into scaling issues?
-but I think these scaling issues are inevitable in high scale deployments -it's just a nature of parsing through big tables.  
My point is Junos folks know what to do to improve their BGP implementation and most of the stuff is there in the pipeline, it just takes ages to implement due to BGP sitting with a bunch of other stuff in the RPD.    

> > 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.
> 
That's certainly a valid viewpoint on the patches thing.
I'm looking at it from a different angle though, the angle I'm looking at it is software testing (regression testing in particular). 
We spend significant effort on SW testing making sure it works as expected, now if midway or god forbid towards the end of the whole exercise we find out a show stopper we can't afford to repeat the whole process again for a different release that doesn't have this problem (or wait for one to be developed) this is where targeted patches are great help -you just need to test dependencies for the delta then. 
(and no having vendor to do the bug scrub and recommend bug free code for your specific case is not the solution, will get you some head start but you still need to perform the rigorous testing). 
    

> > 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.
> 
Hmm that's worrying to hear actually, for a number of reasons.

adam

netconsultings.com
::carrier-class solutions for the telecommunications industry::