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

"G. C." <[email protected]> Wed, 2 Jul 2008 08:57:50 -0400
Newsgroups gmane.ietf.vrrp
Message-ID <[email protected]>
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, <[email protected]> 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:[email protected]]
> *Sent:* Friday, June 27, 2008 5:52 AM
> *To:* [email protected]; 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
[email protected]
https://www.ietf.org/mailman/listinfo/vrrp