RE: 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