On Thu, 19 Sep 2019 at 15:11, <[email protected]> wrote: > Ideally I'd like to see equivalent of Cisco's dynamic update peer-groups in > Junos.
They are dynamic, but once you make export change which affects subset of members in peer-group, that member gets reset while placed to new update-group. > Right this inconsistency between configured and operational state in my > opinion is THE biggest problem of XR, I'm afraid it has to be something > fundamental since they haven't been able to consistently address these > inconsistencies across the board for years now (or ASR9k HW? Not sure if > these types of issues can be experienced on other platforms). It is fundamental with non-monolithic design, because processA has no access to the memory of processB you need IPC, which for many things is too slow, so you replicate state and sync the state, which increases complexity and adds bugs. The argument against monolithic design is that single component failure will bring the whole house of cards down. I think this is debatable, if it's BGP or ISIS or LDP or oror which fails, my whole system is dead anyhow, router isn't multiservice multitenant in most cases, all pieces are needed and any piece failure is total failure. Hopefully Juniper avoids the pitfalls with Evolved, I'm not sure how. It seems like a complex problem to me. Having own DSL which compiles with many safety guarantees, to tune of rust, perhaps monolithic design is what you want, perhaps using the kernel facilities for multiprocess isn't the right solution, I don't think it's axiomatically true multiprocess is right solution. -- ++ytti _______________________________________________ juniper-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/juniper-nsp
