Thanks Steve,
We do have the reason in the current draft for vrrpTrapNewMaster :
vrrpNewMasterReason OBJECT-TYPE
SYNTAX INTEGER {
notmaster (0),
priority (1),
preempted (2),
masterNoResponse (3)
}
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This indicates the reason for vrrpNewMaster trap.
The object can be polled if the vrrpNewMaster trap
is lost to identify the reason for transission.
Backup router should return notmaster(0) when
pooled. "
::= { vrrpOperations 9 }
I will rename this to vrrpStateChangeReason.
Do you think a previous state in the notification will be useful?
Thanks,
Kalyan
-----Original Message-----
From: ext Steve Bates [mailto:[email protected]]
Sent: Monday, February 12, 2007 9:46 AM
To: Tata Kalyan (Nokia-ES/MtView)
Cc: [email protected]; [email protected]
Subject: RE: [VRRP] status of draft-ietf-vrrp-unified-mib-06.txt
Kalyan,
I have no problem with this change. It could be quite useful, but I
assume we would need to come up with a list of reason codes?
Steve
-----Original Message-----
From: [email protected] [mailto:[email protected]]
Sent: Friday, February 02, 2007 12:18 PM
To: [email protected]; [email protected]
Subject: RE: [VRRP] status of draft-ietf-vrrp-unified-mib-06.txt
Hi,
I would like some working group opinion on deprecating vrrpTrapNewMaster
and adding vrrpStateChange notification as Carl suggested.
vrrpStateChange NOTIFICATION-TYPE
OBJECTS { vrrpOperationsMasterIpAddr, vrrpOperationsState,
vrrpStateChangeReason }
STATUS current
DESCRIPTION
"Notification of VRRP state change."
::= { vrrpNotifications 4 }
Will it be useful to include a previous state in the notification?
If we deprecate vrrpTrapNewMaster, I can change the names of newly added
objects to not contain the word 'trap'.
Thanks,
Kalyan
-----Original Message-----
From: ext [email protected] [mailto:[email protected]]
Sent: Monday, January 29, 2007 5:04 PM
To: [email protected]; [email protected]; [email protected]
Subject: RE: [VRRP] status of draft-ietf-vrrp-unified-mib-06.txt
Hi,
Sorry for the delay, I was out of country for the past two
months (with limited email access).
Thanks Joan for the reply. Sorry I missed informing you about
the draft. I was in a hurry to
submit it before leaving and missed emailing you.
1) is it possible to add a vrrpStateChange notification or a
notification for each state. Our requirements require notification from
a device when it EXITS master state. Currently the vrrpTrapNewMaster
only indicates when the system goes into the master state. Having an
indication of backup and initialization states as notifications allows
the management station to correlate when the state changes without
polling.
Kalyan: Management stations cannot rely on receiving a trap indicating
that master is EXITing the
state - for example some one tripped over power cable or even when the
interface goes down.
Please correct me if that is not true.
On the other hand, As Carl mentioned in another offline mail (included
below), Just a generic state change trap might be useful. I do remember
some discussion during the introduction of 'vrrpNewMasterReason' but
could not find in the mailing list archive. Anyone in the mailing list
have a memory of this?
I am tempted to think that a generic state change might be a good idea
but am not convinced that management stations can rely on trap to
indicate the current state (other than the state change to master) with
out polling.
Let us discuss this and I will change the draft as decided by the
working group.
2) is it possible to create an additional conformance statement without
the statistics group. This would simply make it easier to implement a
read-only agent implementation.
- As Joan indicated, I think these statistics are important even for a
basic readonly implementation.
Following is Carl's mail :
---------
I'd like to see the following notification added to the MIB:
vrrpStateChange NOTIFICATION-TYPE
OBJECTS { vrrpOperationsMasterIpAddr, vrrpOperationsState,
vrrpStateChangeReason }
STATUS current
DESCRIPTION
"Notification of VRRP state change."
::= { vrrpNotifications 4 }
Would need to define the vrrpStateChangeReason as well. This could
replace the New Master notification or be in addition to it. The idea is
that we would then get notification of all state changes. An NMS would
use this information to clear alerts from previous notifications.
Without it there is no asynchronous way to know of all state changes.
Please let me know what you think.
-------------
Thanks,
Kalyan
-----Original Message-----
From: ext Carl Kalbfleisch [mailto:[email protected]]
Sent: Sunday, January 14, 2007 8:57 PM
To: Joan Cucchiara; [email protected]
Subject: RE: [VRRP] status of draft-ietf-vrrp-unified-mib-06.txt
Joan,
Thanks for your response. There is not a particular stat in question. It
was just to try to save some development time. Will try to get the stats
implemented.
Carl
-----Original Message-----
From: Joan Cucchiara [mailto:[email protected]]
Sent: Sun 1/14/2007 5:00 PM
To: Carl Kalbfleisch; [email protected]
Cc: Joan Cucchiara
Subject: Re: [VRRP] status of draft-ietf-vrrp-unified-mib-06.txt
Hi Carl,
Thanks for pointing out that there is now a version 6.
I didn't see the announcement. I did a MIB Dr. review of version 5, so
will take a look at version 6 also.
My comments are inline below, prefaced with Joan:
----- Original Message -----
From: "Carl Kalbfleisch" <[email protected]>
To: <[email protected]>
Sent: Thursday, January 11, 2007 6:04 PM
Subject: [VRRP] status of draft-ietf-vrrp-unified-mib-06.txt
What is the status of draft-ietf-vrrp-unified-mib-06.txt?
Joan: It is in the process of the MIB Dr. review. As stated above,
Joan: version 6 is recent and will be reviewed.
Joan: Comments on version 5 were in the June, July and Oct 2006
timeframe
I am interested in implementing this in a product and have a couple
comments.
1) is it possible to add a vrrpStateChange notification or a
notification for each state. Our requirements require notification from
a device when it EXITS master state. Currently the vrrpTrapNewMaster
only indicates when the system goes into the master state. Having an
indication of backup and initialization states as notifications allows
the management station to correlate when the state changes without
polling.
Joan: If the working group is interested in adding this, then I
wouldn't be against it.
2) is it possible to create an additional conformance statement without
the statistics group. This would simply make it easier to implement a
read-only agent implementation.
Joan: I would advise against this. These statistics for the ReadOnly
conformance are informative. Yes, it would make
Joan: the implementation easier, but these statistics give much
information and should be supported for
Joan: a readonly conformance in my opinion. Is there a specific
statistic or statistics that are an issue?
-Thanks,
Joan
Thanks,
Carl
_______________________________________________
vrrp mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/vrrp
_______________________________________________
vrrp mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/vrrp
_______________________________________________
vrrp mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/vrrp
_______________________________________________
vrrp mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/vrrp
_______________________________________________
vrrp mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/vrrp
lmpx.com only provides a reader for public news (NNTP) servers. It is not
affiliated with the servers or forums shown here and is not responsible for
the content of articles, which is written by their respective authors.