[j-nsp] Suggestions for Edge/Peering Router..

[Saku Ytti]

On Thu, 19 Sep 2019 at 16:29, <adamv0025 at netconsultings.com> wrote:

> The dynamic in Cisco implementation means that peers are automatically placed to update groups based on commonalities in export policies, regardless of the configuration.
> In juniper case you can actually have two peers with exact same export policies be part of different update groups just because they have been configured that way -which is inefficient, but who cares throw more CPU at it and you're done -real operational problem is the meaningless peer reset.

I'm not sure I've seen this, but I'm ready to accept it to be true,
but seems like something that could get PR and get fixed. Do you have
a particular example where neighbours which will export the same set
of routes and have same behaviour get separate update-groups?

> True but the argument can go both ways -in case of common memory space there's no protection so one needs to worry about leaking into different parts of memory.

Yes, the whole house of cards effect, which is very relevant in
multitenant time-shared systems like Linux server, just because sshd
crashes doesn't mean httpd should suffer. But I'm not sure if it's so
important in router.

> Hmm, but we wouldn’t second guess this multi-process approach for desktop/mobile operating systems right?

They are much less controlled system, you install nillywilly random
applications to your phone, and it's not good if phone crashes just
because some background app I already forgot crashed. And servers have
multiple tenants. I think in most cases routers have very different
profile, vendor knows exactly what is running there and it's exactly
one use-case.
Note I'm not saying multiprocess is worse than monolithic, I'm just
saying, it's not obvious to me multiprocess is the superior in this
use-case. Certainly C has exuberated the problem as it makes it too
easy to write memory unsafe code, but considering how long lived NOS
are, I think every NOS should be written in its own DSL which compiles
to C++ or Rust. Then you have more choices where given problem is best
solved.

Like forwarding code, should we write it in C or P4 which compiles to
whatever language the NPU can consume? Less capable developers will be
able to  write good code in P4 and can communicate to the smaller set
of developers who write the P4 compiler about missing features. And if
the P4 compiler developer notices some nasty hacks the P4 coders need
to write to solve some problem they can move the solution to the
compiler and have the P4 coders write something less hacky.
I think DSL as an abstraction is justified in any complex long lived project.


-- 
  ++ytti