Subject: RE: [VRRP] status of draft-ietf-vrrp-unified-mib-06.txt

From: <[email-masked]>
Date: Fri, 2 Feb 2007 13:17:48 -0600

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-masked] [mailto:[email-masked]] 
Sent: Monday, January 29, 2007 5:04 PM
To: [email-masked]; [email-masked]; [email-masked]
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-masked]]
Sent: Sunday, January 14, 2007 8:57 PM
To: Joan Cucchiara; [email-masked]
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-masked]]
Sent:	Sun 1/14/2007 5:00 PM
To:	Carl Kalbfleisch; [email-masked]
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-masked]>
To: <[email-masked]>
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-masked]
https://www1.ietf.org/mailman/listinfo/vrrp 

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

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

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

---

From: "Steve Bates" <[email-masked]>
Date: Mon, 12 Feb 2007 10:46:06 -0700

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-masked] [mailto:[email-masked]] 
Sent: Friday, February 02, 2007 12:18 PM
To: [email-masked]; [email-masked]
Subject: RE: [VRRP] status of draft-ietf-vrrp-unified-mib-06.txt

Hi,

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-masked] [mailto:[email-masked]]
Sent: Monday, January 29, 2007 5:04 PM
To: [email-masked]; [email-masked]; [email-masked]
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.

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.

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.

Thanks,
Kalyan

-----Original Message-----
From: ext Carl Kalbfleisch [mailto:[email-masked]]
Sent: Sunday, January 14, 2007 8:57 PM
To: Joan Cucchiara; [email-masked]
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-masked]]
Sent:	Sun 1/14/2007 5:00 PM
To:	Carl Kalbfleisch; [email-masked]
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.

----- Original Message -----
From: "Carl Kalbfleisch" <[email-masked]>
To: <[email-masked]>
Sent: Thursday, January 11, 2007 6:04 PM
Subject: [VRRP] 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

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

---

From: <[email-masked]>
Date: Mon, 12 Feb 2007 13:08:16 -0600

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-masked]] 
Sent: Monday, February 12, 2007 9:46 AM
To: Tata Kalyan (Nokia-ES/MtView)
Cc: [email-masked]; [email-masked]
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-masked] [mailto:[email-masked]]
Sent: Friday, February 02, 2007 12:18 PM
To: [email-masked]; [email-masked]
Subject: RE: [VRRP] status of draft-ietf-vrrp-unified-mib-06.txt

Hi,

Thanks,
Kalyan

-----Original Message-----
From: ext [email-masked] [mailto:[email-masked]]
Sent: Monday, January 29, 2007 5:04 PM
To: [email-masked]; [email-masked]; [email-masked]
Subject: RE: [VRRP] status of draft-ietf-vrrp-unified-mib-06.txt

Hi,

Thanks,
Kalyan

-----Original Message-----
From: ext Carl Kalbfleisch [mailto:[email-masked]]
Sent: Sunday, January 14, 2007 8:57 PM
To: Joan Cucchiara; [email-masked]
Subject: RE: [VRRP] status of draft-ietf-vrrp-unified-mib-06.txt

Joan,

Carl

-----Original Message-----
From:	Joan Cucchiara [mailto:[email-masked]]
Sent:	Sun 1/14/2007 5:00 PM
To:	Carl Kalbfleisch; [email-masked]
Cc:	Joan Cucchiara
Subject:	Re: [VRRP] status of draft-ietf-vrrp-unified-mib-06.txt

Hi Carl,

----- Original Message -----
From: "Carl Kalbfleisch" <[email-masked]>
To: <[email-masked]>
Sent: Thursday, January 11, 2007 6:04 PM
Subject: [VRRP] status of draft-ietf-vrrp-unified-mib-06.txt

wouldn't be against it.

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

---

From: "Steve Bates" <[email-masked]>
Date: Mon, 12 Feb 2007 14:18:54 -0700

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-masked] [mailto:[email-masked]] 
Sent: Monday, February 12, 2007 12:08 PM
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: RE: [VRRP] status of draft-ietf-vrrp-unified-mib-06.txt

Thanks Steve,

		    Backup router should return notmaster(0) when pooled. " 
           ::= { vrrpOperations 9 }  

Thanks,
Kalyan

-----Original Message-----
From: ext Steve Bates [mailto:[email-masked]]
Sent: Monday, February 12, 2007 9:46 AM
To: Tata Kalyan (Nokia-ES/MtView)
Cc: [email-masked]; [email-masked]
Subject: RE: [VRRP] status of draft-ietf-vrrp-unified-mib-06.txt

 Kalyan,

Steve

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Friday, February 02, 2007 12:18 PM
To: [email-masked]; [email-masked]
Subject: RE: [VRRP] status of draft-ietf-vrrp-unified-mib-06.txt

Hi,

Thanks,
Kalyan

-----Original Message-----
From: ext [email-masked] [mailto:[email-masked]]
Sent: Monday, January 29, 2007 5:04 PM
To: [email-masked]; [email-masked]; [email-masked]
Subject: RE: [VRRP] status of draft-ietf-vrrp-unified-mib-06.txt

Hi,

Thanks,
Kalyan

-----Original Message-----
From: ext Carl Kalbfleisch [mailto:[email-masked]]
Sent: Sunday, January 14, 2007 8:57 PM
To: Joan Cucchiara; [email-masked]
Subject: RE: [VRRP] status of draft-ietf-vrrp-unified-mib-06.txt

Joan,

Carl

-----Original Message-----
From:	Joan Cucchiara [mailto:[email-masked]]
Sent:	Sun 1/14/2007 5:00 PM
To:	Carl Kalbfleisch; [email-masked]
Cc:	Joan Cucchiara
Subject:	Re: [VRRP] status of draft-ietf-vrrp-unified-mib-06.txt

Hi Carl,

----- Original Message -----
From: "Carl Kalbfleisch" <[email-masked]>
To: <[email-masked]>
Sent: Thursday, January 11, 2007 6:04 PM
Subject: [VRRP] status of draft-ietf-vrrp-unified-mib-06.txt

-Thanks,
  Joan

Thanks,
Carl