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

"Anurag Kothari (ankothar)" <ankothar@cisco.com> Fri, 22 February 2013 12:09 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 BF7E221F8E21 for <vrrp@ietfa.amsl.com>; Fri, 22 Feb 2013 04:09:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.598
X-Spam-Level:
X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N0ztaggT8s49 for <vrrp@ietfa.amsl.com>; Fri, 22 Feb 2013 04:08:58 -0800 (PST)
Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 84DCC21F8DDC for <vrrp@ietf.org>; Fri, 22 Feb 2013 04:08:58 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=36775; q=dns/txt; s=iport; t=1361534938; x=1362744538; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=0xz1xTmCmEwejYbnz5gx7h/NwjadNJiY/K196tsIGQU=; b=BjzUU24WUMwxHHn1tHLOoA4rpAaP/HsvuwLY44FZ73Zvu3Zi+KNCoY7O +EhmqnpzZOZ355/Ae9SYthT6MFFh/cIbRrFiluxF5hh8onERnFBGkskEc am/IUgDu49JrQQuUI4l0MJcdtVZdxnawtVl/z27mLnnRU1xJAgfl66jGI c=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgMFAIlfJ1GtJXG//2dsb2JhbABEgkO+XYEJFnOCHwEBAQQBAQEqISALDAQCAQgRAwEBAQsCARMBBgcnCgEUCQgCBA4FCAESAgSHcQy/O400CRCBEAYHEwYGAQQGAQIEgllhA6cdgweBaQQCAxce
X-IronPort-AV: E=Sophos; i="4.84,715,1355097600"; d="scan'208,217"; a="180083178"
Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-4.cisco.com with ESMTP; 22 Feb 2013 12:08:57 +0000
Received: from xhc-aln-x10.cisco.com (xhc-aln-x10.cisco.com [173.36.12.84]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id r1MC8vHN024173 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 22 Feb 2013 12:08:57 GMT
Received: from xmb-rcd-x05.cisco.com ([169.254.15.93]) by xhc-aln-x10.cisco.com ([173.36.12.84]) with mapi id 14.02.0318.004; Fri, 22 Feb 2013 06:08:56 -0600
From: "Anurag Kothari (ankothar)" <ankothar@cisco.com>
To: sreenatha <sreenatha.setty@ibtechnology.com>
Thread-Topic: [VRRP] Proposal for Maintenance Event for VRRP [RFC-5798]
Thread-Index: AQHOEE0W0nCX6622rECg/5kR/Wmy05iEejtggAEzEYCAAA+ssIAACf3A
Date: Fri, 22 Feb 2013 12:08:55 +0000
Message-ID: <A2BB90B33FFDF740876C5AAE307D83DB1C2929E8@xmb-rcd-x05.cisco.com>
References: <mailman.53.1361390408.7703.vrrp@ietf.org> <51264544.7070300@ibtechnology.com> <A2BB90B33FFDF740876C5AAE307D83DB1C292349@xmb-rcd-x05.cisco.com> <5126F33F.1080005@ibtechnology.com> <A2BB90B33FFDF740876C5AAE307D83DB1C292974@xmb-rcd-x05.cisco.com>
In-Reply-To: <A2BB90B33FFDF740876C5AAE307D83DB1C292974@xmb-rcd-x05.cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.82.242.135]
Content-Type: multipart/alternative; boundary="_000_A2BB90B33FFDF740876C5AAE307D83DB1C2929E8xmbrcdx05ciscoc_"
MIME-Version: 1.0
Cc: "vrrp@ietf.org" <vrrp@ietf.org>
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: Fri, 22 Feb 2013 12:09:03 -0000

On Further Thought:

We may want to define maintenance event (probably rename it "Priority Change Event") being triggered by a change in priority for a VRID (including dynamic changes to the priority e.g. changes due to tracking interface).

This would make it more generic. Whenever the user configures priority = 0 (which will have to be allowed) it would trigger a failover to the backup router.

Thanks
-Anurag

From: vrrp-bounces@ietf.org [mailto:vrrp-bounces@ietf.org] On Behalf Of Anurag Kothari (ankothar)
Sent: Friday, February 22, 2013 6:42 AM
To: sreenatha
Cc: vrrp@ietf.org
Subject: Re: [VRRP] Proposal for Maintenance Event for VRRP [RFC-5798]

Hi Sreenatha

My bad, by cancel I meant reset the timer.

I would prefer defining maintenance event itself as (or being triggered by) priority being set to 0 for a VRID. So probably we can rephrase the proposal as:


- If a Maintenance event is received, then:



+ Send an ADVERTISEMENT



+ Reset the Adver_Timer to Advertisement_Interval



-endif // maintenance recv

Thanks
-Anurag

From: sreenatha [mailto:sreenatha.setty@ibtechnology.com]
Sent: Thursday, February 21, 2013 11:26 PM
To: Anurag Kothari (ankothar)
Cc: vrrp@ietf.org<mailto:vrrp@ietf.org>
Subject: Re: [VRRP] Proposal for Maintenance Event for VRRP [RFC-5798]

Hi Anurag,
   Your proposal is:


- If a Maintenance event is received, then:



+ Cancel the Adver_Timer



+ Send an ADVERTISEMENT with Priority = 0



-endif // maintenance recv





    And you mentioned that router need to send regular ADVERTISEMENT message till it receives the ADVERTISEMENT message from the backup router.



"2. How much time Master router should wait to receive ADVERTISEMENT message from any backup router?



[Anurag] Master doesn't have to wait. After receiving the maintenance event it will send regular ADVERTISEMENT with Priority = 0 till some other router send back an ADVERTISEMENT message at which point it will transition to Backup."



If Advert_Timer is cancelled, how regular ADVERTISEMENT messages are sent?



So i am suggesting slight changes in the Proposal:



- If a Maintenance event is received, then:



+ Change the router priority to 0



+ Send an ADVERTISEMENT with Priority = 0



+ Reset the Adver_Timer



 -endif // maintenance recv



This will ensure that:

1. ADVERTISEMENT message with priority 0 is sent  immediately on receiving Maintenance event.

2. Master router will send regular Advertisement message till it receives the ADVERTISEMENT message from any backup routers.



Thanks,

Sreenatha Setty






On 02/21/2013 10:12 PM, Anurag Kothari (ankothar) wrote:

Hi Sreenatha



This ideas is based on the way the priority is defined in Section 5.2.4. and 6.1. of RFC-5798.



"

   The priority value zero (0) has special meaning, indicating that the

   current Master has stopped participating in VRRP.  This is used to

   trigger Backup routers to quickly transition to Master without having

   to wait for the current Master to time out.

"



"

   Priority              <snip>  The value of 0 (zero) is

                               reserved for the Master router to

                               indicate it is releasing responsibility

                               for the virtual router.  The range 1-254

                               (decimal) is available for VRRP routers

                               backing up the virtual router. <snip>

"



Please see my responses inline [Anurag]:



Thanks

-Anurag



-----Original Message-----

From: vrrp-bounces@ietf.org<mailto:vrrp-bounces@ietf.org> [mailto:vrrp-bounces@ietf.org] On Behalf Of sreenatha

Sent: Thursday, February 21, 2013 11:03 AM

To: vrrp@ietf.org<mailto:vrrp@ietf.org>

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



Hi Anurag,

     Proposed idea is good. I have some queries on this proposal:



1. On receiving new maintenance_event, priority of the router is not changed, right? So if back-up router has less priority, even if Master receives the ADVERTISEMENT from the backup router, Master will discard.

So how the Master router state is going to change?



[Anurag] On receiving the maintenance event the priority of router (or VRID) will change to 0.



2. How much time Master router should wait to receive ADVERTISEMENT message from any backup router?



[Anurag] Master doesn't have to wait. After receiving the maintenance event it will send regular ADVERTISEMENT with Priority = 0 till some other router send back an ADVERTISEMENT message at which point it will transition to Backup.



3. Standard VRRP MIB(RFC-2787) does not allow user to configure '0' for VRRP Priority. So you are proposing to change this value also?



[Anurag] Yes. Priority 0 will have to be made a user configurable value to indicate the intention of a router to relinquish Master Status.



Thanks,

Sreenatha Setty



On 02/21/2013 01:30 AM, vrrp-request@ietf.org<mailto:vrrp-request@ietf.org> wrote:

If you have received this digest without all the individual message

attachments you will need to update your digest options in your list

subscription.  To do so, go to



https://www.ietf.org/mailman/listinfo/vrrp



Click the 'Unsubscribe or edit options' button, log in, and set "Get

MIME or Plain Text Digests?" to MIME.  You can set this option

globally for all the list digests you receive at this point.







Send vrrp mailing list submissions to

   vrrp@ietf.org<mailto:vrrp@ietf.org>



To subscribe or unsubscribe via the World Wide Web, visit

   https://www.ietf.org/mailman/listinfo/vrrp

or, via email, send a message with subject or body 'help' to

   vrrp-request@ietf.org<mailto:vrrp-request@ietf.org>



You can reach the person managing the list at

   vrrp-owner@ietf.org<mailto:vrrp-owner@ietf.org>



When replying, please edit your Subject line so it is more specific

than "Re: Contents of vrrp digest..."





Today's Topics:



    1. Proposal for Maintenance Event for VRRP [RFC-5798]

       (Anurag Kothari (ankothar))





----------------------------------------------------------------------



Message: 1

Date: Tue, 19 Feb 2013 22:08:41 +0000

From: "Anurag Kothari (ankothar)"<ankothar@cisco.com><mailto:ankothar@cisco.com>

To:"vrrp@ietf.org"<mailto:vrrp@ietf.org>  <vrrp@ietf.org><mailto:vrrp@ietf.org>

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

Message-ID:

   <A2BB90B33FFDF740876C5AAE307D83DB1C290327@xmb-rcd-x05.cisco.com><mailto:A2BB90B33FFDF740876C5AAE307D83DB1C290327@xmb-rcd-x05.cisco.com>

Content-Type: text/plain; charset="us-ascii"



Hi



I want to propose a new Maintenance Event (modification of Shutdown Event) for VRRP (RFC-5798] which would allow to gracefully failover the VRRP Master to Redundant (Backup Router).



Problem Statement:

VRRP preemption is not configured on the redundant / backup router.

How to initiate VRRP Traffic to failover to the redundant / backup

router gracefully without modifying the configuration on the redundant

/ backup router (i.e. adding preemption)



Proposed Solution:

Addition to Section 6.4.3 of RFC-5798:



- If a Maintenance event is received, then:



+ Cancel the Adver_Timer



+ Send an ADVERTISEMENT with Priority = 0



-endif // maintenance recv



Unlike Shutdown event the router will not "Transition to the {Initialize} state" and continue to be Master and forward traffic  till the backup router sends an ADVERTISEMENT (triggered by receiving an ADVERTISEMENT with Priority = 0) and becomes master.





Here are couple of examples of how a maintenance event may be

triggered





1)      By some user command e.g. "maintenance-mode" in the vrrp configuration.



2)      By setting the priority = 0 for a particular VRID.



Thanks

-Anurag



-------------- next part -------------- An HTML attachment was

scrubbed...

URL:<http://www.ietf.org/mail-archive/web/vrrp/attachments/20130219/36<http://www.ietf.org/mail-archive/web/vrrp/attachments/20130219/36a6571f/attachment.htm>

a6571f/attachment.htm><http://www.ietf.org/mail-archive/web/vrrp/attachments/20130219/36a6571f/attachment.htm>



------------------------------



_______________________________________________

vrrp mailing list

vrrp@ietf.org<mailto:vrrp@ietf.org>

https://www.ietf.org/mailman/listinfo/vrrp





End of vrrp Digest, Vol 81, Issue 1

***********************************





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<mailto:vrrp@ietf.org>

https://www.ietf.org/mailman/listinfo/vrrp




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.