[VRRP] . Re: Graceful Failover for VRRP

sreenatha setty <sreenatha.setty@ibtechnology.com> Tue, 06 August 2013 05:41 UTC

Return-Path: <sreenatha.setty@ibtechnology.com>
X-Original-To: vrrp@ietfa.amsl.com
Delivered-To: vrrp@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 9AFC821F9D65 for <vrrp@ietfa.amsl.com>; Mon, 5 Aug 2013 22:41:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id E+HWyOzYO4ow for <vrrp@ietfa.amsl.com>; Mon, 5 Aug 2013 22:41:10 -0700 (PDT)
Received: from ipinternal.indiabulls.com (ipinternal.indiabulls.com []) by ietfa.amsl.com (Postfix) with ESMTP id 43D6421F8EB2 for <vrrp@ietf.org>; Mon, 5 Aug 2013 22:41:08 -0700 (PDT)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="4.89,824,1367951400"; d="scan'208";a="24397727"
Received: from IGSmtp.indiabulls.com ( by MUM-IDC-SCAS.indiabulls.com ( with Microsoft SMTP Server id; Tue, 6 Aug 2013 11:11:01 +0530
X-IronPort-AV: E=Sophos;i="4.89,824,1367951400"; d="scan'208";a="121646262"
Received: from (HELO IBGGN86455L) ([]) by ipgate.indiabulls.com with ESMTP; 06 Aug 2013 11:06:05 +0530
From: sreenatha setty <sreenatha.setty@ibtechnology.com>
To: <vrrp@ietf.org>, "Anurag Kothari (ankothar)" <ankothar@cisco.com>
Date: Tue, 6 Aug 2013 11:11:00 +0530
Message-ID: <001001ce9267$88419810$98c4c830$@ibtechnology.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Mailer: Microsoft Outlook 14.0
Thread-Index: Ac6SZRersJTclBN/T4CjKlje6p1yDw==
Content-Language: en-in
Content-Transfer-Encoding: 7bit
Subject: [VRRP] . Re: 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: Tue, 06 Aug 2013 05:41:14 -0000

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
     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?


Message: 1
Date: Sat, 3 Aug 2013 00:06:13 +0000
From: "Anurag Kothari (ankothar)" <ankothar@cisco.com>
To: "adrian@olddog.co.uk" <adrian@olddog.co.uk>uk>, "vrrp@ietf.org"
Cc: "fhrp-team\(mailer list\)" <fhrp-team@cisco.com>
Subject: [VRRP] Graceful Failover for VRRP
Content-Type: text/plain; charset="us-ascii"


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

HTML: http://tools.ietf.org/html/draft-kothari-vrrp-graceful-failover-00

Please review and provide feedback.


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.