[j-nsp] RE-S-X6-64G-BB

[Colton Conor]

Assuming we are not going to be using these new RE's to load any 3rd party
software on them, the RE-S-X6-64G-BB will just be a quicker processor with
more ram compared to an older RE right? Are there any other benefits?
Juniper is offering the RE-S-X6-64G-BB for the same price as
the RE-S-1800X4-32G. Not sure why one would not go with the new RE with
more ram?

On Wed, May 25, 2016 at 9:34 AM, Saku Ytti <saku at ytti.fi> wrote:

> On 25 May 2016 at 17:10, raf <raph at futomaki.net> wrote:
>
> Hey,
>
> > On this point I disagree. Virtualization add a layer and a little
> overhead,
> > but nowadays it's a mature and stable technologies.
> > And splitting things and decoupling them are always a good things for
> me. I
> > talk about junos which was a relatively complex architecture; and
> splitting
> > them between muliple vm(s) shoud be good.
> > Two other point come in my mind : the opportunity to have an second
> virtual
> > standby RE, which it good for upgrade.
> > Or something I haven't considered at first, the reborn of real logicial
> > systems (multi tenant).
>
> I'm not sure we disagree. You're talking about virtualisation like
> we're moving components off JunOS into separate VM's, but this is not
> what is happening. These VM's are marketed to be there mostly for
> external/3rd party applications.
> Surely we agree, adding 3rd party VM on router cannot increase reliability.
>
> If vendors would be doing, what you're hoping, distributing their own
> control-plane in multiple VM (IOS-XR is sort of doing this, in LXC
> containers). Then I really have to ask, if you can talk between VM or
> LXC, why not talk over network, and have your compute separately for
> those components.
>
> > Yep unfortunately. I really think rpd design must be rethink-ed.
>
> I don't think anything major is being done to rpd in the roadmap,
> other than more threads on the single process.
>
> > Sure; but often network components are relatively isolated of the rest of
> > the DCs, so running all of them on a big hypervisor close to the
> forwarding
> > engine make sense (at least for me).
>
> Adding 1RU dell server to the rack wouldn't a problem. And perhaps
> this is options we can do in future, buy forwarding-plane box and then
> hook control-plane hardwares over ethernet to it. If we can separate
> control-plane on multiple VM, we can also do this. And I like the
> latter option even more.
>
> > Ah completely agree on this. Perhaps running small utilites vm (DNS,
> tools);
> > but corner case use.
>
> I don't see those corner cases as particularly useful. I can't help to
> wonder, is VM a white-label play in disguise? Are some customers not
> running IOS-XR/JunOS at all, just not starting that VM, instead
> running own VM with under NDA documents how to program the hardware?
> Or is the 3rd party VM just marketing gimmick, because they get VM
> 'for free', as they need it for their own infrastructure, to provide
> better redundancy, upgradability and loose coupling to underlaying
> control-plane HW. So as it is going to be there anyhow, no harm done
> investing some marketing efforts to see if market figures out if there
> is application for 3rd party VMs.
>
> --
>   ++ytti
> _______________________________________________
> juniper-nsp mailing list juniper-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
>