[j-nsp] Hardware configuration for cRPD as RR

[Tom Beecher]

>
> No one is saying that cRPD isn't the future, just that there are a lot
> of existing deployments with vRR, which are run with some success, and
> the entire stability of the network depends on it. Whereas cRPD is a
> newer entrant, and early on back when I tested it, it was very feature
> incomplete in comparison.
> So those who are already running vRR, and are happy with it, changing
> to cRPD just to change to cRPD is simply bad risk. Many of us don't
> care about DRAM of vCPU, because you only need a small number of RRs,
> and DRAM/vCPU grows on trees. But we live in constant fear of the
> entire RR setup blowing up, so motivation for change needs to be solid
> and ideally backed by examples of success in a similar role in your
> circle of people.
>

Completely fair, yes. My comments were mostly aimed at a vMX/cRPD
comparison. I probably wasn't clear about that. Completely agree that it
doesn't make much sense to move from an existing vRR to cRPD just because.
For a greenfield thing I'd certainly lean cRPD over VRR at least in
planning. Newer cRPD has definitely come a long way relative to older. (
Although I haven't had reason or cycles to really ride it hard and see
where I can break it.... yet. :) )



On Fri, Feb 9, 2024 at 3:51 AM Saku Ytti <saku at ytti.fi> wrote:

> On Thu, 8 Feb 2024 at 17:11, Tom Beecher via juniper-nsp
> <juniper-nsp at puck.nether.net> wrote:
>
> > For any use cases that you want protocol interaction, but not substantive
> > traffic forwarding capabilities , cRPD is by far the better option.
>
> No one is saying that cRPD isn't the future, just that there are a lot
> of existing deployments with vRR, which are run with some success, and
> the entire stability of the network depends on it. Whereas cRPD is a
> newer entrant, and early on back when I tested it, it was very feature
> incomplete in comparison.
> So those who are already running vRR, and are happy with it, changing
> to cRPD just to change to cRPD is simply bad risk. Many of us don't
> care about DRAM of vCPU, because you only need a small number of RRs,
> and DRAM/vCPU grows on trees. But we live in constant fear of the
> entire RR setup blowing up, so motivation for change needs to be solid
> and ideally backed by examples of success in a similar role in your
> circle of people.
>
>
> --
>   ++ytti
>