[prev in list] [next in list] [prev in thread] [next in thread]
List: ietf-vrrp
Subject: RE: [VRRP] status of draft-ietf-vrrp-unified-mib-06.txt
From: "Steve Bates" <Steve.Bates () alcatel-lucent ! com>
Date: 2007-02-12 21:18:54
Message-ID: 200702122117.NAA03781 () omni ! ind ! alcatel ! com
[Download RAW message or body]
Kalyan,
It depends on the amount of information we choose to convey. The reason
codes you've indicated are geared toward a virtual router becoming master
and I'm not sure how applicable they are to reporting all state changes.
For example a virtual router can transition from master to backup when the
address owner comes online. We can report this as deferring to a higher
priority but what if the owner's advertisement does not match the configured
parameters and we're actually deferring only because it's the address owner.
Would deferring to address owner be a better reason code? If the reason
codes are relatively detailed the previous state would be superfluous.
Steve
-----Original Message-----
From: Kalyan.Tata@nokia.com [mailto:Kalyan.Tata@nokia.com]
Sent: Monday, February 12, 2007 12:08 PM
To: Steve.Bates@alcatel-lucent.com
Cc: jcucchiara@mindspring.com; vrrp@ietf.org
Subject: RE: [VRRP] status of draft-ietf-vrrp-unified-mib-06.txt
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:Steve.Bates@alcatel-lucent.com]
Sent: Monday, February 12, 2007 9:46 AM
To: Tata Kalyan (Nokia-ES/MtView)
Cc: jcucchiara@mindspring.com; vrrp@ietf.org
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: Kalyan.Tata@nokia.com [mailto:Kalyan.Tata@nokia.com]
Sent: Friday, February 02, 2007 12:18 PM
To: jcucchiara@mindspring.com; vrrp@ietf.org
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 vrrp-bounces@ietf.org [mailto:vrrp-bounces@ietf.org]
Sent: Monday, January 29, 2007 5:04 PM
To: carlk@netrake.com; jcucchiara@mindspring.com; vrrp@ietf.org
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:carlk@netrake.com]
Sent: Sunday, January 14, 2007 8:57 PM
To: Joan Cucchiara; vrrp@ietf.org
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:jcucchiara@mindspring.com]
Sent: Sun 1/14/2007 5:00 PM
To: Carl Kalbfleisch; vrrp@ietf.org
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" <carlk@netrake.com>
To: <vrrp@ietf.org>
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
vrrp@ietf.org
https://www1.ietf.org/mailman/listinfo/vrrp
_______________________________________________
vrrp mailing list
vrrp@ietf.org
https://www1.ietf.org/mailman/listinfo/vrrp
_______________________________________________
vrrp mailing list
vrrp@ietf.org
https://www1.ietf.org/mailman/listinfo/vrrp
_______________________________________________
vrrp mailing list
vrrp@ietf.org
https://www1.ietf.org/mailman/listinfo/vrrp
_______________________________________________
vrrp mailing list
vrrp@ietf.org
https://www1.ietf.org/mailman/listinfo/vrrp
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic