Agree. Can’t please everyone all the time. Sent from my iPhone
> On Jul 17, 2018, at 10:34 AM, Mark Tinka <mark.ti...@seacom.mu> wrote: > > > > On 17/Jul/18 16:24, Richard McGovern wrote: > >> Felt need to jump in here, and hopefully get some of the real facts >> straight. Prior to ELS CLI Juniper had basically 2 different CLI’s – one >> for EX Products and branch SRX one for MX and a like. M/MX CLI came first >> and used the terminology IRB and Bridge Domains. These products were >> designed for primarily L3, and L2 was added later. I think this started in >> like mid-1990s. >> >> From there the industry started to use VLANs for L2, and VLANs with >> associated Routing for L3 Switching. When Juniper developed their original >> EX Access switch product line they choose to use the now common term VLAN in >> their CLI, as these devices are primarily used for L2. This time frame was >> around 2008/9. This now made the original EX CLI different than the M/MX >> Junos CLI. >> >> Now fast forward to 2013. Juniper had some decisions to be made with >> regards to future platforms and strategic direction. Be it good or bad, >> Juniper decided on 2 approaches. 1 a common CLI for all future products >> (and therefore some new ‘name’), and to move away from Marvell and onto >> Broadcom as a strategic 3rd party chip vendor. This was especially for >> price competitive products, like L2 (and TOR) switches. The new [ELS] CLI >> was/is based more on MX, than older original EX for a variety of reasons, be >> they now good or bad. This is the reason that the new Broadcom based >> switches have a different [ELS based] CLI that the original EX switches. >> So, the original EX CLI and newer ELS based CLI are 100% based upon hardware >> platform in use, and not SW release, and do not BREAK anything from working. >> You cannot change from one CLI to the other via Junos SW code release >> changes. This CLI change only happens when one switches to a different >> newer hardware platform. >> >> Does this make the transition a little more difficult, yes. This is really >> no different, IMHO, then CISCO CAT CLI, vs IOS CI, etc. One difference is >> Juniper now has one solid CLI moving forward. I am not sure CISCO could make >> the same claim. >> >> FACT – all Juniper Broadcom based devices, outside of original QFX3500/3600 >> (not even 100% sure if Broadcom based) use only the newer ELS based CLI. >> Same as true for all newer and future Junos based devices. > > Thanks, Richard, for stepping in/up and contributing to this discussion. > Nothing beats the horses' mouth! > > I'm sure Juniper's decision process was very clear in their mind, and no one > can fault them for that. You're a business, and you have the make the best > call you possibly can for the future of your concern. > > The bottom line is that for some of us that found the previous CLI simpler, > and don't see the actual benefit in overly complicating it with ELS for some > (not all) of the functionality we employed, our decision process was just as > clear. > > I have no doubt that the new-generation Broadcom-based platforms will do as > well as the outgoing Marvell units. It's just a pity that we won't be on that > train; but sometimes, that's just how it goes. > > Mark. _______________________________________________ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
