RE: status of draft-ietf-vrrp-unified-mib-06.txt

"Steve Bates" <[email protected]>
Newsgroups gmane.ietf.vrrp
Message-ID <[email protected]> 
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: [email protected] [mailto:[email protected]] 
Sent: Monday, February 12, 2007 12:08 PM
To: [email protected]
Cc: [email protected]; [email protected]
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:[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.