[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [VRRP] draft-ietf-vrrp-unified-mib-06: Usage of vrrpTrapProtoError
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
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. TFrom vrrp-bounces at ietf.org Tue Jul 1 22:23:25 2008
Return-Path:
X-Original-To: vrrp-archive at megatron.ietf.org
Delivered-To: ietfarch-vrrp-archive at core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1])
by core3.amsl.com (Postfix) with ESMTP id 5F1CE3A6875;
Tue, 1 Jul 2008 22:23:25 -0700 (PDT)
X-Original-To: vrrp at core3.amsl.com
Delivered-To: vrrp at core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
by core3.amsl.com (Postfix) with ESMTP id A41953A681C
for ; Tue, 1 Jul 2008 22:23:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.598
X-Spam-Level:
X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5
tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32])
by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id B0q9JKXUI1Tg for ;
Tue, 1 Jul 2008 22:23:23 -0700 (PDT)
Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233])
by core3.amsl.com (Postfix) with ESMTP id 7C72E3A6875
for ; Tue, 1 Jul 2008 22:23:23 -0700 (PDT)
Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213])
by mgw-mx06.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id
m625NBxg030075; Wed, 2 Jul 2008 08:23:15 +0300
Received: from vaebh102.NOE.Nokia.com ([10.160.244.23]) by
esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959);
Wed, 2 Jul 2008 08:23:13 +0300
Received: from vaebe108.NOE.Nokia.com ([10.160.244.69]) by
vaebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959);
Wed, 2 Jul 2008 08:23:12 +0300
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Wed, 2 Jul 2008 08:23:10 +0300
Message-ID:
In-Reply-To: <4e44781e0806270551v12e131a8t18e1f62ae5bad992 at mail.gmail.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: draft-ietf-vrrp-unified-mib-06: Usage of vrrpTrapProtoError
Thread-Index: AcjYVI4q/G2CTrDyQD6QepR6NomrIQDrPwmg
References: <4e44781e0806270551v12e131a8t18e1f62ae5bad992 at mail.gmail.com>
From:
To: ,
X-OriginalArrivalTime: 02 Jul 2008 05:23:12.0690 (UTC)
FILETIME=[B900A920:01C8DC03]
X-Nokia-AV: Clean
Subject: Re: [VRRP] draft-ietf-vrrp-unified-mib-06: Usage of
vrrpTrapProtoError
X-BeenThere: vrrp at ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Virtual Router Redundancy Protocol
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
Content-Type: multipart/mixed; boundary="============== 36157126=="
Sender: vrrp-bounces at ietf.org
Errors-To: vrrp-bounces at ietf.org
This is a multi-part message in MIME format.
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 vrrpStatisticsIpTtlErrhis will add
unnecessary overhead to the CPU.<BR><BR>Can the reason hopLimitError be renamed
to IpTllError to be consistent with
vrrpStatisticsIpTtlErrors?<BR><BR>Thanks,<BR>Georges Chung<BR></BODY></HTML>
_______________________________________________
vrrp mailing list
vrrp at ietf.org
https://www.ietf.org/mailman/listinfo/vrrp