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

[raf]

Le 23/05/2016 à 18:57, Saku Ytti a écrit :
>
> I think this is driven by not having options mostly, freescale isn't
> there for today's control-plane scale
Yes absolutely; but as a side effect we should have a much reactive 
control plane while junos was primarily coded on x86; and porting on 
other architecture isn't the juniper best success.
> Sure, it's better than logical-systems but still, it's added
> complexity, which reduces availability. BOM of HW is small. I'd rather
> pay premium to have more robust network.
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).

Obviously this is only valid on high end device with good cpu and lot of 
RAM.
>
> I don't understand your arguments. You're saying it's more complicated
> to do IPC inside single machine than between two different machines?
No no. I just saying that splitting junos component between vm(s) could 
allow better CPU/Ram capping between them.
And it was a first step to distribute them. But as you mention it junos 
is rather monolithic.
> The problem today for JunOS is, that largely everything is inside
> single OS process. So it does not matter how good FreeBSD or Linux
> kernel is doing this stuff, it matters how good Juniper is doing this
> stuff. And Juniper isn't even planning on moving stuff away from RPD,
> but rather introduce OS threads.
Yep unfortunately. I really think rpd design must be rethink-ed.
>
> If we could move significant portions of the control-plane to another
> VM, then we need to do IPC over network. If you can produce
> control-plane which allows for this, then why distribute the work to
> another VM, why not distribute it dedicated compute over network?
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).
> Having said that, my concern on reliability wasn't on vendor itself
> distributing work on VMs, but we, the customers, running our own VMs
> in the router hardware, and I don't see any wins there, just reduced
> availability of whole system.
>
Ah completely agree on this. Perhaps running small utilites vm (DNS, 
tools); but corner case use.

--
Raphael Mazelier