Subject: [pim] PIM yang model counter 64/32 bit

From: Anish Peter <[email-masked]>
Date: Wed, 7 Mar 2018 21:57:08 +0530

Hello PIM group,
 We are doing pim yang model and came across this question of whether to
use a 64/32 bit counter for packet statistics. To the best of our knowledge
all the vendor models support 32bit counters.
 But given that we are having more scalable implementations, we had a
feeling that a 32bit counter may rollover too fast. To give some examples.

Right now now we have routers with more than 10K pim interfaces supported.
In such case even if we consider them to be p2p always, then it would mean
10K pim nbrs. In this case even if an aggressive hello timer of 10 seconds
is configured then it would transmit and receive about 60K pim hellos per
minute. This leads to about 86.4million hello per day. This way a 32bit counter
could roll over in less than 50 days. Half a decade back I had tested pim
for 4K interfaces with 1s hello interval. With this the same counter may
roll over in about 12 days time.

Similarly a pim null register and register stop too for a scale of 15K
group could easily roll over in less than 198 days.

The vendor counters are 32 for historic reasons and may not directly get
impacted by a stats model supporting 64bit.

 Please share your opinion.

Thanks,
pim yang model authors

---

From: Stig Venaas <[email-masked]>
Date: Wed, 7 Mar 2018 09:31:24 -0800

Hi

To me it seems like a great idea to make the counters 64 bit. I expect
there will be pim implementations using 64 bit counters, and I don't
think backwards compatibility with 32 bit implementations is an issue
since the counters are read-only. If you do this for this draft,
please make a similar change in the other multicast YANG models
(igmp/mld/msdp/snooping).

Stig

On Wed, Mar 7, 2018 at 8:27 AM, Anish Peter <[email-masked]> wrote:
> Hello PIM group,
>  We are doing pim yang model and came across this question of whether to use
> a 64/32 bit counter for packet statistics. To the best of our knowledge all
> the vendor models support 32bit counters.
> minute. This leads to about 86.4million hello per day. This way a 32bit
> counter could roll over in less than 50 days. Half a decade back I had
> tested pim for 4K interfaces with 1s hello interval. With this the same
> counter may roll over in about 12 days time.
>
> Similarly a pim null register and register stop too for a scale of 15K group
> could easily roll over in less than 198 days.
>
>

---

From: <[email-masked]>
Date: Thu, 8 Mar 2018 09:55:04 +0000

Hi,

I think it’s a good idea to move to 64 bit counters. Depending on the size (and configuration of certain timers) you might exceed a 32 bit counter quite fast.

regards

Nic

Von: pim [mailto:[email-masked]] Im Auftrag von Anish Peter
Gesendet: Mittwoch, 7. März 2018 17:27
An: [email-masked]
Cc: [email-masked]
Betreff: [pim] PIM yang model counter 64/32 bit

Hello PIM group,
 We are doing pim yang model and came across this question of whether to use a 64/32 bit counter for packet statistics. To the best of our knowledge all the vendor models support 32bit counters.
 But given that we are having more scalable implementations, we had a feeling that a 32bit counter may rollover too fast. To give some examples.

Right now now we have routers with more than 10K pim interfaces supported. In such case even if we consider them to be p2p always, then it would mean 10K pim nbrs. In this case even if an aggressive hello timer of 10 seconds is configured then it would transmit and receive about 60K pim hellos per minute. This leads to about 86.4million hello per day. This way a 32bit counter could roll over in less than 50 days. Half a decade back I had tested pim for 4K interfaces with 1s hello interval. With this the same counter may roll over in about 12 days time.

Similarly a pim null register and register stop too for a scale of 15K group could easily roll over in less than 198 days.

The vendor counters are 32 for historic reasons and may not directly get impacted by a stats model supporting 64bit.
 Please share your opinion.
Thanks,
pim yang model authors