Subject: [VRRP] draft-ietf-vrrp-unified-mib-07 - deprecating vrrpTrapNewMaster

From: <[email-masked]>
Date: Wed, 11 Mar 2009 02:15:08 +0200

Hi,
	I started working on the new draft for the unified VRRP MIB. 
	One of the todo items was to change the vrrpTrapNewMaster. 
	Following is the mail I sent some time back - Resending this to
	see if I get any input before I change this in version 7 of the
draft:

I would like some working group opinion on deprecating vrrpTrapNewMaster
and adding vrrpStateChange notification.

Request from Carl Kalbfleisch  :
--------
 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. 

Proposed :
--
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?

===

Thanks,
Kalyan

---

From: "Joan Cucchiara" <[email-masked]>
Date: Fri, 13 Mar 2009 08:32:40 -0500

----- Original Message ----- 
From: <[email-masked]>
To: <[email-masked]>
Sent: Tuesday, March 10, 2009 7:15 PM
Subject: [VRRP] draft-ietf-vrrp-unified-mib-07 - 
deprecatingvrrpTrapNewMaster

> and adding vrrpStateChange notification.

I would be in favor of this.  As Carl states below, being able to correlate 
the state
changes would  be beneficial.

> station to correlate when the state changes without polling.

If the NMS missed one notification (i.e. a state change) then this
might be useful, but if more than one notification (i.e. few state changes) 
were
missed, then this might be more confusing.

The alternative is that informs be used instead of notifications, or that 
the NMS
poll for the info, or that the NMS be smart enough to deal with missed state 
change within the
its correlation (which it probably needs to do even if using informs or 
polling).

So, I would say sending the previous state doesn't hurt, but may not help 
too much.

Thanks,
   -Joan

> ===
>
> Thanks,
> Kalyan
> _______________________________________________
> vrrp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/vrrp

---

From: <[email-masked]>
Date: Tue, 17 Mar 2009 00:08:57 +0200

Thanks Joan. I deprecated vrrpTrapNewMaster in favor of vrrpStateChange
notification.

>So, I would say sending the previous state doesn't hurt, but 

I agree, previous state may not be useful. 
I will send a separate email regarding VRRPstateChangeReason that should
be included in the notification.

Thanks
Kalyan

---

From: <[email-masked]>
Date: Tue, 17 Mar 2009 02:33:06 +0200

Hi,
	Following are the enumerations for the
vrrpOperationsStateChangeReason.

Prev State  New State   Reason
==================================

Initialize  Master      addressOwner (0)
Initialize  Backup      notAddressOwner (1) 

Master      Backup      higherPriorityAdvtRcvd (2)  higherPrimeryAddress
(3)
Master      Initialize  shutdownReceived 	(5)

Backup      Master      masterDownTimerExpired (4)
Backup      Initialize  shutdownReceived 	(5)

Please let me know if I missed something.	

Thanks,
Kalyan