RE: Changing master priority without going down

 Hi Mortensen,
	 I was not around during RFC2787 discussions and so do not know
the answer to your Question.  Replying as I am currently working on
unified MIB.

I agree with you that RFC2338 doesn't specify this restriction and the
restriction is 
only in the MIB and not in the protocol.

We made some changes to unified MIB which is based on RFC 2787 and it
mentions :

               "The RowStatus variable should be used in accordance to 
               installation and removal conventions for conceptual  
               rows. When `vrrpOperationsRowStatus' is set to  
               active(1), no other objects in the conceptual row can 
               be modified. .."

I think this should be ok. Please let me know if you have any comments
on this.

Thanks,
Kalyan

-----Original Message-----
From: ext Kjeld Mortensen [mailto:[email protected]] 
Sent: Tuesday, November 13, 2007 6:54 AM
To: [email protected]
Subject: [VRRP] Changing master priority without going down

I have noticed that RFC2787 (Definitions of Managed Objects for the
Virtual Router Redundancy Protocol) under vrrpOperRowStatus describes
that:

 "...
  When `vrrpOperRowStatus' is set to active(1), no other
  objects in the conceptual row, with the exception of
  `vrrpOperAdminState', can be modified. Prior to setting the
  `vrrpOperRowStatus' object from `active' to a different value,
  the `vrrpOperAdminState' object must be set to `down' and the
  `vrrpOperState' object be transitioned to `initialize'.
  ..."

The implication of this is that if you change the, say, priority of the
master, then it will always transition to "initialize" and then "backup"
-- even if the master priority is set to a higher value. As far as I can
see this is an unnecessary restriction of RFC2338 (Virtual Router
Redundancy Protocol), and the VRRP protocol state machine should be able
to handle priority changes without taking the master down. Although the
restriction will make the MIB implementation simpler I don't really see
why it is necessary to describe such a restriction in the MIB.

Do you agree that RFC2338 does not imply such a restriction which
RFC2787 describes?

What is the motivation for describing such a restriction in RFC2787?

Regards,

/Kjeld H. Mortensen

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

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