Re: [VRRP] draft-ietf-vrrp-unified-mib-06: Usage of vrrpTrapProtoError

["G. C." <georgesa at gmail.com>]

Hi Kaylan,

I propose that vrrpTrapProtoErrorEnable  should be disabled by default.  The operator can then turn this on if (s)he cares about receiving this trap.  On a scaled system with numerous interfaces configured with multiple VRRPs, these traps will have a big impact and we won't be able to maintain sub-second timers as recommended by the VRRP draft.

Regards,
Georges Chung

On Wed, Jul 2, 2008 at 1:23 AM, <Kalyan.Tata at nokia.com> wrote:

Hi Georges,

    As I remember, the original intent was to identify miss configurations using this trap. You are correct that this needs to be sent every time

    the error condition happens and could cause overhead. probably we should add vrrpTrapProtoErrorEnable which by default

    is enabled but can be turned off?

 

    I promised Mukesh that I will start working on updating the draft in the next couple of weeks. I will update the draft based on the WG suggestion on this.

   

Can the reason hopLimitError be renamed to IpTllError to be consistent with vrrpStatisticsIpTtlErrors?

Will do.

 

Thanks,
Kalyan

 

---

From: ext G. C. [mailto:georgesa at gmail.com]
Sent: Friday, June 27, 2008 5:52 AM
To: vrrp at ietf.org; Tata Kalyan (Nokia-S&S/MtView)
Subject: draft-ietf-vrrp-unified-mib-06: Usage of vrrpTrapProtoError

After reading the draft, I am under the impression that the trap vrrpTrapProtoError is expected to be raised every time an error condition happens.  Can someone please confirm whether this is indeed the intention of the draft?

This means that there will be lots of these being raised, one per offending packet that is received.  This will add unnecessary overhead to the CPU.

Can the reason hopLimitError be renamed to IpTllError to be consistent with vrrpStatisticsIpTtlErrors?

Thanks,
Georges Chung

_______________________________________________
vrrp mailing list
vrrp at ietf.org
https://www.ietf.org/mailman/listinfo/vrrp