On 23 April 2018 at 11:34, <adamv0...@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 _______________________________________________ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp