> From: Saku Ytti <[email protected]> > Sent: Thursday, September 19, 2019 1:32 PM > > 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. > 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.
> > 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. 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. > 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. > Touche, you're right in routers for control plane functions is mostly all or nothing. Management plane is different, but that one is separate in both Junos and XR. Then there's the flexibility aspect, for example being able to run multiple completely separate instances of BGP would be useful in some cases. > 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. > Hmm, but we wouldn’t second guess this multi-process approach for desktop/mobile operating systems right? adam _______________________________________________ juniper-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/juniper-nsp
