Re: [VRRP] . Re: Graceful Failover for VRRP
"Anurag Kothari (ankothar)" <firstname.lastname@example.org> Tue, 06 August 2013 14:17 UTC
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBF9C21F9FE5 for <email@example.com>; Tue, 6 Aug 2013 07:17:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
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 ([126.96.36.199]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JvfP-r5pWSSb for <firstname.lastname@example.org>; Tue, 6 Aug 2013 07:17:48 -0700 (PDT)
Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [188.8.131.52]) by ietfa.amsl.com (Postfix) with ESMTP id 7B19A21F9FC9 for <email@example.com>; Tue, 6 Aug 2013 07:17:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; firstname.lastname@example.org; l=3754; q=dns/txt; s=iport; t=1375798668; x=1377008268; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=cReTtIob1Z1lf+BWdutd0zgyYafZj4u5NIoO4meSMpI=; b=FtZFqVk8UHO7zd91OfQ6G6EIlqzZJhby3vnvjdPwxBrgqLdBofcGKbJF c4Lalllh4zgv8dKxRLIKe+NC2iBBXO/D5OHd1Ivz+5mtWDSMywaz+INL8 T8VxqdbYUWPBHQYQIyWwmnhuApON8sAg90BB0XQ5P4dXeLt/xst/6dxLx 8=;
X-IronPort-AV: E=Sophos;i="4.89,827,1367971200"; d="scan'208";a="244080553"
Received: from rcdn-core-5.cisco.com ([184.108.40.206]) by rcdn-iport-5.cisco.com with ESMTP; 06 Aug 2013 14:17:43 +0000
Received: from xhc-rcd-x12.cisco.com (xhc-rcd-x12.cisco.com [220.127.116.11]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id r76EHhe7022579 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 6 Aug 2013 14:17:43 GMT
Received: from xmb-rcd-x05.cisco.com ([169.254.15.236]) by xhc-rcd-x12.cisco.com ([18.104.22.168]) with mapi id 14.02.0318.004; Tue, 6 Aug 2013 09:17:43 -0500
From: "Anurag Kothari (ankothar)" <email@example.com>
To: sreenatha setty <firstname.lastname@example.org>, "email@example.com" <firstname.lastname@example.org>
Thread-Topic: . Re: Graceful Failover for VRRP
Date: Tue, 6 Aug 2013 14:17:42 +0000
Content-Type: text/plain; charset="us-ascii"
Subject: Re: [VRRP] . Re: Graceful Failover for VRRP
List-Id: Virtual Router Redundancy Protocol <vrrp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/vrrp>, <mailto:email@example.com?subject=unsubscribe>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/vrrp>, <mailto:firstname.lastname@example.org?subject=subscribe>
X-List-Received-Date: Tue, 06 Aug 2013 14:17:54 -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@example.com] Sent: Tuesday, August 06, 2013 1:41 AM To: firstname.lastname@example.org; 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 Date: Sat, 3 Aug 2013 00:06:13 +0000 From: "Anurag Kothari (ankothar)" <email@example.com> To: "firstname.lastname@example.org" <email@example.com>, "firstname.lastname@example.org" <email@example.com> Cc: "fhrp-team\(mailer list\)" <firstname.lastname@example.org> Subject: [VRRP] Graceful Failover for VRRP Message-ID: <A2BB90B33FFDF740876C5AAE307D83DB255B389F@xmb-rcd-x05.cisco.com> 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.