Re: Graceful Failover for VRRP
"Anurag Kothari (ankothar)" <[email protected]> Sat, 3 Aug 2013 19:16:33 +0000
| Newsgroups | gmane.ietf.vrrp |
|---|---|
| Message-ID | <[email protected]> |
Hello Alicja I went through your draft: http://tools.ietf.org/html/draft-celer-vrrp-ext-00 and my draft is totally and fundamentally different from yours. Please let me know if it is some other draft of your that you are referring to or if I am missing something here. Thanks -Anurag -----Original Message----- From: Anurag Kothari (ankothar) Sent: Saturday, August 03, 2013 2:37 PM To: 'Celer, Alicja (Alicja)'; [email protected]; [email protected] Cc: fhrp-team(mailer list) Subject: RE: Graceful Failover for VRRP Hello Alicja Sorry, I was not aware of your draft. I did a quick search and I suppose you are referring to: http://tools.ietf.org/html/draft-celer-vrrp-ext-00 Please let me know if it is otherwise. I would definitely go through it and get back to you; If it is the same idea we can surely try to converge on a solution. Thanks -Anurag -----Original Message----- From: Celer, Alicja (Alicja) [mailto:[email protected]] Sent: Saturday, August 03, 2013 2:21 PM To: Anurag Kothari (ankothar); [email protected]; [email protected] Cc: fhrp-team(mailer list) Subject: RE: Graceful Failover for VRRP Hi Anurag, I've posted a draft addressing a similar issue and proposing a similar solution in 1999. Did you get a chance to review it? If not, would you like a copy maybe we converge on a solution? kind regar ds, Alicja ________________________________________ From: [email protected] [[email protected]] on behalf of Anurag Kothari (ankothar) [[email protected]] Sent: Friday, August 02, 2013 8:06 PM To: [email protected]; [email protected] Cc: fhrp-team(mailer list) Subject: [VRRP] 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 _______________________________________________ vrrp mailing list [email protected] https://www.ietf.org/mailman/listinfo/vrrp