Subject: [VRRP] . Re: Graceful Failover for VRRP

From: sreenatha setty <[email-masked]>
Date: Tue, 6 Aug 2013 11:11:00 +0530

Hi Anurag,
     I went through the draft. I have few queries. 
    The new "Change Event" you are trying to define is not actually new. In
earlier implementation also, if there is a change in Priority or
Advertisement Interval or VRIP address configurations, first VRRP will go to
Init state, then wait for some time (probably for Master down timer interval
if it's not the address owner) then becomes master if no eligible master is
available in the network.  I think only for Priority 0 configuration we need
to define new event. (I guess this you discussed over this mailing list
earlier.)
     And one more thing, I guess draft need to contain one more section
regarding the importance of the priority 0 configuration, before it talks
about the updates to RFC. Draft mentioned about this only in abstract. But
not really explaining in detail why we need to allow this configuration
(Priority 0).  Can you please elaborate it further?

Thanks,
Sreenatha

Message: 1
Date: Sat, 3 Aug 2013 00:06:13 +0000
From: "Anurag Kothari (ankothar)" <[email-masked]>
To: "[email-masked]" <[email-masked]>, "[email-masked]"
	<[email-masked]>
Cc: "fhrp-team\(mailer list\)" <[email-masked]>
Subject: [VRRP] Graceful Failover for VRRP
Message-ID:
	<[email-masked]>
Content-Type: text/plain; charset="us-ascii"

Hi

I have submitted the following I-D on this idea:

TXT:
http://www.ietf.org/internet-drafts/draft-kothari-vrrp-graceful-failover-00.
txt
HTML: http://tools.ietf.org/html/draft-kothari-vrrp-graceful-failover-00

Please review and provide feedback.

Thanks
-Anurag

Disclaimer : 
This email communication may contain privileged and confidential information and is intended for the use of the addressee only.If you are not an intended recipient you are requested not to reproduce, copy disseminate or in any manner distribute this email communication as the same is strictly prohibited. If you have received this email in error, please notify the sender immediately by return e-mail and delete the communication sent in error. Email communications cannot be guaranteed to be secure & error free and IB Technology is not liable for any errors in the email communication or for the proper, timely and complete transmission thereof.

---

From: "Anurag Kothari (ankothar)" <[email-masked]>
Date: Tue, 6 Aug 2013 14:17:42 +0000

Hello Sreenatha

The earlier specification of VRRP do not talk about a change event but I do agree that most implementations would have to have it in some form or the other in order to send the VRRP Packets with correct values after any changes.

I do not think the Master router has to go into Init state even in older (i.e. current) implementations whenever any of the parameters mentioned in the draft change, just that instead of sending the updated VRRP Packet immediately on change it would send it whenever the Adver_Timer fires.

I think it is better to track all changes to priority by the change event instead of just priority being changed to 0 for this will trigger failover immediately for the following Case:

* Preemption is enabled.
* Priority is not reduced all the way to zero on uplink failure.
 * Uplink goes down

Regarding your second point: Next version of the draft can surely have more information regarding why we need priority zero and cover some use cases.

Thanks a lot for taking time to review this and providing your feedback.

Regards
-Anurag 

-----Original Message-----
From: sreenatha setty [mailto:[email-masked]] 
Sent: Tuesday, August 06, 2013 1:41 AM
To: [email-masked]; Anurag Kothari (ankothar)
Subject: . Re: Graceful Failover for VRRP 

Hi Anurag,
     I went through the draft. I have few queries. 
    The new "Change Event" you are trying to define is not actually new. In earlier implementation also, if there is a change in Priority or Advertisement Interval or VRIP address configurations, first VRRP will go to Init state, then wait for some time (probably for Master down timer interval if it's not the address owner) then becomes master if no eligible master is available in the network.  I think only for Priority 0 configuration we need to define new event. (I guess this you discussed over this mailing list
earlier.)
     And one more thing, I guess draft need to contain one more section regarding the importance of the priority 0 configuration, before it talks about the updates to RFC. Draft mentioned about this only in abstract. But not really explaining in detail why we need to allow this configuration (Priority 0).  Can you please elaborate it further?

Thanks,
Sreenatha

Message: 1

Hi

TXT:

Thanks
-Anurag

Disclaimer :