I tried to advocate for both, sorry if I was unclear. ORR for good options, add-path for redundancy and/or ECMPability.
On Fri, 8 Dec 2023 at 19:13, Thomas Scott <tsc...@digitalocean.com> wrote: > > Why not both add-path + ORR? > -- > > Thomas Scott > Sr. Network Engineer > +1-480-241-7422 > tsc...@digitalocean.com > > > On Fri, Dec 8, 2023 at 11:57 AM Saku Ytti via juniper-nsp > <juniper-nsp@puck.nether.net> wrote: >> >> On Fri, 8 Dec 2023 at 18:42, Vincent Bernat via juniper-nsp >> <juniper-nsp@puck.nether.net> wrote: >> >> > On 2023-12-07 15:21, Michael Hare via juniper-nsp wrote: >> > > I recognize Saku's recommendation of rib sharding is a practical one at >> > > 20M routes, I'm curious if anyone is willing to admit to using it in >> > > production and on what version of JunOS. I admit to have not played >> > > with this in the lab yet, we are much smaller [3.5M RIB] worst case at >> > > this point. >> > >> > About the scale, I said routes, but they are paths. We plan to use add >> > path to ensure optimal routing (ORR could be another option, but it is >> > less common). >> >> Given a sufficient count of path options, they're not really >> alternatives, but you need both. Like you can't do add-path <max>, as >> the clients won't scale. And you probably don't want only ORR, because >> of the convergence cost of clients not having a backup option or the >> lack of ECMP opportunity. >> >> -- >> ++ytti >> _______________________________________________ >> juniper-nsp mailing list juniper-nsp@puck.nether.net >> https://puck.nether.net/mailman/listinfo/juniper-nsp -- ++ytti _______________________________________________ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
