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

From: <[email-masked]>
Date: Wed, 2 Jul 2008 08:23:10 +0300

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-masked]] 
Sent: Friday, June 27, 2008 5:52 AM
To: [email-masked]; 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-masked]
https://www.ietf.org/mailman/listinfo/vrrp

---

From: "G. C." <[email-masked]>
Date: Wed, 2 Jul 2008 08:57:50 -0400

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-masked]> 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
> should add vrrpTrapProtoErrorEnable which by default     is enabled but
> can be turned off?
>
> 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-masked]]
> *Sent:* Friday, June 27, 2008 5:52 AM
> *To:* [email-masked]; Tata Kalyan (Nokia-S&S/MtView)
> *Subject:* draft-ietf-vrrp-unified-mib-06: Usage of vrrpTrapProtoError
>
> 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
>