Re: [VRRP] Proposal for Maintenance Event for VRRP [RFC-5798]

"Anurag Kothari (ankothar)" <ankothar@cisco.com> Mon, 04 March 2013 23:43 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 5752711E80E0 for <vrrp@ietfa.amsl.com>; Mon, 4 Mar 2013 15:43:30 -0800 (PST)
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 QwZvhTtWuiZk for <vrrp@ietfa.amsl.com>; Mon, 4 Mar 2013 15:43:29 -0800 (PST)
Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 8C3E111E80D7 for <vrrp@ietf.org>; Mon, 4 Mar 2013 15:43:29 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3246; q=dns/txt; s=iport; t=1362440609; x=1363650209; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=ba22dCglQCSGVpfD15HdaDe3olcyfg+8RKU7PhpJb54=; b=L3Qiueywrp6ENltbQDZBDBThLXwB1Gwcnk/4ebp2bk6EpOlGxaogAbfH Nl3o8cbNs3R9Gih4gz6GuwN4xUBFSJrCL1e3/42AgV/8dL5IGHwnMYoWE N4XA1lswPy4C0DG7XX5JcHDtnFxXGXn/1Tjwg4KE8JLfj1vvZwGizKjTI w=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgEFAB8xNVGtJV2d/2dsb2JhbABEwlSBCxZzgh8BAQEEOj8MBAIBCBEEAQEBChQJBzIUCQgCBAENBQiIC8BojUIJEIEAJgsHBl2BfGEDpzKCew2BcjU
X-IronPort-AV: E=Sophos;i="4.84,783,1355097600"; d="scan'208";a="183482880"
Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-1.cisco.com with ESMTP; 04 Mar 2013 23:43:29 +0000
Received: from xhc-rcd-x07.cisco.com (xhc-rcd-x07.cisco.com [173.37.183.81]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id r24NhSRf028319 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 4 Mar 2013 23:43:29 GMT
Received: from xmb-rcd-x05.cisco.com ([169.254.15.93]) by xhc-rcd-x07.cisco.com ([173.37.183.81]) with mapi id 14.02.0318.004; Mon, 4 Mar 2013 17:43:28 -0600
From: "Anurag Kothari (ankothar)" <ankothar@cisco.com>
To: sreenatha <sreenatha.setty@ibtechnology.com>, "vrrp@ietf.org" <vrrp@ietf.org>
Thread-Topic: Proposal for Maintenance Event for VRRP [RFC-5798]
Thread-Index: AQHOFdIXMs1MhoGdzkqW+jdD3o4AJZiPq2bAgAEBhoCAADnPAIABjt6AgAO2C6A=
Date: Mon, 4 Mar 2013 23:43:27 +0000
Message-ID: <A2BB90B33FFDF740876C5AAE307D83DB1C297B31@xmb-rcd-x05.cisco.com>
References: <512F8815.5010204@ibtechnology.com> <A2BB90B33FFDF740876C5AAE307D83DB1C295D1C@xmb-rcd-x05.cisco.com> <5130366D.6070302@ibtechnology.com> <A2BB90B33FFDF740876C5AAE307D83DB1C2963EE@xmb-rcd-x05.cisco.com> <5131B583.3000500@ibtechnology.com>
In-Reply-To: <5131B583.3000500@ibtechnology.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: [64.102.148.196]
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] Proposal for Maintenance Event for VRRP [RFC-5798]
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: Mon, 04 Mar 2013 23:43:30 -0000

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.