Graceful Failover for VRRP

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

-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of Adrian Farrel
Sent: Wednesday, May 22, 2013 12:12 PM
To: [email protected]
Cc: fhrp-team(mailer list)
Subject: Re: [VRRP] Proposal for Maintenance Event for VRRP [RFC-5798]

Hi,

If you are wondering how to progress this in the IETF, the answer is...

- write an I-D
- discuss it (here)
- polish it
- ask me to sponsor it for publication as an RFC.

Cheers,
Adrian

> -----Original Message-----
> From: [email protected] [mailto:[email protected]] On Behalf 
> Of Anurag Kothari (ankothar)
> Sent: 04 March 2013 23:43
> To: sreenatha; [email protected]
> Cc: fhrp-team(mailer list)
> Subject: Re: [VRRP] Proposal for Maintenance Event for VRRP [RFC-5798]
> 
> Hi Sreenatha
> 
> If you mean "if I am not wrong" then yes what you have said below is correct.
> 
> Also I believe the objective (particularly in case of time sensitive
application) is to
> avoid any unnecessary switch overs; as already suggested earlier let's 
> call
this a
> "Change Event" instead of "Maintenance Event". The "Change Event" 
> would be triggered by change in one of the following parameters of the VRRP Packet :
> 
> 1) Priority (Section 5.2.4. of RFC-5798)
> 2) Max Adver Int (Section 5.2.7. of RFC-5798)
> 
> And possibly:
> 
> 3) IPvX Address(es) (Section 5.2.9.  of RFC-5798)
> 
> The "Change Event" would only be handled in Master State and ignored 
> in other state as the VRRP Packets are only supposed to be sent by the Master.
> 
> So to rephrase the proposal:
> 
>     - If a Change event is received, then:
> 
>     + Send an ADVERTISEMENT
> 
>     + Reset the Adver_Timer to Advertisement_Interval
> 
>     -endif // Change recv
> 
> To cover the failover scenario (in the absence of preemption) Priority 
> = 0
will now
> have to be allowed along with the previously discussed modifications 
> to avoid
a
> storm of Priority = 0 Advertisements from two masters.
> 
> Please Share your thoughts.
> 
> Thanks
> -Anurag
> 
> -----Original Message-----
> From: sreenatha [mailto:[email protected]]
> Sent: Saturday, March 02, 2013 3:17 AM
> To: Anurag Kothari (ankothar)
> Cc: [email protected]
> Subject: Re: Proposal for Maintenance Event for VRRP [RFC-5798]
> 
> Hi Anurag,
>      Thanks for clarification.
> 
>       If i am wrong, user is allowed to configure Priority value as 
> zero(i.e., Maintenance_Event), priority value will be changed. And 
> handling of the Maintenance_Event is done only in Master state and 
> ignored in Backup and Init state.
> 
> Thanks,
> Sreenatha
> 
> On 03/01/2013 08:31 PM, Anurag Kothari (ankothar) wrote:
> > Hi Sreenatha
> >
> > I don't think we need to define a "Maintenance_Event" when the 
> > router is in
> either Init or Backup State. The intention of the "Maintenance_Event" 
> is to trigger a failover from "Master" to a "Backup" router as soon as 
> possible (especially when preemption is not configured).
> >
> > But if you are asking if priority = 0 should be allowed (either by 
> > user
> configuration or dynamically) when the router is in "Init" or "Backup" 
> state
then I
> think the answer should be yes, It should be treated just like any 
> other
change in
> priority is treated when the router is in these states.
> >
> > Please let me know if I am missing something.
> >
> > 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.
> 
> _______________________________________________
> vrrp mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/vrrp

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