RE: Unified VRRP-MIB: vrrpNewMasterReason

I  mean Polled and not Pooled ..

Thanks, 
Kalyan 

 

________________________________

From: ext [email protected] [mailto:[email protected]] 
Sent: Wednesday, December 05, 2007 5:38 PM
To: [email protected]; [email protected]
Subject: RE: [VRRP] Unified VRRP-MIB: vrrpNewMasterReason


hi Sylwester,    
 
- Does VRRP router need to remember the last transiting virtual router
and respond with its status? 

- What will be the relevance of sending of virtual router status that is
completely out of context? 

 

The intent was to allow management stations to identify the reason a
system became master even when notifications are

lost.  You bring up a good issue regarding the state not having a
context when pooled. This needs to be corrected in 

next revision. I will fix this by including vrrpStateChangeReason (see
below) in vrrpOperationsTable. Please let me know your comments about
this change.

 
On a side note:
      One of the to-do items for the next draft is to replace
vrrpTrapNewMaster  with vrrpStateChange. We had discussions on this 
in feb/march of this year and this is one of the changes suggested by
Carl. 
 
This will also add a new vrrpStateChangeReason  replacing
vrrpNewMasterReason. 
 
I stopped working on the next revision waiting for VRRP v3 draft to be
published. Now that this is published,
I will start working on the next revision. 
 
Following is the mail I sent to the list some time back, Would
appreciate your comments :
 
=====================
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 
 


________________________________

From: ext Sylwester Chojkiewicz [mailto:[email protected]] 
Sent: Tuesday, December 04, 2007 2:01 PM
To: [email protected]
Subject: [VRRP] Unified VRRP-MIB: vrrpNewMasterReason



Hi,

 

I have been implementing the unified  VRRP MIB and was stopped when it
came to the implementation of support for the vrrpNewMasterReason object
{vrrpOperations 9}.

Per the MIB provided descriptions, it can serve two goals:

-          It can be delivered with vrrpTrapNewMaster, along the
vrrpOperationsMasterIpAddr object

-          It can be pooled "if the vrrpTrapNewMaster is lost to
identify the reason for "transmission..." (N.B: Should not it be
"transition", instead?).

 

As far as the "polling" is concerned, assuming the following:

1.	The VRRP router is running several virtual routers at the same
time 
2.	Each virtual router can become Master or Backup at any time -
independently of the others 
3.	The polling message does not identify any specific virtual
router 

-- the question sounds as follow:

 

Which virtual router status needs to be returned in response to the
polling of the VRRP router? 

 

Does VRRP router need to remember the last transiting virtual router and
respond with its status? 

What will be the relevance of sending of virtual router status that is
completely out of context? 

 

I will appreciate your prompt answer.

 

Thanks,

Sylwester

_______________________________________________
vrrp mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/vrrp