Re: [VRRP] Graceful Failover for VRRP

"Anurag Kothari (ankothar)" <ankothar@cisco.com> Sat, 03 August 2013 18:36 UTC

Return-Path: <ankothar@cisco.com>
X-Original-To: vrrp@ietfa.amsl.com
Delivered-To: vrrp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B795C21F9F52 for <vrrp@ietfa.amsl.com>; Sat, 3 Aug 2013 11:36:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Level:
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hpOFAgqsFK+p for <vrrp@ietfa.amsl.com>; Sat, 3 Aug 2013 11:36:47 -0700 (PDT)
Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id AA01F11E80AD for <vrrp@ietf.org>; Sat, 3 Aug 2013 11:36:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6088; q=dns/txt; s=iport; t=1375555007; x=1376764607; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=r72iLLWOm1sENNaktMyonXbTyft8DAdRtgv20yQd04Q=; b=aLmqZfIO6uDX1HUs5fZueJEVChk5d3uLhAY9MMo3RwTG7zI4oQlWD69R ZP03fm8GW6pvqLaZyqo5ySUgB32AojmO5xtZOtdj4pfMeZkaXbOq6uSIC YWxbDgxSXZ34C7k1m7yMX5I3O+8Drdti+bYeIbq1/fiGA5Fd1N06aO0GX A=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgUFAOtM/VGtJV2a/2dsb2JhbABagwY1UL8UgR0WdIIkAQEBAQMBAQE3NAsMBAIBCBEEAQEBChQJBycLFAkIAQEEAQ0FCAESh3UMtkWOSAkQgQcPIgcGgxN0A5kKkCWDF4FxOQ
X-IronPort-AV: E=Sophos;i="4.89,808,1367971200"; d="scan'208";a="242951217"
Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-1.cisco.com with ESMTP; 03 Aug 2013 18:36:47 +0000
Received: from xhc-rcd-x07.cisco.com (xhc-rcd-x07.cisco.com [173.37.183.81]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r73Ialvx000594 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 3 Aug 2013 18:36:47 GMT
Received: from xmb-rcd-x05.cisco.com ([169.254.15.236]) by xhc-rcd-x07.cisco.com ([173.37.183.81]) with mapi id 14.02.0318.004; Sat, 3 Aug 2013 13:36:46 -0500
From: "Anurag Kothari (ankothar)" <ankothar@cisco.com>
To: "Celer, Alicja (Alicja)" <aceler@avaya.com>, "adrian@olddog.co.uk" <adrian@olddog.co.uk>, "vrrp@ietf.org" <vrrp@ietf.org>
Thread-Topic: Graceful Failover for VRRP
Thread-Index: Ac6P3T4o48vQ/TAOSwOeNRO+A7+U1wAmJQlGAABFo1A=
Date: Sat, 03 Aug 2013 18:36:45 +0000
Message-ID: <A2BB90B33FFDF740876C5AAE307D83DB255B46EF@xmb-rcd-x05.cisco.com>
References: <A2BB90B33FFDF740876C5AAE307D83DB255B389F@xmb-rcd-x05.cisco.com> <BADCB091A7B456478087D87523A86EBA42C5431A@AZ-US1EXMB05.global.avaya.com>
In-Reply-To: <BADCB091A7B456478087D87523A86EBA42C5431A@AZ-US1EXMB05.global.avaya.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-Auto-Response-Suppress: DR, OOF, AutoReply
X-MS-TNEF-Correlator:
x-originating-ip: [10.82.218.55]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "fhrp-team(mailer list)" <fhrp-team@cisco.com>
Subject: Re: [VRRP] Graceful Failover for VRRP
X-BeenThere: vrrp@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Virtual Router Redundancy Protocol <vrrp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/vrrp>, <mailto:vrrp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/vrrp>
List-Post: <mailto:vrrp@ietf.org>
List-Help: <mailto:vrrp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/vrrp>, <mailto:vrrp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 03 Aug 2013 18:36:53 -0000

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:aceler@avaya.com] 
Sent: Saturday, August 03, 2013 2:21 PM
To: Anurag Kothari (ankothar); adrian@olddog.co.uk; vrrp@ietf.org
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: vrrp-bounces@ietf.org [vrrp-bounces@ietf.org] on behalf of Anurag Kothari (ankothar) [ankothar@cisco.com]
Sent: Friday, August 02, 2013 8:06 PM
To: adrian@olddog.co.uk; vrrp@ietf.org
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: vrrp-bounces@ietf.org [mailto:vrrp-bounces@ietf.org] On Behalf Of Adrian Farrel
Sent: Wednesday, May 22, 2013 12:12 PM
To: vrrp@ietf.org
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: vrrp-bounces@ietf.org [mailto:vrrp-bounces@ietf.org] On Behalf 
> Of Anurag Kothari (ankothar)
> Sent: 04 March 2013 23:43
> To: sreenatha; vrrp@ietf.org
> 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:sreenatha.setty@ibtechnology.com]
> Sent: Saturday, March 02, 2013 3:17 AM
> To: Anurag Kothari (ankothar)
> Cc: vrrp@ietf.org
> 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
> vrrp@ietf.org
> https://www.ietf.org/mailman/listinfo/vrrp

_______________________________________________
vrrp mailing list
vrrp@ietf.org
https://www.ietf.org/mailman/listinfo/vrrp
_______________________________________________
vrrp mailing list
vrrp@ietf.org
https://www.ietf.org/mailman/listinfo/vrrp