From ankothar@cisco.com Tue Feb 19 14:08:49 2013 Return-Path: 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 92C4121F85F5 for ; Tue, 19 Feb 2013 14:08:48 -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 ghhhtgKQlF55 for ; Tue, 19 Feb 2013 14:08:43 -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 510EE21F85E7 for ; Tue, 19 Feb 2013 14:08:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8330; q=dns/txt; s=iport; t=1361311723; x=1362521323; h=from:to:subject:date:message-id:mime-version; bh=g2v9W6OYxA0zgvX3n19IVu+kOPkqlJfarJKa5Z37CHE=; b=HMG6LriY0v1psUPdz2Gv2S14NIg/JVgXwt1g5uKk5vgwpH2lVjwYX7ar nF8/OJuTcscQaWEjGQJ9lA1G9WwCv5Yw5eOJYbQL4XDhPsgeofiRbZY+O WEzO5H4VuEZyRZNEX1L+WEBNEBmYSIlojKRKhzzOKmW5L667x4yEoLGZD 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAJX2I1GtJXG+/2dsb2JhbABFgkO9f4ENFnOCIQEELV4BKlYmAQQbE4d3nxyRE5AojTSBKYMXYQOnA4MHgic X-IronPort-AV: E=Sophos;i="4.84,697,1355097600"; d="scan'208,217";a="178690665" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-1.cisco.com with ESMTP; 19 Feb 2013 22:08:42 +0000 Received: from xhc-rcd-x15.cisco.com (xhc-rcd-x15.cisco.com [173.37.183.89]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id r1JM8gYh029199 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 19 Feb 2013 22:08:42 GMT Received: from xmb-rcd-x05.cisco.com ([169.254.15.93]) by xhc-rcd-x15.cisco.com ([173.37.183.89]) with mapi id 14.02.0318.004; Tue, 19 Feb 2013 16:08:42 -0600 From: "Anurag Kothari (ankothar)" To: "vrrp@ietf.org" Thread-Topic: Proposal for Maintenance Event for VRRP [RFC-5798] Thread-Index: Ac4O7aThy0QLWPNySdyGWhregnot6w== Date: Tue, 19 Feb 2013 22:08:41 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.82.255.97] Content-Type: multipart/alternative; boundary="_000_A2BB90B33FFDF740876C5AAE307D83DB1C290327xmbrcdx05ciscoc_" MIME-Version: 1.0 Subject: [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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Feb 2013 22:22:32 -0000 --_000_A2BB90B33FFDF740876C5AAE307D83DB1C290327xmbrcdx05ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 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 Maste= r 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 graceful= ly 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 =3D 0 -endif // maintenance recv Unlike Shutdown event the router will not "Transition to the {Initialize} s= tate" and continue to be Master and forward traffic till the backup router= sends an ADVERTISEMENT (triggered by receiving an ADVERTISEMENT with Prior= ity =3D 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 configurat= ion. 2) By setting the priority =3D 0 for a particular VRID. Thanks -Anurag --_000_A2BB90B33FFDF740876C5AAE307D83DB1C290327xmbrcdx05ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi

 

I want to propose a new Maintenance Event (modificat= ion 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 redund= ant / 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 =3D 0

=  

= -endif // maintenance recv

 

Unlike Shutdown event the router will not “Transition to the {Initial= ize} state” and continue to be Master and forward traffic &nbs= p;till the backup router sends an ADVERTISEMENT (t= riggered by receiving an ADVERTISEMENT wi= th Priority =3D 0) and becomes master.

 

Here are couple of examples of how a maintenance eve= nt may be triggered

 

1)      By some user command e.g. “maintenance-mode&#= 8221; in the vrrp configuration.

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

 

Thanks

-Anurag

 

--_000_A2BB90B33FFDF740876C5AAE307D83DB1C290327xmbrcdx05ciscoc_-- From sreenatha.setty@ibtechnology.com Thu Feb 21 08:04:00 2013 Return-Path: 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 B676921F8EBB for ; Thu, 21 Feb 2013 08:03:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 8LJdqSoF5XF1 for ; Thu, 21 Feb 2013 08:03:56 -0800 (PST) Received: from ipinternal.indiabulls.com (ipinternal.indiabulls.com [202.54.119.192]) by ietfa.amsl.com (Postfix) with ESMTP id 8B8A021F8950 for ; Thu, 21 Feb 2013 08:03:53 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqIEAB1FJlGsEQGd/2dsb2JhbABFwHuBG3OCHwEBAQEDAQEBNRYgChELDQQDAQIBCQMBEg8JAwIBAgEVCh4IEQIGAgEBBRICBId9vw6NNAkQgTYSBoM6A4hnhUOOI41WgWo X-IronPort-AV: E=Sophos;i="4.84,710,1355077800"; d="scan'208";a="7554844" X-IronPort-AV: E=Sophos;i="4.84,710,1355077800"; d="scan'208";a="102937383" Received: from unknown (HELO [192.168.0.102]) ([27.124.57.10]) by ipgate.indiabulls.com with ESMTP; 21 Feb 2013 21:29:25 +0530 Message-ID: <51264544.7070300@ibtechnology.com> Date: Thu, 21 Feb 2013 21:33:16 +0530 From: sreenatha User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: vrrp@ietf.org References: In-Reply-To: Content-Type: text/plain; charset="iso-8859-1"; format="flowed" Content-Transfer-Encoding: quoted-printable 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2013 16:04:00 -0000 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? 2. How much time Master router should wait to receive ADVERTISEMENT = message from any backup router? 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? Thanks, Sreenatha Setty On 02/21/2013 01:30 AM, 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 > > 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 > > You can reach the person managing the list at > 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)" > To:"vrrp@ietf.org" > Subject: [VRRP] Proposal for Maintenance Event for VRRP [RFC-5798] > Message-ID: > > Content-Type: text/plain; charset=3D"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 Mas= ter to Redundant (Backup Router). > > Problem Statement: > VRRP preemption is not configured on the redundant / backup router. How t= o initiate VRRP Traffic to failover to the redundant / backup router gracef= ully 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 =3D 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 rout= er sends an ADVERTISEMENT (triggered by receiving an ADVERTISEMENT with Pri= ority =3D 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 configur= ation. > > 2) By setting the priority =3D 0 for a particular VRID. > > Thanks > -Anurag > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > > ------------------------------ > > _______________________________________________ > vrrp mailing list > 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 informatio= n and is intended for the use of the addressee only.If you are not an inten= ded recipient you are requested not to reproduce, copy disseminate or in an= y manner distribute this email communication as the same is strictly prohib= ited. If you have received this email in error, please notify the sender im= mediately by return e-mail and delete the communication sent in error. Emai= l communications cannot be guaranteed to be secure & error free and IB Tech= nology is not liable for any errors in the email communication or for the p= roper, timely and complete transmission thereof. From ankothar@cisco.com Thu Feb 21 08:43:01 2013 Return-Path: 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 1222921F8EA5 for ; Thu, 21 Feb 2013 08:43:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.534 X-Spam-Level: X-Spam-Status: No, score=-10.534 tagged_above=-999 required=5 tests=[AWL=0.065, BAYES_00=-2.599, 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 DpH-azGRcSx5 for ; Thu, 21 Feb 2013 08:43:00 -0800 (PST) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 0B5B321F8EDD for ; Thu, 21 Feb 2013 08:42:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6315; q=dns/txt; s=iport; t=1361464980; x=1362674580; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=bVJk+rqMeVTPYVNY9pl0RpI24keW8r4e1m0o7YgBDBc=; b=SVH53rW6a/LURYpWZzbJB3n6C74DuSIeWYNQ6yzNod/tWjZFYAdmhnhF t1X1Vj8Lkde54t5YbshYI8sourpMpgvqaOWNkTO0huDoZISfjIgvgIFIi qK8GVquD4bv3Y46hSKo4o9gpGdvJ6cK+fDe1ZhzIKOIvsopzC+Hn7J3BY c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgIFAItNJlGtJXG//2dsb2JhbABFwHuBBRZzgh8BAQEDAQEBATcUIBcEAgEIEQMBAQEBCgIBEQkHJwoBFAkIAgQBEggBEgIEh2sGDL55jTQJEIEQBiAGDAIEgllhA6cUgweBaQYDFx4 X-IronPort-AV: E=Sophos;i="4.84,710,1355097600"; d="scan'208";a="176700388" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-9.cisco.com with ESMTP; 21 Feb 2013 16:42:59 +0000 Received: from xhc-rcd-x12.cisco.com (xhc-rcd-x12.cisco.com [173.37.183.86]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id r1LGgxbf020103 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 21 Feb 2013 16:42:59 GMT Received: from xmb-rcd-x05.cisco.com ([169.254.15.93]) by xhc-rcd-x12.cisco.com ([173.37.183.86]) with mapi id 14.02.0318.004; Thu, 21 Feb 2013 10:42:59 -0600 From: "Anurag Kothari (ankothar)" To: sreenatha , "vrrp@ietf.org" Thread-Topic: [VRRP] Proposal for Maintenance Event for VRRP [RFC-5798] Thread-Index: AQHOEE0W0nCX6622rECg/5kR/Wmy05iEejtg Date: Thu, 21 Feb 2013 16:42:58 +0000 Message-ID: References: <51264544.7070300@ibtechnology.com> In-Reply-To: <51264544.7070300@ibtechnology.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.82.219.226] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2013 16:43:01 -0000 Hi Sreenatha This ideas is based on the way the priority is defined in Section 5.2.4. an= d 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 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. " Please see my responses inline [Anurag]: Thanks -Anurag -----Original Message----- From: vrrp-bounces@ietf.org [mailto:vrrp-bounces@ietf.org] On Behalf Of sre= enatha Sent: Thursday, February 21, 2013 11:03 AM To: 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 change= d, right? So if back-up router has less priority, even if Master receives t= he ADVERTISEMENT from the backup router, Master will discard.=20 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 =3D 0 till some other rou= ter 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 VRR= P 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 wrote: > If you have received this digest without all the individual message=20 > attachments you will need to update your digest options in your list=20 > 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=20 > MIME or Plain Text Digests?" to MIME. You can set this option=20 > globally for all the list digests you receive at this point. > > > > Send vrrp mailing list submissions to > 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 > > You can reach the person managing the list at > vrrp-owner@ietf.org > > When replying, please edit your Subject line so it is more specific=20 > 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)"=20 > To:"vrrp@ietf.org" > Subject: [VRRP] Proposal for Maintenance Event for VRRP [RFC-5798] > Message-ID: > > Content-Type: text/plain; charset=3D"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 Mas= ter to Redundant (Backup Router). > > Problem Statement: > VRRP preemption is not configured on the redundant / backup router.=20 > How to initiate VRRP Traffic to failover to the redundant / backup=20 > router gracefully without modifying the configuration on the redundant=20 > / 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 =3D 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 rout= er sends an ADVERTISEMENT (triggered by receiving an ADVERTISEMENT with Pri= ority =3D 0) and becomes master. > > Here are couple of examples of how a maintenance event may be=20 > triggered > > > 1) By some user command e.g. "maintenance-mode" in the vrrp configur= ation. > > 2) By setting the priority =3D 0 for a particular VRID. > > Thanks > -Anurag > > -------------- next part -------------- An HTML attachment was=20 > scrubbed... > URL: a6571f/attachment.htm> > > ------------------------------ > > _______________________________________________ > vrrp mailing list > vrrp@ietf.org > https://www.ietf.org/mailman/listinfo/vrrp > > > End of vrrp Digest, Vol 81, Issue 1 > *********************************** > Disclaimer :=20 This email communication may contain privileged and confidential informatio= n and is intended for the use of the addressee only.If you are not an inten= ded recipient you are requested not to reproduce, copy disseminate or in an= y manner distribute this email communication as the same is strictly prohib= ited. If you have received this email in error, please notify the sender im= mediately by return e-mail and delete the communication sent in error. Emai= l communications cannot be guaranteed to be secure & error free and IB Tech= nology is not liable for any errors in the email communication or for the p= roper, timely and complete transmission thereof. _______________________________________________ vrrp mailing list vrrp@ietf.org https://www.ietf.org/mailman/listinfo/vrrp From sreenatha.setty@ibtechnology.com Thu Feb 21 20:26:09 2013 Return-Path: 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 73E3321E803D for ; Thu, 21 Feb 2013 20:26:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 FZwmyFySk7Zh for ; Thu, 21 Feb 2013 20:26:08 -0800 (PST) Received: from ipinternal.indiabulls.com (ipinternal.indiabulls.com [202.54.119.192]) by ietfa.amsl.com (Postfix) with ESMTP id ACD0E21F87C6 for ; Thu, 21 Feb 2013 20:26:05 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqgEAAjzJlGsEQGd/2dsb2JhbABFjCm0cIEec4IfAQEBAQMBAQFLIAoBDAQLDQQDAQEBAQkDARIIBwkDAgECARUKFQkIBgsCAQUCAQEFEgIEh32/KY00CRCBMAYGBQcGgzoDiGeFQ41vjgqBYQQCAw X-IronPort-AV: E=Sophos;i="4.84,713,1355077800"; d="scan'208,217";a="7712469" X-IronPort-AV: E=Sophos;i="4.84,713,1355077800"; d="scan'208,217";a="102985854" Received: from 110-234-12-145.del.tulipconnect.com (HELO [172.16.210.32]) ([110.234.12.145]) by ipgate.indiabulls.com with ESMTP; 22 Feb 2013 09:51:43 +0530 Message-ID: <5126F33F.1080005@ibtechnology.com> Date: Fri, 22 Feb 2013 09:55:35 +0530 From: sreenatha User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: "Anurag Kothari (ankothar)" References: <51264544.7070300@ibtechnology.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------080809040106050203080509" Cc: "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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2013 04:26:09 -0000 This is a multi-part message in MIME format. --------------080809040106050203080509 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format="flowed" Content-Transfer-Encoding: quoted-printable Hi Anurag, Your proposal is: - If a Maintenance event is received, then: + Cancel the Adver_Timer + Send an ADVERTISEMENT with Priority =3D 0 -endif // maintenance recv And you mentioned that router need to send regular ADVERTISEMENT messa= ge till it receives the ADVERTISEMENT message from the backup router. "2. How much time Master router should wait to receive ADVERTISEMENT messag= e from any backup router? [Anurag] Master doesn't have to wait. After receiving the maintenance event= it will send regular ADVERTISEMENT with Priority =3D 0 till some other rou= ter 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 =3D 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 t= he 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 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. > " > > Please see my responses inline [Anurag]: > > Thanks > -Anurag > > -----Original Message----- > From: vrrp-bounces@ietf.org [mailto:vrrp-bounces@ietf.org] On Behalf Of s= reenatha > Sent: Thursday, February 21, 2013 11:03 AM > To: 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 chan= ged, 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 VR= ID) will change to 0. > > 2. How much time Master router should wait to receive ADVERTISEMENT messa= ge from any backup router? > > [Anurag] Master doesn't have to wait. After receiving the maintenance eve= nt it will send regular ADVERTISEMENT with Priority =3D 0 till some other r= outer 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 V= RRP Priority. So you are proposing to change this value also? > > [Anurag] Yes. Priority 0 will have to be made a user configurable value t= o indicate the intention of a router to relinquish Master Status. > > Thanks, > Sreenatha Setty > > On 02/21/2013 01:30 AM, 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 >> >> 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 >> >> You can reach the person managing the list at >> 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)" >> To:"vrrp@ietf.org" >> Subject: [VRRP] Proposal for Maintenance Event for VRRP [RFC-5798] >> Message-ID: >> >> Content-Type: text/plain; charset=3D"us-ascii" >> >> Hi >> >> I want to propose a new Maintenance Event (modification of Shutdown Even= t) for VRRP (RFC-5798] which would allow to gracefully failover the VRRP Ma= ster 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 =3D 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 rou= ter sends an ADVERTISEMENT (triggered by receiving an ADVERTISEMENT with Pr= iority =3D 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 configu= ration. >> >> 2) By setting the priority =3D 0 for a particular VRID. >> >> Thanks >> -Anurag >> >> -------------- next part -------------- An HTML attachment was >> scrubbed... >> URL:> a6571f/attachment.htm> >> >> ------------------------------ >> >> _______________________________________________ >> vrrp mailing list >> 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 informat= ion and is intended for the use of the addressee only.If you are not an int= ended recipient you are requested not to reproduce, copy disseminate or in = any manner distribute this email communication as the same is strictly proh= ibited. If you have received this email in error, please notify the sender = immediately by return e-mail and delete the communication sent in error. Em= ail communications cannot be guaranteed to be secure & error free and IB Te= chnology 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 > Disclaimer : = This email communication may contain privileged and confidential informatio= n and is intended for the use of the addressee only.If you are not an inten= ded recipient you are requested not to reproduce, copy disseminate or in an= y manner distribute this email communication as the same is strictly prohib= ited. If you have received this email in error, please notify the sender im= mediately by return e-mail and delete the communication sent in error. Emai= l communications cannot be guaranteed to be secure & error free and IB Tech= nology is not liable for any errors in the email communication or for the p= roper, timely and complete transmission thereof. --------------080809040106050203080509 MIME-Version: 1.0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi Anurag,
   Your proposal is:

- If a Maintenance event is received, then:

+ Cancel the Adver_Timer

+ Send an ADVERTISEMENT with Priority =3D 0

-endif // maintenance recv


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

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

[Anurag] Master doesn't have to wait. After receiving the maintenance event=
 it will send regular ADVERTISEMENT with Priority =3D 0 till some other rou=
ter 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 =3D 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 t=
he 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. an=
d 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] On Beha=
lf Of sreenatha
Sent: Thursday, February 21, 2013 11:03 AM
To: vrr=
p@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 change=
d, right? So if back-up router has less priority, even if Master receives t=
he 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 =3D 0 till some other rou=
ter 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 VRR=
P 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 wrote:

If you have received this digest without all the ind=
ividual 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@i=
etf.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

You can reach the person managing the list at
	=
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> =

To:"vrrp@i=
etf.org"  <vrrp@ietf.org>
Subject: [VRRP] Proposal for Maintenance Event for VRRP [RFC-5798]
Message-ID:
	<A2BB90B33FFDF740876C5AAE307D83D=
B1C290327@xmb-rcd-x05.cisco.com>
Content-Type: text/plain; charset=3D"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 Maste=
r 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 =3D 0

-endif // maintenance recv

Unlike Shutdown event the router will not "Transition to the {Initialize} s=
tate" and continue to be Master and forward traffic  till the backup router=
 sends an ADVERTISEMENT (triggered by receiving an ADVERTISEMENT with Prior=
ity =3D 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 configurat=
ion.

2)      By setting the priority =3D 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
a6571f/attachment.htm>

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

_______________________________________________
vrrp mailing list
vrrp@ie=
tf.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 informatio=
n and is intended for the use of the addressee only.If you are not an inten=
ded recipient you are requested not to reproduce, copy disseminate or in an=
y manner distribute this email communication as the same is strictly prohib=
ited. If you have received this email in error, please notify the sender im=
mediately by return e-mail and delete the communication sent in error. Emai=
l communications cannot be guaranteed to be secure & error free and IB =
Technology is not liable for any errors in the email communication or for t=
he proper, timely and complete transmission thereof.

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



    

    

  
Disclaimer : 
This e=
mail communication may contain privileged and confidential information and =
is intended for the use of the addressee only.If you are not an intended re=
cipient you are requested not to reproduce, copy disseminate or in any mann=
er distribute this email communication as the same is strictly prohibited. =
If you have received this email in error, please notify the sender immediat=
ely by return e-mail and delete the communication sent in error. Email comm=
unications cannot be guaranteed to be secure & error free and IB Techno=
logy is not liable for any errors in the email communication or for the pro=
per, timely and complete transmission thereof.



--------------080809040106050203080509--


From ankothar@cisco.com  Fri Feb 22 03:41:50 2013
Return-Path: 
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 64F4421F8ECD for ; Fri, 22 Feb 2013 03:41:50 -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 YF5Q35-L7l1u for ; Fri, 22 Feb 2013 03:41:48 -0800 (PST)
Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 4110021F8EFD for ; Fri, 22 Feb 2013 03:41:48 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=33223; q=dns/txt; s=iport; t=1361533308; x=1362742908; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=ei8Lg742MMdraiJo48PKOij5iqTQnbd3ai6oGiQkgNo=; b=Il9B/TfbltPnFSeJerXFafgVaJXZOHTmkwPrehvNb80F5k+eWHKEJZyf l5Y1N64TdYzg4foD29Deo5niYG0ipMxvjXjOsiFSGAgrs30kodKXJkLVI db2eIG3Cc1o6vvhLSXblVLREzsNSDsosxuKOlqTMoeai0WI4uU8c2sdZG o=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgMFAKtYJ1GtJV2Y/2dsb2JhbABFgkO+XYEKFnOCHwEBAQQBAQEqISALDAQCAQgRAwEBAQsCARMBBgcnCgEUCQgCBA4FCAESAgSHcQy/JY00CRCBEAYHEwYGAQQGAQIEgllhA6cdgweBaQQCAxce
X-IronPort-AV: E=Sophos;i="4.84,715,1355097600";  d="scan'208,217";a="180009140"
Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-2.cisco.com with ESMTP; 22 Feb 2013 11:41:47 +0000
Received: from xhc-aln-x03.cisco.com (xhc-aln-x03.cisco.com [173.36.12.77]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r1MBflVs020496 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 22 Feb 2013 11:41:47 GMT
Received: from xmb-rcd-x05.cisco.com ([169.254.15.93]) by xhc-aln-x03.cisco.com ([173.36.12.77]) with mapi id 14.02.0318.004; Fri, 22 Feb 2013 05:41:47 -0600
From: "Anurag Kothari (ankothar)" 
To: sreenatha 
Thread-Topic: [VRRP] Proposal for Maintenance Event for VRRP [RFC-5798]
Thread-Index: AQHOEE0W0nCX6622rECg/5kR/Wmy05iEejtggAEzEYCAAA+ssA==
Date: Fri, 22 Feb 2013 11:41:47 +0000
Message-ID: 
References:  <51264544.7070300@ibtechnology.com>  <5126F33F.1080005@ibtechnology.com>
In-Reply-To: <5126F33F.1080005@ibtechnology.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_A2BB90B33FFDF740876C5AAE307D83DB1C292974xmbrcdx05ciscoc_"
MIME-Version: 1.0
Cc: "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  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 22 Feb 2013 11:41:50 -0000

--_000_A2BB90B33FFDF740876C5AAE307D83DB1C292974xmbrcdx05ciscoc_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

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 propos=
al 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
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 =3D 0



-endif // maintenance recv





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



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



[Anurag] Master doesn't have to wait. After receiving the maintenance event=
 it will send regular ADVERTISEMENT with Priority =3D 0 till some other rou=
ter 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 =3D 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 t=
he 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. an=
d 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                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. 

"



Please see my responses inline [Anurag]:



Thanks

-Anurag



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

From: vrrp-bounces@ietf.org [mailto:vrrp-boun=
ces@ietf.org] On Behalf Of sreenatha

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

To: 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 change=
d, right? So if back-up router has less priority, even if Master receives t=
he 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 =3D 0 till some other rou=
ter 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 VRR=
P 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=
 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



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



You can reach the person managing the list at

   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)"

To:"vrrp@ietf.org"  

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

Message-ID:

   

Content-Type: text/plain; charset=3D"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 Maste=
r 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 =3D 0



-endif // maintenance recv



Unlike Shutdown event the router will not "Transition to the {Initialize} s=
tate" and continue to be Master and forward traffic  till the backup router=
 sends an ADVERTISEMENT (triggered by receiving an ADVERTISEMENT with Prior=
ity =3D 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 configurat=
ion.



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



Thanks

-Anurag



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

scrubbed...

URL:

a6571f/attachment.htm>



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



_______________________________________________

vrrp mailing list

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 informatio=
n and is intended for the use of the addressee only.If you are not an inten=
ded recipient you are requested not to reproduce, copy disseminate or in an=
y manner distribute this email communication as the same is strictly prohib=
ited. If you have received this email in error, please notify the sender im=
mediately by return e-mail and delete the communication sent in error. Emai=
l communications cannot be guaranteed to be secure & error free and IB Tech=
nology is not liable for any errors in the email communication or for the p=
roper, timely and complete transmission thereof.



_______________________________________________

vrrp mailing list

vrrp@ietf.org

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




Disclaimer :
This email communication may contain privileged and confidential informatio=
n and is intended for the use of the addressee only.If you are not an inten=
ded recipient you are requested not to reproduce, copy disseminate or in an=
y manner distribute this email communication as the same is strictly prohib=
ited. If you have received this email in error, please notify the sender im=
mediately by return e-mail and delete the communication sent in error. Emai=
l communications cannot be guaranteed to be secure & error free and IB Tech=
nology is not liable for any errors in the email communication or for the p=
roper, timely and complete transmission thereof.

--_000_A2BB90B33FFDF740876C5AAE307D83DB1C292974xmbrcdx05ciscoc_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











Hi Sreenatha


 <=
/p>

My bad, by cancel I meant=
 reset the timer.


 <=
/p>

I would prefer defining m=
aintenance event itself as (or being triggered by) priority being set to 0 =
for a VRID. So probably we can rephrase the proposal as:<=
/p>

 <=
/p>

- If a Maintenance event is received, then:


 


+ Send an ADVERTISEMENT


 


+ Reset the Adver_Timer to Advertisement_Interval


 


-endif // maintenance recv


 <=
/p>

Thanks<=
/p>

-Anurag=



 <=
/p>





From: sreenatha [mailto:sreenatha.setty@ibtechnology.co=
m]


Sent: Thursday, February 21, 2013 11:26 PM

To: Anurag Kothari (ankothar)

Cc: vrrp@ietf.org

Subject: Re: [VRRP] Proposal for Maintenance Event for VRRP [RFC-579=
8]






 




Hi Anurag,

   Your proposal is:








- If a Maintenance event is received, then:


 


+ Cancel the Adver_Timer


 


+ Send an ADVERTISEMENT with Priority =3D 0


 


-endif // maintenance recv


 


 


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


 


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


 


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


<=
o:p> 


I=
f Advert_Timer is cancelled, how regular ADVERTISEMENT messages are sent?


 


S=
o i am suggesting slight changes in the Proposal:


<=
o:p> 


-=
 If a Maintenance event is received, then:


<=
o:p> 


&=
#43; Change the router priority to 0


<=
o:p> 


&=
#43; Send an ADVERTISEMENT with Priority =3D 0


<=
o:p> 


&=
#43; Reset the Adver_Timer


<=
o:p> 


&=
nbsp;-endif // maintenance recv


<=
o:p> 


T=
his will ensure that:


1=
. ADVERTISEMENT message with priority 0 is sent  immediately on receiv=
ing Maintenance event.


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


<=
o:p> 


T=
hanks,


S=
reenatha Setty


<=
o:p> 


 






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, indicati=
ng that the


   current Master has stopped participating in VRRP.  T=
his is used to


   trigger Backup routers to quickly transition to Master wi=
thout having


   to wait for the current Master to time out.

"


 


"


   Priority        &=
nbsp;     <snip>  The value of 0 (zero) is


           &nbs=
p;            &=
nbsp;      reserved for the Master router to<=
/o:p>


           &nbs=
p;            &=
nbsp;      indicate it is releasing responsibility=



           &nbs=
p;            &=
nbsp;      for the virtual router.  The range=
 1-254


           &nbs=
p;            &=
nbsp;      (decimal) is available for VRRP routers=



           &nbs=
p;            &=
nbsp;      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] On Behalf Of sreenatha


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


To: 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 c=
hanged, right? So if back-up router has less priority, even if Master recei=
ves 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 me=
ssage from any backup router?


 


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


 


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



 


[Anurag] Yes. Priority 0 will have to be made a user configurable valu=
e 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 wrote:




If you have received this digest without all the individual message 


attachments you will need to update your digest options in your list <=
o:p>


subscription.  To do so, go to


 


https://www.iet=
f.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 opti=
on 


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


 


 


 


Send vrrp mailing list submissions to


   vrrp@ietf.org


 


To subscribe or unsubscribe via the World Wide Web, visit

   ht=
tps://www.ietf.org/mailman/listinfo/vrrp


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


   vrrp-request@iet=
f.org


 


You can reach the person managing the list at


   vrrp-owner@ietf.or=
g


 


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-579=
8]


       (Anurag Kothari (ankothar))<=
/o:p>


 


 


----------------------------------------------------------------------=



 


Message: 1


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


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


To:"vrrp@ietf.org" =
; <vrrp@ietf.org>

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


Message-ID:


   <A2BB90B33FFDF740876C5AAE307D83DB1C290327@xmb-r=
cd-x05.cisco.com>


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

 


Hi


 


I want to propose a new Maintenance Event (modification of Shutdown Ev=
ent) 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 =3D 0


 


-endif // maintenance recv


 


Unlike Shutdown event the router will not "Transition to the {Ini=
tialize} state" and continue to be Master and forward traffic  ti=
ll the backup router sends an ADVERTISEMENT (triggered by receiving an ADVE=
RTISEMENT with Priority =3D 0) and becomes master.




 




 


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


triggered


 


 


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


 


2)      By setting the priority =3D 0 for a p=
articular VRID.


 


Thanks


-Anurag


 


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


scrubbed...


URL:<http://www.ietf.org/mail-archive/web/v=
rrp/attachments/20130219/36


a6571f/attachment=
.htm>


 


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


 


_______________________________________________


vrrp mailing list


vrrp@ietf.org


https://www.iet=
f.org/mailman/listinfo/vrrp


 


 


End of vrrp Digest, Vol 81, Issue 1


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


 




 


Disclaimer : 


This email communication may contain privileged and confidential infor=
mation 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 p=
rohibited. If you have received this email in error, please notify the send=
er immediately by return e-mail and delete the communication sent in error.=
 Email communications cannot be guaranteed to be secure & error free an=
d 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.iet=
f.org/mailman/listinfo/vrrp


 




 


Disclaimer : 

This email communication may contain privileged and confidential informatio=
n and is intended for the use of the addressee only.If you are not an inten=
ded recipient you are requested not to reproduce, copy disseminate or in an=
y manner distribute this email communication
 as the same is strictly prohibited. If you have received this email in err=
or, please notify the sender immediately by return e-mail and delete the co=
mmunication 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.






--_000_A2BB90B33FFDF740876C5AAE307D83DB1C292974xmbrcdx05ciscoc_--

From ankothar@cisco.com  Fri Feb 22 04:09:03 2013
Return-Path: 
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 ; 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 ; 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 ; 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)" 
To: sreenatha 
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: 
References:  <51264544.7070300@ibtechnology.com>  <5126F33F.1080005@ibtechnology.com> 
In-Reply-To: 
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" 
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  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 22 Feb 2013 12:09:03 -0000

--_000_A2BB90B33FFDF740876C5AAE307D83DB1C2929E8xmbrcdx05ciscoc_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

On Further Thought:

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

This would make it more generic. Whenever the user configures priority =3D =
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 Anu=
rag 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 propos=
al 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
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 =3D 0



-endif // maintenance recv





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



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



[Anurag] Master doesn't have to wait. After receiving the maintenance event=
 it will send regular ADVERTISEMENT with Priority =3D 0 till some other rou=
ter 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 =3D 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 t=
he 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. an=
d 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                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. 

"



Please see my responses inline [Anurag]:



Thanks

-Anurag



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

From: vrrp-bounces@ietf.org [mailto:vrrp-boun=
ces@ietf.org] On Behalf Of sreenatha

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

To: 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 change=
d, right? So if back-up router has less priority, even if Master receives t=
he 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 =3D 0 till some other rou=
ter 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 VRR=
P 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=
 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



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



You can reach the person managing the list at

   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)"

To:"vrrp@ietf.org"  

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

Message-ID:

   

Content-Type: text/plain; charset=3D"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 Maste=
r 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 =3D 0



-endif // maintenance recv



Unlike Shutdown event the router will not "Transition to the {Initialize} s=
tate" and continue to be Master and forward traffic  till the backup router=
 sends an ADVERTISEMENT (triggered by receiving an ADVERTISEMENT with Prior=
ity =3D 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 configurat=
ion.



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



Thanks

-Anurag



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

scrubbed...

URL:

a6571f/attachment.htm>



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



_______________________________________________

vrrp mailing list

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 informatio=
n and is intended for the use of the addressee only.If you are not an inten=
ded recipient you are requested not to reproduce, copy disseminate or in an=
y manner distribute this email communication as the same is strictly prohib=
ited. If you have received this email in error, please notify the sender im=
mediately by return e-mail and delete the communication sent in error. Emai=
l communications cannot be guaranteed to be secure & error free and IB Tech=
nology is not liable for any errors in the email communication or for the p=
roper, timely and complete transmission thereof.



_______________________________________________

vrrp mailing list

vrrp@ietf.org

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




Disclaimer :
This email communication may contain privileged and confidential informatio=
n and is intended for the use of the addressee only.If you are not an inten=
ded recipient you are requested not to reproduce, copy disseminate or in an=
y manner distribute this email communication as the same is strictly prohib=
ited. If you have received this email in error, please notify the sender im=
mediately by return e-mail and delete the communication sent in error. Emai=
l communications cannot be guaranteed to be secure & error free and IB Tech=
nology is not liable for any errors in the email communication or for the p=
roper, timely and complete transmission thereof.

--_000_A2BB90B33FFDF740876C5AAE307D83DB1C2929E8xmbrcdx05ciscoc_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











On Further Thought:<=
/o:p>


 <=
/p>

We may want to define mai=
ntenance event (probably rename it “Priority Change Event”) bei=
ng triggered by a change in priority for a VRID (including dynamic changes
 to the priority e.g. changes due to tracking interface).=



 <=
/p>

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


 <=
/p>

Thanks<=
/p>

-Anurag=



 <=
/p>





From: vrrp-bounces@ietf.org [mailto:vrrp-bounces@ietf.o=
rg]
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-579=
8]






 


Hi Sreenatha


 <=
/p>

My bad, by cancel I meant=
 reset the timer.


 <=
/p>

I would prefer defining m=
aintenance event itself as (or being triggered by) priority being set to 0 =
for a VRID. So probably we can rephrase the proposal as:<=
/p>

 <=
/p>

- If a Maintenance event is received, then:


 


+ Send an ADVERTISEMENT


 


+ Reset the Adver_Timer to Advertisement_Interval


 


-endif // maintenance recv


 <=
/p>

Thanks<=
/p>

-Anurag=



 <=
/p>





From: sreenatha [mailto:sreenatha.setty@ibtechnology.com]


Sent: Thursday, February 21, 2013 11:26 PM

To: Anurag Kothari (ankothar)

Cc: vrrp@ietf.org

Subject: Re: [VRRP] Proposal for Maintenance Event for VRRP [RFC-579=
8]






 




Hi Anurag,

   Your proposal is:






- If a Maintenance event is received, then:


 


+ Cancel the Adver_Timer


 


+ Send an ADVERTISEMENT with Priority =3D 0


 


-endif // maintenance recv


 


 


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


 


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


 


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


<=
o:p> 


I=
f Advert_Timer is cancelled, how regular ADVERTISEMENT messages are sent?


 


S=
o i am suggesting slight changes in the Proposal:


<=
o:p> 


-=
 If a Maintenance event is received, then:


<=
o:p> 


&=
#43; Change the router priority to 0


<=
o:p> 


&=
#43; Send an ADVERTISEMENT with Priority =3D 0


<=
o:p> 


&=
#43; Reset the Adver_Timer


<=
o:p> 


&=
nbsp;-endif // maintenance recv


<=
o:p> 


T=
his will ensure that:


1=
. ADVERTISEMENT message with priority 0 is sent  immediately on receiv=
ing Maintenance event.


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


<=
o:p> 


T=
hanks,


S=
reenatha Setty


<=
o:p> 


 






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, indicati=
ng that the


   current Master has stopped participating in VRRP.  T=
his is used to


   trigger Backup routers to quickly transition to Master wi=
thout having


   to wait for the current Master to time out.

"


 


"


   Priority        &=
nbsp;     <snip>  The value of 0 (zero) is


           &nbs=
p;            &=
nbsp;      reserved for the Master router to<=
/o:p>


           &nbs=
p;            &=
nbsp;      indicate it is releasing responsibility=



           &nbs=
p;            &=
nbsp;      for the virtual router.  The range=
 1-254


           &nbs=
p;            &=
nbsp;      (decimal) is available for VRRP routers=



           &nbs=
p;            &=
nbsp;      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] On Behalf Of sreenatha


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


To: 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 c=
hanged, right? So if back-up router has less priority, even if Master recei=
ves 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 me=
ssage from any backup router?


 


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


 


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



 


[Anurag] Yes. Priority 0 will have to be made a user configurable valu=
e 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 wrote:




If you have received this digest without all the individual message 


attachments you will need to update your digest options in your list <=
o:p>


subscription.  To do so, go to


 


https://www.iet=
f.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 opti=
on 


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


 


 


 


Send vrrp mailing list submissions to


   vrrp@ietf.org


 


To subscribe or unsubscribe via the World Wide Web, visit

   ht=
tps://www.ietf.org/mailman/listinfo/vrrp


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


   vrrp-request@iet=
f.org


 


You can reach the person managing the list at


   vrrp-owner@ietf.or=
g


 


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-579=
8]


       (Anurag Kothari (ankothar))<=
/o:p>


 


 


----------------------------------------------------------------------=



 


Message: 1


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


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


To:"vrrp@ietf.org" =
; <vrrp@ietf.org>

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


Message-ID:


   <A2BB90B33FFDF740876C5AAE307D83DB1C290327@xmb-r=
cd-x05.cisco.com>


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

 


Hi


 


I want to propose a new Maintenance Event (modification of Shutdown Ev=
ent) 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 =3D 0


 


-endif // maintenance recv


 


Unlike Shutdown event the router will not "Transition to the {Ini=
tialize} state" and continue to be Master and forward traffic  ti=
ll the backup router sends an ADVERTISEMENT (triggered by receiving an ADVE=
RTISEMENT with Priority =3D 0) and becomes master.




 




 


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


triggered


 


 


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


 


2)      By setting the priority =3D 0 for a p=
articular VRID.


 


Thanks


-Anurag


 


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


scrubbed...


URL:<http://www.ietf.org/mail-archive/web/v=
rrp/attachments/20130219/36


a6571f/attachment=
.htm>


 


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


 


_______________________________________________


vrrp mailing list


vrrp@ietf.org


https://www.iet=
f.org/mailman/listinfo/vrrp


 


 


End of vrrp Digest, Vol 81, Issue 1


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


 




 


Disclaimer : 


This email communication may contain privileged and confidential infor=
mation 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 p=
rohibited. If you have received this email in error, please notify the send=
er immediately by return e-mail and delete the communication sent in error.=
 Email communications cannot be guaranteed to be secure & error free an=
d 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.iet=
f.org/mailman/listinfo/vrrp


 




 


Disclaimer : 

This email communication may contain privileged and confidential informatio=
n and is intended for the use of the addressee only.If you are not an inten=
ded recipient you are requested not to reproduce, copy disseminate or in an=
y manner distribute this email communication
 as the same is strictly prohibited. If you have received this email in err=
or, please notify the sender immediately by return e-mail and delete the co=
mmunication 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.






--_000_A2BB90B33FFDF740876C5AAE307D83DB1C2929E8xmbrcdx05ciscoc_--

From tperiyannan@extremenetworks.com  Fri Feb 22 05:56:25 2013
Return-Path: 
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 002B521F8EAF for ; Fri, 22 Feb 2013 05:56:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
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 dLfd5e9kKZ8q for ; Fri, 22 Feb 2013 05:56:23 -0800 (PST)
Received: from ussc-casht-p1.extremenetworks.com (ussc-casht-p1.extremenetworks.com [207.179.9.62]) by ietfa.amsl.com (Postfix) with ESMTP id 23F2D21F8E6C for ; Fri, 22 Feb 2013 05:56:22 -0800 (PST)
Received: from inch-casht-p1.corp.extremenetworks.com (10.120.89.28) by ussc-casht-p1.corp.extremenetworks.com (10.0.4.73) with Microsoft SMTP Server (TLS) id 8.3.297.1; Fri, 22 Feb 2013 05:56:22 -0800
Received: from INEXCHANGE.corp.extremenetworks.com ([192.168.131.111]) by inch-casht-p1.corp.extremenetworks.com ([10.120.89.28]) with mapi; Fri, 22 Feb 2013 19:26:18 +0530
From: Thirumavalavan Periyannan 
To: "vrrp@ietf.org" 
CC: "vrrp@ietf.org" 
Date: Fri, 22 Feb 2013 19:26:08 +0530
Thread-Topic: vrrp Digest, Vol 81, Issue 3
Thread-Index: Ac4RBGKo4P5hWc5lTiSJPUEgi0SCSQ==
Message-ID: <14CA6619-DB7C-40ED-85E4-535CB689AC86@extremenetworks.com>
References: 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-GB
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [VRRP] vrrp Digest, Vol 81, Issue 3
X-BeenThere: vrrp@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Virtual Router Redundancy Protocol  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 22 Feb 2013 13:56:25 -0000

Hi Anurag,

You meant to say that when we do graceful failover on VRRP Master then traf=
fic needs switch to VRRP backup router without waiting for Master_Down_Inte=
rval time.

Please correct me if I am wrong.

Sent from my iPhone

On 22-Feb-2013, at 5:11 PM, "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
>
> 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
>
> You can reach the person managing the list at
>        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. Re: Proposal for Maintenance Event for VRRP [RFC-5798] (sreenatha)
>   2. Re: Proposal for Maintenance Event for VRRP [RFC-5798]
>      (Anurag Kothari (ankothar))
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Fri, 22 Feb 2013 09:55:35 +0530
> From: sreenatha 
> To: "Anurag Kothari (ankothar)" 
> Cc: "vrrp@ietf.org" 
> Subject: Re: [VRRP] Proposal for Maintenance Event for VRRP [RFC-5798]
> Message-ID: <5126F33F.1080005@ibtechnology.com>
> Content-Type: text/plain; charset=3D"iso-8859-1"; Format=3D"flowed"
>
> Hi Anurag,
>    Your proposal is:
>
> - If a Maintenance event is received, then:
>
> + Cancel the Adver_Timer
>
> + Send an ADVERTISEMENT with Priority =3D 0
>
> -endif // maintenance recv
>
>
>     And you mentioned that router need to send regular ADVERTISEMENT mess=
age till it receives the ADVERTISEMENT message from the backup router.
>
> "2. How much time Master router should wait to receive ADVERTISEMENT mess=
age from any backup router?
>
> [Anurag] Master doesn't have to wait. After receiving the maintenance eve=
nt it will send regular ADVERTISEMENT with Priority =3D 0 till some other r=
outer 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 =3D 0
>
> + Reset the Adver_Timer
>
>  -endif // maintenance recv
>
> This will ensure that:
> 1. ADVERTISEMENT message with priority 0 is sent  immediately on receivin=
g 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                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. 
>> "
>>
>> Please see my responses inline [Anurag]:
>>
>> Thanks
>> -Anurag
>>
>> -----Original Message-----
>> From: 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
>> 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 cha=
nged, right? So if back-up router has less priority, even if Master receive=
s 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 V=
RID) will change to 0.
>>
>> 2. How much time Master router should wait to receive ADVERTISEMENT mess=
age from any backup router?
>>
>> [Anurag] Master doesn't have to wait. After receiving the maintenance ev=
ent it will send regular ADVERTISEMENT with Priority =3D 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 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
>>>
>>> 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
>>>
>>> You can reach the person managing the list at
>>>     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)"
>>> To:"vrrp@ietf.org"  
>>> Subject: [VRRP] Proposal for Maintenance Event for VRRP [RFC-5798]
>>> Message-ID:
>>>     
>>> Content-Type: text/plain; charset=3D"us-ascii"
>>>
>>> Hi
>>>
>>> I want to propose a new Maintenance Event (modification of Shutdown Eve=
nt) for VRRP (RFC-5798] which would allow to gracefully failover the VRRP M=
aster 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 =3D 0
>>>
>>> -endif // maintenance recv
>>>
>>> Unlike Shutdown event the router will not "Transition to the {Initializ=
e} state" and continue to be Master and forward traffic  till the backup ro=
uter sends an ADVERTISEMENT (triggered by receiving an ADVERTISEMENT with P=
riority =3D 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 config=
uration.
>>>
>>> 2)      By setting the priority =3D 0 for a particular VRID.
>>>
>>> Thanks
>>> -Anurag
>>>
>>> -------------- next part -------------- An HTML attachment was
>>> scrubbed...
>>> URL:>> a6571f/attachment.htm>
>>>
>>> ------------------------------
>>>
>>> _______________________________________________
>>> vrrp mailing list
>>> 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 informa=
tion and is intended for the use of the addressee only.If you are not an in=
tended recipient you are requested not to reproduce, copy disseminate or in=
 any manner distribute this email communication as the same is strictly pro=
hibited. If you have received this email in error, please notify the sender=
 immediately by return e-mail and delete the communication sent in error. E=
mail communications cannot be guaranteed to be secure & error free and IB T=
echnology is not liable for any errors in the email communication or for th=
e proper, timely and complete transmission thereof.
>>
>> _______________________________________________
>> vrrp mailing list
>> vrrp@ietf.org
>> https://www.ietf.org/mailman/listinfo/vrrp
>
> Disclaimer :
> This email communication may contain privileged and confidential informat=
ion and is intended for the use of the addressee only.If you are not an int=
ended recipient you are requested not to reproduce, copy disseminate or in =
any manner distribute this email communication as the same is strictly proh=
ibited. If you have received this email in error, please notify the sender =
immediately by return e-mail and delete the communication sent in error. Em=
ail communications cannot be guaranteed to be secure & error free and IB Te=
chnology is not liable for any errors in the email communication or for the=
 proper, timely and complete transmission thereof.
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: 
>
> ------------------------------
>
> Message: 2
> Date: Fri, 22 Feb 2013 11:41:47 +0000
> From: "Anurag Kothari (ankothar)" 
> To: sreenatha 
> Cc: "vrrp@ietf.org" 
> Subject: Re: [VRRP] Proposal for Maintenance Event for VRRP [RFC-5798]
> Message-ID:
>        
> Content-Type: text/plain; charset=3D"us-ascii"
>
> Hi Sreenatha
>
> My bad, by cancel I meant reset the timer.
>
> I would prefer defining maintenance event itself as (or being triggered b=
y) priority being set to 0 for a VRID. So probably we can rephrase the prop=
osal 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
> 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 =3D 0
>
>
>
> -endif // maintenance recv
>
>
>
>
>
>    And you mentioned that router need to send regular ADVERTISEMENT messa=
ge till it receives the ADVERTISEMENT message from the backup router.
>
>
>
> "2. How much time Master router should wait to receive ADVERTISEMENT mess=
age from any backup router?
>
>
>
> [Anurag] Master doesn't have to wait. After receiving the maintenance eve=
nt it will send regular ADVERTISEMENT with Priority =3D 0 till some other r=
outer 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 =3D 0
>
>
>
> + Reset the Adver_Timer
>
>
>
> -endif // maintenance recv
>
>
>
> This will ensure that:
>
> 1. ADVERTISEMENT message with priority 0 is sent  immediately on receivin=
g 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                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. 
>
> "
>
>
>
> Please see my responses inline [Anurag]:
>
>
>
> Thanks
>
> -Anurag
>
>
>
> -----Original Message-----
>
> From: vrrp-bounces@ietf.org [mailto:vrrp-bo=
unces@ietf.org] On Behalf Of sreenatha
>
> Sent: Thursday, February 21, 2013 11:03 AM
>
> To: 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 chan=
ged, 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 VR=
ID) will change to 0.
>
>
>
> 2. How much time Master router should wait to receive ADVERTISEMENT messa=
ge from any backup router?
>
>
>
> [Anurag] Master doesn't have to wait. After receiving the maintenance eve=
nt it will send regular ADVERTISEMENT with Priority =3D 0 till some other r=
outer 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 V=
RRP Priority. So you are proposing to change this value also?
>
>
>
> [Anurag] Yes. Priority 0 will have to be made a user configurable value t=
o indicate the intention of a router to relinquish Master Status.
>
>
>
> Thanks,
>
> Sreenatha Setty
>
>
>
> On 02/21/2013 01:30 AM, 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
>
>
>
> 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
>
>
>
> You can reach the person managing the list at
>
>   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)"
>
> To:"vrrp@ietf.org"  
>
> Subject: [VRRP] Proposal for Maintenance Event for VRRP [RFC-5798]
>
> Message-ID:
>
>   
>
> Content-Type: text/plain; charset=3D"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 Mas=
ter 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 =3D 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 rout=
er sends an ADVERTISEMENT (triggered by receiving an ADVERTISEMENT with Pri=
ority =3D 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 configur=
ation.
>
>
>
> 2)      By setting the priority =3D 0 for a particular VRID.
>
>
>
> Thanks
>
> -Anurag
>
>
>
> -------------- next part -------------- An HTML attachment was
>
> scrubbed...
>
> URL:
>
> a6571f/attachment.htm>
>
>
>
> ------------------------------
>
>
>
> _______________________________________________
>
> vrrp mailing list
>
> 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 informat=
ion and is intended for the use of the addressee only.If you are not an int=
ended recipient you are requested not to reproduce, copy disseminate or in =
any manner distribute this email communication as the same is strictly proh=
ibited. If you have received this email in error, please notify the sender =
immediately by return e-mail and delete the communication sent in error. Em=
ail communications cannot be guaranteed to be secure & error free and IB Te=
chnology 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
>
>
>
>
> Disclaimer :
> This email communication may contain privileged and confidential informat=
ion and is intended for the use of the addressee only.If you are not an int=
ended recipient you are requested not to reproduce, copy disseminate or in =
any manner distribute this email communication as the same is strictly proh=
ibited. If you have received this email in error, please notify the sender =
immediately by return e-mail and delete the communication sent in error. Em=
ail communications cannot be guaranteed to be secure & error free and IB Te=
chnology is not liable for any errors in the email communication or for the=
 proper, timely and complete transmission thereof.
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: 
>
> ------------------------------
>
> _______________________________________________
> vrrp mailing list
> vrrp@ietf.org
> https://www.ietf.org/mailman/listinfo/vrrp
>
>
> End of vrrp Digest, Vol 81, Issue 3
> ***********************************

DISCLAIMER:
This e-mail and any attachments to it may contain confidential and propriet=
ary material and is solely for the use of the intended recipient. Any revie=
w, use, disclosure, distribution or copying of this transmittal is prohibit=
ed except by or on behalf of the intended recipient.  If you have received =
this transmittal in error, please notify the sender and destroy this e-mail=
 and any attachments and all copies, whether electronic or printed.

From ankothar@cisco.com  Fri Feb 22 07:55:53 2013
Return-Path: 
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 25E3921F8E64 for ; Fri, 22 Feb 2013 07:55:53 -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=[AWL=0.000, BAYES_00=-2.599, 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 XrbsRm-H5QT0 for ; Fri, 22 Feb 2013 07:55:51 -0800 (PST)
Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id A418D21F8F23 for ; Fri, 22 Feb 2013 07:55:50 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=23330; q=dns/txt; s=iport; t=1361548550; x=1362758150; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=jyF97k3qmOHRUfLo6iNXmpZggol1cV+txTHiEzqs7Lc=; b=N75yhwNjD/hDox1YsVgQpXVa3dCAYIZhbjaCTfCXcOtrf40HjOVLKgr9 Thi1arMI2w3Ybu3zDYy8niLCgM36nVbcY5vPhatoI4dzdPOjY+9tGTQPl YJg0WnqCs5II1IBCfPyT4fXFMqDgKKOtNdfMjcRJSS3ZBF+j2MhFmzzw+ 4=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgMFAH6TJ1GtJXG9/2dsb2JhbABEwSOBCRZzgh8BAQEDAQEBARcgFCAQBwQCAQgOAwMBAQEBCgIBEQkHJwoBFAkIAQEEARIIARICBIdrBgy/QY00CRCBEAYgBgwCBIJZYQOnHYMHgWkEAgMXHg
X-IronPort-AV: E=Sophos;i="4.84,717,1355097600"; d="scan'208";a="180142306"
Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-3.cisco.com with ESMTP; 22 Feb 2013 15:55:49 +0000
Received: from xhc-aln-x03.cisco.com (xhc-aln-x03.cisco.com [173.36.12.77]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id r1MFtnRE018432 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 22 Feb 2013 15:55:49 GMT
Received: from xmb-rcd-x05.cisco.com ([169.254.15.93]) by xhc-aln-x03.cisco.com ([173.36.12.77]) with mapi id 14.02.0318.004; Fri, 22 Feb 2013 09:55:48 -0600
From: "Anurag Kothari (ankothar)" 
To: Thirumavalavan Periyannan , "vrrp@ietf.org" 
Thread-Topic: vrrp Digest, Vol 81, Issue 3
Thread-Index: Ac4RBGKo4P5hWc5lTiSJPUEgi0SCSQADvuFg
Date: Fri, 22 Feb 2013 15:55:47 +0000
Message-ID: 
References:  <14CA6619-DB7C-40ED-85E4-535CB689AC86@extremenetworks.com>
In-Reply-To: <14CA6619-DB7C-40ED-85E4-535CB689AC86@extremenetworks.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: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [VRRP] vrrp Digest, Vol 81, Issue 3
X-BeenThere: vrrp@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Virtual Router Redundancy Protocol  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 22 Feb 2013 15:55:53 -0000

Yes that is correct.=20

The intention is to be able to switch the traffic to the backup router (wit=
h minimal traffic interruption) when preemption is not configured on the ba=
ckup router without shutting down the interface or VRRP on Master.

Thanks
~Anurag

-----Original Message-----
From: vrrp-bounces@ietf.org [mailto:vrrp-bounces@ietf.org] On Behalf Of Thi=
rumavalavan Periyannan
Sent: Friday, February 22, 2013 8:56 AM
To: vrrp@ietf.org
Cc: vrrp@ietf.org
Subject: Re: [VRRP] vrrp Digest, Vol 81, Issue 3

Hi Anurag,

You meant to say that when we do graceful failover on VRRP Master then traf=
fic needs switch to VRRP backup router without waiting for Master_Down_Inte=
rval time.

Please correct me if I am wrong.

Sent from my iPhone

On 22-Feb-2013, at 5:11 PM, "vrrp-request@ietf.org" =
 wrote:

> If you have received this digest without all the individual message=20
> attachments you will need to update your digest options in your list=20
> 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=20
> MIME or Plain Text Digests?" to MIME.  You can set this option=20
> globally for all the list digests you receive at this point.
>
>
>
> Send vrrp mailing list submissions to
>        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
>
> You can reach the person managing the list at
>        vrrp-owner@ietf.org
>
> When replying, please edit your Subject line so it is more specific=20
> than "Re: Contents of vrrp digest..."
>
>
> Today's Topics:
>
>   1. Re: Proposal for Maintenance Event for VRRP [RFC-5798] (sreenatha)
>   2. Re: Proposal for Maintenance Event for VRRP [RFC-5798]
>      (Anurag Kothari (ankothar))
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Fri, 22 Feb 2013 09:55:35 +0530
> From: sreenatha 
> To: "Anurag Kothari (ankothar)" 
> Cc: "vrrp@ietf.org" 
> Subject: Re: [VRRP] Proposal for Maintenance Event for VRRP [RFC-5798]
> Message-ID: <5126F33F.1080005@ibtechnology.com>
> Content-Type: text/plain; charset=3D"iso-8859-1"; Format=3D"flowed"
>
> Hi Anurag,
>    Your proposal is:
>
> - If a Maintenance event is received, then:
>
> + Cancel the Adver_Timer
>
> + Send an ADVERTISEMENT with Priority =3D 0
>
> -endif // maintenance recv
>
>
>     And you mentioned that router need to send regular ADVERTISEMENT mess=
age till it receives the ADVERTISEMENT message from the backup router.
>
> "2. How much time Master router should wait to receive ADVERTISEMENT mess=
age from any backup router?
>
> [Anurag] Master doesn't have to wait. After receiving the maintenance eve=
nt it will send regular ADVERTISEMENT with Priority =3D 0 till some other r=
outer 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 =3D 0
>
> + Reset the Adver_Timer
>
>  -endif // maintenance recv
>
> This will ensure that:
> 1. ADVERTISEMENT message with priority 0 is sent  immediately on receivin=
g 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                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. =20
>> "
>>
>> Please see my responses inline [Anurag]:
>>
>> Thanks
>> -Anurag
>>
>> -----Original Message-----
>> From: vrrp-bounces@ietf.org [mailto:vrrp-bounces@ietf.org] On Behalf=20
>> Of sreenatha
>> Sent: Thursday, February 21, 2013 11:03 AM
>> To: vrrp@ietf.org
>> Subject: Re: [VRRP] Proposal for Maintenance Event for VRRP=20
>> [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 cha=
nged, right? So if back-up router has less priority, even if Master receive=
s 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 V=
RID) will change to 0.
>>
>> 2. How much time Master router should wait to receive ADVERTISEMENT mess=
age from any backup router?
>>
>> [Anurag] Master doesn't have to wait. After receiving the maintenance ev=
ent it will send regular ADVERTISEMENT with Priority =3D 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 wrote:
>>> If you have received this digest without all the individual message=20
>>> attachments you will need to update your digest options in your list=20
>>> 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=20
>>> MIME or Plain Text Digests?" to MIME.  You can set this option=20
>>> globally for all the list digests you receive at this point.
>>>
>>>
>>>
>>> Send vrrp mailing list submissions to
>>>     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
>>>
>>> You can reach the person managing the list at
>>>     vrrp-owner@ietf.org
>>>
>>> When replying, please edit your Subject line so it is more specific=20
>>> 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)"=20
>>> To:"vrrp@ietf.org"  
>>> Subject: [VRRP] Proposal for Maintenance Event for VRRP [RFC-5798]
>>> Message-ID:
>>>     
>>> Content-Type: text/plain; charset=3D"us-ascii"
>>>
>>> Hi
>>>
>>> I want to propose a new Maintenance Event (modification of Shutdown Eve=
nt) for VRRP (RFC-5798] which would allow to gracefully failover the VRRP M=
aster 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=20
>>> router gracefully without modifying the configuration on the=20
>>> 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 =3D 0
>>>
>>> -endif // maintenance recv
>>>
>>> Unlike Shutdown event the router will not "Transition to the {Initializ=
e} state" and continue to be Master and forward traffic  till the backup ro=
uter sends an ADVERTISEMENT (triggered by receiving an ADVERTISEMENT with P=
riority =3D 0) and becomes master.
>>> Here are couple of examples of how a maintenance event may be=20
>>> triggered
>>>
>>>
>>> 1)      By some user command e.g. "maintenance-mode" in the vrrp config=
uration.
>>>
>>> 2)      By setting the priority =3D 0 for a particular VRID.
>>>
>>> Thanks
>>> -Anurag
>>>
>>> -------------- next part -------------- An HTML attachment was=20
>>> scrubbed...
>>> URL:>> 36
>>> a6571f/attachment.htm>
>>>
>>> ------------------------------
>>>
>>> _______________________________________________
>>> vrrp mailing list
>>> 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 informa=
tion and is intended for the use of the addressee only.If you are not an in=
tended recipient you are requested not to reproduce, copy disseminate or in=
 any manner distribute this email communication as the same is strictly pro=
hibited. If you have received this email in error, please notify the sender=
 immediately by return e-mail and delete the communication sent in error. E=
mail communications cannot be guaranteed to be secure & error free and IB T=
echnology is not liable for any errors in the email communication or for th=
e proper, timely and complete transmission thereof.
>>
>> _______________________________________________
>> vrrp mailing list
>> vrrp@ietf.org
>> https://www.ietf.org/mailman/listinfo/vrrp
>
> Disclaimer :
> This email communication may contain privileged and confidential informat=
ion and is intended for the use of the addressee only.If you are not an int=
ended recipient you are requested not to reproduce, copy disseminate or in =
any manner distribute this email communication as the same is strictly proh=
ibited. If you have received this email in error, please notify the sender =
immediately by return e-mail and delete the communication sent in error. Em=
ail communications cannot be guaranteed to be secure & error free and IB Te=
chnology is not liable for any errors in the email communication or for the=
 proper, timely and complete transmission thereof.
> -------------- next part -------------- An HTML attachment was=20
> scrubbed...
> URL:=20
>  14/attachment.htm>
>
> ------------------------------
>
> Message: 2
> Date: Fri, 22 Feb 2013 11:41:47 +0000
> From: "Anurag Kothari (ankothar)" 
> To: sreenatha 
> Cc: "vrrp@ietf.org" 
> Subject: Re: [VRRP] Proposal for Maintenance Event for VRRP [RFC-5798]
> Message-ID:
>       =20
> 
> Content-Type: text/plain; charset=3D"us-ascii"
>
> Hi Sreenatha
>
> My bad, by cancel I meant reset the timer.
>
> I would prefer defining maintenance event itself as (or being triggered b=
y) priority being set to 0 for a VRID. So probably we can rephrase the prop=
osal 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
> 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 =3D 0
>
>
>
> -endif // maintenance recv
>
>
>
>
>
>    And you mentioned that router need to send regular ADVERTISEMENT messa=
ge till it receives the ADVERTISEMENT message from the backup router.
>
>
>
> "2. How much time Master router should wait to receive ADVERTISEMENT mess=
age from any backup router?
>
>
>
> [Anurag] Master doesn't have to wait. After receiving the maintenance eve=
nt it will send regular ADVERTISEMENT with Priority =3D 0 till some other r=
outer 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 =3D 0
>
>
>
> + Reset the Adver_Timer
>
>
>
> -endif // maintenance recv
>
>
>
> This will ensure that:
>
> 1. ADVERTISEMENT message with priority 0 is sent  immediately on receivin=
g 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=20
> having
>
>   to wait for the current Master to time out.
>
> "
>
>
>
> "
>
>   Priority                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. 
>
> "
>
>
>
> Please see my responses inline [Anurag]:
>
>
>
> Thanks
>
> -Anurag
>
>
>
> -----Original Message-----
>
> From: vrrp-bounces@ietf.org=20
> [mailto:vrrp-bounces@ietf.org] On Behalf Of sreenatha
>
> Sent: Thursday, February 21, 2013 11:03 AM
>
> To: 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 chan=
ged, 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 VR=
ID) will change to 0.
>
>
>
> 2. How much time Master router should wait to receive ADVERTISEMENT messa=
ge from any backup router?
>
>
>
> [Anurag] Master doesn't have to wait. After receiving the maintenance eve=
nt it will send regular ADVERTISEMENT with Priority =3D 0 till some other r=
outer 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 V=
RRP Priority. So you are proposing to change this value also?
>
>
>
> [Anurag] Yes. Priority 0 will have to be made a user configurable value t=
o indicate the intention of a router to relinquish Master Status.
>
>
>
> Thanks,
>
> Sreenatha Setty
>
>
>
> On 02/21/2013 01:30 AM, 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
>
>
>
> 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
>
>
>
> You can reach the person managing the list at
>
>   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=20
> (ankothar)"
>
> To:"vrrp@ietf.org" =20
> 
>
> Subject: [VRRP] Proposal for Maintenance Event for VRRP [RFC-5798]
>
> Message-ID:
>
>  =20
>  o:A2BB90B33FFDF740876C5AAE307D83DB1C290327@xmb-rcd-x05.cisco.com>
>
> Content-Type: text/plain; charset=3D"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 Mas=
ter 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 =3D 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 rout=
er sends an ADVERTISEMENT (triggered by receiving an ADVERTISEMENT with Pri=
ority =3D 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 configur=
ation.
>
>
>
> 2)      By setting the priority =3D 0 for a particular VRID.
>
>
>
> Thanks
>
> -Anurag
>
>
>
> -------------- next part -------------- An HTML attachment was
>
> scrubbed...
>
> URL:  1f/attachment.htm>
>
> a6571f/attachment.htm> hments/20130219/36a6571f/attachment.htm>
>
>
>
> ------------------------------
>
>
>
> _______________________________________________
>
> vrrp mailing list
>
> 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 informat=
ion and is intended for the use of the addressee only.If you are not an int=
ended recipient you are requested not to reproduce, copy disseminate or in =
any manner distribute this email communication as the same is strictly proh=
ibited. If you have received this email in error, please notify the sender =
immediately by return e-mail and delete the communication sent in error. Em=
ail communications cannot be guaranteed to be secure & error free and IB Te=
chnology 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
>
>
>
>
> Disclaimer :
> This email communication may contain privileged and confidential informat=
ion and is intended for the use of the addressee only.If you are not an int=
ended recipient you are requested not to reproduce, copy disseminate or in =
any manner distribute this email communication as the same is strictly proh=
ibited. If you have received this email in error, please notify the sender =
immediately by return e-mail and delete the communication sent in error. Em=
ail communications cannot be guaranteed to be secure & error free and IB Te=
chnology is not liable for any errors in the email communication or for the=
 proper, timely and complete transmission thereof.
> -------------- next part -------------- An HTML attachment was=20
> scrubbed...
> URL:=20
>  c7/attachment.htm>
>
> ------------------------------
>
> _______________________________________________
> vrrp mailing list
> vrrp@ietf.org
> https://www.ietf.org/mailman/listinfo/vrrp
>
>
> End of vrrp Digest, Vol 81, Issue 3
> ***********************************

DISCLAIMER:
This e-mail and any attachments to it may contain confidential and propriet=
ary material and is solely for the use of the intended recipient. Any revie=
w, use, disclosure, distribution or copying of this transmittal is prohibit=
ed except by or on behalf of the intended recipient.  If you have received =
this transmittal in error, please notify the sender and destroy this e-mail=
 and any attachments and all copies, whether electronic or printed.
_______________________________________________
vrrp mailing list
vrrp@ietf.org
https://www.ietf.org/mailman/listinfo/vrrp

From pfhunt@gmail.com  Fri Feb 22 08:59:04 2013
Return-Path: 
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 C871C21F888B for ; Fri, 22 Feb 2013 08:59:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.203
X-Spam-Level: 
X-Spam-Status: No, score=-2.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1]
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 lJksEyDkO8ys for ; Fri, 22 Feb 2013 08:59:03 -0800 (PST)
Received: from mail-pb0-f45.google.com (mail-pb0-f45.google.com [209.85.160.45]) by ietfa.amsl.com (Postfix) with ESMTP id 2CF1421F85FD for ; Fri, 22 Feb 2013 08:59:03 -0800 (PST)
Received: by mail-pb0-f45.google.com with SMTP id ro8so507702pbb.4 for ; Fri, 22 Feb 2013 08:59:02 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:references:in-reply-to:mime-version :content-transfer-encoding:content-type:message-id:cc:x-mailer:from :subject:date:to; bh=44oNOCGORm9B1pp25Am/EB79M4kH+2el1NoDORmx7U8=; b=HibRbq3SyMQ2OWh4q8IYqlw9wG2ujO9kT2dHaOiWdYxCXICWOPnaz6F3ggSNalq9Qm +Xge2RRXUDd2nampjM/Ewn5cnD9D4yWzoXM0dAO110IPltQLQdDdQJBqyDeO3jFT2no6 +2y3AGQr18vq4OQ0lS3m2Iq4ToRit80RiT3M0n3gMQESdg7Whg4sa7jMH9g8Ho+ha6K6 U9ENV5/XXfvdZkNuOO1ZqomuNGeS6TgS9WbRIeKlhSMrNLQbajU5UhdtbB517CC+QbaC SDQW8B9AxngDo0GWonGILNr4W87Kp7eAiNbMLOF7oH5RgdltJsL3Gn8osBvJAUyiZTTY FqvQ==
X-Received: by 10.68.116.169 with SMTP id jx9mr4121430pbb.94.1361552342690; Fri, 22 Feb 2013 08:59:02 -0800 (PST)
Received: from [192.168.2.68] (ppp-71-139-164-20.dsl.snfc21.pacbell.net. [71.139.164.20]) by mx.google.com with ESMTPS id kt5sm3054786pbc.30.2013.02.22.08.58.57 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 22 Feb 2013 08:59:01 -0800 (PST)
References:  <14CA6619-DB7C-40ED-85E4-535CB689AC86@extremenetworks.com> 
In-Reply-To: 
Mime-Version: 1.0 (1.0)
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=us-ascii
Message-Id: 
X-Mailer: iPhone Mail (9B206)
From: Peter Hunt 
Date: Fri, 22 Feb 2013 08:58:54 -0800
To: "Anurag Kothari (ankothar)" 
Cc: Thirumavalavan Periyannan , "vrrp@ietf.org" 
Subject: Re: [VRRP] vrrp Digest, Vol 81, Issue 3
X-BeenThere: vrrp@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Virtual Router Redundancy Protocol  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 22 Feb 2013 16:59:04 -0000

Sorry to jump in here, but I'm having trouble understanding the motivation f=
or the maintenance event.

It seems like its behaviour is to relinquish mastership immediately to a bac=
kup if it exists, but remain master silently otherwise. Is that correct?

If so, why is that desirable behaviour? It seems to me that you would either=
 want to take the node out of the vrrp cluster completely, or have it partic=
ipate at a reduced priority. What situation makes a silent-but-active master=
 preferable?

Peter


On Feb 22, 2013, at 7:55 AM, "Anurag Kothari (ankothar)"  wrote:

> Yes that is correct.=20
>=20
> The intention is to be able to switch the traffic to the backup router (wi=
th minimal traffic interruption) when preemption is not configured on the ba=
ckup router without shutting down the interface or VRRP on Master.
>=20
> Thanks
> ~Anurag
>=20
> -----Original Message-----
> From: vrrp-bounces@ietf.org [mailto:vrrp-bounces@ietf.org] On Behalf Of Th=
irumavalavan Periyannan
> Sent: Friday, February 22, 2013 8:56 AM
> To: vrrp@ietf.org
> Cc: vrrp@ietf.org
> Subject: Re: [VRRP] vrrp Digest, Vol 81, Issue 3
>=20
> Hi Anurag,
>=20
> You meant to say that when we do graceful failover on VRRP Master then tra=
ffic needs switch to VRRP backup router without waiting for Master_Down_Inte=
rval time.
>=20
> Please correct me if I am wrong.
>=20
> Sent from my iPhone
>=20
> On 22-Feb-2013, at 5:11 PM, "vrrp-request@ietf.org"  wrote:
>=20
>> If you have received this digest without all the individual message=20
>> attachments you will need to update your digest options in your list=20
>> subscription.  To do so, go to
>>=20
>> https://www.ietf.org/mailman/listinfo/vrrp
>>=20
>> Click the 'Unsubscribe or edit options' button, log in, and set "Get=20
>> MIME or Plain Text Digests?" to MIME.  You can set this option=20
>> globally for all the list digests you receive at this point.
>>=20
>>=20
>>=20
>> Send vrrp mailing list submissions to
>>       vrrp@ietf.org
>>=20
>> 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
>>=20
>> You can reach the person managing the list at
>>       vrrp-owner@ietf.org
>>=20
>> When replying, please edit your Subject line so it is more specific=20
>> than "Re: Contents of vrrp digest..."
>>=20
>>=20
>> Today's Topics:
>>=20
>>  1. Re: Proposal for Maintenance Event for VRRP [RFC-5798] (sreenatha)
>>  2. Re: Proposal for Maintenance Event for VRRP [RFC-5798]
>>     (Anurag Kothari (ankothar))
>>=20
>>=20
>> ----------------------------------------------------------------------
>>=20
>> Message: 1
>> Date: Fri, 22 Feb 2013 09:55:35 +0530
>> From: sreenatha 
>> To: "Anurag Kothari (ankothar)" 
>> Cc: "vrrp@ietf.org" 
>> Subject: Re: [VRRP] Proposal for Maintenance Event for VRRP [RFC-5798]
>> Message-ID: <5126F33F.1080005@ibtechnology.com>
>> Content-Type: text/plain; charset=3D"iso-8859-1"; Format=3D"flowed"
>>=20
>> Hi Anurag,
>>   Your proposal is:
>>=20
>> - If a Maintenance event is received, then:
>>=20
>> + Cancel the Adver_Timer
>>=20
>> + Send an ADVERTISEMENT with Priority =3D 0
>>=20
>> -endif // maintenance recv
>>=20
>>=20
>>    And you mentioned that router need to send regular ADVERTISEMENT messa=
ge till it receives the ADVERTISEMENT message from the backup router.
>>=20
>> "2. How much time Master router should wait to receive ADVERTISEMENT mess=
age from any backup router?
>>=20
>> [Anurag] Master doesn't have to wait. After receiving the maintenance eve=
nt it will send regular ADVERTISEMENT with Priority =3D 0 till some other ro=
uter send back an ADVERTISEMENT message at which point it will transition to=
 Backup."
>>=20
>> If Advert_Timer is cancelled, how regular ADVERTISEMENT messages are sent=
?
>>=20
>> So i am suggesting slight changes in the Proposal:
>>=20
>> - If a Maintenance event is received, then:
>>=20
>> + Change the router priority to 0
>>=20
>> + Send an ADVERTISEMENT with Priority =3D 0
>>=20
>> + Reset the Adver_Timer
>>=20
>> -endif // maintenance recv
>>=20
>> This will ensure that:
>> 1. ADVERTISEMENT message with priority 0 is sent  immediately on receivin=
g Maintenance event.
>> 2. Master router will send regular Advertisement message till it receives=
 the ADVERTISEMENT message from any backup routers.
>>=20
>> Thanks,
>> Sreenatha Setty
>>=20
>>=20
>>=20
>>=20
>> On 02/21/2013 10:12 PM, Anurag Kothari (ankothar) wrote:
>>> Hi Sreenatha
>>>=20
>>> This ideas is based on the way the priority is defined in Section 5.2.4.=
 and 6.1. of RFC-5798.
>>>=20
>>> "
>>>   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.
>>> "
>>>=20
>>> "
>>>   Priority                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. =20
>>> "
>>>=20
>>> Please see my responses inline [Anurag]:
>>>=20
>>> Thanks
>>> -Anurag
>>>=20
>>> -----Original Message-----
>>> From: vrrp-bounces@ietf.org [mailto:vrrp-bounces@ietf.org] On Behalf=20
>>> Of sreenatha
>>> Sent: Thursday, February 21, 2013 11:03 AM
>>> To: vrrp@ietf.org
>>> Subject: Re: [VRRP] Proposal for Maintenance Event for VRRP=20
>>> [RFC-5798]
>>>=20
>>> Hi Anurag,
>>>     Proposed idea is good. I have some queries on this proposal:
>>>=20
>>> 1. On receiving new maintenance_event, priority of the router is not cha=
nged, 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?
>>>=20
>>> [Anurag] On receiving the maintenance event the priority of router (or V=
RID) will change to 0.
>>>=20
>>> 2. How much time Master router should wait to receive ADVERTISEMENT mess=
age from any backup router?
>>>=20
>>> [Anurag] Master doesn't have to wait. After receiving the maintenance ev=
ent it will send regular ADVERTISEMENT with Priority =3D 0 till some other r=
outer send back an ADVERTISEMENT message at which point it will transition t=
o Backup.
>>>=20
>>> 3. Standard VRRP MIB(RFC-2787) does not allow user to configure '0' for V=
RRP Priority. So you are proposing to change this value also?
>>>=20
>>> [Anurag] Yes. Priority 0 will have to be made a user configurable value t=
o indicate the intention of a router to relinquish Master Status.
>>>=20
>>> Thanks,
>>> Sreenatha Setty
>>>=20
>>> On 02/21/2013 01:30 AM, vrrp-request@ietf.org wrote:
>>>> If you have received this digest without all the individual message=20
>>>> attachments you will need to update your digest options in your list=20=

>>>> subscription.  To do so, go to
>>>>=20
>>>> https://www.ietf.org/mailman/listinfo/vrrp
>>>>=20
>>>> Click the 'Unsubscribe or edit options' button, log in, and set "Get=20=

>>>> MIME or Plain Text Digests?" to MIME.  You can set this option=20
>>>> globally for all the list digests you receive at this point.
>>>>=20
>>>>=20
>>>>=20
>>>> Send vrrp mailing list submissions to
>>>>    vrrp@ietf.org
>>>>=20
>>>> 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
>>>>=20
>>>> You can reach the person managing the list at
>>>>    vrrp-owner@ietf.org
>>>>=20
>>>> When replying, please edit your Subject line so it is more specific=20
>>>> than "Re: Contents of vrrp digest..."
>>>>=20
>>>>=20
>>>> Today's Topics:
>>>>=20
>>>>    1. Proposal for Maintenance Event for VRRP [RFC-5798]
>>>>       (Anurag Kothari (ankothar))
>>>>=20
>>>>=20
>>>> --------------------------------------------------------------------
>>>> --
>>>>=20
>>>> Message: 1
>>>> Date: Tue, 19 Feb 2013 22:08:41 +0000
>>>> From: "Anurag Kothari (ankothar)"=20
>>>> To:"vrrp@ietf.org"  
>>>> Subject: [VRRP] Proposal for Maintenance Event for VRRP [RFC-5798]
>>>> Message-ID:
>>>>    
>>>> Content-Type: text/plain; charset=3D"us-ascii"
>>>>=20
>>>> Hi
>>>>=20
>>>> I want to propose a new Maintenance Event (modification of Shutdown Eve=
nt) for VRRP (RFC-5798] which would allow to gracefully failover the VRRP Ma=
ster to Redundant (Backup Router).
>>>>=20
>>>> Problem Statement:
>>>> VRRP preemption is not configured on the redundant / backup router.
>>>> How to initiate VRRP Traffic to failover to the redundant / backup=20
>>>> router gracefully without modifying the configuration on the=20
>>>> redundant / backup router (i.e. adding preemption)
>>>>=20
>>>> Proposed Solution:
>>>> Addition to Section 6.4.3 of RFC-5798:
>>>>=20
>>>> - If a Maintenance event is received, then:
>>>>=20
>>>> + Cancel the Adver_Timer
>>>>=20
>>>> + Send an ADVERTISEMENT with Priority =3D 0
>>>>=20
>>>> -endif // maintenance recv
>>>>=20
>>>> Unlike Shutdown event the router will not "Transition to the {Initializ=
e} state" and continue to be Master and forward traffic  till the backup rou=
ter sends an ADVERTISEMENT (triggered by receiving an ADVERTISEMENT with Pri=
ority =3D 0) and becomes master.
>>>> Here are couple of examples of how a maintenance event may be=20
>>>> triggered
>>>>=20
>>>>=20
>>>> 1)      By some user command e.g. "maintenance-mode" in the vrrp config=
uration.
>>>>=20
>>>> 2)      By setting the priority =3D 0 for a particular VRID.
>>>>=20
>>>> Thanks
>>>> -Anurag
>>>>=20
>>>> -------------- next part -------------- An HTML attachment was=20
>>>> scrubbed...
>>>> URL:>>> 36
>>>> a6571f/attachment.htm>
>>>>=20
>>>> ------------------------------
>>>>=20
>>>> _______________________________________________
>>>> vrrp mailing list
>>>> vrrp@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/vrrp
>>>>=20
>>>>=20
>>>> End of vrrp Digest, Vol 81, Issue 1
>>>> ***********************************
>>> Disclaimer :
>>> This email communication may contain privileged and confidential informa=
tion and is intended for the use of the addressee only.If you are not an int=
ended recipient you are requested not to reproduce, copy disseminate or in a=
ny manner distribute this email communication as the same is strictly prohib=
ited. If you have received this email in error, please notify the sender imm=
ediately by return e-mail and delete the communication sent in error. Email c=
ommunications cannot be guaranteed to be secure & error free and IB Technolo=
gy is not liable for any errors in the email communication or for the proper=
, timely and complete transmission thereof.
>>>=20
>>> _______________________________________________
>>> vrrp mailing list
>>> vrrp@ietf.org
>>> https://www.ietf.org/mailman/listinfo/vrrp
>>=20
>> Disclaimer :
>> This email communication may contain privileged and confidential informat=
ion and is intended for the use of the addressee only.If you are not an inte=
nded recipient you are requested not to reproduce, copy disseminate or in an=
y manner distribute this email communication as the same is strictly prohibi=
ted. If you have received this email in error, please notify the sender imme=
diately by return e-mail and delete the communication sent in error. Email c=
ommunications cannot be guaranteed to be secure & error free and IB Technolo=
gy is not liable for any errors in the email communication or for the proper=
, timely and complete transmission thereof.
>> -------------- next part -------------- An HTML attachment was=20
>> scrubbed...
>> URL:=20
>> > 14/attachment.htm>
>>=20
>> ------------------------------
>>=20
>> Message: 2
>> Date: Fri, 22 Feb 2013 11:41:47 +0000
>> From: "Anurag Kothari (ankothar)" 
>> To: sreenatha 
>> Cc: "vrrp@ietf.org" 
>> Subject: Re: [VRRP] Proposal for Maintenance Event for VRRP [RFC-5798]
>> Message-ID:
>>=20
>> 
>> Content-Type: text/plain; charset=3D"us-ascii"
>>=20
>> Hi Sreenatha
>>=20
>> My bad, by cancel I meant reset the timer.
>>=20
>> I would prefer defining maintenance event itself as (or being triggered b=
y) priority being set to 0 for a VRID. So probably we can rephrase the propo=
sal as:
>>=20
>>=20
>> - If a Maintenance event is received, then:
>>=20
>>=20
>>=20
>> + Send an ADVERTISEMENT
>>=20
>>=20
>>=20
>> + Reset the Adver_Timer to Advertisement_Interval
>>=20
>>=20
>>=20
>> -endif // maintenance recv
>>=20
>> Thanks
>> -Anurag
>>=20
>> From: sreenatha [mailto:sreenatha.setty@ibtechnology.com]
>> Sent: Thursday, February 21, 2013 11:26 PM
>> To: Anurag Kothari (ankothar)
>> Cc: vrrp@ietf.org
>> Subject: Re: [VRRP] Proposal for Maintenance Event for VRRP [RFC-5798]
>>=20
>> Hi Anurag,
>>  Your proposal is:
>>=20
>>=20
>>=20
>> - If a Maintenance event is received, then:
>>=20
>>=20
>>=20
>> + Cancel the Adver_Timer
>>=20
>>=20
>>=20
>> + Send an ADVERTISEMENT with Priority =3D 0
>>=20
>>=20
>>=20
>> -endif // maintenance recv
>>=20
>>=20
>>=20
>>=20
>>=20
>>   And you mentioned that router need to send regular ADVERTISEMENT messag=
e till it receives the ADVERTISEMENT message from the backup router.
>>=20
>>=20
>>=20
>> "2. How much time Master router should wait to receive ADVERTISEMENT mess=
age from any backup router?
>>=20
>>=20
>>=20
>> [Anurag] Master doesn't have to wait. After receiving the maintenance eve=
nt it will send regular ADVERTISEMENT with Priority =3D 0 till some other ro=
uter send back an ADVERTISEMENT message at which point it will transition to=
 Backup."
>>=20
>>=20
>>=20
>> If Advert_Timer is cancelled, how regular ADVERTISEMENT messages are sent=
?
>>=20
>>=20
>>=20
>> So i am suggesting slight changes in the Proposal:
>>=20
>>=20
>>=20
>> - If a Maintenance event is received, then:
>>=20
>>=20
>>=20
>> + Change the router priority to 0
>>=20
>>=20
>>=20
>> + Send an ADVERTISEMENT with Priority =3D 0
>>=20
>>=20
>>=20
>> + Reset the Adver_Timer
>>=20
>>=20
>>=20
>> -endif // maintenance recv
>>=20
>>=20
>>=20
>> This will ensure that:
>>=20
>> 1. ADVERTISEMENT message with priority 0 is sent  immediately on receivin=
g Maintenance event.
>>=20
>> 2. Master router will send regular Advertisement message till it receives=
 the ADVERTISEMENT message from any backup routers.
>>=20
>>=20
>>=20
>> Thanks,
>>=20
>> Sreenatha Setty
>>=20
>>=20
>>=20
>>=20
>>=20
>>=20
>> On 02/21/2013 10:12 PM, Anurag Kothari (ankothar) wrote:
>>=20
>> Hi Sreenatha
>>=20
>>=20
>>=20
>> This ideas is based on the way the priority is defined in Section 5.2.4. a=
nd 6.1. of RFC-5798.
>>=20
>>=20
>>=20
>> "
>>=20
>>  The priority value zero (0) has special meaning, indicating that the
>>=20
>>  current Master has stopped participating in VRRP.  This is used to
>>=20
>>  trigger Backup routers to quickly transition to Master without=20
>> having
>>=20
>>  to wait for the current Master to time out.
>>=20
>> "
>>=20
>>=20
>>=20
>> "
>>=20
>>  Priority                The value of 0 (zero) is
>>=20
>>                              reserved for the Master router to
>>=20
>>                              indicate it is releasing responsibility
>>=20
>>                              for the virtual router.  The range 1-254
>>=20
>>                              (decimal) is available for VRRP routers
>>=20
>>                              backing up the virtual router. 
>>=20
>> "
>>=20
>>=20
>>=20
>> Please see my responses inline [Anurag]:
>>=20
>>=20
>>=20
>> Thanks
>>=20
>> -Anurag
>>=20
>>=20
>>=20
>> -----Original Message-----
>>=20
>> From: vrrp-bounces@ietf.org=20
>> [mailto:vrrp-bounces@ietf.org] On Behalf Of sreenatha
>>=20
>> Sent: Thursday, February 21, 2013 11:03 AM
>>=20
>> To: vrrp@ietf.org
>>=20
>> Subject: Re: [VRRP] Proposal for Maintenance Event for VRRP [RFC-5798]
>>=20
>>=20
>>=20
>> Hi Anurag,
>>=20
>>    Proposed idea is good. I have some queries on this proposal:
>>=20
>>=20
>>=20
>> 1. On receiving new maintenance_event, priority of the router is not chan=
ged, right? So if back-up router has less priority, even if Master receives t=
he ADVERTISEMENT from the backup router, Master will discard.
>>=20
>> So how the Master router state is going to change?
>>=20
>>=20
>>=20
>> [Anurag] On receiving the maintenance event the priority of router (or VR=
ID) will change to 0.
>>=20
>>=20
>>=20
>> 2. How much time Master router should wait to receive ADVERTISEMENT messa=
ge from any backup router?
>>=20
>>=20
>>=20
>> [Anurag] Master doesn't have to wait. After receiving the maintenance eve=
nt it will send regular ADVERTISEMENT with Priority =3D 0 till some other ro=
uter send back an ADVERTISEMENT message at which point it will transition to=
 Backup.
>>=20
>>=20
>>=20
>> 3. Standard VRRP MIB(RFC-2787) does not allow user to configure '0' for V=
RRP Priority. So you are proposing to change this value also?
>>=20
>>=20
>>=20
>> [Anurag] Yes. Priority 0 will have to be made a user configurable value t=
o indicate the intention of a router to relinquish Master Status.
>>=20
>>=20
>>=20
>> Thanks,
>>=20
>> Sreenatha Setty
>>=20
>>=20
>>=20
>> On 02/21/2013 01:30 AM, vrrp-request@ietf.org wrote:
>>=20
>> If you have received this digest without all the individual message
>>=20
>> attachments you will need to update your digest options in your list
>>=20
>> subscription.  To do so, go to
>>=20
>>=20
>>=20
>> https://www.ietf.org/mailman/listinfo/vrrp
>>=20
>>=20
>>=20
>> Click the 'Unsubscribe or edit options' button, log in, and set "Get
>>=20
>> MIME or Plain Text Digests?" to MIME.  You can set this option
>>=20
>> globally for all the list digests you receive at this point.
>>=20
>>=20
>>=20
>>=20
>>=20
>>=20
>>=20
>> Send vrrp mailing list submissions to
>>=20
>>  vrrp@ietf.org
>>=20
>>=20
>>=20
>> To subscribe or unsubscribe via the World Wide Web, visit
>>=20
>>  https://www.ietf.org/mailman/listinfo/vrrp
>>=20
>> or, via email, send a message with subject or body 'help' to
>>=20
>>  vrrp-request@ietf.org
>>=20
>>=20
>>=20
>> You can reach the person managing the list at
>>=20
>>  vrrp-owner@ietf.org
>>=20
>>=20
>>=20
>> When replying, please edit your Subject line so it is more specific
>>=20
>> than "Re: Contents of vrrp digest..."
>>=20
>>=20
>>=20
>>=20
>>=20
>> Today's Topics:
>>=20
>>=20
>>=20
>>   1. Proposal for Maintenance Event for VRRP [RFC-5798]
>>=20
>>      (Anurag Kothari (ankothar))
>>=20
>>=20
>>=20
>>=20
>>=20
>> ----------------------------------------------------------------------
>>=20
>>=20
>>=20
>> Message: 1
>>=20
>> Date: Tue, 19 Feb 2013 22:08:41 +0000
>>=20
>> From: "Anurag Kothari=20
>> (ankothar)"
>>=20
>> To:"vrrp@ietf.org" =20
>> 
>>=20
>> Subject: [VRRP] Proposal for Maintenance Event for VRRP [RFC-5798]
>>=20
>> Message-ID:
>>=20
>>=20
>> > o:A2BB90B33FFDF740876C5AAE307D83DB1C290327@xmb-rcd-x05.cisco.com>
>>=20
>> Content-Type: text/plain; charset=3D"us-ascii"
>>=20
>>=20
>>=20
>> Hi
>>=20
>>=20
>>=20
>> I want to propose a new Maintenance Event (modification of Shutdown Event=
) for VRRP (RFC-5798] which would allow to gracefully failover the VRRP Mast=
er to Redundant (Backup Router).
>>=20
>>=20
>>=20
>> Problem Statement:
>>=20
>> VRRP preemption is not configured on the redundant / backup router.
>>=20
>> How to initiate VRRP Traffic to failover to the redundant / backup
>>=20
>> router gracefully without modifying the configuration on the redundant
>>=20
>> / backup router (i.e. adding preemption)
>>=20
>>=20
>>=20
>> Proposed Solution:
>>=20
>> Addition to Section 6.4.3 of RFC-5798:
>>=20
>>=20
>>=20
>> - If a Maintenance event is received, then:
>>=20
>>=20
>>=20
>> + Cancel the Adver_Timer
>>=20
>>=20
>>=20
>> + Send an ADVERTISEMENT with Priority =3D 0
>>=20
>>=20
>>=20
>> -endif // maintenance recv
>>=20
>>=20
>>=20
>> Unlike Shutdown event the router will not "Transition to the {Initialize}=
 state" and continue to be Master and forward traffic  till the backup route=
r sends an ADVERTISEMENT (triggered by receiving an ADVERTISEMENT with Prior=
ity =3D 0) and becomes master.
>=20
>>=20
>>=20
>>=20
>>=20
>>=20
>> Here are couple of examples of how a maintenance event may be
>>=20
>> triggered
>>=20
>>=20
>>=20
>>=20
>>=20
>> 1)      By some user command e.g. "maintenance-mode" in the vrrp configur=
ation.
>>=20
>>=20
>>=20
>> 2)      By setting the priority =3D 0 for a particular VRID.
>>=20
>>=20
>>=20
>> Thanks
>>=20
>> -Anurag
>>=20
>>=20
>>=20
>> -------------- next part -------------- An HTML attachment was
>>=20
>> scrubbed...
>>=20
>> URL:> > 1f/attachment.htm>
>>=20
>> a6571f/attachment.htm>> hments/20130219/36a6571f/attachment.htm>
>>=20
>>=20
>>=20
>> ------------------------------
>>=20
>>=20
>>=20
>> _______________________________________________
>>=20
>> vrrp mailing list
>>=20
>> vrrp@ietf.org
>>=20
>> https://www.ietf.org/mailman/listinfo/vrrp
>>=20
>>=20
>>=20
>>=20
>>=20
>> End of vrrp Digest, Vol 81, Issue 1
>>=20
>> ***********************************
>>=20
>>=20
>>=20
>>=20
>>=20
>> Disclaimer :
>>=20
>> This email communication may contain privileged and confidential informat=
ion and is intended for the use of the addressee only.If you are not an inte=
nded recipient you are requested not to reproduce, copy disseminate or in an=
y manner distribute this email communication as the same is strictly prohibi=
ted. If you have received this email in error, please notify the sender imme=
diately by return e-mail and delete the communication sent in error. Email c=
ommunications cannot be guaranteed to be secure & error free and IB Technolo=
gy is not liable for any errors in the email communication or for the proper=
, timely and complete transmission thereof.
>>=20
>>=20
>>=20
>> _______________________________________________
>>=20
>> vrrp mailing list
>>=20
>> vrrp@ietf.org
>>=20
>> https://www.ietf.org/mailman/listinfo/vrrp
>>=20
>>=20
>>=20
>>=20
>> Disclaimer :
>> This email communication may contain privileged and confidential informat=
ion and is intended for the use of the addressee only.If you are not an inte=
nded recipient you are requested not to reproduce, copy disseminate or in an=
y manner distribute this email communication as the same is strictly prohibi=
ted. If you have received this email in error, please notify the sender imme=
diately by return e-mail and delete the communication sent in error. Email c=
ommunications cannot be guaranteed to be secure & error free and IB Technolo=
gy is not liable for any errors in the email communication or for the proper=
, timely and complete transmission thereof.
>> -------------- next part -------------- An HTML attachment was=20
>> scrubbed...
>> URL:=20
>> > c7/attachment.htm>
>>=20
>> ------------------------------
>>=20
>> _______________________________________________
>> vrrp mailing list
>> vrrp@ietf.org
>> https://www.ietf.org/mailman/listinfo/vrrp
>>=20
>>=20
>> End of vrrp Digest, Vol 81, Issue 3
>> ***********************************
>=20
> DISCLAIMER:
> This e-mail and any attachments to it may contain confidential and proprie=
tary material and is solely for the use of the intended recipient. Any revie=
w, use, disclosure, distribution or copying of this transmittal is prohibite=
d except by or on behalf of the intended recipient.  If you have received th=
is transmittal in error, please notify the sender and destroy this e-mail an=
d any attachments and all copies, whether electronic or printed.
> _______________________________________________
> 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

From ankothar@cisco.com  Fri Feb 22 09:29:42 2013
Return-Path: 
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 D1B4721F8E05 for ; Fri, 22 Feb 2013 09:29:42 -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=[AWL=0.000, BAYES_00=-2.599, 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 mHrl3V+d5t38 for ; Fri, 22 Feb 2013 09:29:41 -0800 (PST)
Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id B2EE821F8DFF for ; Fri, 22 Feb 2013 09:29:40 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=27811; q=dns/txt; s=iport; t=1361554180; x=1362763780; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=51O7gaw71tY8oC19lapl09oe+dXgC1YDEdxCVcGcOBc=; b=fRclEKgHmvQUsBXK1zVD+CpWfxrz7HI4bb0R0ZRJdxKM6Q2SL696bnuV 35RnP3gSMsZQ16pwaZQNWS7vnsVws8NaapZjnTYynN9zVHYyqcs5j35To BLM81/FjqJZQUYczHt5qRCC9/7nixdZig6XgkcozrWYimzNflvsC6dwyL c=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgMFANepJ1GtJV2Z/2dsb2JhbABEwSWBChZzgh8BAQEDAQEBARcgFCALBQcEAgEIDgMDAQEBAQoCAREJByEGCgEUCQgBAQQOBQgBEgIEh18DCQYMtV0NiU6MN30JEIEQBiAGBQcCBIJZYQOUXY0phReDB4FpBAIDFx4
X-IronPort-AV: E=Sophos;i="4.84,717,1355097600"; d="scan'208";a="180148145"
Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-7.cisco.com with ESMTP; 22 Feb 2013 17:29:39 +0000
Received: from xhc-aln-x09.cisco.com (xhc-aln-x09.cisco.com [173.36.12.83]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r1MHTdQd008948 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 22 Feb 2013 17:29:39 GMT
Received: from xmb-rcd-x05.cisco.com ([169.254.15.93]) by xhc-aln-x09.cisco.com ([173.36.12.83]) with mapi id 14.02.0318.004; Fri, 22 Feb 2013 11:29:39 -0600
From: "Anurag Kothari (ankothar)" 
To: Peter Hunt 
Thread-Topic: [VRRP] vrrp Digest, Vol 81, Issue 3
Thread-Index: Ac4RBGKo4P5hWc5lTiSJPUEgi0SCSQADvuFgAA80cgAADFd4oA==
Date: Fri, 22 Feb 2013 17:29:38 +0000
Message-ID: 
References:  <14CA6619-DB7C-40ED-85E4-535CB689AC86@extremenetworks.com>  
In-Reply-To: 
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: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: Thirumavalavan Periyannan , "vrrp@ietf.org" 
Subject: Re: [VRRP] vrrp Digest, Vol 81, Issue 3
X-BeenThere: vrrp@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Virtual Router Redundancy Protocol  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 22 Feb 2013 17:29:43 -0000

Hi Peter

Please See my responses inline [Anurag]

Thanks
-Anurag

-----Original Message-----
From: Peter Hunt [mailto:pfhunt@gmail.com]=20
Sent: Friday, February 22, 2013 11:59 AM
To: Anurag Kothari (ankothar)
Cc: Thirumavalavan Periyannan; vrrp@ietf.org
Subject: Re: [VRRP] vrrp Digest, Vol 81, Issue 3

Sorry to jump in here, but I'm having trouble understanding the motivation =
for the maintenance event.

It seems like its behaviour is to relinquish mastership immediately to a ba=
ckup if it exists, but remain master silently otherwise. Is that correct?

[Anurag] The master will not remain silent it will keep sending Advertiseme=
nts with Priority =3D 0 until some backup router takes over as Master.

If so, why is that desirable behaviour? It seems to me that you would eithe=
r want to take the node out of the vrrp cluster completely, or have it part=
icipate at a reduced priority. What situation makes a silent-but-active mas=
ter preferable?

[Anurag] Many mobile service providers disable preemption for VRRP as they =
do not like the idea of unplanned traffic switch when a router with higher =
priority comes up. They only want traffic to switch in the event of a failu=
re or as part of a planned activity in a maintenance window.
Now here is an example: A site has PE1 and PE2 configured to backup each ot=
her. Now if I want to perform any maintenance work on the say PE1 (Code upg=
rade / HW upgrade etc.) I want to take it out of the traffic path gracefull=
y. Now the only way to Gracefully failover the traffic to PE2 is to configu=
re preemption on it and reduce the priority on PE1 (or increase it on PE2) =
and remove it at the end of the maintenance work. But most service provider=
s do not like the idea of touching (making changes to configuration) on bot=
h the boxes within the same maintenance window. So the idea here is to be a=
ble to failover the traffic to the backup router without enabling preemptio=
n on the Backup router.  If the backup router exists it will take over imme=
diately if it doesn't exist the existing Master will continue to provide se=
rvice. A lack of failover will indicate to the operator that backup is miss=
ing / not working and he will have to troubleshoot the situation.=20

Peter


On Feb 22, 2013, at 7:55 AM, "Anurag Kothari (ankothar)"  wrote:

> Yes that is correct.=20
>=20
> The intention is to be able to switch the traffic to the backup router (w=
ith minimal traffic interruption) when preemption is not configured on the =
backup router without shutting down the interface or VRRP on Master.
>=20
> Thanks
> ~Anurag
>=20
> -----Original Message-----
> From: vrrp-bounces@ietf.org [mailto:vrrp-bounces@ietf.org] On Behalf=20
> Of Thirumavalavan Periyannan
> Sent: Friday, February 22, 2013 8:56 AM
> To: vrrp@ietf.org
> Cc: vrrp@ietf.org
> Subject: Re: [VRRP] vrrp Digest, Vol 81, Issue 3
>=20
> Hi Anurag,
>=20
> You meant to say that when we do graceful failover on VRRP Master then tr=
affic needs switch to VRRP backup router without waiting for Master_Down_In=
terval time.
>=20
> Please correct me if I am wrong.
>=20
> Sent from my iPhone
>=20
> On 22-Feb-2013, at 5:11 PM, "vrrp-request@ietf.org"  wrote:
>=20
>> If you have received this digest without all the individual message=20
>> attachments you will need to update your digest options in your list=20
>> subscription.  To do so, go to
>>=20
>> https://www.ietf.org/mailman/listinfo/vrrp
>>=20
>> Click the 'Unsubscribe or edit options' button, log in, and set "Get=20
>> MIME or Plain Text Digests?" to MIME.  You can set this option=20
>> globally for all the list digests you receive at this point.
>>=20
>>=20
>>=20
>> Send vrrp mailing list submissions to
>>       vrrp@ietf.org
>>=20
>> 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
>>=20
>> You can reach the person managing the list at
>>       vrrp-owner@ietf.org
>>=20
>> When replying, please edit your Subject line so it is more specific=20
>> than "Re: Contents of vrrp digest..."
>>=20
>>=20
>> Today's Topics:
>>=20
>>  1. Re: Proposal for Maintenance Event for VRRP [RFC-5798]=20
>> (sreenatha)  2. Re: Proposal for Maintenance Event for VRRP [RFC-5798]
>>     (Anurag Kothari (ankothar))
>>=20
>>=20
>> ---------------------------------------------------------------------
>> -
>>=20
>> Message: 1
>> Date: Fri, 22 Feb 2013 09:55:35 +0530
>> From: sreenatha 
>> To: "Anurag Kothari (ankothar)" 
>> Cc: "vrrp@ietf.org" 
>> Subject: Re: [VRRP] Proposal for Maintenance Event for VRRP=20
>> [RFC-5798]
>> Message-ID: <5126F33F.1080005@ibtechnology.com>
>> Content-Type: text/plain; charset=3D"iso-8859-1"; Format=3D"flowed"
>>=20
>> Hi Anurag,
>>   Your proposal is:
>>=20
>> - If a Maintenance event is received, then:
>>=20
>> + Cancel the Adver_Timer
>>=20
>> + Send an ADVERTISEMENT with Priority =3D 0
>>=20
>> -endif // maintenance recv
>>=20
>>=20
>>    And you mentioned that router need to send regular ADVERTISEMENT mess=
age till it receives the ADVERTISEMENT message from the backup router.
>>=20
>> "2. How much time Master router should wait to receive ADVERTISEMENT mes=
sage from any backup router?
>>=20
>> [Anurag] Master doesn't have to wait. After receiving the maintenance ev=
ent it will send regular ADVERTISEMENT with Priority =3D 0 till some other =
router send back an ADVERTISEMENT message at which point it will transition=
 to Backup."
>>=20
>> If Advert_Timer is cancelled, how regular ADVERTISEMENT messages are sen=
t?
>>=20
>> So i am suggesting slight changes in the Proposal:
>>=20
>> - If a Maintenance event is received, then:
>>=20
>> + Change the router priority to 0
>>=20
>> + Send an ADVERTISEMENT with Priority =3D 0
>>=20
>> + Reset the Adver_Timer
>>=20
>> -endif // maintenance recv
>>=20
>> This will ensure that:
>> 1. ADVERTISEMENT message with priority 0 is sent  immediately on receivi=
ng Maintenance event.
>> 2. Master router will send regular Advertisement message till it receive=
s the ADVERTISEMENT message from any backup routers.
>>=20
>> Thanks,
>> Sreenatha Setty
>>=20
>>=20
>>=20
>>=20
>> On 02/21/2013 10:12 PM, Anurag Kothari (ankothar) wrote:
>>> Hi Sreenatha
>>>=20
>>> This ideas is based on the way the priority is defined in Section 5.2.4=
. and 6.1. of RFC-5798.
>>>=20
>>> "
>>>   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.
>>> "
>>>=20
>>> "
>>>   Priority                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. =20
>>> "
>>>=20
>>> Please see my responses inline [Anurag]:
>>>=20
>>> Thanks
>>> -Anurag
>>>=20
>>> -----Original Message-----
>>> From: vrrp-bounces@ietf.org [mailto:vrrp-bounces@ietf.org] On Behalf=20
>>> Of sreenatha
>>> Sent: Thursday, February 21, 2013 11:03 AM
>>> To: vrrp@ietf.org
>>> Subject: Re: [VRRP] Proposal for Maintenance Event for VRRP=20
>>> [RFC-5798]
>>>=20
>>> Hi Anurag,
>>>     Proposed idea is good. I have some queries on this proposal:
>>>=20
>>> 1. On receiving new maintenance_event, priority of the router is not ch=
anged, right? So if back-up router has less priority, even if Master receiv=
es the ADVERTISEMENT from the backup router, Master will discard.
>>> So how the Master router state is going to change?
>>>=20
>>> [Anurag] On receiving the maintenance event the priority of router (or =
VRID) will change to 0.
>>>=20
>>> 2. How much time Master router should wait to receive ADVERTISEMENT mes=
sage from any backup router?
>>>=20
>>> [Anurag] Master doesn't have to wait. After receiving the maintenance e=
vent it will send regular ADVERTISEMENT with Priority =3D 0 till some other=
 router send back an ADVERTISEMENT message at which point it will transitio=
n to Backup.
>>>=20
>>> 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?
>>>=20
>>> [Anurag] Yes. Priority 0 will have to be made a user configurable value=
 to indicate the intention of a router to relinquish Master Status.
>>>=20
>>> Thanks,
>>> Sreenatha Setty
>>>=20
>>> On 02/21/2013 01:30 AM, vrrp-request@ietf.org wrote:
>>>> If you have received this digest without all the individual message=20
>>>> attachments you will need to update your digest options in your=20
>>>> list subscription.  To do so, go to
>>>>=20
>>>> https://www.ietf.org/mailman/listinfo/vrrp
>>>>=20
>>>> Click the 'Unsubscribe or edit options' button, log in, and set=20
>>>> "Get MIME or Plain Text Digests?" to MIME.  You can set this option=20
>>>> globally for all the list digests you receive at this point.
>>>>=20
>>>>=20
>>>>=20
>>>> Send vrrp mailing list submissions to
>>>>    vrrp@ietf.org
>>>>=20
>>>> 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
>>>>=20
>>>> You can reach the person managing the list at
>>>>    vrrp-owner@ietf.org
>>>>=20
>>>> When replying, please edit your Subject line so it is more specific=20
>>>> than "Re: Contents of vrrp digest..."
>>>>=20
>>>>=20
>>>> Today's Topics:
>>>>=20
>>>>    1. Proposal for Maintenance Event for VRRP [RFC-5798]
>>>>       (Anurag Kothari (ankothar))
>>>>=20
>>>>=20
>>>> -------------------------------------------------------------------
>>>> -
>>>> --
>>>>=20
>>>> Message: 1
>>>> Date: Tue, 19 Feb 2013 22:08:41 +0000
>>>> From: "Anurag Kothari (ankothar)"=20
>>>> To:"vrrp@ietf.org"  
>>>> Subject: [VRRP] Proposal for Maintenance Event for VRRP [RFC-5798]
>>>> Message-ID:
>>>>    
>>>> Content-Type: text/plain; charset=3D"us-ascii"
>>>>=20
>>>> Hi
>>>>=20
>>>> I want to propose a new Maintenance Event (modification of Shutdown Ev=
ent) for VRRP (RFC-5798] which would allow to gracefully failover the VRRP =
Master to Redundant (Backup Router).
>>>>=20
>>>> Problem Statement:
>>>> VRRP preemption is not configured on the redundant / backup router.
>>>> How to initiate VRRP Traffic to failover to the redundant / backup=20
>>>> router gracefully without modifying the configuration on the=20
>>>> redundant / backup router (i.e. adding preemption)
>>>>=20
>>>> Proposed Solution:
>>>> Addition to Section 6.4.3 of RFC-5798:
>>>>=20
>>>> - If a Maintenance event is received, then:
>>>>=20
>>>> + Cancel the Adver_Timer
>>>>=20
>>>> + Send an ADVERTISEMENT with Priority =3D 0
>>>>=20
>>>> -endif // maintenance recv
>>>>=20
>>>> Unlike Shutdown event the router will not "Transition to the {Initiali=
ze} state" and continue to be Master and forward traffic  till the backup r=
outer sends an ADVERTISEMENT (triggered by receiving an ADVERTISEMENT with =
Priority =3D 0) and becomes master.
>>>> Here are couple of examples of how a maintenance event may be=20
>>>> triggered
>>>>=20
>>>>=20
>>>> 1)      By some user command e.g. "maintenance-mode" in the vrrp confi=
guration.
>>>>=20
>>>> 2)      By setting the priority =3D 0 for a particular VRID.
>>>>=20
>>>> Thanks
>>>> -Anurag
>>>>=20
>>>> -------------- next part -------------- An HTML attachment was=20
>>>> scrubbed...
>>>> URL:>>> /
>>>> 36
>>>> a6571f/attachment.htm>
>>>>=20
>>>> ------------------------------
>>>>=20
>>>> _______________________________________________
>>>> vrrp mailing list
>>>> vrrp@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/vrrp
>>>>=20
>>>>=20
>>>> End of vrrp Digest, Vol 81, Issue 1
>>>> ***********************************
>>> Disclaimer :
>>> This email communication may contain privileged and confidential inform=
ation and is intended for the use of the addressee only.If you are not an i=
ntended recipient you are requested not to reproduce, copy disseminate or i=
n any manner distribute this email communication as the same is strictly pr=
ohibited. If you have received this email in error, please notify the sende=
r 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 t=
he proper, timely and complete transmission thereof.
>>>=20
>>> _______________________________________________
>>> vrrp mailing list
>>> vrrp@ietf.org
>>> https://www.ietf.org/mailman/listinfo/vrrp
>>=20
>> Disclaimer :
>> This email communication may contain privileged and confidential informa=
tion and is intended for the use of the addressee only.If you are not an in=
tended recipient you are requested not to reproduce, copy disseminate or in=
 any manner distribute this email communication as the same is strictly pro=
hibited. If you have received this email in error, please notify the sender=
 immediately by return e-mail and delete the communication sent in error. E=
mail communications cannot be guaranteed to be secure & error free and IB T=
echnology is not liable for any errors in the email communication or for th=
e proper, timely and complete transmission thereof.
>> -------------- next part -------------- An HTML attachment was=20
>> scrubbed...
>> URL:=20
>> > 7
>> 14/attachment.htm>
>>=20
>> ------------------------------
>>=20
>> Message: 2
>> Date: Fri, 22 Feb 2013 11:41:47 +0000
>> From: "Anurag Kothari (ankothar)" 
>> To: sreenatha 
>> Cc: "vrrp@ietf.org" 
>> Subject: Re: [VRRP] Proposal for Maintenance Event for VRRP=20
>> [RFC-5798]
>> Message-ID:
>>=20
>> 
>> Content-Type: text/plain; charset=3D"us-ascii"
>>=20
>> Hi Sreenatha
>>=20
>> My bad, by cancel I meant reset the timer.
>>=20
>> 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 pro=
posal as:
>>=20
>>=20
>> - If a Maintenance event is received, then:
>>=20
>>=20
>>=20
>> + Send an ADVERTISEMENT
>>=20
>>=20
>>=20
>> + Reset the Adver_Timer to Advertisement_Interval
>>=20
>>=20
>>=20
>> -endif // maintenance recv
>>=20
>> Thanks
>> -Anurag
>>=20
>> From: sreenatha [mailto:sreenatha.setty@ibtechnology.com]
>> Sent: Thursday, February 21, 2013 11:26 PM
>> To: Anurag Kothari (ankothar)
>> Cc: vrrp@ietf.org
>> Subject: Re: [VRRP] Proposal for Maintenance Event for VRRP=20
>> [RFC-5798]
>>=20
>> Hi Anurag,
>>  Your proposal is:
>>=20
>>=20
>>=20
>> - If a Maintenance event is received, then:
>>=20
>>=20
>>=20
>> + Cancel the Adver_Timer
>>=20
>>=20
>>=20
>> + Send an ADVERTISEMENT with Priority =3D 0
>>=20
>>=20
>>=20
>> -endif // maintenance recv
>>=20
>>=20
>>=20
>>=20
>>=20
>>   And you mentioned that router need to send regular ADVERTISEMENT messa=
ge till it receives the ADVERTISEMENT message from the backup router.
>>=20
>>=20
>>=20
>> "2. How much time Master router should wait to receive ADVERTISEMENT mes=
sage from any backup router?
>>=20
>>=20
>>=20
>> [Anurag] Master doesn't have to wait. After receiving the maintenance ev=
ent it will send regular ADVERTISEMENT with Priority =3D 0 till some other =
router send back an ADVERTISEMENT message at which point it will transition=
 to Backup."
>>=20
>>=20
>>=20
>> If Advert_Timer is cancelled, how regular ADVERTISEMENT messages are sen=
t?
>>=20
>>=20
>>=20
>> So i am suggesting slight changes in the Proposal:
>>=20
>>=20
>>=20
>> - If a Maintenance event is received, then:
>>=20
>>=20
>>=20
>> + Change the router priority to 0
>>=20
>>=20
>>=20
>> + Send an ADVERTISEMENT with Priority =3D 0
>>=20
>>=20
>>=20
>> + Reset the Adver_Timer
>>=20
>>=20
>>=20
>> -endif // maintenance recv
>>=20
>>=20
>>=20
>> This will ensure that:
>>=20
>> 1. ADVERTISEMENT message with priority 0 is sent  immediately on receivi=
ng Maintenance event.
>>=20
>> 2. Master router will send regular Advertisement message till it receive=
s the ADVERTISEMENT message from any backup routers.
>>=20
>>=20
>>=20
>> Thanks,
>>=20
>> Sreenatha Setty
>>=20
>>=20
>>=20
>>=20
>>=20
>>=20
>> On 02/21/2013 10:12 PM, Anurag Kothari (ankothar) wrote:
>>=20
>> Hi Sreenatha
>>=20
>>=20
>>=20
>> This ideas is based on the way the priority is defined in Section 5.2.4.=
 and 6.1. of RFC-5798.
>>=20
>>=20
>>=20
>> "
>>=20
>>  The priority value zero (0) has special meaning, indicating that the
>>=20
>>  current Master has stopped participating in VRRP.  This is used to
>>=20
>>  trigger Backup routers to quickly transition to Master without=20
>> having
>>=20
>>  to wait for the current Master to time out.
>>=20
>> "
>>=20
>>=20
>>=20
>> "
>>=20
>>  Priority                The value of 0 (zero) is
>>=20
>>                              reserved for the Master router to
>>=20
>>                              indicate it is releasing responsibility
>>=20
>>                              for the virtual router.  The range 1-254
>>=20
>>                              (decimal) is available for VRRP routers
>>=20
>>                              backing up the virtual router. 
>>=20
>> "
>>=20
>>=20
>>=20
>> Please see my responses inline [Anurag]:
>>=20
>>=20
>>=20
>> Thanks
>>=20
>> -Anurag
>>=20
>>=20
>>=20
>> -----Original Message-----
>>=20
>> From: vrrp-bounces@ietf.org
>> [mailto:vrrp-bounces@ietf.org] On Behalf Of sreenatha
>>=20
>> Sent: Thursday, February 21, 2013 11:03 AM
>>=20
>> To: vrrp@ietf.org
>>=20
>> Subject: Re: [VRRP] Proposal for Maintenance Event for VRRP=20
>> [RFC-5798]
>>=20
>>=20
>>=20
>> Hi Anurag,
>>=20
>>    Proposed idea is good. I have some queries on this proposal:
>>=20
>>=20
>>=20
>> 1. On receiving new maintenance_event, priority of the router is not cha=
nged, right? So if back-up router has less priority, even if Master receive=
s the ADVERTISEMENT from the backup router, Master will discard.
>>=20
>> So how the Master router state is going to change?
>>=20
>>=20
>>=20
>> [Anurag] On receiving the maintenance event the priority of router (or V=
RID) will change to 0.
>>=20
>>=20
>>=20
>> 2. How much time Master router should wait to receive ADVERTISEMENT mess=
age from any backup router?
>>=20
>>=20
>>=20
>> [Anurag] Master doesn't have to wait. After receiving the maintenance ev=
ent it will send regular ADVERTISEMENT with Priority =3D 0 till some other =
router send back an ADVERTISEMENT message at which point it will transition=
 to Backup.
>>=20
>>=20
>>=20
>> 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?
>>=20
>>=20
>>=20
>> [Anurag] Yes. Priority 0 will have to be made a user configurable value =
to indicate the intention of a router to relinquish Master Status.
>>=20
>>=20
>>=20
>> Thanks,
>>=20
>> Sreenatha Setty
>>=20
>>=20
>>=20
>> On 02/21/2013 01:30 AM, vrrp-request@ietf.org wrote:
>>=20
>> If you have received this digest without all the individual message
>>=20
>> attachments you will need to update your digest options in your list
>>=20
>> subscription.  To do so, go to
>>=20
>>=20
>>=20
>> https://www.ietf.org/mailman/listinfo/vrrp
>>=20
>>=20
>>=20
>> Click the 'Unsubscribe or edit options' button, log in, and set "Get
>>=20
>> MIME or Plain Text Digests?" to MIME.  You can set this option
>>=20
>> globally for all the list digests you receive at this point.
>>=20
>>=20
>>=20
>>=20
>>=20
>>=20
>>=20
>> Send vrrp mailing list submissions to
>>=20
>>  vrrp@ietf.org
>>=20
>>=20
>>=20
>> To subscribe or unsubscribe via the World Wide Web, visit
>>=20
>>  https://www.ietf.org/mailman/listinfo/vrrp
>>=20
>> or, via email, send a message with subject or body 'help' to
>>=20
>>  vrrp-request@ietf.org
>>=20
>>=20
>>=20
>> You can reach the person managing the list at
>>=20
>>  vrrp-owner@ietf.org
>>=20
>>=20
>>=20
>> When replying, please edit your Subject line so it is more specific
>>=20
>> than "Re: Contents of vrrp digest..."
>>=20
>>=20
>>=20
>>=20
>>=20
>> Today's Topics:
>>=20
>>=20
>>=20
>>   1. Proposal for Maintenance Event for VRRP [RFC-5798]
>>=20
>>      (Anurag Kothari (ankothar))
>>=20
>>=20
>>=20
>>=20
>>=20
>> ---------------------------------------------------------------------
>> -
>>=20
>>=20
>>=20
>> Message: 1
>>=20
>> Date: Tue, 19 Feb 2013 22:08:41 +0000
>>=20
>> From: "Anurag Kothari
>> (ankothar)"
>>=20
>> To:"vrrp@ietf.org"
>> 
>>=20
>> Subject: [VRRP] Proposal for Maintenance Event for VRRP [RFC-5798]
>>=20
>> Message-ID:
>>=20
>>=20
>> > t o:A2BB90B33FFDF740876C5AAE307D83DB1C290327@xmb-rcd-x05.cisco.com>
>>=20
>> Content-Type: text/plain; charset=3D"us-ascii"
>>=20
>>=20
>>=20
>> Hi
>>=20
>>=20
>>=20
>> I want to propose a new Maintenance Event (modification of Shutdown Even=
t) for VRRP (RFC-5798] which would allow to gracefully failover the VRRP Ma=
ster to Redundant (Backup Router).
>>=20
>>=20
>>=20
>> Problem Statement:
>>=20
>> VRRP preemption is not configured on the redundant / backup router.
>>=20
>> How to initiate VRRP Traffic to failover to the redundant / backup
>>=20
>> router gracefully without modifying the configuration on the=20
>> redundant
>>=20
>> / backup router (i.e. adding preemption)
>>=20
>>=20
>>=20
>> Proposed Solution:
>>=20
>> Addition to Section 6.4.3 of RFC-5798:
>>=20
>>=20
>>=20
>> - If a Maintenance event is received, then:
>>=20
>>=20
>>=20
>> + Cancel the Adver_Timer
>>=20
>>=20
>>=20
>> + Send an ADVERTISEMENT with Priority =3D 0
>>=20
>>=20
>>=20
>> -endif // maintenance recv
>>=20
>>=20
>>=20
>> Unlike Shutdown event the router will not "Transition to the {Initialize=
} state" and continue to be Master and forward traffic  till the backup rou=
ter sends an ADVERTISEMENT (triggered by receiving an ADVERTISEMENT with Pr=
iority =3D 0) and becomes master.
>=20
>>=20
>>=20
>>=20
>>=20
>>=20
>> Here are couple of examples of how a maintenance event may be
>>=20
>> triggered
>>=20
>>=20
>>=20
>>=20
>>=20
>> 1)      By some user command e.g. "maintenance-mode" in the vrrp configu=
ration.
>>=20
>>=20
>>=20
>> 2)      By setting the priority =3D 0 for a particular VRID.
>>=20
>>=20
>>=20
>> Thanks
>>=20
>> -Anurag
>>=20
>>=20
>>=20
>> -------------- next part -------------- An HTML attachment was
>>=20
>> scrubbed...
>>=20
>> URL:> 6
>> > 7
>> 1f/attachment.htm>
>>=20
>> a6571f/attachment.htm>> c hments/20130219/36a6571f/attachment.htm>
>>=20
>>=20
>>=20
>> ------------------------------
>>=20
>>=20
>>=20
>> _______________________________________________
>>=20
>> vrrp mailing list
>>=20
>> vrrp@ietf.org
>>=20
>> https://www.ietf.org/mailman/listinfo/vrrp
>>=20
>>=20
>>=20
>>=20
>>=20
>> End of vrrp Digest, Vol 81, Issue 1
>>=20
>> ***********************************
>>=20
>>=20
>>=20
>>=20
>>=20
>> Disclaimer :
>>=20
>> This email communication may contain privileged and confidential informa=
tion and is intended for the use of the addressee only.If you are not an in=
tended recipient you are requested not to reproduce, copy disseminate or in=
 any manner distribute this email communication as the same is strictly pro=
hibited. If you have received this email in error, please notify the sender=
 immediately by return e-mail and delete the communication sent in error. E=
mail communications cannot be guaranteed to be secure & error free and IB T=
echnology is not liable for any errors in the email communication or for th=
e proper, timely and complete transmission thereof.
>>=20
>>=20
>>=20
>> _______________________________________________
>>=20
>> vrrp mailing list
>>=20
>> vrrp@ietf.org
>>=20
>> https://www.ietf.org/mailman/listinfo/vrrp
>>=20
>>=20
>>=20
>>=20
>> Disclaimer :
>> This email communication may contain privileged and confidential informa=
tion and is intended for the use of the addressee only.If you are not an in=
tended recipient you are requested not to reproduce, copy disseminate or in=
 any manner distribute this email communication as the same is strictly pro=
hibited. If you have received this email in error, please notify the sender=
 immediately by return e-mail and delete the communication sent in error. E=
mail communications cannot be guaranteed to be secure & error free and IB T=
echnology is not liable for any errors in the email communication or for th=
e proper, timely and complete transmission thereof.
>> -------------- next part -------------- An HTML attachment was=20
>> scrubbed...
>> URL:=20
>> > 4
>> c7/attachment.htm>
>>=20
>> ------------------------------
>>=20
>> _______________________________________________
>> vrrp mailing list
>> vrrp@ietf.org
>> https://www.ietf.org/mailman/listinfo/vrrp
>>=20
>>=20
>> End of vrrp Digest, Vol 81, Issue 3
>> ***********************************
>=20
> DISCLAIMER:
> This e-mail and any attachments to it may contain confidential and propri=
etary material and is solely for the use of the intended recipient. Any rev=
iew, use, disclosure, distribution or copying of this transmittal is prohib=
ited except by or on behalf of the intended recipient.  If you have receive=
d this transmittal in error, please notify the sender and destroy this e-ma=
il and any attachments and all copies, whether electronic or printed.
> _______________________________________________
> 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

From tperiyannan@extremenetworks.com  Fri Feb 22 09:41:06 2013
Return-Path: 
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 4707921F8E4A for ; Fri, 22 Feb 2013 09:41:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
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 M1Uly7csMT8z for ; Fri, 22 Feb 2013 09:41:04 -0800 (PST)
Received: from ussc-casht-p1.extremenetworks.com (ussc-casht-p1.extremenetworks.com [207.179.9.62]) by ietfa.amsl.com (Postfix) with ESMTP id 6F91A21F8E3A for ; Fri, 22 Feb 2013 09:41:04 -0800 (PST)
Received: from inch-casht-p1.corp.extremenetworks.com (10.120.89.28) by ussc-casht-p1.corp.extremenetworks.com (10.0.4.73) with Microsoft SMTP Server (TLS) id 8.3.297.1; Fri, 22 Feb 2013 09:41:04 -0800
Received: from INEXCHANGE.corp.extremenetworks.com ([192.168.131.111]) by inch-casht-p1.corp.extremenetworks.com ([10.120.89.28]) with mapi; Fri, 22 Feb 2013 23:11:00 +0530
From: Thirumavalavan Periyannan 
To: "Anurag Kothari (ankothar)" 
Date: Fri, 22 Feb 2013 23:10:54 +0530
Thread-Topic: [VRRP] vrrp Digest, Vol 81, Issue 3
Thread-Index: Ac4RI8Z8FN8e4KHYQ92R/65MDP3rdQ==
Message-ID: <91BD27DC-D555-49C7-8B40-F74F4D8B596F@extremenetworks.com>
References:  <14CA6619-DB7C-40ED-85E4-535CB689AC86@extremenetworks.com>   
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-GB
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "vrrp@ietf.org" 
Subject: Re: [VRRP] vrrp Digest, Vol 81, Issue 3
X-BeenThere: vrrp@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Virtual Router Redundancy Protocol  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 22 Feb 2013 17:41:06 -0000

Hi Anurag,

If customer wants to do any maintenance work then they can do "disable vrrp=
" on MASTER Router which will generate VRRP Advertisement with "priority 0"=
 and one among the backup router will become master based on the priority o=
r higher interface IP addres.


Sent from my iPhone

On 22-Feb-2013, at 10:59 PM, "Anurag Kothari (ankothar)"  wrote:

> Hi Peter
>
> Please See my responses inline [Anurag]
>
> Thanks
> -Anurag
>
> -----Original Message-----
> From: Peter Hunt [mailto:pfhunt@gmail.com]
> Sent: Friday, February 22, 2013 11:59 AM
> To: Anurag Kothari (ankothar)
> Cc: Thirumavalavan Periyannan; vrrp@ietf.org
> Subject: Re: [VRRP] vrrp Digest, Vol 81, Issue 3
>
> Sorry to jump in here, but I'm having trouble understanding the motivatio=
n for the maintenance event.
>
> It seems like its behaviour is to relinquish mastership immediately to a =
backup if it exists, but remain master silently otherwise. Is that correct?
>
> [Anurag] The master will not remain silent it will keep sending Advertise=
ments with Priority =3D 0 until some backup router takes over as Master.
>
> If so, why is that desirable behaviour? It seems to me that you would eit=
her want to take the node out of the vrrp cluster completely, or have it pa=
rticipate at a reduced priority. What situation makes a silent-but-active m=
aster preferable?
>
> [Anurag] Many mobile service providers disable preemption for VRRP as the=
y do not like the idea of unplanned traffic switch when a router with highe=
r priority comes up. They only want traffic to switch in the event of a fai=
lure or as part of a planned activity in a maintenance window.
> Now here is an example: A site has PE1 and PE2 configured to backup each =
other. Now if I want to perform any maintenance work on the say PE1 (Code u=
pgrade / HW upgrade etc.) I want to take it out of the traffic path gracefu=
lly. Now the only way to Gracefully failover the traffic to PE2 is to confi=
gure preemption on it and reduce the priority on PE1 (or increase it on PE2=
) and remove it at the end of the maintenance work. But most service provid=
ers do not like the idea of touching (making changes to configuration) on b=
oth the boxes within the same maintenance window. So the idea here is to be=
 able to failover the traffic to the backup router without enabling preempt=
ion on the Backup router.  If the backup router exists it will take over im=
mediately if it doesn't exist the existing Master will continue to provide =
service. A lack of failover will indicate to the operator that backup is mi=
ssing / not working and he will have to troubleshoot the situation.
>
> Peter
>
>
> On Feb 22, 2013, at 7:55 AM, "Anurag Kothari (ankothar)"  wrote:
>
>> Yes that is correct.
>>
>> The intention is to be able to switch the traffic to the backup router (=
with minimal traffic interruption) when preemption is not configured on the=
 backup router without shutting down the interface or VRRP on Master.
>>
>> Thanks
>> ~Anurag
>>
>> -----Original Message-----
>> From: vrrp-bounces@ietf.org [mailto:vrrp-bounces@ietf.org] On Behalf
>> Of Thirumavalavan Periyannan
>> Sent: Friday, February 22, 2013 8:56 AM
>> To: vrrp@ietf.org
>> Cc: vrrp@ietf.org
>> Subject: Re: [VRRP] vrrp Digest, Vol 81, Issue 3
>>
>> Hi Anurag,
>>
>> You meant to say that when we do graceful failover on VRRP Master then t=
raffic needs switch to VRRP backup router without waiting for Master_Down_I=
nterval time.
>>
>> Please correct me if I am wrong.
>>
>> Sent from my iPhone
>>
>> On 22-Feb-2013, at 5:11 PM, "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
>>>
>>> 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
>>>
>>> You can reach the person managing the list at
>>>      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. Re: Proposal for Maintenance Event for VRRP [RFC-5798]
>>> (sreenatha)  2. Re: Proposal for Maintenance Event for VRRP [RFC-5798]
>>>    (Anurag Kothari (ankothar))
>>>
>>>
>>> ---------------------------------------------------------------------
>>> -
>>>
>>> Message: 1
>>> Date: Fri, 22 Feb 2013 09:55:35 +0530
>>> From: sreenatha 
>>> To: "Anurag Kothari (ankothar)" 
>>> Cc: "vrrp@ietf.org" 
>>> Subject: Re: [VRRP] Proposal for Maintenance Event for VRRP
>>> [RFC-5798]
>>> Message-ID: <5126F33F.1080005@ibtechnology.com>
>>> Content-Type: text/plain; charset=3D"iso-8859-1"; Format=3D"flowed"
>>>
>>> Hi Anurag,
>>>  Your proposal is:
>>>
>>> - If a Maintenance event is received, then:
>>>
>>> + Cancel the Adver_Timer
>>>
>>> + Send an ADVERTISEMENT with Priority =3D 0
>>>
>>> -endif // maintenance recv
>>>
>>>
>>>   And you mentioned that router need to send regular ADVERTISEMENT mess=
age till it receives the ADVERTISEMENT message from the backup router.
>>>
>>> "2. How much time Master router should wait to receive ADVERTISEMENT me=
ssage from any backup router?
>>>
>>> [Anurag] Master doesn't have to wait. After receiving the maintenance e=
vent it will send regular ADVERTISEMENT with Priority =3D 0 till some other=
 router send back an ADVERTISEMENT message at which point it will transitio=
n to Backup."
>>>
>>> If Advert_Timer is cancelled, how regular ADVERTISEMENT messages are se=
nt?
>>>
>>> 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 =3D 0
>>>
>>> + Reset the Adver_Timer
>>>
>>> -endif // maintenance recv
>>>
>>> This will ensure that:
>>> 1. ADVERTISEMENT message with priority 0 is sent  immediately on receiv=
ing Maintenance event.
>>> 2. Master router will send regular Advertisement message till it receiv=
es 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                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. 
>>>> "
>>>>
>>>> Please see my responses inline [Anurag]:
>>>>
>>>> Thanks
>>>> -Anurag
>>>>
>>>> -----Original Message-----
>>>> From: 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
>>>> 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 c=
hanged, right? So if back-up router has less priority, even if Master recei=
ves 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 me=
ssage from any backup router?
>>>>
>>>> [Anurag] Master doesn't have to wait. After receiving the maintenance =
event it will send regular ADVERTISEMENT with Priority =3D 0 till some othe=
r router send back an ADVERTISEMENT message at which point it will transiti=
on to Backup.
>>>>
>>>> 3. Standard VRRP MIB(RFC-2787) does not allow user to configure '0' fo=
r VRRP Priority. So you are proposing to change this value also?
>>>>
>>>> [Anurag] Yes. Priority 0 will have to be made a user configurable valu=
e 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 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
>>>>>
>>>>> 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
>>>>>
>>>>> You can reach the person managing the list at
>>>>>   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)"
>>>>> To:"vrrp@ietf.org"  
>>>>> Subject: [VRRP] Proposal for Maintenance Event for VRRP [RFC-5798]
>>>>> Message-ID:
>>>>>   
>>>>> Content-Type: text/plain; charset=3D"us-ascii"
>>>>>
>>>>> Hi
>>>>>
>>>>> I want to propose a new Maintenance Event (modification of Shutdown E=
vent) 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 =3D 0
>>>>>
>>>>> -endif // maintenance recv
>>>>>
>>>>> Unlike Shutdown event the router will not "Transition to the {Initial=
ize} state" and continue to be Master and forward traffic  till the backup =
router sends an ADVERTISEMENT (triggered by receiving an ADVERTISEMENT with=
 Priority =3D 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 conf=
iguration.
>>>>>
>>>>> 2)      By setting the priority =3D 0 for a particular VRID.
>>>>>
>>>>> Thanks
>>>>> -Anurag
>>>>>
>>>>> -------------- next part -------------- An HTML attachment was
>>>>> scrubbed...
>>>>> URL:>>>> /
>>>>> 36
>>>>> a6571f/attachment.htm>
>>>>>
>>>>> ------------------------------
>>>>>
>>>>> _______________________________________________
>>>>> vrrp mailing list
>>>>> 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 infor=
mation 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 p=
rohibited. If you have received this email in error, please notify the send=
er 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
>>>
>>> Disclaimer :
>>> This email communication may contain privileged and confidential inform=
ation and is intended for the use of the addressee only.If you are not an i=
ntended recipient you are requested not to reproduce, copy disseminate or i=
n any manner distribute this email communication as the same is strictly pr=
ohibited. If you have received this email in error, please notify the sende=
r 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 t=
he proper, timely and complete transmission thereof.
>>> -------------- next part -------------- An HTML attachment was
>>> scrubbed...
>>> URL:
>>> >> 7
>>> 14/attachment.htm>
>>>
>>> ------------------------------
>>>
>>> Message: 2
>>> Date: Fri, 22 Feb 2013 11:41:47 +0000
>>> From: "Anurag Kothari (ankothar)" 
>>> To: sreenatha 
>>> Cc: "vrrp@ietf.org" 
>>> Subject: Re: [VRRP] Proposal for Maintenance Event for VRRP
>>> [RFC-5798]
>>> Message-ID:
>>>
>>> 
>>> Content-Type: text/plain; charset=3D"us-ascii"
>>>
>>> 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 pr=
oposal 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
>>> 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 =3D 0
>>>
>>>
>>>
>>> -endif // maintenance recv
>>>
>>>
>>>
>>>
>>>
>>>  And you mentioned that router need to send regular ADVERTISEMENT messa=
ge till it receives the ADVERTISEMENT message from the backup router.
>>>
>>>
>>>
>>> "2. How much time Master router should wait to receive ADVERTISEMENT me=
ssage from any backup router?
>>>
>>>
>>>
>>> [Anurag] Master doesn't have to wait. After receiving the maintenance e=
vent it will send regular ADVERTISEMENT with Priority =3D 0 till some other=
 router send back an ADVERTISEMENT message at which point it will transitio=
n to Backup."
>>>
>>>
>>>
>>> If Advert_Timer is cancelled, how regular ADVERTISEMENT messages are se=
nt?
>>>
>>>
>>>
>>> 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 =3D 0
>>>
>>>
>>>
>>> + Reset the Adver_Timer
>>>
>>>
>>>
>>> -endif // maintenance recv
>>>
>>>
>>>
>>> This will ensure that:
>>>
>>> 1. ADVERTISEMENT message with priority 0 is sent  immediately on receiv=
ing Maintenance event.
>>>
>>> 2. Master router will send regular Advertisement message till it receiv=
es 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                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. 
>>>
>>> "
>>>
>>>
>>>
>>> Please see my responses inline [Anurag]:
>>>
>>>
>>>
>>> Thanks
>>>
>>> -Anurag
>>>
>>>
>>>
>>> -----Original Message-----
>>>
>>> From: 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
>>>
>>> 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 ch=
anged, right? So if back-up router has less priority, even if Master receiv=
es 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 mes=
sage from any backup router?
>>>
>>>
>>>
>>> [Anurag] Master doesn't have to wait. After receiving the maintenance e=
vent it will send regular ADVERTISEMENT with Priority =3D 0 till some other=
 router send back an ADVERTISEMENT message at which point it will transitio=
n 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 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
>>>
>>>
>>>
>>> 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
>>>
>>>
>>>
>>> You can reach the person managing the list at
>>>
>>> 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)"
>>>
>>> To:"vrrp@ietf.org"
>>> 
>>>
>>> Subject: [VRRP] Proposal for Maintenance Event for VRRP [RFC-5798]
>>>
>>> Message-ID:
>>>
>>>
>>> >> t o:A2BB90B33FFDF740876C5AAE307D83DB1C290327@xmb-rcd-x05.cisco.com>
>>>
>>> Content-Type: text/plain; charset=3D"us-ascii"
>>>
>>>
>>>
>>> Hi
>>>
>>>
>>>
>>> I want to propose a new Maintenance Event (modification of Shutdown Eve=
nt) for VRRP (RFC-5798] which would allow to gracefully failover the VRRP M=
aster 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 =3D 0
>>>
>>>
>>>
>>> -endif // maintenance recv
>>>
>>>
>>>
>>> Unlike Shutdown event the router will not "Transition to the {Initializ=
e} state" and continue to be Master and forward traffic  till the backup ro=
uter sends an ADVERTISEMENT (triggered by receiving an ADVERTISEMENT with P=
riority =3D 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 config=
uration.
>>>
>>>
>>>
>>> 2)      By setting the priority =3D 0 for a particular VRID.
>>>
>>>
>>>
>>> Thanks
>>>
>>> -Anurag
>>>
>>>
>>>
>>> -------------- next part -------------- An HTML attachment was
>>>
>>> scrubbed...
>>>
>>> URL:>> 6
>>> >> 7
>>> 1f/attachment.htm>
>>>
>>> a6571f/attachment.htm>>> c hments/20130219/36a6571f/attachment.htm>
>>>
>>>
>>>
>>> ------------------------------
>>>
>>>
>>>
>>> _______________________________________________
>>>
>>> vrrp mailing list
>>>
>>> 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 inform=
ation and is intended for the use of the addressee only.If you are not an i=
ntended recipient you are requested not to reproduce, copy disseminate or i=
n any manner distribute this email communication as the same is strictly pr=
ohibited. If you have received this email in error, please notify the sende=
r 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 t=
he proper, timely and complete transmission thereof.
>>>
>>>
>>>
>>> _______________________________________________
>>>
>>> vrrp mailing list
>>>
>>> vrrp@ietf.org
>>>
>>> https://www.ietf.org/mailman/listinfo/vrrp
>>>
>>>
>>>
>>>
>>> Disclaimer :
>>> This email communication may contain privileged and confidential inform=
ation and is intended for the use of the addressee only.If you are not an i=
ntended recipient you are requested not to reproduce, copy disseminate or i=
n any manner distribute this email communication as the same is strictly pr=
ohibited. If you have received this email in error, please notify the sende=
r 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 t=
he proper, timely and complete transmission thereof.
>>> -------------- next part -------------- An HTML attachment was
>>> scrubbed...
>>> URL:
>>> >> 4
>>> c7/attachment.htm>
>>>
>>> ------------------------------
>>>
>>> _______________________________________________
>>> vrrp mailing list
>>> vrrp@ietf.org
>>> https://www.ietf.org/mailman/listinfo/vrrp
>>>
>>>
>>> End of vrrp Digest, Vol 81, Issue 3
>>> ***********************************
>>
>> DISCLAIMER:
>> This e-mail and any attachments to it may contain confidential and propr=
ietary material and is solely for the use of the intended recipient. Any re=
view, use, disclosure, distribution or copying of this transmittal is prohi=
bited except by or on behalf of the intended recipient.  If you have receiv=
ed this transmittal in error, please notify the sender and destroy this e-m=
ail and any attachments and all copies, whether electronic or printed.
>> _______________________________________________
>> 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

DISCLAIMER:
This e-mail and any attachments to it may contain confidential and propriet=
ary material and is solely for the use of the intended recipient. Any revie=
w, use, disclosure, distribution or copying of this transmittal is prohibit=
ed except by or on behalf of the intended recipient.  If you have received =
this transmittal in error, please notify the sender and destroy this e-mail=
 and any attachments and all copies, whether electronic or printed.

From ankothar@cisco.com  Fri Feb 22 11:26:41 2013
Return-Path: 
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 02DFD21F8A18 for ; Fri, 22 Feb 2013 11:26:41 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t8F2J0XmKxDl for ; Fri, 22 Feb 2013 11:26:37 -0800 (PST)
Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 4C8F021F84DF for ; Fri, 22 Feb 2013 11:26:37 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=29826; q=dns/txt; s=iport; t=1361561197; x=1362770797; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=O7YZUD/Vk6eQddfmcJMH4IPrQ4PPL8kRFw4xZjUJ3hc=; b=fTIF4qLNIgqmi1s8kvOsw/ncj97v2ZxOp1Rg35mZUJlJkeJ9MrQaBlI1 MlKvU2KuSFUgXW4tFuWSjtRMFMXT7AAH0w+r1ufQzHlh3NltBoAJc4INj 9xEptKe96qQXtYZsdfzc6rkabZfkdICUiTaTHOp5/Rf/pC5gLR3twzIEt k=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgMFAIDFJ1GtJXG+/2dsb2JhbABEwSaBDBZzgh8BAQEDAQEBARcgFCALBQcEAgEIDgMDAQEBAQoCAREJByEGCgEUCQgBAQQBDQUIARICBIdfAwkGDLVaDYlCjDd9CRCBEAYgBgUCBQIEgllhA5RdjSmFF4MHgWkEAgMXHg
X-IronPort-AV: E=Sophos;i="4.84,717,1355097600"; d="scan'208";a="180189060"
Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-6.cisco.com with ESMTP; 22 Feb 2013 19:26:35 +0000
Received: from xhc-rcd-x08.cisco.com (xhc-rcd-x08.cisco.com [173.37.183.82]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id r1MJQZ8m021757 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 22 Feb 2013 19:26:35 GMT
Received: from xmb-rcd-x05.cisco.com ([169.254.15.93]) by xhc-rcd-x08.cisco.com ([173.37.183.82]) with mapi id 14.02.0318.004; Fri, 22 Feb 2013 13:26:35 -0600
From: "Anurag Kothari (ankothar)" 
To: Thirumavalavan Periyannan , "vrrp@ietf.org" 
Thread-Topic: [VRRP] vrrp Digest, Vol 81, Issue 3
Thread-Index: Ac4RBGKo4P5hWc5lTiSJPUEgi0SCSQADvuFgAA80cgAADFd4oP//qQAAgABMd9A=
Date: Fri, 22 Feb 2013 19:26:35 +0000
Message-ID: 
References:  <14CA6619-DB7C-40ED-85E4-535CB689AC86@extremenetworks.com>    <91BD27DC-D555-49C7-8B40-F74F4D8B596F@extremenetworks.com>
In-Reply-To: <91BD27DC-D555-49C7-8B40-F74F4D8B596F@extremenetworks.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [64.102.148.157]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [VRRP] vrrp Digest, Vol 81, Issue 3
X-BeenThere: vrrp@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Virtual Router Redundancy Protocol  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 22 Feb 2013 19:26:41 -0000

Hi Thirumavalavan

Here are couple of points:

1) With something like "disable vrrp" or "shutdown vrrp" it will not be gra=
ceful as the router will treat it as a shutdown event (which is a break bef=
ore you make approach) and the router will "Transition to the {Initialize} =
state". The backup router will wait for "Skew_Time" before it becomes maste=
r; So we probably will have traffic loss for a period approximately equal t=
o "Skew_Time". Even with Default configuration this will be close to 609 ms=
 which would be a duration long enough for to impact time sensitive applica=
tions (e.g. voice calls). For sure the actual failover time will depend upo=
n the size of the Network and the switches in between but with the method p=
roposed below we can try to improve that time.

2) This will also improve convergence in scenarios where we want the failov=
er to trigger because of up uplink interface from the router going down (tr=
acking interface and decrementing the priority).

I am not sure if you saw the modified proposal which was sent out today ear=
ly morning. Here is the link to it in case you need it http://www.ietf.org/=
mail-archive/web/vrrp/current/msg01489.html

Thanks
~Anurag

-----Original Message-----
From: Thirumavalavan Periyannan [mailto:tperiyannan@extremenetworks.com]=20
Sent: Friday, February 22, 2013 12:41 PM
To: Anurag Kothari (ankothar)
Cc: Peter Hunt; vrrp@ietf.org
Subject: Re: [VRRP] vrrp Digest, Vol 81, Issue 3

Hi Anurag,

If customer wants to do any maintenance work then they can do "disable vrrp=
" on MASTER Router which will generate VRRP Advertisement with "priority 0"=
 and one among the backup router will become master based on the priority o=
r higher interface IP addres.


Sent from my iPhone

On 22-Feb-2013, at 10:59 PM, "Anurag Kothari (ankothar)"  wrote:

> Hi Peter
>
> Please See my responses inline [Anurag]
>
> Thanks
> -Anurag
>
> -----Original Message-----
> From: Peter Hunt [mailto:pfhunt@gmail.com]
> Sent: Friday, February 22, 2013 11:59 AM
> To: Anurag Kothari (ankothar)
> Cc: Thirumavalavan Periyannan; vrrp@ietf.org
> Subject: Re: [VRRP] vrrp Digest, Vol 81, Issue 3
>
> Sorry to jump in here, but I'm having trouble understanding the motivatio=
n for the maintenance event.
>
> It seems like its behaviour is to relinquish mastership immediately to a =
backup if it exists, but remain master silently otherwise. Is that correct?
>
> [Anurag] The master will not remain silent it will keep sending Advertise=
ments with Priority =3D 0 until some backup router takes over as Master.
>
> If so, why is that desirable behaviour? It seems to me that you would eit=
her want to take the node out of the vrrp cluster completely, or have it pa=
rticipate at a reduced priority. What situation makes a silent-but-active m=
aster preferable?
>
> [Anurag] Many mobile service providers disable preemption for VRRP as the=
y do not like the idea of unplanned traffic switch when a router with highe=
r priority comes up. They only want traffic to switch in the event of a fai=
lure or as part of a planned activity in a maintenance window.
> Now here is an example: A site has PE1 and PE2 configured to backup each =
other. Now if I want to perform any maintenance work on the say PE1 (Code u=
pgrade / HW upgrade etc.) I want to take it out of the traffic path gracefu=
lly. Now the only way to Gracefully failover the traffic to PE2 is to confi=
gure preemption on it and reduce the priority on PE1 (or increase it on PE2=
) and remove it at the end of the maintenance work. But most service provid=
ers do not like the idea of touching (making changes to configuration) on b=
oth the boxes within the same maintenance window. So the idea here is to be=
 able to failover the traffic to the backup router without enabling preempt=
ion on the Backup router.  If the backup router exists it will take over im=
mediately if it doesn't exist the existing Master will continue to provide =
service. A lack of failover will indicate to the operator that backup is mi=
ssing / not working and he will have to troubleshoot the situation.
>
> Peter
>
>
> On Feb 22, 2013, at 7:55 AM, "Anurag Kothari (ankothar)"  wrote:
>
>> Yes that is correct.
>>
>> The intention is to be able to switch the traffic to the backup router (=
with minimal traffic interruption) when preemption is not configured on the=
 backup router without shutting down the interface or VRRP on Master.
>>
>> Thanks
>> ~Anurag
>>
>> -----Original Message-----
>> From: vrrp-bounces@ietf.org [mailto:vrrp-bounces@ietf.org] On Behalf=20
>> Of Thirumavalavan Periyannan
>> Sent: Friday, February 22, 2013 8:56 AM
>> To: vrrp@ietf.org
>> Cc: vrrp@ietf.org
>> Subject: Re: [VRRP] vrrp Digest, Vol 81, Issue 3
>>
>> Hi Anurag,
>>
>> You meant to say that when we do graceful failover on VRRP Master then t=
raffic needs switch to VRRP backup router without waiting for Master_Down_I=
nterval time.
>>
>> Please correct me if I am wrong.
>>
>> Sent from my iPhone
>>
>> On 22-Feb-2013, at 5:11 PM, "vrrp-request@ietf.org"  wrote:
>>
>>> If you have received this digest without all the individual message=20
>>> attachments you will need to update your digest options in your list=20
>>> 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=20
>>> MIME or Plain Text Digests?" to MIME.  You can set this option=20
>>> globally for all the list digests you receive at this point.
>>>
>>>
>>>
>>> Send vrrp mailing list submissions to
>>>      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
>>>
>>> You can reach the person managing the list at
>>>      vrrp-owner@ietf.org
>>>
>>> When replying, please edit your Subject line so it is more specific=20
>>> than "Re: Contents of vrrp digest..."
>>>
>>>
>>> Today's Topics:
>>>
>>> 1. Re: Proposal for Maintenance Event for VRRP [RFC-5798]
>>> (sreenatha)  2. Re: Proposal for Maintenance Event for VRRP [RFC-5798]
>>>    (Anurag Kothari (ankothar))
>>>
>>>
>>> --------------------------------------------------------------------
>>> -
>>> -
>>>
>>> Message: 1
>>> Date: Fri, 22 Feb 2013 09:55:35 +0530
>>> From: sreenatha 
>>> To: "Anurag Kothari (ankothar)" 
>>> Cc: "vrrp@ietf.org" 
>>> Subject: Re: [VRRP] Proposal for Maintenance Event for VRRP=20
>>> [RFC-5798]
>>> Message-ID: <5126F33F.1080005@ibtechnology.com>
>>> Content-Type: text/plain; charset=3D"iso-8859-1"; Format=3D"flowed"
>>>
>>> Hi Anurag,
>>>  Your proposal is:
>>>
>>> - If a Maintenance event is received, then:
>>>
>>> + Cancel the Adver_Timer
>>>
>>> + Send an ADVERTISEMENT with Priority =3D 0
>>>
>>> -endif // maintenance recv
>>>
>>>
>>>   And you mentioned that router need to send regular ADVERTISEMENT mess=
age till it receives the ADVERTISEMENT message from the backup router.
>>>
>>> "2. How much time Master router should wait to receive ADVERTISEMENT me=
ssage from any backup router?
>>>
>>> [Anurag] Master doesn't have to wait. After receiving the maintenance e=
vent it will send regular ADVERTISEMENT with Priority =3D 0 till some other=
 router send back an ADVERTISEMENT message at which point it will transitio=
n to Backup."
>>>
>>> If Advert_Timer is cancelled, how regular ADVERTISEMENT messages are se=
nt?
>>>
>>> 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 =3D 0
>>>
>>> + Reset the Adver_Timer
>>>
>>> -endif // maintenance recv
>>>
>>> This will ensure that:
>>> 1. ADVERTISEMENT message with priority 0 is sent  immediately on receiv=
ing Maintenance event.
>>> 2. Master router will send regular Advertisement message till it receiv=
es 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=20
>>>> the  current Master has stopped participating in VRRP.  This is=20
>>>> used to  trigger Backup routers to quickly transition to Master=20
>>>> without having  to wait for the current Master to time out.
>>>> "
>>>>
>>>> "
>>>>  Priority                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. =20
>>>> "
>>>>
>>>> Please see my responses inline [Anurag]:
>>>>
>>>> Thanks
>>>> -Anurag
>>>>
>>>> -----Original Message-----
>>>> From: vrrp-bounces@ietf.org [mailto:vrrp-bounces@ietf.org] On=20
>>>> Behalf Of sreenatha
>>>> Sent: Thursday, February 21, 2013 11:03 AM
>>>> To: vrrp@ietf.org
>>>> Subject: Re: [VRRP] Proposal for Maintenance Event for VRRP=20
>>>> [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 c=
hanged, right? So if back-up router has less priority, even if Master recei=
ves 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 me=
ssage from any backup router?
>>>>
>>>> [Anurag] Master doesn't have to wait. After receiving the maintenance =
event it will send regular ADVERTISEMENT with Priority =3D 0 till some othe=
r router send back an ADVERTISEMENT message at which point it will transiti=
on to Backup.
>>>>
>>>> 3. Standard VRRP MIB(RFC-2787) does not allow user to configure '0' fo=
r VRRP Priority. So you are proposing to change this value also?
>>>>
>>>> [Anurag] Yes. Priority 0 will have to be made a user configurable valu=
e 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 wrote:
>>>>> If you have received this digest without all the individual=20
>>>>> message attachments you will need to update your digest options in=20
>>>>> 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=20
>>>>> "Get MIME or Plain Text Digests?" to MIME.  You can set this=20
>>>>> option globally for all the list digests you receive at this point.
>>>>>
>>>>>
>>>>>
>>>>> Send vrrp mailing list submissions to
>>>>>   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
>>>>>
>>>>> You can reach the person managing the list at
>>>>>   vrrp-owner@ietf.org
>>>>>
>>>>> When replying, please edit your Subject line so it is more=20
>>>>> 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)"=20
>>>>> To:"vrrp@ietf.org"  
>>>>> Subject: [VRRP] Proposal for Maintenance Event for VRRP [RFC-5798]
>>>>> Message-ID:
>>>>>   
>>>>> Content-Type: text/plain; charset=3D"us-ascii"
>>>>>
>>>>> Hi
>>>>>
>>>>> I want to propose a new Maintenance Event (modification of Shutdown E=
vent) 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=20
>>>>> router gracefully without modifying the configuration on the=20
>>>>> 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 =3D 0
>>>>>
>>>>> -endif // maintenance recv
>>>>>
>>>>> Unlike Shutdown event the router will not "Transition to the {Initial=
ize} state" and continue to be Master and forward traffic  till the backup =
router sends an ADVERTISEMENT (triggered by receiving an ADVERTISEMENT with=
 Priority =3D 0) and becomes master.
>>>>> Here are couple of examples of how a maintenance event may be=20
>>>>> triggered
>>>>>
>>>>>
>>>>> 1)      By some user command e.g. "maintenance-mode" in the vrrp conf=
iguration.
>>>>>
>>>>> 2)      By setting the priority =3D 0 for a particular VRID.
>>>>>
>>>>> Thanks
>>>>> -Anurag
>>>>>
>>>>> -------------- next part -------------- An HTML attachment was=20
>>>>> scrubbed...
>>>>> URL:>>>> 9
>>>>> /
>>>>> 36
>>>>> a6571f/attachment.htm>
>>>>>
>>>>> ------------------------------
>>>>>
>>>>> _______________________________________________
>>>>> vrrp mailing list
>>>>> 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 infor=
mation 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 p=
rohibited. If you have received this email in error, please notify the send=
er 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
>>>
>>> Disclaimer :
>>> This email communication may contain privileged and confidential inform=
ation and is intended for the use of the addressee only.If you are not an i=
ntended recipient you are requested not to reproduce, copy disseminate or i=
n any manner distribute this email communication as the same is strictly pr=
ohibited. If you have received this email in error, please notify the sende=
r 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 t=
he proper, timely and complete transmission thereof.
>>> -------------- next part -------------- An HTML attachment was=20
>>> scrubbed...
>>> URL:
>>> >> 0
>>> 7
>>> 14/attachment.htm>
>>>
>>> ------------------------------
>>>
>>> Message: 2
>>> Date: Fri, 22 Feb 2013 11:41:47 +0000
>>> From: "Anurag Kothari (ankothar)" 
>>> To: sreenatha 
>>> Cc: "vrrp@ietf.org" 
>>> Subject: Re: [VRRP] Proposal for Maintenance Event for VRRP=20
>>> [RFC-5798]
>>> Message-ID:
>>>
>>> 
>>> Content-Type: text/plain; charset=3D"us-ascii"
>>>
>>> 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 pr=
oposal 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
>>> Subject: Re: [VRRP] Proposal for Maintenance Event for VRRP=20
>>> [RFC-5798]
>>>
>>> Hi Anurag,
>>> Your proposal is:
>>>
>>>
>>>
>>> - If a Maintenance event is received, then:
>>>
>>>
>>>
>>> + Cancel the Adver_Timer
>>>
>>>
>>>
>>> + Send an ADVERTISEMENT with Priority =3D 0
>>>
>>>
>>>
>>> -endif // maintenance recv
>>>
>>>
>>>
>>>
>>>
>>>  And you mentioned that router need to send regular ADVERTISEMENT messa=
ge till it receives the ADVERTISEMENT message from the backup router.
>>>
>>>
>>>
>>> "2. How much time Master router should wait to receive ADVERTISEMENT me=
ssage from any backup router?
>>>
>>>
>>>
>>> [Anurag] Master doesn't have to wait. After receiving the maintenance e=
vent it will send regular ADVERTISEMENT with Priority =3D 0 till some other=
 router send back an ADVERTISEMENT message at which point it will transitio=
n to Backup."
>>>
>>>
>>>
>>> If Advert_Timer is cancelled, how regular ADVERTISEMENT messages are se=
nt?
>>>
>>>
>>>
>>> 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 =3D 0
>>>
>>>
>>>
>>> + Reset the Adver_Timer
>>>
>>>
>>>
>>> -endif // maintenance recv
>>>
>>>
>>>
>>> This will ensure that:
>>>
>>> 1. ADVERTISEMENT message with priority 0 is sent  immediately on receiv=
ing Maintenance event.
>>>
>>> 2. Master router will send regular Advertisement message till it receiv=
es 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=20
>>> having
>>>
>>> to wait for the current Master to time out.
>>>
>>> "
>>>
>>>
>>>
>>> "
>>>
>>> Priority                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. 
>>>
>>> "
>>>
>>>
>>>
>>> Please see my responses inline [Anurag]:
>>>
>>>
>>>
>>> Thanks
>>>
>>> -Anurag
>>>
>>>
>>>
>>> -----Original Message-----
>>>
>>> From: 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
>>>
>>> Subject: Re: [VRRP] Proposal for Maintenance Event for VRRP=20
>>> [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 ch=
anged, right? So if back-up router has less priority, even if Master receiv=
es 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 mes=
sage from any backup router?
>>>
>>>
>>>
>>> [Anurag] Master doesn't have to wait. After receiving the maintenance e=
vent it will send regular ADVERTISEMENT with Priority =3D 0 till some other=
 router send back an ADVERTISEMENT message at which point it will transitio=
n 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 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
>>>
>>>
>>>
>>> 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
>>>
>>>
>>>
>>> You can reach the person managing the list at
>>>
>>> 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)"
>>>
>>> To:"vrrp@ietf.org"
>>> 
>>>
>>> Subject: [VRRP] Proposal for Maintenance Event for VRRP [RFC-5798]
>>>
>>> Message-ID:
>>>
>>>
>>> >> l t=20
>>> o:A2BB90B33FFDF740876C5AAE307D83DB1C290327@xmb-rcd-x05.cisco.com>
>>>
>>> Content-Type: text/plain; charset=3D"us-ascii"
>>>
>>>
>>>
>>> Hi
>>>
>>>
>>>
>>> I want to propose a new Maintenance Event (modification of Shutdown Eve=
nt) for VRRP (RFC-5798] which would allow to gracefully failover the VRRP M=
aster 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=20
>>> 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 =3D 0
>>>
>>>
>>>
>>> -endif // maintenance recv
>>>
>>>
>>>
>>> Unlike Shutdown event the router will not "Transition to the {Initializ=
e} state" and continue to be Master and forward traffic  till the backup ro=
uter sends an ADVERTISEMENT (triggered by receiving an ADVERTISEMENT with P=
riority =3D 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 config=
uration.
>>>
>>>
>>>
>>> 2)      By setting the priority =3D 0 for a particular VRID.
>>>
>>>
>>>
>>> Thanks
>>>
>>> -Anurag
>>>
>>>
>>>
>>> -------------- next part -------------- An HTML attachment was
>>>
>>> scrubbed...
>>>
>>> URL:>> 3
>>> 6
>>> >> 5
>>> 7
>>> 1f/attachment.htm>
>>>
>>> a6571f/attachment.htm>>> a c hments/20130219/36a6571f/attachment.htm>
>>>
>>>
>>>
>>> ------------------------------
>>>
>>>
>>>
>>> _______________________________________________
>>>
>>> vrrp mailing list
>>>
>>> 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 inform=
ation and is intended for the use of the addressee only.If you are not an i=
ntended recipient you are requested not to reproduce, copy disseminate or i=
n any manner distribute this email communication as the same is strictly pr=
ohibited. If you have received this email in error, please notify the sende=
r 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 t=
he proper, timely and complete transmission thereof.
>>>
>>>
>>>
>>> _______________________________________________
>>>
>>> vrrp mailing list
>>>
>>> vrrp@ietf.org
>>>
>>> https://www.ietf.org/mailman/listinfo/vrrp
>>>
>>>
>>>
>>>
>>> Disclaimer :
>>> This email communication may contain privileged and confidential inform=
ation and is intended for the use of the addressee only.If you are not an i=
ntended recipient you are requested not to reproduce, copy disseminate or i=
n any manner distribute this email communication as the same is strictly pr=
ohibited. If you have received this email in error, please notify the sende=
r 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 t=
he proper, timely and complete transmission thereof.
>>> -------------- next part -------------- An HTML attachment was=20
>>> scrubbed...
>>> URL:
>>> >> c
>>> 4
>>> c7/attachment.htm>
>>>
>>> ------------------------------
>>>
>>> _______________________________________________
>>> vrrp mailing list
>>> vrrp@ietf.org
>>> https://www.ietf.org/mailman/listinfo/vrrp
>>>
>>>
>>> End of vrrp Digest, Vol 81, Issue 3
>>> ***********************************
>>
>> DISCLAIMER:
>> This e-mail and any attachments to it may contain confidential and propr=
ietary material and is solely for the use of the intended recipient. Any re=
view, use, disclosure, distribution or copying of this transmittal is prohi=
bited except by or on behalf of the intended recipient.  If you have receiv=
ed this transmittal in error, please notify the sender and destroy this e-m=
ail and any attachments and all copies, whether electronic or printed.
>> _______________________________________________
>> 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

DISCLAIMER:
This e-mail and any attachments to it may contain confidential and propriet=
ary material and is solely for the use of the intended recipient. Any revie=
w, use, disclosure, distribution or copying of this transmittal is prohibit=
ed except by or on behalf of the intended recipient.  If you have received =
this transmittal in error, please notify the sender and destroy this e-mail=
 and any attachments and all copies, whether electronic or printed.

From tperiyannan@extremenetworks.com  Mon Feb 25 07:07:45 2013
Return-Path: 
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 91E1721F9352 for ; Mon, 25 Feb 2013 07:07:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.932
X-Spam-Level: 
X-Spam-Status: No, score=-1.932 tagged_above=-999 required=5 tests=[AWL=-0.334, BAYES_00=-2.599, EXTRA_MPART_TYPE=1, HTML_MESSAGE=0.001]
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 EMTwr55hTcWO for ; Mon, 25 Feb 2013 07:07:43 -0800 (PST)
Received: from ussc-casht-p1.extremenetworks.com (ussc-casht-p1.extremenetworks.com [207.179.9.62]) by ietfa.amsl.com (Postfix) with ESMTP id D7FCB21F9325 for ; Mon, 25 Feb 2013 07:07:43 -0800 (PST)
Received: from USSC-CASHT-P3.corp.extremenetworks.com (10.0.4.78) by ussc-casht-p2.corp.extremenetworks.com (10.255.181.88) with Microsoft SMTP Server (TLS) id 8.3.297.1; Mon, 25 Feb 2013 07:07:43 -0800
Received: from inch-casht-p1.corp.extremenetworks.com (10.120.89.28) by ussc-casht-p3.corp.extremenetworks.com (10.0.4.78) with Microsoft SMTP Server (TLS) id 14.2.283.3; Mon, 25 Feb 2013 07:07:42 -0800
Received: from INEXCHANGE.corp.extremenetworks.com ([192.168.131.111]) by inch-casht-p1.corp.extremenetworks.com ([10.120.89.28]) with mapi; Mon, 25 Feb 2013 20:37:38 +0530
From: Thirumavalavan Periyannan 
To: "Anurag Kothari (ankothar)" , "vrrp@ietf.org" 
Date: Mon, 25 Feb 2013 20:37:37 +0530
Thread-Topic: [VRRP] vrrp Digest, Vol 81, Issue 3
Thread-Index: Ac4RBGKo4P5hWc5lTiSJPUEgi0SCSQADvuFgAA80cgAADFd4oP//qQAAgABMd9D//JbYQP/4vEBg
Message-ID: <617438426768D648ABBC00E677AA014902697FB19C66@INEXCHANGE.corp.extremenetworks.com>
References:  <14CA6619-DB7C-40ED-85E4-535CB689AC86@extremenetworks.com>    <91BD27DC-D555-49C7-8B40-F74F4D8B596F@extremenetworks.com>  
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: multipart/related; boundary="_004_617438426768D648ABBC00E677AA014902697FB19C66INEXCHANGEc_"; type="multipart/alternative"
MIME-Version: 1.0
Subject: Re: [VRRP] vrrp Digest, Vol 81, Issue 3
X-BeenThere: vrrp@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Virtual Router Redundancy Protocol  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 25 Feb 2013 15:07:45 -0000

--_004_617438426768D648ABBC00E677AA014902697FB19C66INEXCHANGEc_
Content-Type: multipart/alternative;
	boundary="_000_617438426768D648ABBC00E677AA014902697FB19C66INEXCHANGEc_"

--_000_617438426768D648ABBC00E677AA014902697FB19C66INEXCHANGEc_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable



Hi Anurag,



Sorry for the late response.



See the inline [Thiru]



Here, I have a question,



1.Do We have to configure priority Zero on Master router to do graceful fai=
lover?

Thanks & Regards,
Thirumavalavan Periyannan
Associate SQA Engineer  - VRRP Module Owner

[cid:image001.jpg@01CE1397.F2FD5080]


-----Original Message-----
From: Anurag Kothari (ankothar) [mailto:ankothar@cisco.com]
Sent: Saturday, February 23, 2013 12:57 AM
To: Thirumavalavan Periyannan; vrrp@ietf.org
Cc: Peter Hunt
Subject: RE: [VRRP] vrrp Digest, Vol 81, Issue 3



Hi Thirumavalavan



Here are couple of points:



1) With something like "disable vrrp" or "shutdown vrrp" it will not be gra=
ceful as the router will treat it as a shutdown event (which is a break bef=
ore you make approach) and the router will "Transition to the {Initialize} =
state". The backup router will wait for "Skew_Time"[Thiru]I think, it's Mas=
ter_Down_interval time. before it becomes master; So we probably will have =
traffic loss for a period approximately equal to "Skew_Time"[Thiru]I think,=
 it's Master_Down_interval time. Even with Default configuration this will =
be close to 609 ms which would be a duration long enough for to impact time=
 sensitive applications (e.g. voice calls). For sure the actual failover ti=
me will depend upon the size of the Network and the switches in between but=
 with the method proposed below we can try to improve that time.



2) This will also improve convergence in scenarios where we want the failov=
er to trigger because of up uplink interface from the router going down (tr=
acking interface and decrementing the priority).



I am not sure if you saw the modified proposal which was sent out today ear=
ly morning. Here is the link to it in case you need it http://www.ietf.org/=
mail-archive/web/vrrp/current/msg01489.html



Thanks

~Anurag





________________________________
DISCLAIMER:
This e-mail and any attachments to it may contain confidential and propriet=
ary material and is solely for the use of the intended recipient. Any revie=
w, use, disclosure, distribution or copying of this transmittal is prohibit=
ed except by or on behalf of the intended recipient. If you have received t=
his transmittal in error, please notify the sender and destroy this e-mail =
and any attachments and all copies, whether electronic or printed.

--_000_617438426768D648ABBC00E677AA014902697FB19C66INEXCHANGEc_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











 


Hi Anurag,


 


Sorry for the late =
response.


 


See the inline [Thi=
ru]


 


Here, I have a
question,


 


1.Do We have to configure priority Zero on Master router =
to do graceful failover?


=
 


Thank=
s & Regards,


Th=
irumavalavan Periyannan


Assoc=
iate SQA Engineer  - VRRP Module Owner


=
 


3D"Description:


 


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

From: Anurag Kothari (ankothar) [mailto:ankothar@cisco.com] 

Sent: Saturday, February 23, 2013 12:57 AM

To: Thirumavalavan Periyannan; vrrp@ietf.org

Cc: Peter Hunt

Subject: RE: [VRRP] vrrp Digest, Vol 81, Issue 3


 


Hi Thirumavalavan


 


Here are couple of points:


 


1) With something like "disable vrrp" o=
r "shutdown vrrp" it will not be graceful as the router will trea=
t it as a shutdown event (which is a break before you make approach) and th=
e router will "Transition to the {Initialize} state".
 The backup router will wait for "Skew_Time"[Thiru]I think, it’s Master_Down_interval time. be=
fore it becomes master; So we probably will have traffic loss for a period =
approximately equal to "Skew_Time"[T=
hiru]I
 think, it’s Master_Down_interval time. Even with Default =
configuration this will be close to 609 ms which would be a duration long e=
nough for to impact time sensitive applications (e.g. voice calls). For sur=
e the actual failover time will depend
 upon the size of the Network and the switches in between but with the meth=
od proposed below we can try to improve that time.


 


2) This will also improve convergence in scenario=
s where we want the failover to trigger because of up uplink interface from=
 the router going down (tracking interface and decrementing the priority).<=
o:p>


 


I am not sure if you saw the modified proposal wh=
ich was sent out today early morning. Here is the link to it in case you ne=
ed it
http://www.ietf.org/mai=
l-archive/web/vrrp/current/msg01489.html


 


Thanks


~Anurag


 


 







DISCLAIMER:

This e-mail and any attachments to it may contain confidential and propriet=
ary material and is solely for the use of the intended recipient. Any revie=
w, use, disclosure, distribution or copying of this transmittal is prohibit=
ed except by or on behalf of the
 intended recipient. If you have received this transmittal in error, please=
 notify the sender and destroy this e-mail and any attachments and all copi=
es, whether electronic or printed.





--_000_617438426768D648ABBC00E677AA014902697FB19C66INEXCHANGEc_--

--_004_617438426768D648ABBC00E677AA014902697FB19C66INEXCHANGEc_
Content-Type: image/jpeg; name="image001.jpg"
Content-Description: image001.jpg
Content-Disposition: inline; filename="image001.jpg"; size=3541;
	creation-date="Mon, 25 Feb 2013 15:07:38 GMT";
	modification-date="Mon, 25 Feb 2013 15:07:38 GMT"
Content-ID: 
Content-Transfer-Encoding: base64

/9j/4AAQSkZJRgABAQEAeAB4AAD/2wBDAAoHBwkHBgoJCAkLCwoMDxkQDw4ODx4WFxIZJCAmJSMg
IyIoLTkwKCo2KyIjMkQyNjs9QEBAJjBGS0U+Sjk/QD3/2wBDAQsLCw8NDx0QEB09KSMpPT09PT09
PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT3/wAARCABBALwDASIA
AhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQA
AAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3
ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWm
p6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEA
AwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSEx
BhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElK
U1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3
uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD2akLB
RkkAe9BIAyTgCuS13XLWzLFr2HKku0aPuEh/hGOq44NVGLk7IDppL+1hB8yeMYcRnnox7H0qpL4g
sYzgSFzvKEKMnjqfce4ry7UvEqNK32NpH4ysrKAWY/eLDv6A113w7itruwe9YK10rGMKTnyl9Bn1
rWVLljdiub39vM6F4rK4KqC7ZU5KDuPXPpVeLxnpraiLScyW7MBseZCoYn+H61y3inU7ePXpo7nV
NUt2jI2xxDao+nrWl/atrqHhzy7zT76+hEZH2h4uT75o9mrJ2A1/EHiC50Q+Y1rutHA23C8hD33D
0rDg+JP2iZVt7CackneiDJQDoR65pPAV/qN/bTWd5bm40sAhJpeoHpz1FaWpW6eFdDluPDmnJI7k
lnB3bR6+potGL5WtQLnhjXb3WY5RfWD2rx92BAb0xms7WvFeq6bqd1a22kyTohXy5QpwRjJqP4c6
vfavb6jJf3DTMkqhd3bINZmr61qlv8R4rNLmZLR54lEf8JBAzQoe+1YCe5+IeqQ7f+JE6bjhS5bk
+mMVTvPHviGCREbTlhZ/mVShYkfSuu8Y6udD0M3scKSTBwkW8ZCse9P8NXa6roltfTSR3FztO59o
BU/3aE4qPNygcQ3ijxnLF5i2rBM9VtqzX8WeJ5ZxB586yt0QIQx/CtDUNZtxq0rz6xrEc6SEbAMA
c9MV2mn6lDqNzaNJplz5mPluZIsdupNaNqKvygeby6x4q85Ua61FXfoi5GfwqC7ufEdtGTdy36Ie
SWzj8a7n4j6pd6Xb2T2UvkyO5BdRzjHTNbHhm6l1PwjbTXxE7vGd5cZ3fWj2loqVgPKoo9du4C8S
3skRHXBwRVKSS8il8uQzpJ/dYEE/hXZ+EvEOpXfi8W01wTbMWAiAwqgdABXokun2k90lxNbxPOgw
rsoJFOVXkdmgseJw6drU67ora8YYznYarT/b7VsXAuIj/tgiu58XanCmtyRXepana7MbUhG1ceo9
av2mr2t94fWG6sb/AFGAKR57w5JH19qftHZOwHmqahdxgiO5lUH0arMXiPWIMeVqdyuPR6rxx2j3
rpJK8UO8hW25KjPcV2Ph+x8LGNWmhmluVAPlSnJOTxtA6/Srk0lqhCeFfFviK+1KG32fbIGbDsU+
6O53V6fVPT2sFtl+wCFYiSAIwAMjrVyuKpJSeisUeReKrrxPPcyrqEdxFb5+VIgdmPXjrXKtG4OX
RwfVlNfQ1QSWNrN/rbaJ8/3kBraNeytYVj5+JA6nH1qxY6nc6bP51lcvDJ6o3Wvcn0LS5Dl9OtWI
9Ylpv/CPaR/0DbT/AL8rVfWF2Cx5SfHurOqiU2spXo0kQJqrf+LtV1JfLnu8Q94k+VT+Ar2D/hHt
I/6Btp/35Wj/AIR7SP8AoGWn/flalVoL7IWPIp/F2rz2P2QXHlwEbdsS7ePSrnhXxfdaFKILhZJ7
Bz8yEElfcf4V6qNG00AAWNtgf9MhUi6dZqAFtYQB0wgpOtFq3KFjkb3Sp4om1vwfPsEw3S24Hyye
4Hr7Vyz/ABA1wSnzFthIp53QjcK9eVFQYRQo9AMVQn0DTLm7+0zWcLTYKltvUH19amNRfaVwPItY
8XanrlkLW+aMxbg42pgkiqOm6zf6S5ewupIQfvAHg/hXrz+CtEkBD2gIyCBuPy47D2qOfwNok90Z
ja7Qc5RThST3xWqrQStYLHnh8easzh3W0dx/E0IJqufGWtNfR3T3hZo+VjP3B+FegXfgHQkt0Mga
JY8APnt6H1+tVz4M8OSu0cc20OdwG7kHtg+ntUPEUIuzCzOB1rxNqGvpEl+0ZERyu1cVZ0/xrq2m
aellbPEIYwVAZMnFdkPBOgIVAuNzBdrljwx7n2NQjwr4da5aMyyZQgq3Rdo/hPr9amWMwySTaCzO
B07VrnS9SF7alROMn5hkc+1aN/411m/eB3uRE8DFkaIbTk+vrXcHwZoIiVnkVY5SSmD0f2PoPSpG
8H+HYJGWRl3FArhm/Mj0NU8VQ3bCzOI/4TrWHjAl+zz7Od0kIYj8ahv/ABNrmpwPHLO6QgAtHENg
wenAr0OLw/oUaMzSRld4BGAMr2QjuPenpZaDFdwQQQq8u4skg+baT7+ntUPGYePYLM8rg0u5lY7Y
yz5wig8se5HrjvW7p+iXDbWjB2g/u2YYGB1YHqrE8AV6J9m0eMNH+6XjbhTgD1xjoTV2M2TrM0KR
uxAMgAGWx0zQ8ZB6JhY5vTdPuEmOMjgLJkYYDtGw9e5YV0yQ3CoNsoXPJVhux7A+lM/tSISrGyss
jEAA+9XaxVWNT4RhRRRTAKKKKACiiigAooooAKKKKACiiigCpqdkdQsngDhCxHJGazrnw79ogtYx
KqeSu1iF5atyisKmGpVW3Nb/APDjuYA8NEQ+SZIim7O4od386mXQTFfPNFJH5bjayMmePatmis1g
aC2QXMBfDC7ZVecsuD5Qx9zmlHhr5UkNxuuVbJdlyD7YreopfUMP/KF2YFz4ce7keWW4QSNj7iYX
H0qe40BJ5bYhwiQptYKuC341sUU/qVDX3dwuzAbw22CiToYg25VZMkfjVvTNHaxmkd5g4cY2gYFa
lFOGDowkpRWqC5EbaEuGMa7hjB+nSpaKK6UkthBXOzeKBa69cW1ygWzjUIsoGS0mMlfyroqzbPRo
reFhNtnlMzTB2XoxPH5DirjbqBm2HiWeSzuby7tvLjE5iijB+bAHU1LP4mg82xaOQJDKjSvuHzED
jAHrmo28LSrHAILxQ6I6yNJFu3bu4GeDTT4MgaNd8xaWGJEgk28xsDkt75NX7gi1J4ptogxeGYeW
AZuP9UD6+/tVzVbue10x7q0VZGTDlT3Xv+lZ7eGnN+8/2iJo5mV5keLJYgYODngH0rXvbZrmxlt4
38oyJsDYzgVL5bqwzGHiYzXEctvEzWTnZGdp3zv/ALI7AetXINft5/LUJIszzeS0TDDK3fPtTbnR
H8qxNjOtvPZLtjZk3KRjBBFVz4bmjaG4t73beq7vJK8e4OWAB4zx04p+6wJ7rxLa2zbfLmkfzzAF
jXJLDrin6zqdxZaSs1rCGupWVI4n/vMe9R6b4fNjcQTS3JmaJXzlcbnY5LfWrl5p/wBrvbOZpMJb
szlMfeJGB+VL3UwM0eJFeOzk+VEeN5Ljd1jC8EfXJpz+KYRa3LpBIJYofORGGN69B+tNm8JW81zq
MnmuovVHyj/lm3cj64FIfDcsmnTwyXMQnkK7ZUhwFCkHBGeQcU/cAlg8SRrZmW/ia3kSATOuOx7C
nyeJrNApUSSbo1cBFySW+6v1NJdeH1vr+3ubqbd5UexkVcK57H8PSoIPCwtdKggguiLqGXzhOy5y
3PUemD0o9wCeTxLbQW00txFNG8LKrRFct83THrVd/EoTUQkkbxosQbyiuZHZj8oA/CpY/DztdxXV
3dmaYS+ZKdmA2BhQB2A60k/hlJr+S/M2LzzhJHLt+4o/gx3HWj3ALOtanNp+iPdQw7rkgCOI92J6
VlS+LXl+xRWMKvLJIqXDt9yL+8Pc1uXtgb24tHaQqlvJ5hXH3zggfzqCfQrea5gZQscMfmExIuNz
OMEk+tKLjbUBkXiO2lmiUxyrDM5SKdlwrsP/ANRqrpniQzOBdwyIktw0UUm35SAePzpU8O3LRRw3
N+JIbfP2dRFgqcEAtzzgE02Dw1crbwW1xqPmwWynyVEe0hscFjnnFP3AEPiBlnjczL9nd5HZtv3Y
04x9Sa0NO1yHULkwCOSOTZ5ihx95fWqZ8LI9vJC85KNbiFcL905JLfiTVzSNKewMj3EkMsrAANHF
swB26mh8ttANOiiiswCiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoooo
AKKKKAP/2Q==

--_004_617438426768D648ABBC00E677AA014902697FB19C66INEXCHANGEc_--

From ankothar@cisco.com  Mon Feb 25 07:13:44 2013
Return-Path: 
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 B093621F84B6 for ; Mon, 25 Feb 2013 07:13:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.098
X-Spam-Level: 
X-Spam-Status: No, score=-10.098 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599, EXTRA_MPART_TYPE=1, 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 QUHPheRhPnIW for ; Mon, 25 Feb 2013 07:13:42 -0800 (PST)
Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 11F9221F9445 for ; Mon, 25 Feb 2013 07:13:42 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=20864; q=dns/txt; s=iport; t=1361805222; x=1363014822; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=ddKc8D0kJssjiFCrRWL83xaq8PBM8O4Xqmrp0jxXJhk=; b=DAiZI7cAE+FGLihJKrmEEjkhFr6Dg2Fl12UjYh22W+eCysHo4xo79HHH 9UOWkqAs5SHDk+uv1c0moPPfymaiEryhsImYxhgpiK3T9YSxW5jRo57xX dhSyAUAUjNOrB5QAiNOJnbPFLH/HgpyvSqNYPqn8aEzAxk7BBpIDiyogL Y=;
X-Files: image001.jpg : 3541
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgMFALJ+K1GtJXG9/2dsb2JhbABFgkO/EYEFFnOCHwEBAQQFIAgBVwQCAQgOAwICAQEGAQEBAggVBwIFEAEMAgwUCQgCBAERAQYCAQWIBQy+L400GYEQCA4QEQEGgllhA5BJAVKIbI0agweBcjU
X-IronPort-AV: E=Sophos;i="4.84,735,1355097600";  d="jpg'145?scan'145,208,217,145";a="180825544"
Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-2.cisco.com with ESMTP; 25 Feb 2013 15:13:41 +0000
Received: from xhc-aln-x12.cisco.com (xhc-aln-x12.cisco.com [173.36.12.86]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id r1PFDfw4027871 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 25 Feb 2013 15:13:41 GMT
Received: from xmb-rcd-x05.cisco.com ([169.254.15.93]) by xhc-aln-x12.cisco.com ([173.36.12.86]) with mapi id 14.02.0318.004; Mon, 25 Feb 2013 09:13:41 -0600
From: "Anurag Kothari (ankothar)" 
To: Thirumavalavan Periyannan , "vrrp@ietf.org" 
Thread-Topic: [VRRP] vrrp Digest, Vol 81, Issue 3
Thread-Index: Ac4RBGKo4P5hWc5lTiSJPUEgi0SCSQADvuFgAA80cgAADFd4oP//qQAAgABMd9D//JbYQP/4vEBg//F3tKA=
Date: Mon, 25 Feb 2013 15:13:40 +0000
Message-ID: 
References:  <14CA6619-DB7C-40ED-85E4-535CB689AC86@extremenetworks.com>    <91BD27DC-D555-49C7-8B40-F74F4D8B596F@extremenetworks.com>  <617438426768D648ABBC00E677AA014902697FB19C66@INEXCHANGE.corp.extremenetworks.com>
In-Reply-To: <617438426768D648ABBC00E677AA014902697FB19C66@INEXCHANGE.corp.extremenetworks.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
x-originating-ip: [10.82.240.69]
Content-Type: multipart/related; boundary="_004_A2BB90B33FFDF740876C5AAE307D83DB1C293C32xmbrcdx05ciscoc_"; type="multipart/alternative"
MIME-Version: 1.0
Subject: Re: [VRRP] vrrp Digest, Vol 81, Issue 3
X-BeenThere: vrrp@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Virtual Router Redundancy Protocol  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 25 Feb 2013 15:13:44 -0000

--_004_A2BB90B33FFDF740876C5AAE307D83DB1C293C32xmbrcdx05ciscoc_
Content-Type: multipart/alternative;
	boundary="_000_A2BB90B33FFDF740876C5AAE307D83DB1C293C32xmbrcdx05ciscoc_"

--_000_A2BB90B33FFDF740876C5AAE307D83DB1C293C32xmbrcdx05ciscoc_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi Thirumavalavan

The Master_Down_Timer is set to Skew_Time by the backup router on receiving=
 an ADVERTISEMENT with Priority =3D 0. That is why I said will have to wait=
 Skew_Time in the thread below. I am copy pasting the relevant section from=
 the RFC for easy reference:

(420) - If an ADVERTISEMENT is received, then:

   (425) + If the Priority in the ADVERTISEMENT is zero, then:

      (430) * Set the Master_Down_Timer to Skew_Time

   (440) + else // priority non-zero

Yes the Priority on the Master router will have to be set to zero to initia=
te a graceful failover.

Thanks
-Anurag

From: Thirumavalavan Periyannan [mailto:tperiyannan@extremenetworks.com]
Sent: Monday, February 25, 2013 10:08 AM
To: Anurag Kothari (ankothar); vrrp@ietf.org
Subject: RE: [VRRP] vrrp Digest, Vol 81, Issue 3



Hi Anurag,



Sorry for the late response.



See the inline [Thiru]



Here, I have a question,



1.Do We have to configure priority Zero on Master router to do graceful fai=
lover?

Thanks & Regards,
Thirumavalavan Periyannan
Associate SQA Engineer  - VRRP Module Owner

[Description: Description: Description: Description: Description: Descripti=
on: Description: Description: cid:image001.png@01CBF547.656FF3F0]


-----Original Message-----
From: Anurag Kothari (ankothar) [mailto:ankothar@cisco.com]
Sent: Saturday, February 23, 2013 12:57 AM
To: Thirumavalavan Periyannan; vrrp@ietf.org
Cc: Peter Hunt
Subject: RE: [VRRP] vrrp Digest, Vol 81, Issue 3



Hi Thirumavalavan



Here are couple of points:



1) With something like "disable vrrp" or "shutdown vrrp" it will not be gra=
ceful as the router will treat it as a shutdown event (which is a break bef=
ore you make approach) and the router will "Transition to the {Initialize} =
state". The backup router will wait for "Skew_Time"[Thiru]I think, it's Mas=
ter_Down_interval time. before it becomes master; So we probably will have =
traffic loss for a period approximately equal to "Skew_Time"[Thiru]I think,=
 it's Master_Down_interval time. Even with Default configuration this will =
be close to 609 ms which would be a duration long enough for to impact time=
 sensitive applications (e.g. voice calls). For sure the actual failover ti=
me will depend upon the size of the Network and the switches in between but=
 with the method proposed below we can try to improve that time.



2) This will also improve convergence in scenarios where we want the failov=
er to trigger because of up uplink interface from the router going down (tr=
acking interface and decrementing the priority).



I am not sure if you saw the modified proposal which was sent out today ear=
ly morning. Here is the link to it in case you need it http://www.ietf.org/=
mail-archive/web/vrrp/current/msg01489.html



Thanks

~Anurag





________________________________
DISCLAIMER:
This e-mail and any attachments to it may contain confidential and propriet=
ary material and is solely for the use of the intended recipient. Any revie=
w, use, disclosure, distribution or copying of this transmittal is prohibit=
ed except by or on behalf of the intended recipient. If you have received t=
his transmittal in error, please notify the sender and destroy this e-mail =
and any attachments and all copies, whether electronic or printed.

--_000_A2BB90B33FFDF740876C5AAE307D83DB1C293C32xmbrcdx05ciscoc_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











Hi Thirumavalavan=



 


The Master_Down_Timer =
is set to Skew_Time by the backup router on receiving an ADVERTISEMENT with=
 Priority =3D 0. That is why I said will have to wait Skew_Time in the thre=
ad below. I am copy pasting the relevant
 section from the RFC for easy reference:


 


=
(420) - If an ADVERTISEMENT is received, then:


=
 


=
   (425) + If the Priority in the ADVERTISEMENT is zero, then=
:


=
 


=
      (430) * Set the Master_Down_Timer to Skew_Ti=
me


=
 


=
   (440) + else // priority non-zero


 


Yes the Priority on th=
e Master router will have to be set to zero to initiate a graceful failover=
.


 


Thanks


-Anurag


 






From: Thirumav=
alavan Periyannan [mailto:tperiyannan@extremenetworks.com]


Sent: Monday, February 25, 2013 10:08 AM

To: Anurag Kothari (ankothar); vrrp@ietf.org

Subject: RE: [VRRP] vrrp Digest, Vol 81, Issue 3





 


 


Hi Anurag,


 


Sorry for the late =
response.


 


See the inline [Thi=
ru]


 


Here, I have a
question,


 


1.Do We have to configure priority Zero on Master router =
to do graceful failover?


=
 


Thank=
s & Regards,


Th=
irumavalavan Periyannan


Assoc=
iate SQA Engineer  - VRRP Module Owner


=
 


3D"Description:


 


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

From: Anurag Kothari (ankothar) [mail=
to:ankothar@cisco.com]


Sent: Saturday, February 23, 2013 12:57 AM

To: Thirumavalavan Periyannan; vrrp@ietf.o=
rg

Cc: Peter Hunt

Subject: RE: [VRRP] vrrp Digest, Vol 81, Issue 3


 


Hi Thirumavalavan


 


Here are couple of points:


 


1) With something like "disable vrrp" o=
r "shutdown vrrp" it will not be graceful as the router will trea=
t it as a shutdown event (which is a break before you make approach) and th=
e router will "Transition to the {Initialize} state".
 The backup router will wait for "Skew_Time"[Thiru]I think, it’s Master_Down_interval time. be=
fore it becomes master; So we probably will have traffic loss for a period =
approximately equal to "Skew_Time"[T=
hiru]I
 think, it’s Master_Down_interval time. Even with Default =
configuration this will be close to 609 ms which would be a duration long e=
nough for to impact time sensitive applications (e.g. voice calls). For sur=
e the actual failover time will depend
 upon the size of the Network and the switches in between but with the meth=
od proposed below we can try to improve that time.


 


2) This will also improve convergence in scenario=
s where we want the failover to trigger because of up uplink interface from=
 the router going down (tracking interface and decrementing the priority).<=
o:p>


 


I am not sure if you saw the modified proposal wh=
ich was sent out today early morning. Here is the link to it in case you ne=
ed it
http://www.ietf.org/mai=
l-archive/web/vrrp/current/msg01489.html


 


Thanks


~Anurag


 


 


 








DISCLAIMER:

This e-mail and any attachments to it may contain confidential and propriet=
ary material and is solely for the use of the intended recipient. Any revie=
w, use, disclosure, distribution or copying of this transmittal is prohibit=
ed except by or on behalf of the
 intended recipient. If you have received this transmittal in error, please=
 notify the sender and destroy this e-mail and any attachments and all copi=
es, whether electronic or printed.=







--_000_A2BB90B33FFDF740876C5AAE307D83DB1C293C32xmbrcdx05ciscoc_--

--_004_A2BB90B33FFDF740876C5AAE307D83DB1C293C32xmbrcdx05ciscoc_
Content-Type: image/jpeg; name="image001.jpg"
Content-Description: image001.jpg
Content-Disposition: inline; filename="image001.jpg"; size=3541;
	creation-date="Mon, 25 Feb 2013 15:13:39 GMT";
	modification-date="Mon, 25 Feb 2013 15:13:39 GMT"
Content-ID: 
Content-Transfer-Encoding: base64

/9j/4AAQSkZJRgABAQEAeAB4AAD/2wBDAAoHBwkHBgoJCAkLCwoMDxkQDw4ODx4WFxIZJCAmJSMg
IyIoLTkwKCo2KyIjMkQyNjs9QEBAJjBGS0U+Sjk/QD3/2wBDAQsLCw8NDx0QEB09KSMpPT09PT09
PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT3/wAARCABBALwDASIA
AhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQA
AAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3
ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWm
p6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEA
AwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSEx
BhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElK
U1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3
uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD2akLB
RkkAe9BIAyTgCuS13XLWzLFr2HKku0aPuEh/hGOq44NVGLk7IDppL+1hB8yeMYcRnnox7H0qpL4g
sYzgSFzvKEKMnjqfce4ry7UvEqNK32NpH4ysrKAWY/eLDv6A113w7itruwe9YK10rGMKTnyl9Bn1
rWVLljdiub39vM6F4rK4KqC7ZU5KDuPXPpVeLxnpraiLScyW7MBseZCoYn+H61y3inU7ePXpo7nV
NUt2jI2xxDao+nrWl/atrqHhzy7zT76+hEZH2h4uT75o9mrJ2A1/EHiC50Q+Y1rutHA23C8hD33D
0rDg+JP2iZVt7CackneiDJQDoR65pPAV/qN/bTWd5bm40sAhJpeoHpz1FaWpW6eFdDluPDmnJI7k
lnB3bR6+potGL5WtQLnhjXb3WY5RfWD2rx92BAb0xms7WvFeq6bqd1a22kyTohXy5QpwRjJqP4c6
vfavb6jJf3DTMkqhd3bINZmr61qlv8R4rNLmZLR54lEf8JBAzQoe+1YCe5+IeqQ7f+JE6bjhS5bk
+mMVTvPHviGCREbTlhZ/mVShYkfSuu8Y6udD0M3scKSTBwkW8ZCse9P8NXa6roltfTSR3FztO59o
BU/3aE4qPNygcQ3ijxnLF5i2rBM9VtqzX8WeJ5ZxB586yt0QIQx/CtDUNZtxq0rz6xrEc6SEbAMA
c9MV2mn6lDqNzaNJplz5mPluZIsdupNaNqKvygeby6x4q85Ua61FXfoi5GfwqC7ufEdtGTdy36Ie
SWzj8a7n4j6pd6Xb2T2UvkyO5BdRzjHTNbHhm6l1PwjbTXxE7vGd5cZ3fWj2loqVgPKoo9du4C8S
3skRHXBwRVKSS8il8uQzpJ/dYEE/hXZ+EvEOpXfi8W01wTbMWAiAwqgdABXokun2k90lxNbxPOgw
rsoJFOVXkdmgseJw6drU67ora8YYznYarT/b7VsXAuIj/tgiu58XanCmtyRXepana7MbUhG1ceo9
av2mr2t94fWG6sb/AFGAKR57w5JH19qftHZOwHmqahdxgiO5lUH0arMXiPWIMeVqdyuPR6rxx2j3
rpJK8UO8hW25KjPcV2Ph+x8LGNWmhmluVAPlSnJOTxtA6/Srk0lqhCeFfFviK+1KG32fbIGbDsU+
6O53V6fVPT2sFtl+wCFYiSAIwAMjrVyuKpJSeisUeReKrrxPPcyrqEdxFb5+VIgdmPXjrXKtG4OX
RwfVlNfQ1QSWNrN/rbaJ8/3kBraNeytYVj5+JA6nH1qxY6nc6bP51lcvDJ6o3Wvcn0LS5Dl9OtWI
9Ylpv/CPaR/0DbT/AL8rVfWF2Cx5SfHurOqiU2spXo0kQJqrf+LtV1JfLnu8Q94k+VT+Ar2D/hHt
I/6Btp/35Wj/AIR7SP8AoGWn/flalVoL7IWPIp/F2rz2P2QXHlwEbdsS7ePSrnhXxfdaFKILhZJ7
Bz8yEElfcf4V6qNG00AAWNtgf9MhUi6dZqAFtYQB0wgpOtFq3KFjkb3Sp4om1vwfPsEw3S24Hyye
4Hr7Vyz/ABA1wSnzFthIp53QjcK9eVFQYRQo9AMVQn0DTLm7+0zWcLTYKltvUH19amNRfaVwPItY
8XanrlkLW+aMxbg42pgkiqOm6zf6S5ewupIQfvAHg/hXrz+CtEkBD2gIyCBuPy47D2qOfwNok90Z
ja7Qc5RThST3xWqrQStYLHnh8easzh3W0dx/E0IJqufGWtNfR3T3hZo+VjP3B+FegXfgHQkt0Mga
JY8APnt6H1+tVz4M8OSu0cc20OdwG7kHtg+ntUPEUIuzCzOB1rxNqGvpEl+0ZERyu1cVZ0/xrq2m
aellbPEIYwVAZMnFdkPBOgIVAuNzBdrljwx7n2NQjwr4da5aMyyZQgq3Rdo/hPr9amWMwySTaCzO
B07VrnS9SF7alROMn5hkc+1aN/411m/eB3uRE8DFkaIbTk+vrXcHwZoIiVnkVY5SSmD0f2PoPSpG
8H+HYJGWRl3FArhm/Mj0NU8VQ3bCzOI/4TrWHjAl+zz7Od0kIYj8ahv/ABNrmpwPHLO6QgAtHENg
wenAr0OLw/oUaMzSRld4BGAMr2QjuPenpZaDFdwQQQq8u4skg+baT7+ntUPGYePYLM8rg0u5lY7Y
yz5wig8se5HrjvW7p+iXDbWjB2g/u2YYGB1YHqrE8AV6J9m0eMNH+6XjbhTgD1xjoTV2M2TrM0KR
uxAMgAGWx0zQ8ZB6JhY5vTdPuEmOMjgLJkYYDtGw9e5YV0yQ3CoNsoXPJVhux7A+lM/tSISrGyss
jEAA+9XaxVWNT4RhRRRTAKKKKACiiigAooooAKKKKACiiigCpqdkdQsngDhCxHJGazrnw79ogtYx
KqeSu1iF5atyisKmGpVW3Nb/APDjuYA8NEQ+SZIim7O4od386mXQTFfPNFJH5bjayMmePatmis1g
aC2QXMBfDC7ZVecsuD5Qx9zmlHhr5UkNxuuVbJdlyD7YreopfUMP/KF2YFz4ce7keWW4QSNj7iYX
H0qe40BJ5bYhwiQptYKuC341sUU/qVDX3dwuzAbw22CiToYg25VZMkfjVvTNHaxmkd5g4cY2gYFa
lFOGDowkpRWqC5EbaEuGMa7hjB+nSpaKK6UkthBXOzeKBa69cW1ygWzjUIsoGS0mMlfyroqzbPRo
reFhNtnlMzTB2XoxPH5DirjbqBm2HiWeSzuby7tvLjE5iijB+bAHU1LP4mg82xaOQJDKjSvuHzED
jAHrmo28LSrHAILxQ6I6yNJFu3bu4GeDTT4MgaNd8xaWGJEgk28xsDkt75NX7gi1J4ptogxeGYeW
AZuP9UD6+/tVzVbue10x7q0VZGTDlT3Xv+lZ7eGnN+8/2iJo5mV5keLJYgYODngH0rXvbZrmxlt4
38oyJsDYzgVL5bqwzGHiYzXEctvEzWTnZGdp3zv/ALI7AetXINft5/LUJIszzeS0TDDK3fPtTbnR
H8qxNjOtvPZLtjZk3KRjBBFVz4bmjaG4t73beq7vJK8e4OWAB4zx04p+6wJ7rxLa2zbfLmkfzzAF
jXJLDrin6zqdxZaSs1rCGupWVI4n/vMe9R6b4fNjcQTS3JmaJXzlcbnY5LfWrl5p/wBrvbOZpMJb
szlMfeJGB+VL3UwM0eJFeOzk+VEeN5Ljd1jC8EfXJpz+KYRa3LpBIJYofORGGN69B+tNm8JW81zq
MnmuovVHyj/lm3cj64FIfDcsmnTwyXMQnkK7ZUhwFCkHBGeQcU/cAlg8SRrZmW/ia3kSATOuOx7C
nyeJrNApUSSbo1cBFySW+6v1NJdeH1vr+3ubqbd5UexkVcK57H8PSoIPCwtdKggguiLqGXzhOy5y
3PUemD0o9wCeTxLbQW00txFNG8LKrRFct83THrVd/EoTUQkkbxosQbyiuZHZj8oA/CpY/DztdxXV
3dmaYS+ZKdmA2BhQB2A60k/hlJr+S/M2LzzhJHLt+4o/gx3HWj3ALOtanNp+iPdQw7rkgCOI92J6
VlS+LXl+xRWMKvLJIqXDt9yL+8Pc1uXtgb24tHaQqlvJ5hXH3zggfzqCfQrea5gZQscMfmExIuNz
OMEk+tKLjbUBkXiO2lmiUxyrDM5SKdlwrsP/ANRqrpniQzOBdwyIktw0UUm35SAePzpU8O3LRRw3
N+JIbfP2dRFgqcEAtzzgE02Dw1crbwW1xqPmwWynyVEe0hscFjnnFP3AEPiBlnjczL9nd5HZtv3Y
04x9Sa0NO1yHULkwCOSOTZ5ihx95fWqZ8LI9vJC85KNbiFcL905JLfiTVzSNKewMj3EkMsrAANHF
swB26mh8ttANOiiiswCiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoooo
AKKKKAP/2Q==

--_004_A2BB90B33FFDF740876C5AAE307D83DB1C293C32xmbrcdx05ciscoc_--

From tperiyannan@extremenetworks.com  Mon Feb 25 08:19:35 2013
Return-Path: 
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 D8D1321F9505 for ; Mon, 25 Feb 2013 08:19:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.848
X-Spam-Level: 
X-Spam-Status: No, score=-1.848 tagged_above=-999 required=5 tests=[AWL=-0.250, BAYES_00=-2.599, EXTRA_MPART_TYPE=1, HTML_MESSAGE=0.001]
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 D0UpEZtyoW1D for ; Mon, 25 Feb 2013 08:19:28 -0800 (PST)
Received: from ussc-casht-p1.extremenetworks.com (ussc-casht-p1.extremenetworks.com [207.179.9.62]) by ietfa.amsl.com (Postfix) with ESMTP id 28DAA21F9524 for ; Mon, 25 Feb 2013 08:19:28 -0800 (PST)
Received: from inch-casht-p1.corp.extremenetworks.com (10.120.89.28) by ussc-casht-p2.corp.extremenetworks.com (10.255.181.88) with Microsoft SMTP Server (TLS) id 8.3.297.1; Mon, 25 Feb 2013 08:19:28 -0800
Received: from INEXCHANGE.corp.extremenetworks.com ([192.168.131.111]) by inch-casht-p1.corp.extremenetworks.com ([10.120.89.28]) with mapi; Mon, 25 Feb 2013 21:49:24 +0530
From: Thirumavalavan Periyannan 
To: "Anurag Kothari (ankothar)" , "vrrp@ietf.org" 
Date: Mon, 25 Feb 2013 21:49:21 +0530
Thread-Topic: [VRRP] vrrp Digest, Vol 81, Issue 3
Thread-Index: Ac4RBGKo4P5hWc5lTiSJPUEgi0SCSQADvuFgAA80cgAADFd4oP//qQAAgABMd9D//JbYQP/4vEBg//F3tKD/4t/KMA==
Message-ID: <617438426768D648ABBC00E677AA014902697FB19C70@INEXCHANGE.corp.extremenetworks.com>
References:  <14CA6619-DB7C-40ED-85E4-535CB689AC86@extremenetworks.com>    <91BD27DC-D555-49C7-8B40-F74F4D8B596F@extremenetworks.com>  <617438426768D648ABBC00E677AA014902697FB19C66@INEXCHANGE.corp.extremenetworks.com> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: multipart/related; boundary="_004_617438426768D648ABBC00E677AA014902697FB19C70INEXCHANGEc_"; type="multipart/alternative"
MIME-Version: 1.0
Subject: Re: [VRRP] vrrp Digest, Vol 81, Issue 3
X-BeenThere: vrrp@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Virtual Router Redundancy Protocol  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 25 Feb 2013 16:19:36 -0000

--_004_617438426768D648ABBC00E677AA014902697FB19C70INEXCHANGEc_
Content-Type: multipart/alternative;
	boundary="_000_617438426768D648ABBC00E677AA014902697FB19C70INEXCHANGEc_"

--_000_617438426768D648ABBC00E677AA014902697FB19C70INEXCHANGEc_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Yes Anurag, I agree that backup router will reset Master_Down_timer value a=
s Skew_Time and
It will be become master when Master_Down_timer fired and will send VRRP Ad=
vertisements with their own priority.

After VRRP Master elected, What could be the VRRP state of priority ZERO co=
nfigured router? Is it Backup?

Thanks & Regards,
Thirumavalavan Periyannan
Associate SQA Engineer  - VRRP Module Owner

[cid:image001.jpg@01CE13A0.CD29B200]

From: Anurag Kothari (ankothar) [mailto:ankothar@cisco.com]
Sent: Monday, February 25, 2013 8:44 PM
To: Thirumavalavan Periyannan; vrrp@ietf.org
Subject: RE: [VRRP] vrrp Digest, Vol 81, Issue 3

Hi Thirumavalavan

The Master_Down_Timer is set to Skew_Time by the backup router on receiving=
 an ADVERTISEMENT with Priority =3D 0. That is why I said will have to wait=
 Skew_Time in the thread below. I am copy pasting the relevant section from=
 the RFC for easy reference:

(420) - If an ADVERTISEMENT is received, then:

   (425) + If the Priority in the ADVERTISEMENT is zero, then:

      (430) * Set the Master_Down_Timer to Skew_Time

   (440) + else // priority non-zero

Yes the Priority on the Master router will have to be set to zero to initia=
te a graceful failover.

Thanks
-Anurag

From: Thirumavalavan Periyannan [mailto:tperiyannan@extremenetworks.com]
Sent: Monday, February 25, 2013 10:08 AM
To: Anurag Kothari (ankothar); vrrp@ietf.org
Subject: RE: [VRRP] vrrp Digest, Vol 81, Issue 3



Hi Anurag,



Sorry for the late response.



See the inline [Thiru]



Here, I have a question,



1.Do We have to configure priority Zero on Master router to do graceful fai=
lover?

Thanks & Regards,
Thirumavalavan Periyannan
Associate SQA Engineer  - VRRP Module Owner

[cid:image001.jpg@01CE13A0.CD29B200]


-----Original Message-----
From: Anurag Kothari (ankothar) [mailto:ankothar@cisco.com]
Sent: Saturday, February 23, 2013 12:57 AM
To: Thirumavalavan Periyannan; vrrp@ietf.org
Cc: Peter Hunt
Subject: RE: [VRRP] vrrp Digest, Vol 81, Issue 3



Hi Thirumavalavan



Here are couple of points:



1) With something like "disable vrrp" or "shutdown vrrp" it will not be gra=
ceful as the router will treat it as a shutdown event (which is a break bef=
ore you make approach) and the router will "Transition to the {Initialize} =
state". The backup router will wait for "Skew_Time"[Thiru]I think, it's Mas=
ter_Down_interval time. before it becomes master; So we probably will have =
traffic loss for a period approximately equal to "Skew_Time"[Thiru]I think,=
 it's Master_Down_interval time. Even with Default configuration this will =
be close to 609 ms which would be a duration long enough for to impact time=
 sensitive applications (e.g. voice calls). For sure the actual failover ti=
me will depend upon the size of the Network and the switches in between but=
 with the method proposed below we can try to improve that time.



2) This will also improve convergence in scenarios where we want the failov=
er to trigger because of up uplink interface from the router going down (tr=
acking interface and decrementing the priority).



I am not sure if you saw the modified proposal which was sent out today ear=
ly morning. Here is the link to it in case you need it http://www.ietf.org/=
mail-archive/web/vrrp/current/msg01489.html



Thanks

~Anurag





________________________________
DISCLAIMER:
This e-mail and any attachments to it may contain confidential and propriet=
ary material and is solely for the use of the intended recipient. Any revie=
w, use, disclosure, distribution or copying of this transmittal is prohibit=
ed except by or on behalf of the intended recipient. If you have received t=
his transmittal in error, please notify the sender and destroy this e-mail =
and any attachments and all copies, whether electronic or printed.

________________________________
DISCLAIMER:
This e-mail and any attachments to it may contain confidential and propriet=
ary material and is solely for the use of the intended recipient. Any revie=
w, use, disclosure, distribution or copying of this transmittal is prohibit=
ed except by or on behalf of the intended recipient. If you have received t=
his transmittal in error, please notify the sender and destroy this e-mail =
and any attachments and all copies, whether electronic or printed.

--_000_617438426768D648ABBC00E677AA014902697FB19C70INEXCHANGEc_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











Yes Anurag, I agree that backup router will reset Master_Down_t=
imer value as Skew_Time and



It will be become master when Master_Down_timer fired and will =
send VRRP Advertisements with their own priority.


 


After VRRP Master elected, What could be the VRRP state of prio=
rity ZERO configured router? Is it Backup?


 


Thank=
s & Regards,


Th=
irumavalavan Periyannan


Assoc=
iate SQA Engineer  - VRRP Module Owner


=
 




 






From: Anurag K=
othari (ankothar) [mailto:ankothar@cisco.com]


Sent: Monday, February 25, 2013 8:44 PM

To: Thirumavalavan Periyannan; vrrp@ietf.org

Subject: RE: [VRRP] vrrp Digest, Vol 81, Issue 3





 


Hi Thirumavalavan=



 


The Master_Down_Timer =
is set to Skew_Time by the backup router on receiving an ADVERTISEMENT with=
 Priority =3D 0. That is why I said will have to wait Skew_Time in the thre=
ad below. I am copy pasting the relevant
 section from the RFC for easy reference:


 


=
(420) - If an ADVERTISEMENT is received, then:


=
 


=
   (425) + If the Priority in the ADVERTISEMENT is zero, then=
:


=
 


=
      (430) * Set the Master_Down_Timer to Skew_Ti=
me


=
 


=
   (440) + else // priority non-zero


 


Yes the Priority on th=
e Master router will have to be set to zero to initiate a graceful failover=
.


 


Thanks


-Anurag


 






From: Thirumav=
alavan Periyannan [mailto:tperiyannan@extremenetworks.com]


Sent: Monday, February 25, 2013 10:08 AM

To: Anurag Kothari (ankothar); vrrp@ietf.org

Subject: RE: [VRRP] vrrp Digest, Vol 81, Issue 3





 


 


Hi Anurag,


 


Sorry for the late =
response.


 


See the inline [Thi=
ru]


 


Here, I have a
question,


 


1.Do We have to configure priority Zero on Master router =
to do graceful failover?


=
 


Thank=
s & Regards,


Th=
irumavalavan Periyannan


Assoc=
iate SQA Engineer  - VRRP Module Owner


=
 


3D"Description:


 


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

From: Anurag Kothari (ankothar) [mail=
to:ankothar@cisco.com]


Sent: Saturday, February 23, 2013 12:57 AM

To: Thirumavalavan Periyannan; vrrp@ietf.o=
rg

Cc: Peter Hunt

Subject: RE: [VRRP] vrrp Digest, Vol 81, Issue 3


 


Hi Thirumavalavan


 


Here are couple of points:


 


1) With something like "disable vrrp" o=
r "shutdown vrrp" it will not be graceful as the router will trea=
t it as a shutdown event (which is a break before you make approach) and th=
e router will "Transition to the {Initialize} state".
 The backup router will wait for "Skew_Time"[Thiru]I think, it’s Master_Down_interval time. be=
fore it becomes master; So we probably will have traffic loss for a period =
approximately equal to "Skew_Time"[T=
hiru]I
 think, it’s Master_Down_interval time. Even with Default =
configuration this will be close to 609 ms which would be a duration long e=
nough for to impact time sensitive applications (e.g. voice calls). For sur=
e the actual failover time will depend
 upon the size of the Network and the switches in between but with the meth=
od proposed below we can try to improve that time.


 


2) This will also improve convergence in scenario=
s where we want the failover to trigger because of up uplink interface from=
 the router going down (tracking interface and decrementing the priority).<=
o:p>


 


I am not sure if you saw the modified proposal wh=
ich was sent out today early morning. Here is the link to it in case you ne=
ed it
http://www.ietf.org/mai=
l-archive/web/vrrp/current/msg01489.html


 


Thanks


~Anurag


 


 


 








DISCLAIMER:

This e-mail and any attachments to it may contain confidential and propriet=
ary material and is solely for the use of the intended recipient. Any revie=
w, use, disclosure, distribution or copying of this transmittal is prohibit=
ed except by or on behalf of the
 intended recipient. If you have received this transmittal in error, please=
 notify the sender and destroy this e-mail and any attachments and all copi=
es, whether electronic or printed.=








DISCLAIMER:

This e-mail and any attachments to it may contain confidential and propriet=
ary material and is solely for the use of the intended recipient. Any revie=
w, use, disclosure, distribution or copying of this transmittal is prohibit=
ed except by or on behalf of the
 intended recipient. If you have received this transmittal in error, please=
 notify the sender and destroy this e-mail and any attachments and all copi=
es, whether electronic or printed.





--_000_617438426768D648ABBC00E677AA014902697FB19C70INEXCHANGEc_--

--_004_617438426768D648ABBC00E677AA014902697FB19C70INEXCHANGEc_
Content-Type: image/jpeg; name="image001.jpg"
Content-Description: image001.jpg
Content-Disposition: inline; filename="image001.jpg"; size=3541;
	creation-date="Mon, 25 Feb 2013 16:19:22 GMT";
	modification-date="Mon, 25 Feb 2013 16:19:22 GMT"
Content-ID: 
Content-Transfer-Encoding: base64

/9j/4AAQSkZJRgABAQEAeAB4AAD/2wBDAAoHBwkHBgoJCAkLCwoMDxkQDw4ODx4WFxIZJCAmJSMg
IyIoLTkwKCo2KyIjMkQyNjs9QEBAJjBGS0U+Sjk/QD3/2wBDAQsLCw8NDx0QEB09KSMpPT09PT09
PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT3/wAARCABBALwDASIA
AhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQA
AAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3
ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWm
p6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEA
AwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSEx
BhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElK
U1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3
uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD2akLB
RkkAe9BIAyTgCuS13XLWzLFr2HKku0aPuEh/hGOq44NVGLk7IDppL+1hB8yeMYcRnnox7H0qpL4g
sYzgSFzvKEKMnjqfce4ry7UvEqNK32NpH4ysrKAWY/eLDv6A113w7itruwe9YK10rGMKTnyl9Bn1
rWVLljdiub39vM6F4rK4KqC7ZU5KDuPXPpVeLxnpraiLScyW7MBseZCoYn+H61y3inU7ePXpo7nV
NUt2jI2xxDao+nrWl/atrqHhzy7zT76+hEZH2h4uT75o9mrJ2A1/EHiC50Q+Y1rutHA23C8hD33D
0rDg+JP2iZVt7CackneiDJQDoR65pPAV/qN/bTWd5bm40sAhJpeoHpz1FaWpW6eFdDluPDmnJI7k
lnB3bR6+potGL5WtQLnhjXb3WY5RfWD2rx92BAb0xms7WvFeq6bqd1a22kyTohXy5QpwRjJqP4c6
vfavb6jJf3DTMkqhd3bINZmr61qlv8R4rNLmZLR54lEf8JBAzQoe+1YCe5+IeqQ7f+JE6bjhS5bk
+mMVTvPHviGCREbTlhZ/mVShYkfSuu8Y6udD0M3scKSTBwkW8ZCse9P8NXa6roltfTSR3FztO59o
BU/3aE4qPNygcQ3ijxnLF5i2rBM9VtqzX8WeJ5ZxB586yt0QIQx/CtDUNZtxq0rz6xrEc6SEbAMA
c9MV2mn6lDqNzaNJplz5mPluZIsdupNaNqKvygeby6x4q85Ua61FXfoi5GfwqC7ufEdtGTdy36Ie
SWzj8a7n4j6pd6Xb2T2UvkyO5BdRzjHTNbHhm6l1PwjbTXxE7vGd5cZ3fWj2loqVgPKoo9du4C8S
3skRHXBwRVKSS8il8uQzpJ/dYEE/hXZ+EvEOpXfi8W01wTbMWAiAwqgdABXokun2k90lxNbxPOgw
rsoJFOVXkdmgseJw6drU67ora8YYznYarT/b7VsXAuIj/tgiu58XanCmtyRXepana7MbUhG1ceo9
av2mr2t94fWG6sb/AFGAKR57w5JH19qftHZOwHmqahdxgiO5lUH0arMXiPWIMeVqdyuPR6rxx2j3
rpJK8UO8hW25KjPcV2Ph+x8LGNWmhmluVAPlSnJOTxtA6/Srk0lqhCeFfFviK+1KG32fbIGbDsU+
6O53V6fVPT2sFtl+wCFYiSAIwAMjrVyuKpJSeisUeReKrrxPPcyrqEdxFb5+VIgdmPXjrXKtG4OX
RwfVlNfQ1QSWNrN/rbaJ8/3kBraNeytYVj5+JA6nH1qxY6nc6bP51lcvDJ6o3Wvcn0LS5Dl9OtWI
9Ylpv/CPaR/0DbT/AL8rVfWF2Cx5SfHurOqiU2spXo0kQJqrf+LtV1JfLnu8Q94k+VT+Ar2D/hHt
I/6Btp/35Wj/AIR7SP8AoGWn/flalVoL7IWPIp/F2rz2P2QXHlwEbdsS7ePSrnhXxfdaFKILhZJ7
Bz8yEElfcf4V6qNG00AAWNtgf9MhUi6dZqAFtYQB0wgpOtFq3KFjkb3Sp4om1vwfPsEw3S24Hyye
4Hr7Vyz/ABA1wSnzFthIp53QjcK9eVFQYRQo9AMVQn0DTLm7+0zWcLTYKltvUH19amNRfaVwPItY
8XanrlkLW+aMxbg42pgkiqOm6zf6S5ewupIQfvAHg/hXrz+CtEkBD2gIyCBuPy47D2qOfwNok90Z
ja7Qc5RThST3xWqrQStYLHnh8easzh3W0dx/E0IJqufGWtNfR3T3hZo+VjP3B+FegXfgHQkt0Mga
JY8APnt6H1+tVz4M8OSu0cc20OdwG7kHtg+ntUPEUIuzCzOB1rxNqGvpEl+0ZERyu1cVZ0/xrq2m
aellbPEIYwVAZMnFdkPBOgIVAuNzBdrljwx7n2NQjwr4da5aMyyZQgq3Rdo/hPr9amWMwySTaCzO
B07VrnS9SF7alROMn5hkc+1aN/411m/eB3uRE8DFkaIbTk+vrXcHwZoIiVnkVY5SSmD0f2PoPSpG
8H+HYJGWRl3FArhm/Mj0NU8VQ3bCzOI/4TrWHjAl+zz7Od0kIYj8ahv/ABNrmpwPHLO6QgAtHENg
wenAr0OLw/oUaMzSRld4BGAMr2QjuPenpZaDFdwQQQq8u4skg+baT7+ntUPGYePYLM8rg0u5lY7Y
yz5wig8se5HrjvW7p+iXDbWjB2g/u2YYGB1YHqrE8AV6J9m0eMNH+6XjbhTgD1xjoTV2M2TrM0KR
uxAMgAGWx0zQ8ZB6JhY5vTdPuEmOMjgLJkYYDtGw9e5YV0yQ3CoNsoXPJVhux7A+lM/tSISrGyss
jEAA+9XaxVWNT4RhRRRTAKKKKACiiigAooooAKKKKACiiigCpqdkdQsngDhCxHJGazrnw79ogtYx
KqeSu1iF5atyisKmGpVW3Nb/APDjuYA8NEQ+SZIim7O4od386mXQTFfPNFJH5bjayMmePatmis1g
aC2QXMBfDC7ZVecsuD5Qx9zmlHhr5UkNxuuVbJdlyD7YreopfUMP/KF2YFz4ce7keWW4QSNj7iYX
H0qe40BJ5bYhwiQptYKuC341sUU/qVDX3dwuzAbw22CiToYg25VZMkfjVvTNHaxmkd5g4cY2gYFa
lFOGDowkpRWqC5EbaEuGMa7hjB+nSpaKK6UkthBXOzeKBa69cW1ygWzjUIsoGS0mMlfyroqzbPRo
reFhNtnlMzTB2XoxPH5DirjbqBm2HiWeSzuby7tvLjE5iijB+bAHU1LP4mg82xaOQJDKjSvuHzED
jAHrmo28LSrHAILxQ6I6yNJFu3bu4GeDTT4MgaNd8xaWGJEgk28xsDkt75NX7gi1J4ptogxeGYeW
AZuP9UD6+/tVzVbue10x7q0VZGTDlT3Xv+lZ7eGnN+8/2iJo5mV5keLJYgYODngH0rXvbZrmxlt4
38oyJsDYzgVL5bqwzGHiYzXEctvEzWTnZGdp3zv/ALI7AetXINft5/LUJIszzeS0TDDK3fPtTbnR
H8qxNjOtvPZLtjZk3KRjBBFVz4bmjaG4t73beq7vJK8e4OWAB4zx04p+6wJ7rxLa2zbfLmkfzzAF
jXJLDrin6zqdxZaSs1rCGupWVI4n/vMe9R6b4fNjcQTS3JmaJXzlcbnY5LfWrl5p/wBrvbOZpMJb
szlMfeJGB+VL3UwM0eJFeOzk+VEeN5Ljd1jC8EfXJpz+KYRa3LpBIJYofORGGN69B+tNm8JW81zq
MnmuovVHyj/lm3cj64FIfDcsmnTwyXMQnkK7ZUhwFCkHBGeQcU/cAlg8SRrZmW/ia3kSATOuOx7C
nyeJrNApUSSbo1cBFySW+6v1NJdeH1vr+3ubqbd5UexkVcK57H8PSoIPCwtdKggguiLqGXzhOy5y
3PUemD0o9wCeTxLbQW00txFNG8LKrRFct83THrVd/EoTUQkkbxosQbyiuZHZj8oA/CpY/DztdxXV
3dmaYS+ZKdmA2BhQB2A60k/hlJr+S/M2LzzhJHLt+4o/gx3HWj3ALOtanNp+iPdQw7rkgCOI92J6
VlS+LXl+xRWMKvLJIqXDt9yL+8Pc1uXtgb24tHaQqlvJ5hXH3zggfzqCfQrea5gZQscMfmExIuNz
OMEk+tKLjbUBkXiO2lmiUxyrDM5SKdlwrsP/ANRqrpniQzOBdwyIktw0UUm35SAePzpU8O3LRRw3
N+JIbfP2dRFgqcEAtzzgE02Dw1crbwW1xqPmwWynyVEe0hscFjnnFP3AEPiBlnjczL9nd5HZtv3Y
04x9Sa0NO1yHULkwCOSOTZ5ihx95fWqZ8LI9vJC85KNbiFcL905JLfiTVzSNKewMj3EkMsrAANHF
swB26mh8ttANOiiiswCiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoooo
AKKKKAP/2Q==

--_004_617438426768D648ABBC00E677AA014902697FB19C70INEXCHANGEc_--

From ankothar@cisco.com  Mon Feb 25 08:25:02 2013
Return-Path: 
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 D49BF21F9560 for ; Mon, 25 Feb 2013 08:25:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.055
X-Spam-Level: 
X-Spam-Status: No, score=-10.055 tagged_above=-999 required=5 tests=[AWL=-0.457, BAYES_00=-2.599, EXTRA_MPART_TYPE=1, 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 HizRKOZ+SKAK for ; Mon, 25 Feb 2013 08:24:46 -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 85C4E21F955C for ; Mon, 25 Feb 2013 08:24:46 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=27838; q=dns/txt; s=iport; t=1361809486; x=1363019086; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=uX0+Q+UXAcxV5uvJdhfAjZZoyfjvkjnAO/5s9FaKxzI=; b=JT6iQrCm4ln4eqGjGskaMSzfPuHwx9VO3w00P6mouqPktvzpYwTtRReV 8NGu88k8ArgVe3dR37zTjkGDMLol5aUEXAqf6rUKLyu9zPvrkuG/xRRpp sDPAVdxd5VuzBJ1B6NRDI3P2AB9IctT8oLC2IrrCMwi3N4pe3G07auLy5 Q=;
X-Files: image001.jpg : 3541
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgMFAEqPK1GtJV2d/2dsb2JhbABFgkO/EoEFFnOCHwEBAQQFIAgBVwQCAQgOAwICAQEGAQEBAggOBwcCBRABDAIMFAkIAgQBEQEGAgEFiAUMvxaNNBmBEAgOCQcRAQaCWWEDkEkBUohsjRqDB4FyNQ
X-IronPort-AV: E=Sophos;i="4.84,735,1355097600";  d="jpg'145?scan'145,208,217,145";a="180665091"
Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-1.cisco.com with ESMTP; 25 Feb 2013 16:24:45 +0000
Received: from xhc-rcd-x04.cisco.com (xhc-rcd-x04.cisco.com [173.37.183.78]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id r1PGOjWb004940 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 25 Feb 2013 16:24:45 GMT
Received: from xmb-rcd-x05.cisco.com ([169.254.15.93]) by xhc-rcd-x04.cisco.com ([173.37.183.78]) with mapi id 14.02.0318.004; Mon, 25 Feb 2013 10:24:45 -0600
From: "Anurag Kothari (ankothar)" 
To: Thirumavalavan Periyannan , "vrrp@ietf.org" 
Thread-Topic: [VRRP] vrrp Digest, Vol 81, Issue 3
Thread-Index: Ac4RBGKo4P5hWc5lTiSJPUEgi0SCSQADvuFgAA80cgAADFd4oP//qQAAgABMd9D//JbYQP/4vEBg//F3tKD/4t/KMP/FuwJg
Date: Mon, 25 Feb 2013 16:24:44 +0000
Message-ID: 
References:  <14CA6619-DB7C-40ED-85E4-535CB689AC86@extremenetworks.com>    <91BD27DC-D555-49C7-8B40-F74F4D8B596F@extremenetworks.com>  <617438426768D648ABBC00E677AA014902697FB19C66@INEXCHANGE.corp.extremenetworks.com>  <617438426768D648ABBC00E677AA014902697FB19C70@INEXCHANGE.corp.extremenetworks.com>
In-Reply-To: <617438426768D648ABBC00E677AA014902697FB19C70@INEXCHANGE.corp.extremenetworks.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
x-originating-ip: [10.82.240.69]
Content-Type: multipart/related; boundary="_004_A2BB90B33FFDF740876C5AAE307D83DB1C293D07xmbrcdx05ciscoc_"; type="multipart/alternative"
MIME-Version: 1.0
Subject: Re: [VRRP] vrrp Digest, Vol 81, Issue 3
X-BeenThere: vrrp@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Virtual Router Redundancy Protocol  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 25 Feb 2013 16:25:02 -0000

--_004_A2BB90B33FFDF740876C5AAE307D83DB1C293D07xmbrcdx05ciscoc_
Content-Type: multipart/alternative;
	boundary="_000_A2BB90B33FFDF740876C5AAE307D83DB1C293D07xmbrcdx05ciscoc_"

--_000_A2BB90B33FFDF740876C5AAE307D83DB1C293D07xmbrcdx05ciscoc_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi Thirumavalavan

Yes the priority zero router will become backup on receiving the ADVERTISEM=
ENT from other router which would have transitioned to Master.

Thanks
-Anurag

From: Thirumavalavan Periyannan [mailto:tperiyannan@extremenetworks.com]
Sent: Monday, February 25, 2013 11:19 AM
To: Anurag Kothari (ankothar); vrrp@ietf.org
Subject: RE: [VRRP] vrrp Digest, Vol 81, Issue 3

Yes Anurag, I agree that backup router will reset Master_Down_timer value a=
s Skew_Time and
It will be become master when Master_Down_timer fired and will send VRRP Ad=
vertisements with their own priority.

After VRRP Master elected, What could be the VRRP state of priority ZERO co=
nfigured router? Is it Backup?

Thanks & Regards,
Thirumavalavan Periyannan
Associate SQA Engineer  - VRRP Module Owner

[cid:image001.jpg@01CE134A.87062E80]

From: Anurag Kothari (ankothar) [mailto:ankothar@cisco.com]
Sent: Monday, February 25, 2013 8:44 PM
To: Thirumavalavan Periyannan; vrrp@ietf.org
Subject: RE: [VRRP] vrrp Digest, Vol 81, Issue 3

Hi Thirumavalavan

The Master_Down_Timer is set to Skew_Time by the backup router on receiving=
 an ADVERTISEMENT with Priority =3D 0. That is why I said will have to wait=
 Skew_Time in the thread below. I am copy pasting the relevant section from=
 the RFC for easy reference:

(420) - If an ADVERTISEMENT is received, then:

   (425) + If the Priority in the ADVERTISEMENT is zero, then:

      (430) * Set the Master_Down_Timer to Skew_Time

   (440) + else // priority non-zero

Yes the Priority on the Master router will have to be set to zero to initia=
te a graceful failover.

Thanks
-Anurag

From: Thirumavalavan Periyannan [mailto:tperiyannan@extremenetworks.com]
Sent: Monday, February 25, 2013 10:08 AM
To: Anurag Kothari (ankothar); vrrp@ietf.org
Subject: RE: [VRRP] vrrp Digest, Vol 81, Issue 3



Hi Anurag,



Sorry for the late response.



See the inline [Thiru]



Here, I have a question,



1.Do We have to configure priority Zero on Master router to do graceful fai=
lover?

Thanks & Regards,
Thirumavalavan Periyannan
Associate SQA Engineer  - VRRP Module Owner

[Description: Description: Description: Description: Description: Descripti=
on: Description: Description: cid:image001.png@01CBF547.656FF3F0]


-----Original Message-----
From: Anurag Kothari (ankothar) [mailto:ankothar@cisco.com]
Sent: Saturday, February 23, 2013 12:57 AM
To: Thirumavalavan Periyannan; vrrp@ietf.org
Cc: Peter Hunt
Subject: RE: [VRRP] vrrp Digest, Vol 81, Issue 3



Hi Thirumavalavan



Here are couple of points:



1) With something like "disable vrrp" or "shutdown vrrp" it will not be gra=
ceful as the router will treat it as a shutdown event (which is a break bef=
ore you make approach) and the router will "Transition to the {Initialize} =
state". The backup router will wait for "Skew_Time"[Thiru]I think, it's Mas=
ter_Down_interval time. before it becomes master; So we probably will have =
traffic loss for a period approximately equal to "Skew_Time"[Thiru]I think,=
 it's Master_Down_interval time. Even with Default configuration this will =
be close to 609 ms which would be a duration long enough for to impact time=
 sensitive applications (e.g. voice calls). For sure the actual failover ti=
me will depend upon the size of the Network and the switches in between but=
 with the method proposed below we can try to improve that time.



2) This will also improve convergence in scenarios where we want the failov=
er to trigger because of up uplink interface from the router going down (tr=
acking interface and decrementing the priority).



I am not sure if you saw the modified proposal which was sent out today ear=
ly morning. Here is the link to it in case you need it http://www.ietf.org/=
mail-archive/web/vrrp/current/msg01489.html



Thanks

~Anurag





________________________________
DISCLAIMER:
This e-mail and any attachments to it may contain confidential and propriet=
ary material and is solely for the use of the intended recipient. Any revie=
w, use, disclosure, distribution or copying of this transmittal is prohibit=
ed except by or on behalf of the intended recipient. If you have received t=
his transmittal in error, please notify the sender and destroy this e-mail =
and any attachments and all copies, whether electronic or printed.

________________________________
DISCLAIMER:
This e-mail and any attachments to it may contain confidential and propriet=
ary material and is solely for the use of the intended recipient. Any revie=
w, use, disclosure, distribution or copying of this transmittal is prohibit=
ed except by or on behalf of the intended recipient. If you have received t=
his transmittal in error, please notify the sender and destroy this e-mail =
and any attachments and all copies, whether electronic or printed.

--_000_A2BB90B33FFDF740876C5AAE307D83DB1C293D07xmbrcdx05ciscoc_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











Hi Thirumavalavan=



 


Yes the priority zero =
router will become backup on receiving the ADVERTISEMENT from other router =
which would have transitioned to Master.


 


Thanks


-Anurag


 






From: Thirumav=
alavan Periyannan [mailto:tperiyannan@extremenetworks.com]


Sent: Monday, February 25, 2013 11:19 AM

To: Anurag Kothari (ankothar); vrrp@ietf.org

Subject: RE: [VRRP] vrrp Digest, Vol 81, Issue 3





 


Yes Anurag, I agree that backup router will reset Master_Down_t=
imer value as Skew_Time and



It will be become master when Master_Down_timer fired and will =
send VRRP Advertisements with their own priority.


 


After VRRP Master elected, What could be the VRRP state of prio=
rity ZERO configured router? Is it Backup?


 


Thank=
s & Regards,


Th=
irumavalavan Periyannan


Assoc=
iate SQA Engineer  - VRRP Module Owner


=
 




 






From: Anurag K=
othari (ankothar) [mailto:ankothar@ci=
sco.com]


Sent: Monday, February 25, 2013 8:44 PM

To: Thirumavalavan Periyannan; vrrp=
@ietf.org

Subject: RE: [VRRP] vrrp Digest, Vol 81, Issue 3





 


Hi Thirumavalavan=



 


The Master_Down_Timer =
is set to Skew_Time by the backup router on receiving an ADVERTISEMENT with=
 Priority =3D 0. That is why I said will have to wait Skew_Time in the thre=
ad below. I am copy pasting the relevant
 section from the RFC for easy reference:


 


=
(420) - If an ADVERTISEMENT is received, then:


=
 


=
   (425) + If the Priority in the ADVERTISEMENT is zero, then=
:


=
 


=
      (430) * Set the Master_Down_Timer to Skew_Ti=
me


=
 


=
   (440) + else // priority non-zero


 


Yes the Priority on th=
e Master router will have to be set to zero to initiate a graceful failover=
.


 


Thanks


-Anurag


 






From: Thirumav=
alavan Periyannan [mailt=
o:tperiyannan@extremenetworks.com]


Sent: Monday, February 25, 2013 10:08 AM

To: Anurag Kothari (ankothar); vrrp=
@ietf.org

Subject: RE: [VRRP] vrrp Digest, Vol 81, Issue 3





 


 


Hi Anurag,


 


Sorry for the late =
response.


 


See the inline [Thi=
ru]


 


Here, I have a
question,


 


1.Do We have to configure priority Zero on Master router =
to do graceful failover?


=
 


Thank=
s & Regards,


Th=
irumavalavan Periyannan


Assoc=
iate SQA Engineer  - VRRP Module Owner


=
 


3D"Description:<=
/p>

 


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

From: Anurag Kothari (ankothar) [mail=
to:ankothar@cisco.com]


Sent: Saturday, February 23, 2013 12:57 AM

To: Thirumavalavan Periyannan; vrrp@ietf.o=
rg

Cc: Peter Hunt

Subject: RE: [VRRP] vrrp Digest, Vol 81, Issue 3


 


Hi Thirumavalavan


 


Here are couple of points:


 


1) With something like "disable vrrp" o=
r "shutdown vrrp" it will not be graceful as the router will trea=
t it as a shutdown event (which is a break before you make approach) and th=
e router will "Transition to the {Initialize} state".
 The backup router will wait for "Skew_Time"[Thiru]I think, it’s Master_Down_interval time. be=
fore it becomes master; So we probably will have traffic loss for a period =
approximately equal to "Skew_Time"[T=
hiru]I
 think, it’s Master_Down_interval time. Even with Default =
configuration this will be close to 609 ms which would be a duration long e=
nough for to impact time sensitive applications (e.g. voice calls). For sur=
e the actual failover time will depend
 upon the size of the Network and the switches in between but with the meth=
od proposed below we can try to improve that time.


 


2) This will also improve convergence in scenario=
s where we want the failover to trigger because of up uplink interface from=
 the router going down (tracking interface and decrementing the priority).<=
o:p>


 


I am not sure if you saw the modified proposal wh=
ich was sent out today early morning. Here is the link to it in case you ne=
ed it
http://www.ietf.org/mai=
l-archive/web/vrrp/current/msg01489.html


 


Thanks


~Anurag


 


 


 








DISCLAIMER:

This e-mail and any attachments to it may contain confidential and propriet=
ary material and is solely for the use of the intended recipient. Any revie=
w, use, disclosure, distribution or copying of this transmittal is prohibit=
ed except by or on behalf of the
 intended recipient. If you have received this transmittal in error, please=
 notify the sender and destroy this e-mail and any attachments and all copi=
es, whether electronic or printed.=



 








DISCLAIMER:

This e-mail and any attachments to it may contain confidential and propriet=
ary material and is solely for the use of the intended recipient. Any revie=
w, use, disclosure, distribution or copying of this transmittal is prohibit=
ed except by or on behalf of the
 intended recipient. If you have received this transmittal in error, please=
 notify the sender and destroy this e-mail and any attachments and all copi=
es, whether electronic or printed.=







--_000_A2BB90B33FFDF740876C5AAE307D83DB1C293D07xmbrcdx05ciscoc_--

--_004_A2BB90B33FFDF740876C5AAE307D83DB1C293D07xmbrcdx05ciscoc_
Content-Type: image/jpeg; name="image001.jpg"
Content-Description: image001.jpg
Content-Disposition: inline; filename="image001.jpg"; size=3541;
	creation-date="Mon, 25 Feb 2013 16:24:43 GMT";
	modification-date="Mon, 25 Feb 2013 16:24:43 GMT"
Content-ID: 
Content-Transfer-Encoding: base64

/9j/4AAQSkZJRgABAQEAeAB4AAD/2wBDAAoHBwkHBgoJCAkLCwoMDxkQDw4ODx4WFxIZJCAmJSMg
IyIoLTkwKCo2KyIjMkQyNjs9QEBAJjBGS0U+Sjk/QD3/2wBDAQsLCw8NDx0QEB09KSMpPT09PT09
PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT3/wAARCABBALwDASIA
AhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQA
AAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3
ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWm
p6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEA
AwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSEx
BhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElK
U1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3
uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD2akLB
RkkAe9BIAyTgCuS13XLWzLFr2HKku0aPuEh/hGOq44NVGLk7IDppL+1hB8yeMYcRnnox7H0qpL4g
sYzgSFzvKEKMnjqfce4ry7UvEqNK32NpH4ysrKAWY/eLDv6A113w7itruwe9YK10rGMKTnyl9Bn1
rWVLljdiub39vM6F4rK4KqC7ZU5KDuPXPpVeLxnpraiLScyW7MBseZCoYn+H61y3inU7ePXpo7nV
NUt2jI2xxDao+nrWl/atrqHhzy7zT76+hEZH2h4uT75o9mrJ2A1/EHiC50Q+Y1rutHA23C8hD33D
0rDg+JP2iZVt7CackneiDJQDoR65pPAV/qN/bTWd5bm40sAhJpeoHpz1FaWpW6eFdDluPDmnJI7k
lnB3bR6+potGL5WtQLnhjXb3WY5RfWD2rx92BAb0xms7WvFeq6bqd1a22kyTohXy5QpwRjJqP4c6
vfavb6jJf3DTMkqhd3bINZmr61qlv8R4rNLmZLR54lEf8JBAzQoe+1YCe5+IeqQ7f+JE6bjhS5bk
+mMVTvPHviGCREbTlhZ/mVShYkfSuu8Y6udD0M3scKSTBwkW8ZCse9P8NXa6roltfTSR3FztO59o
BU/3aE4qPNygcQ3ijxnLF5i2rBM9VtqzX8WeJ5ZxB586yt0QIQx/CtDUNZtxq0rz6xrEc6SEbAMA
c9MV2mn6lDqNzaNJplz5mPluZIsdupNaNqKvygeby6x4q85Ua61FXfoi5GfwqC7ufEdtGTdy36Ie
SWzj8a7n4j6pd6Xb2T2UvkyO5BdRzjHTNbHhm6l1PwjbTXxE7vGd5cZ3fWj2loqVgPKoo9du4C8S
3skRHXBwRVKSS8il8uQzpJ/dYEE/hXZ+EvEOpXfi8W01wTbMWAiAwqgdABXokun2k90lxNbxPOgw
rsoJFOVXkdmgseJw6drU67ora8YYznYarT/b7VsXAuIj/tgiu58XanCmtyRXepana7MbUhG1ceo9
av2mr2t94fWG6sb/AFGAKR57w5JH19qftHZOwHmqahdxgiO5lUH0arMXiPWIMeVqdyuPR6rxx2j3
rpJK8UO8hW25KjPcV2Ph+x8LGNWmhmluVAPlSnJOTxtA6/Srk0lqhCeFfFviK+1KG32fbIGbDsU+
6O53V6fVPT2sFtl+wCFYiSAIwAMjrVyuKpJSeisUeReKrrxPPcyrqEdxFb5+VIgdmPXjrXKtG4OX
RwfVlNfQ1QSWNrN/rbaJ8/3kBraNeytYVj5+JA6nH1qxY6nc6bP51lcvDJ6o3Wvcn0LS5Dl9OtWI
9Ylpv/CPaR/0DbT/AL8rVfWF2Cx5SfHurOqiU2spXo0kQJqrf+LtV1JfLnu8Q94k+VT+Ar2D/hHt
I/6Btp/35Wj/AIR7SP8AoGWn/flalVoL7IWPIp/F2rz2P2QXHlwEbdsS7ePSrnhXxfdaFKILhZJ7
Bz8yEElfcf4V6qNG00AAWNtgf9MhUi6dZqAFtYQB0wgpOtFq3KFjkb3Sp4om1vwfPsEw3S24Hyye
4Hr7Vyz/ABA1wSnzFthIp53QjcK9eVFQYRQo9AMVQn0DTLm7+0zWcLTYKltvUH19amNRfaVwPItY
8XanrlkLW+aMxbg42pgkiqOm6zf6S5ewupIQfvAHg/hXrz+CtEkBD2gIyCBuPy47D2qOfwNok90Z
ja7Qc5RThST3xWqrQStYLHnh8easzh3W0dx/E0IJqufGWtNfR3T3hZo+VjP3B+FegXfgHQkt0Mga
JY8APnt6H1+tVz4M8OSu0cc20OdwG7kHtg+ntUPEUIuzCzOB1rxNqGvpEl+0ZERyu1cVZ0/xrq2m
aellbPEIYwVAZMnFdkPBOgIVAuNzBdrljwx7n2NQjwr4da5aMyyZQgq3Rdo/hPr9amWMwySTaCzO
B07VrnS9SF7alROMn5hkc+1aN/411m/eB3uRE8DFkaIbTk+vrXcHwZoIiVnkVY5SSmD0f2PoPSpG
8H+HYJGWRl3FArhm/Mj0NU8VQ3bCzOI/4TrWHjAl+zz7Od0kIYj8ahv/ABNrmpwPHLO6QgAtHENg
wenAr0OLw/oUaMzSRld4BGAMr2QjuPenpZaDFdwQQQq8u4skg+baT7+ntUPGYePYLM8rg0u5lY7Y
yz5wig8se5HrjvW7p+iXDbWjB2g/u2YYGB1YHqrE8AV6J9m0eMNH+6XjbhTgD1xjoTV2M2TrM0KR
uxAMgAGWx0zQ8ZB6JhY5vTdPuEmOMjgLJkYYDtGw9e5YV0yQ3CoNsoXPJVhux7A+lM/tSISrGyss
jEAA+9XaxVWNT4RhRRRTAKKKKACiiigAooooAKKKKACiiigCpqdkdQsngDhCxHJGazrnw79ogtYx
KqeSu1iF5atyisKmGpVW3Nb/APDjuYA8NEQ+SZIim7O4od386mXQTFfPNFJH5bjayMmePatmis1g
aC2QXMBfDC7ZVecsuD5Qx9zmlHhr5UkNxuuVbJdlyD7YreopfUMP/KF2YFz4ce7keWW4QSNj7iYX
H0qe40BJ5bYhwiQptYKuC341sUU/qVDX3dwuzAbw22CiToYg25VZMkfjVvTNHaxmkd5g4cY2gYFa
lFOGDowkpRWqC5EbaEuGMa7hjB+nSpaKK6UkthBXOzeKBa69cW1ygWzjUIsoGS0mMlfyroqzbPRo
reFhNtnlMzTB2XoxPH5DirjbqBm2HiWeSzuby7tvLjE5iijB+bAHU1LP4mg82xaOQJDKjSvuHzED
jAHrmo28LSrHAILxQ6I6yNJFu3bu4GeDTT4MgaNd8xaWGJEgk28xsDkt75NX7gi1J4ptogxeGYeW
AZuP9UD6+/tVzVbue10x7q0VZGTDlT3Xv+lZ7eGnN+8/2iJo5mV5keLJYgYODngH0rXvbZrmxlt4
38oyJsDYzgVL5bqwzGHiYzXEctvEzWTnZGdp3zv/ALI7AetXINft5/LUJIszzeS0TDDK3fPtTbnR
H8qxNjOtvPZLtjZk3KRjBBFVz4bmjaG4t73beq7vJK8e4OWAB4zx04p+6wJ7rxLa2zbfLmkfzzAF
jXJLDrin6zqdxZaSs1rCGupWVI4n/vMe9R6b4fNjcQTS3JmaJXzlcbnY5LfWrl5p/wBrvbOZpMJb
szlMfeJGB+VL3UwM0eJFeOzk+VEeN5Ljd1jC8EfXJpz+KYRa3LpBIJYofORGGN69B+tNm8JW81zq
MnmuovVHyj/lm3cj64FIfDcsmnTwyXMQnkK7ZUhwFCkHBGeQcU/cAlg8SRrZmW/ia3kSATOuOx7C
nyeJrNApUSSbo1cBFySW+6v1NJdeH1vr+3ubqbd5UexkVcK57H8PSoIPCwtdKggguiLqGXzhOy5y
3PUemD0o9wCeTxLbQW00txFNG8LKrRFct83THrVd/EoTUQkkbxosQbyiuZHZj8oA/CpY/DztdxXV
3dmaYS+ZKdmA2BhQB2A60k/hlJr+S/M2LzzhJHLt+4o/gx3HWj3ALOtanNp+iPdQw7rkgCOI92J6
VlS+LXl+xRWMKvLJIqXDt9yL+8Pc1uXtgb24tHaQqlvJ5hXH3zggfzqCfQrea5gZQscMfmExIuNz
OMEk+tKLjbUBkXiO2lmiUxyrDM5SKdlwrsP/ANRqrpniQzOBdwyIktw0UUm35SAePzpU8O3LRRw3
N+JIbfP2dRFgqcEAtzzgE02Dw1crbwW1xqPmwWynyVEe0hscFjnnFP3AEPiBlnjczL9nd5HZtv3Y
04x9Sa0NO1yHULkwCOSOTZ5ihx95fWqZ8LI9vJC85KNbiFcL905JLfiTVzSNKewMj3EkMsrAANHF
swB26mh8ttANOiiiswCiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoooo
AKKKKAP/2Q==

--_004_A2BB90B33FFDF740876C5AAE307D83DB1C293D07xmbrcdx05ciscoc_--

From ankothar@cisco.com  Tue Feb 26 07:13:54 2013
Return-Path: 
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 264C521F8820 for ; Tue, 26 Feb 2013 07:13:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.441
X-Spam-Level: 
X-Spam-Status: No, score=-10.441 tagged_above=-999 required=5 tests=[AWL=0.157, 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 DOpYuPXBgDxw for ; Tue, 26 Feb 2013 07:13:53 -0800 (PST)
Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 25A1821F870C for ; Tue, 26 Feb 2013 07:13:53 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=17448; q=dns/txt; s=iport; t=1361891633; x=1363101233; h=from:to:subject:date:message-id:mime-version; bh=OYkI9IhnAxEX4E5J2jrCQnCWTCKiJ0g/p+Zqsb5ec8U=; b=RLC+a/zK4G+wD8hTF+VnUey/GiPpNXWJbuRKPyBUJ/xXqfeW3q+qavb3 reFWImbS3aYcQY//I9a6nZIigS6mvAPBud7FfkxRdimkMPAh27X24xwFg 95fDfM/z4bZ+6j71qF26k0dcHxH+FYrYhkr7OVHfVuh+vvCYD52sPK1zV w=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgAFANvQLFGtJV2Y/2dsb2JhbABFgkO/Jn4Wc4IhAQQtXgEIIlYmAQQbE4d4nlaRFY9ojTqBKYMXYQOnKIMIgic
X-IronPort-AV: E=Sophos;i="4.84,740,1355097600";  d="scan'208,217";a="178336317"
Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-9.cisco.com with ESMTP; 26 Feb 2013 15:13:52 +0000
Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r1QFDqps018373 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 26 Feb 2013 15:13:52 GMT
Received: from xmb-rcd-x05.cisco.com ([169.254.15.93]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.02.0318.004; Tue, 26 Feb 2013 09:13:52 -0600
From: "Anurag Kothari (ankothar)" 
To: "vrrp@ietf.org" 
Thread-Topic: [VRRP] Proposal for Maintenance Event for VRRP [RFC-5798]
Thread-Index: Ac4UM9OxSXkTjEjFQomcNOLGEc+dwg==
Date: Tue, 26 Feb 2013 15:13:51 +0000
Message-ID: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.82.221.130]
Content-Type: multipart/alternative; boundary="_000_A2BB90B33FFDF740876C5AAE307D83DB1C2946D3xmbrcdx05ciscoc_"
MIME-Version: 1.0
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  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 26 Feb 2013 15:13:54 -0000

--_000_A2BB90B33FFDF740876C5AAE307D83DB1C2946D3xmbrcdx05ciscoc_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Some concerns have been raised regarding the following situation / Corner C=
ase:
Due to congestion or some other fault in the network the ADVERTISEMENTs fro=
m the Master router do not reach backup router(s). The Master_Down_timer fi=
res and one of the back router transitions to Master State at the same time=
 the priority of this router and the original Master is set to zero. How wo=
uld the network behave in this case?

For sure the probability of this happening would be very low (as it is a do=
uble/multiple fault situation). Here is my analysis of the situation and so=
lution for the same.

We will have two Master routers both sending ADVERTISEMENTs with Priority =
=3D 0. This will create a vicious circle of sending ADVERTISEMENTs (one rou=
ter triggering the other) at a fast rate. This would also cause the Virtual=
 MAC to shuttle continuously between two ports on the switch(es) at a fast =
rate. Both of these can probably cause high CPU utilization on the router a=
nd the LAN Switches.

If there is an additional backup router available then it will become maste=
r on seeing the first Advertisement with Priority =3D 0 and both the Master=
s (with priority =3D 0) will transition to Backup on seeing the advertiseme=
nt with non-zero priority from the new Master.

For the situation where we do not have an additional backup router we can a=
void this by making following modifications (Differences from RFC-5798 high=
lighted in RED):

(700) - If an ADVERTISEMENT is received, then:

   (705) -+ If the Priority in the ADVERTISEMENT is zero,

   (701) -+ and

   (702) -+ Local Priority is greater than zero, then:

      (710) -* Send an ADVERTISEMENT

      (715) -* Reset the Adver_Timer to Advertisement_Interval

   (720) -+ else // priority was non-zero or local priority was zero

      (725) -* If the Priority in the ADVERTISEMENT is greater
      than the local Priority,

      (730) -* or

      (735) -* If the Priority in the ADVERTISEMENT is equal to
      the local Priority and the primary IPvX Address of the
      sender is greater than the local primary IPvX Address, then:

         (740) -@ Cancel Adver_Timer

         (745) -@ Set Master_Adver_Interval to Adver Interval
         contained in the ADVERTISEMENT

         (750) -@ Recompute the Skew_Time

         (755) @ Recompute the Master_Down_Interval

         (760) @ Set Master_Down_Timer to Master_Down_Interval

         (765) @ Transition to the {Backup} state

      (770) * else // new Master logic

         (775) @ Discard ADVERTISEMENT

      (780) *endif // new Master detected

   (785) +endif // was priority zero?

(790) -endif // advert recv


Please let me know if I have missed something.

Thanks
-Anurag

--_000_A2BB90B33FFDF740876C5AAE307D83DB1C2946D3xmbrcdx05ciscoc_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











Some concerns have been r=
aised regarding the following situation / Corner Case:

Due to congestion or some=
 other fault in the network the ADVERTISEMENTs from the Master router do no=
t reach backup router(s). The Master_Down_timer fires and
 one of the back router transitions to Master State at the same time the pr=
iority of this router and the original Master is set to zero. How would the=
 network behave in this case?


 <=
/p>

For sure the probability =
of this happening would be very low (as it is a double/multiple fault situa=
tion). Here is my analysis of the situation and solution
 for the same.


 <=
/p>

We will have two Master r=
outers both sending ADVERTISEMENTs with Priority =3D 0. This will create a =
vicious circle of sending ADVERTISEMENTs (one router triggering
 the other) at a fast rate. This would also cause the Virtual MAC to shuttl=
e continuously between two ports on the switch(es) at a fast rate. Both of =
these can probably cause high CPU utilization on the router and the LAN Swi=
tches.


 <=
/p>

If there is an additional=
 backup router available then it will become master on seeing the first Adv=
ertisement with Priority =3D 0 and both the Masters (with
 priority =3D 0) will transition to Backup on seeing the advertisement with=
 non-zero priority from the new Master.


 <=
/p>

For the situation where w=
e do not have an additional backup router we can avoid this by making follo=
wing modifications (Differences from RFC-5798 highlighted
 in RED):


 <=
/p>

(700) - If an ADVERTISEMENT is received, then:


 


   (705) -+ If the Priority in the ADVERTISE=
MENT is zero,


 


   
(701) -+ and


 


   (702) -+ Local Priority is grea=
ter than zero, then:


 


      (710) -* Send an ADVERTISEM=
ENT


 


      (715) -* Reset the Adver_Ti=
mer to Advertisement_Interval


 


   (720) -+ else // priority was non-zero
or local priority was zero


         &nbs=
p;            &=
nbsp;           &nbs=
p;       



      (725) -* If the Priority in=
 the ADVERTISEMENT is greater


      than the local Priority,


 


      (730) -* or


 


      (735) -* If the Priority in=
 the ADVERTISEMENT is equal to


      the local Priority and the =
primary IPvX Address of the


      sender is greater than the =
local primary IPvX Address, then:


 


         (740) -@ =
Cancel Adver_Timer


 


         (745) -@ =
Set Master_Adver_Interval to Adver Interval


         contained=
 in the ADVERTISEMENT


 


         (750) -@ =
Recompute the Skew_Time


 


         (755) @ R=
ecompute the Master_Down_Interval


 


         (760) @ S=
et Master_Down_Timer to Master_Down_Interval


 


         (765) @ T=
ransition to the {Backup} state


 


      (770) * else // new Master =
logic


 


         (775) @ D=
iscard ADVERTISEMENT


 


      (780) *endif // new Master =
detected


 


   (785) +endif // was priority zero?


 


(790) -endif // advert recv



 <=
/p>

 <=
/p>

Please let me know if I h=
ave missed something.


 <=
/p>

Thanks<=
/p>

-Anurag=







--_000_A2BB90B33FFDF740876C5AAE307D83DB1C2946D3xmbrcdx05ciscoc_--

From sreenatha.setty@ibtechnology.com  Thu Feb 28 08:38:53 2013
Return-Path: 
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 4337221F8C00 for ; Thu, 28 Feb 2013 08:38:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level: 
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001]
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 R7-D41x6VENG for ; Thu, 28 Feb 2013 08:38:52 -0800 (PST)
Received: from ipinternal.indiabulls.com (ipinternal.indiabulls.com [202.54.119.192]) by ietfa.amsl.com (Postfix) with ESMTP id E773721F8BB6 for ; Thu, 28 Feb 2013 08:38:49 -0800 (PST)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AqAEAN2GL1GsEQGd/2dsb2JhbABFwiyBEHOCHwEBAQEEAQFrCgEbDQsJFhgDAgECARU2CwIBBQIBAQUSiATBT406GYFBg0cDiGiFSo4ojWGBag
X-IronPort-AV: E=Sophos;i="4.84,755,1355077800"; d="scan'208,217";a="8311586"
X-IronPort-AV: E=Sophos;i="4.84,755,1355077800";  d="scan'208,217";a="103789426"
Received: from unknown (HELO [192.168.0.102]) ([27.124.57.10]) by ipgate.indiabulls.com with ESMTP; 28 Feb 2013 22:04:32 +0530
Message-ID: <512F8815.5010204@ibtechnology.com>
Date: Thu, 28 Feb 2013 22:08:45 +0530
From: sreenatha 
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/17.0 Thunderbird/17.0
MIME-Version: 1.0
To: "vrrp@ietf.org" 
Content-Type: multipart/alternative; boundary="------------090500060409030003070204"
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  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 28 Feb 2013 16:38:53 -0000

This is a multi-part message in MIME format.
--------------090500060409030003070204
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"; format="flowed"
Content-Transfer-Encoding: quoted-printable

Hi Anurag,
     Modification to algorithm is correct. But this modification is =

taking care only when Router is in Master state.
What about if Backup router(priority value is zero) receives =

ADVERTISEMENT message with priority value as zero?

Same condition we will consider, where both VRRP routers priority is set =

to zero, and both sending ADVERTISEMENT messages with priority as zero. =

According to new modification any one router, lets take "Router A", will =

remain in Master state and other router, lets say "Router B", will =

transit to Backup state.

Now according to RFC-5798:
When "Router B" is in Backup state,

(420) - If an ADVERTISEMENT is received, then:

          (425) + If the Priority in the ADVERTISEMENT is zero, then:

             (430) * Set the Master_Down_Timer to Skew_Time

          (440) + else // priority non-zero

So this lead to Master_Down_Timer to expire soon.

Again in Backup state,
(365) - If the Master_Down_Timer fires, then:

          (370) + Send an ADVERTISEMENT
                     |
                     |
                     ...
                     =

          (405) + Set the Adver_Timer to Advertisement_Interval

          (410) + Transition to the {Master} state

(415) -endif // Master_Down_Timer fire

So this lead to continuous switch over from Backup to Master state and vice=
 verse state transitions in "Router B".

To avoid this condition,
In Backup state also we need to do modification. Same as you suggested in M=
aster state, same extra condition we need to check in Backup state also.
Modifications in Backup state as follows(Differences from RFC-5798 highligh=
ted with Underline):


(420) - If an ADVERTISEMENT is received, then:

          (425) + If the Priority in the ADVERTISEMENT is zero,
          =

          _(421) -+ and_

          _(422) -+ Local Priority is greater than zero, then:_

             (430) * Set the Master_Down_Timer to Skew_Time

          (440) + else // priority non-zero or local-priority is zero
              (Continue other logic)

This will avoid state-transition flip-flap problem in "Router B".

Thanks,
Sreenatha Setty


On 02/27/2013 01:30 AM, vrrp-request@ietf.org wrote:
> Some concerns have been raised regarding the following situation / Corner=
 Case:
> Due to congestion or some other fault in the network the ADVERTISEMENTs f=
rom the Master router do not reach backup router(s). The Master_Down_timer =
fires and one of the back router transitions to Master State at the same ti=
me the priority of this router and the original Master is set to zero. How =
would the network behave in this case?
>
> For sure the probability of this happening would be very low (as it is a =
double/multiple fault situation). Here is my analysis of the situation and =
solution for the same.
>
> We will have two Master routers both sending ADVERTISEMENTs with Priority=
 =3D 0. This will create a vicious circle of sending ADVERTISEMENTs (one ro=
uter triggering the other) at a fast rate. This would also cause the Virtua=
l MAC to shuttle continuously between two ports on the switch(es) at a fast=
 rate. Both of these can probably cause high CPU utilization on the router =
and the LAN Switches.
>
> If there is an additional backup router available then it will become mas=
ter on seeing the first Advertisement with Priority =3D 0 and both the Mast=
ers (with priority =3D 0) will transition to Backup on seeing the advertise=
ment with non-zero priority from the new Master.
>
> For the situation where we do not have an additional backup router we can=
 avoid this by making following modifications (Differences from RFC-5798 hi=
ghlighted in RED):
>
> (700) - If an ADVERTISEMENT is received, then:
>
>     (705) -+ If the Priority in the ADVERTISEMENT is zero,
>
>     (701) -+ and
>
>     (702) -+ Local Priority is greater than zero, then:
>
>        (710) -* Send an ADVERTISEMENT
>
>        (715) -* Reset the Adver_Timer to Advertisement_Interval
>
>     (720) -+ else // priority was non-zero or local priority was zero
>
>        (725) -* If the Priority in the ADVERTISEMENT is greater
>        than the local Priority,
>
>        (730) -* or
>
>        (735) -* If the Priority in the ADVERTISEMENT is equal to
>        the local Priority and the primary IPvX Address of the
>        sender is greater than the local primary IPvX Address, then:
>
>           (740) -@ Cancel Adver_Timer
>
>           (745) -@ Set Master_Adver_Interval to Adver Interval
>           contained in the ADVERTISEMENT
>
>           (750) -@ Recompute the Skew_Time
>
>           (755) @ Recompute the Master_Down_Interval
>
>           (760) @ Set Master_Down_Timer to Master_Down_Interval
>
>           (765) @ Transition to the {Backup} state
>
>        (770) * else // new Master logic
>
>           (775) @ Discard ADVERTISEMENT
>
>        (780) *endif // new Master detected
>
>     (785) +endif // was priority zero?
>
> (790) -endif // advert recv
>
>
> Please let me know if I have missed something.
>
> Thanks
> -Anurag
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
>
> ------------------------------
>
> _______________________________________________
> vrrp mailing list
> vrrp@ietf.org
> https://www.ietf.org/mailman/listinfo/vrrp
>
>
> End of vrrp Digest, Vol 81, Issue 10
> ************************************
>

Disclaimer : =

This email communication may contain privileged and confidential informatio=
n and is intended for the use of the addressee only.If you are not an inten=
ded recipient you are requested not to reproduce, copy disseminate or in an=
y manner distribute this email communication as the same is strictly prohib=
ited. If you have received this email in error, please notify the sender im=
mediately by return e-mail and delete the communication sent in error. Emai=
l communications cannot be guaranteed to be secure & error free and IB Tech=
nology is not liable for any errors in the email communication or for the p=
roper, timely and complete transmission thereof.

--------------090500060409030003070204
MIME-Version: 1.0
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


  

    
  
  
    

      
Hi Anurag,

             Modification to algorithm is correct. =
But this
          modification is taking care only when Router is in Master
          state.

         What about if Backup router(priority value is zero)
          receives ADVERTISEMENT message with priority value as zero?<=
tt>

         

          Same condition we will consider, where both VRRP routers
          priority is set to zero, and both sending ADVERTISEMENT
          messages with priority as zero. According to new modification
          any one router, lets take "Router A", will remain in Master
          state and other router, lets say "Router B", will transit to
          Backup state.

         

         Now according to RFC-5798:

         When "Router B" is in Backup state,

        
(420) - If an ADVERTISEMENT is received, the=
n:

         (425) + If the Priority in the ADVERTISEMENT is zero, then:

            (430) * Set the Master_Down_Timer to Skew_Time

         (440) + else // priority non-zero

So this lead to Master_Down_Timer to expire soon. =


Again in Backup state,
(365) - If the Master_Down_Timer fires, then:

         (370) + Send an ADVERTISEMENT
                    |
                    |
                    ...
                    =

         (405) + Set the Adver_Timer to Advertisement_Interval

         (410) + Transition to the {Master} state

(415) -endif // Master_Down_Timer fire

So this lead to continuous switch over from Backup to Master state and vice=
 verse state transitions in "Router B".

To avoid this condition,
In Backup state also we need to do modification. Same as you suggested in M=
aster state, same extra condition we need to check in Backup state also.
Modifications in Backup state as follows(Differences from RFC-5798 highligh=
ted with Underline):


(420) - If an ADVERTISEMENT is received, then:

         (425) + If the Priority in the ADVERTISEMENT is zero, =

         =

         (421) -+ and

         (422) -+ Local Priority is greater than zero, then:

            (430) * Set the Master_Down_Timer to Skew_Time

         (440) + else // priority non-zero or local-priority is zero
             (Continue other logic)

This will avoid state-transition flip-flap problem in "Router B".

Thanks,
Sreenatha Setty



        

        On 02/27/2013 01:30 AM, vrrp-request@ietf.org
        wrote:

      

      

        
Some concerns have been raised regarding the followi=
ng situation / Corner Case:
Due to congestion or some other fault in the network the ADVERTISEMENTs fro=
m the Master router do not reach backup router(s). The Master_Down_timer fi=
res and one of the back router transitions to Master State at the same time=
 the priority of this router and the original Master is set to zero. How wo=
uld the network behave in this case?

For sure the probability of this happening would be very low (as it is a do=
uble/multiple fault situation). Here is my analysis of the situation and so=
lution for the same.

We will have two Master routers both sending ADVERTISEMENTs with Priority =
=3D 0. This will create a vicious circle of sending ADVERTISEMENTs (one rou=
ter triggering the other) at a fast rate. This would also cause the Virtual=
 MAC to shuttle continuously between two ports on the switch(es) at a fast =
rate. Both of these can probably cause high CPU utilization on the router a=
nd the LAN Switches.

If there is an additional backup router available then it will become maste=
r on seeing the first Advertisement with Priority =3D 0 and both the Master=
s (with priority =3D 0) will transition to Backup on seeing the advertiseme=
nt with non-zero priority from the new Master.

For the situation where we do not have an additional backup router we can a=
void this by making following modifications (Differences from RFC-5798 high=
lighted in RED):

(700) - If an ADVERTISEMENT is received, then:

   (705) -+ If the Priority in the ADVERTISEMENT is zero,

   (701) -+ and

   (702) -+ Local Priority is greater than zero, then:

      (710) -* Send an ADVERTISEMENT

      (715) -* Reset the Adver_Timer to Advertisement_Interval

   (720) -+ else // priority was non-zero or local priority was zero

      (725) -* If the Priority in the ADVERTISEMENT is greater
      than the local Priority,

      (730) -* or

      (735) -* If the Priority in the ADVERTISEMENT is equal to
      the local Priority and the primary IPvX Address of the
      sender is greater than the local primary IPvX Address, then:

         (740) -@ Cancel Adver_Timer

         (745) -@ Set Master_Adver_Interval to Adver Interval
         contained in the ADVERTISEMENT

         (750) -@ Recompute the Skew_Time

         (755) @ Recompute the Master_Down_Interval

         (760) @ Set Master_Down_Timer to Master_Down_Interval

         (765) @ Transition to the {Backup} state

      (770) * else // new Master logic

         (775) @ Discard ADVERTISEMENT

      (780) *endif // new Master detected

   (785) +endif // was priority zero?

(790) -endif // advert recv


Please let me know if I have missed something.

Thanks
-Anurag
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www=
.ietf.org/mail-archive/web/vrrp/attachments/20130226/cc6018e8/attachment.ht=
m>

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

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


End of vrrp Digest, Vol 81, Issue 10
************************************



      

      

    

  
Disclaimer : 
This e=
mail communication may contain privileged and confidential information and =
is intended for the use of the addressee only.If you are not an intended re=
cipient you are requested not to reproduce, copy disseminate or in any mann=
er distribute this email communication as the same is strictly prohibited. =
If you have received this email in error, please notify the sender immediat=
ely by return e-mail and delete the communication sent in error. Email comm=
unications cannot be guaranteed to be secure & error free and IB Techno=
logy is not liable for any errors in the email communication or for the pro=
per, timely and complete transmission thereof.



--------------090500060409030003070204--


From ankothar@cisco.com  Thu Feb 28 12:01:38 2013
Return-Path: 
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 C66BC21F8996 for ; Thu, 28 Feb 2013 12:01:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.472
X-Spam-Level: 
X-Spam-Status: No, score=-10.472 tagged_above=-999 required=5 tests=[AWL=0.126, 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 U-S5W2qFa+80 for ; Thu, 28 Feb 2013 12:01:34 -0800 (PST)
Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id EB79F21F89FC for ; Thu, 28 Feb 2013 12:01:30 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=24983; q=dns/txt; s=iport; t=1362081692; x=1363291292; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=I9JAeGZxrE4xqvpb5fcGgz7VXqrYDXgVKb2T+SZrTy0=; b=Suj8QnqmlYLoavFdt9CeI0kuKFuAPYl5ZxQgGRVpaVRrgq3oW6E6e9mx 0WXBI3hFwVsOrP7Of+h2XQ4v9FlIRyWtjXJv1kzv+gQjy6XRKIVa/HF+I Fc127pgMqfmjhz5Cox8f+pTfwclru/BRac7pFDX7vIYGXM7J5pe60zOCh A=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgIFACi3L1GtJXG9/2dsb2JhbABFgkO/bXwWc4IfAQEBBAEBASpBGwIBCBEEAQELFgcHJwsUCQgCBAESCAESh3gMwTONOgkQgRAmBgEKAQaCWWEDpyuDCIFyNQ
X-IronPort-AV: E=Sophos;i="4.84,756,1355097600";  d="scan'208,217";a="179375574"
Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-9.cisco.com with ESMTP; 28 Feb 2013 20:01:29 +0000
Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id r1SK1Tu4023257 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 28 Feb 2013 20:01:29 GMT
Received: from xmb-rcd-x05.cisco.com ([169.254.15.93]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.02.0318.004; Thu, 28 Feb 2013 14:01:29 -0600
From: "Anurag Kothari (ankothar)" 
To: sreenatha , "vrrp@ietf.org" 
Thread-Topic: Proposal for Maintenance Event for VRRP [RFC-5798]
Thread-Index: AQHOFdIXMs1MhoGdzkqW+jdD3o4AJZiPq2bA
Date: Thu, 28 Feb 2013 20:01:29 +0000
Message-ID: 
References: <512F8815.5010204@ibtechnology.com>
In-Reply-To: <512F8815.5010204@ibtechnology.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.82.229.53]
Content-Type: multipart/alternative; boundary="_000_A2BB90B33FFDF740876C5AAE307D83DB1C295D1Cxmbrcdx05ciscoc_"
MIME-Version: 1.0
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  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 28 Feb 2013 20:01:38 -0000

--_000_A2BB90B33FFDF740876C5AAE307D83DB1C295D1Cxmbrcdx05ciscoc_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi Sreenatha

Totally agree with your observation.

Also as pointed out by some other participants the additional backup router=
 in my original analysis will never become master on seeing the first ADVER=
TISEMENT with priority zero as it will keep resetting it's Master_Down_Time=
r to Skew_Time in the storm of ADVERTISEMENTs with zero priority and the Ma=
ster_Down_Timer will never fire for the additional backup router.

Thanks
-Anurag

P.S. Noticed the typos: the additional lines in my email should be numbered=
 706 and 707 (instead of 701 and 702) and probably yours should be 426 and =
427 (instead of 421 and 422).

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

Hi Anurag,
    Modification to algorithm is correct. But this modification is taking c=
are only when Router is in Master state.
What about if Backup router(priority value is zero) receives ADVERTISEMENT =
message with priority value as zero?

Same condition we will consider, where both VRRP routers priority is set to=
 zero, and both sending ADVERTISEMENT messages with priority as zero. Accor=
ding to new modification any one router, lets take "Router A", will remain =
in Master state and other router, lets say "Router B", will transit to Back=
up state.

Now according to RFC-5798:
When "Router B" is in Backup state,

(420) - If an ADVERTISEMENT is received, then:



         (425) + If the Priority in the ADVERTISEMENT is zero, then:



            (430) * Set the Master_Down_Timer to Skew_Time



         (440) + else // priority non-zero



So this lead to Master_Down_Timer to expire soon.



Again in Backup state,

(365) - If the Master_Down_Timer fires, then:



         (370) + Send an ADVERTISEMENT

                    |

                    |

                    ...



         (405) + Set the Adver_Timer to Advertisement_Interval



         (410) + Transition to the {Master} state



(415) -endif // Master_Down_Timer fire



So this lead to continuous switch over from Backup to Master state and vice=
 verse state transitions in "Router B".



To avoid this condition,

In Backup state also we need to do modification. Same as you suggested in M=
aster state, same extra condition we need to check in Backup state also.

Modifications in Backup state as follows(Differences from RFC-5798 highligh=
ted with Underline):





(420) - If an ADVERTISEMENT is received, then:



         (425) + If the Priority in the ADVERTISEMENT is zero,



         (421) -+ and



         (422) -+ Local Priority is greater than zero, then:



            (430) * Set the Master_Down_Timer to Skew_Time



         (440) + else // priority non-zero or local-priority is zero

             (Continue other logic)



This will avoid state-transition flip-flap problem in "Router B".



Thanks,

Sreenatha Setty



On 02/27/2013 01:30 AM, vrrp-request@ietf.org=
 wrote:

Some concerns have been raised regarding the following situation / Corner C=
ase:

Due to congestion or some other fault in the network the ADVERTISEMENTs fro=
m the Master router do not reach backup router(s). The Master_Down_timer fi=
res and one of the back router transitions to Master State at the same time=
 the priority of this router and the original Master is set to zero. How wo=
uld the network behave in this case?



For sure the probability of this happening would be very low (as it is a do=
uble/multiple fault situation). Here is my analysis of the situation and so=
lution for the same.



We will have two Master routers both sending ADVERTISEMENTs with Priority =
=3D 0. This will create a vicious circle of sending ADVERTISEMENTs (one rou=
ter triggering the other) at a fast rate. This would also cause the Virtual=
 MAC to shuttle continuously between two ports on the switch(es) at a fast =
rate. Both of these can probably cause high CPU utilization on the router a=
nd the LAN Switches.



If there is an additional backup router available then it will become maste=
r on seeing the first Advertisement with Priority =3D 0 and both the Master=
s (with priority =3D 0) will transition to Backup on seeing the advertiseme=
nt with non-zero priority from the new Master.



For the situation where we do not have an additional backup router we can a=
void this by making following modifications (Differences from RFC-5798 high=
lighted in RED):



(700) - If an ADVERTISEMENT is received, then:



   (705) -+ If the Priority in the ADVERTISEMENT is zero,



   (701) -+ and



   (702) -+ Local Priority is greater than zero, then:



      (710) -* Send an ADVERTISEMENT



      (715) -* Reset the Adver_Timer to Advertisement_Interval



   (720) -+ else // priority was non-zero or local priority was zero



      (725) -* If the Priority in the ADVERTISEMENT is greater

      than the local Priority,



      (730) -* or



      (735) -* If the Priority in the ADVERTISEMENT is equal to

      the local Priority and the primary IPvX Address of the

      sender is greater than the local primary IPvX Address, then:



         (740) -@ Cancel Adver_Timer



         (745) -@ Set Master_Adver_Interval to Adver Interval

         contained in the ADVERTISEMENT



         (750) -@ Recompute the Skew_Time



         (755) @ Recompute the Master_Down_Interval



         (760) @ Set Master_Down_Timer to Master_Down_Interval



         (765) @ Transition to the {Backup} state



      (770) * else // new Master logic



         (775) @ Discard ADVERTISEMENT



      (780) *endif // new Master detected



   (785) +endif // was priority zero?



(790) -endif // advert recv





Please let me know if I have missed something.



Thanks

-Anurag

-------------- next part --------------

An HTML attachment was scrubbed...

URL: 



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



_______________________________________________

vrrp mailing list

vrrp@ietf.org

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





End of vrrp Digest, Vol 81, Issue 10

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




Disclaimer :
This email communication may contain privileged and confidential informatio=
n and is intended for the use of the addressee only.If you are not an inten=
ded recipient you are requested not to reproduce, copy disseminate or in an=
y manner distribute this email communication as the same is strictly prohib=
ited. If you have received this email in error, please notify the sender im=
mediately by return e-mail and delete the communication sent in error. Emai=
l communications cannot be guaranteed to be secure & error free and IB Tech=
nology is not liable for any errors in the email communication or for the p=
roper, timely and complete transmission thereof.

--_000_A2BB90B33FFDF740876C5AAE307D83DB1C295D1Cxmbrcdx05ciscoc_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











Hi Sreenatha


 <=
/p>

Totally agree with your o=
bservation.


 <=
/p>

Also as pointed out by so=
me other participants the additional backup router in my original analysis =
will never become master on seeing the first ADVERTISEMENT
 with priority zero as it will keep resetting it’s Master_Down_Timer =
to Skew_Time in the storm of ADVERTISEMENTs with zero priority and the Mast=
er_Down_Timer will never fire for the additional backup router.<=
/span>


 <=
/p>

Thanks<=
/p>

-Anurag



 <=
/p>

P.S. Noticed the typos: t=
he additional lines in my email should be numbered 706 and 707 (instead of =
701 and 702) and probably yours should be 426 and 427 (instead
 of 421 and 422).


 <=
/p>





From: sreenatha [mailto:sreenatha.setty@ibtechnology.co=
m]


Sent: Thursday, February 28, 2013 11:39 AM

To: vrrp@ietf.org

Cc: Anurag Kothari (ankothar)

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







 






Hi Anurag,

    Modification to algorithm is correct. But this modif=
ication is taking care only when Router is in Master state.

What about if Backup router(priority value is zero) receives ADVERTISEM=
ENT message with priority value as zero?



Same condition we will consider, where both VRRP routers priority is se=
t to zero, and both sending ADVERTISEMENT messages with priority as zero. A=
ccording to new modification any one router, lets take "Router A"=
, will remain in Master state and other router,
 lets say "Router B", will transit to Backup state.



Now according to RFC-5798:

When "Router B" is in Backup state,

(420) - If an ADVERTISEMENT is received, then:


 


         (425) + If the Pr=
iority in the ADVERTISEMENT is zero, then:


 


            (43=
0) * Set the Master_Down_Timer to Skew_Time


 


         (440) + else // p=
riority non-zero


 


So this lead to Master_Down_Timer to expire soon. 


 


Again in Backup state,


(365) - If the Master_Down_Timer fires, then:


 


         (370) + Send an A=
DVERTISEMENT


            &nb=
sp;       |


           &nbs=
p;        |


           &nbs=
p;        ...


           &nbs=
p;        


         (405) + Set =
the Adver_Timer to Advertisement_Interval


 


         (410) + Transitio=
n to the {Master} state


 


(415) -endif // Master_Down_Timer fire


 


So this lead to continuous switch over from Backup to Master state and=
 vice verse state transitions in "Router B".


 


To avoid this condition,


In Backup state also we need to do modification. Same as you suggested=
 in Master state, same extra condition we need to check in Backup state als=
o.


Modifications in Backup state as follows(Differences from RFC-5798 hig=
hlighted with Underline):


 


 


(420) - If an ADVERTISEMENT is received, then:


 


         (425) + If the Pr=
iority in the ADVERTISEMENT is zero, 


         

         (421) -+ =
and


 


         (422) -+ Local=
 Priority is greater than zero, then:


 


            (43=
0) * Set the Master_Down_Timer to Skew_Time


 


         (440) + else // p=
riority non-zero or local-priority is zero


           &nbs=
p; (Continue other logic)


 


This will avoid state-transition flip-flap problem in "Router B&q=
uot;.


 


Thanks,


Sreenatha Setty


 




On 02/27/2013 01:30 AM, vrrp-reque=
st@ietf.org wrote:






Some concerns have been raised regarding the following situation / Cor=
ner Case:


Due to congestion or some other fault in the network the ADVERTISEMENT=
s from the Master router do not reach backup router(s). The Master_Down_tim=
er fires and one of the back router transitions to Master State at the same=
 time the priority of this router and the original Master is set to zero. H=
ow would the network behave in this case?


 


For sure the probability of this happening would be very low (as it is=
 a double/multiple fault situation). Here is my analysis of the situation a=
nd solution for the same.


 


We will have two Master routers both sending ADVERTISEMENTs with Prior=
ity =3D 0. This will create a vicious circle of sending ADVERTISEMENTs (one=
 router triggering the other) at a fast rate. This would also cause the Vir=
tual MAC to shuttle continuously between two ports on the switch(es) at a f=
ast rate. Both of these can probably cause high CPU utilization on the rout=
er and the LAN Switches.


 


If there is an additional backup router available then it will become =
master on seeing the first Advertisement with Priority =3D 0 and both the M=
asters (with priority =3D 0) will transition to Backup on seeing the advert=
isement with non-zero priority from the new Master.


 


For the situation where we do not have an additional backup router we =
can avoid this by making following modifications (Differences from RFC-5798=
 highlighted in RED):


 


(700) - If an ADVERTISEMENT is received, then:


 


   (705) -+ If the Priority in the ADVERTISEMENT is zero=
,


 


   (701) -+ and


 


   (702) -+ Local Priority is greater than zero, then:


 


      (710) -* Send an ADVERTISEMENT


 


      (715) -* Reset the Adver_Timer to Adver=
tisement_Interval


 


   (720) -+ else // priority was non-zero or local prior=
ity was zero


 


      (725) -* If the Priority in the ADVERTI=
SEMENT is greater


      than the local Priority,

 


      (730) -* or


 


      (735) -* If the Priority in the ADVERTI=
SEMENT is equal to


      the local Priority and the primary IPvX=
 Address of the


      sender is greater than the local primar=
y IPvX Address, then:


 


         (740) -@ Cancel Adver=
_Timer


 


         (745) -@ Set Master_A=
dver_Interval to Adver Interval


         contained in the ADVE=
RTISEMENT


 


         (750) -@ Recompute th=
e Skew_Time


 


         (755) @ Recompute the=
 Master_Down_Interval


 


         (760) @ Set Master_Do=
wn_Timer to Master_Down_Interval


 


         (765) @ Transition to=
 the {Backup} state


 


      (770) * else // new Master logic


 


         (775) @ Discard ADVER=
TISEMENT


 


      (780) *endif // new Master detected


 


   (785) +endif // was priority zero?


 


(790) -endif // advert recv


 


 


Please let me know if I have missed something.


 


Thanks


-Anurag


-------------- next part --------------


An HTML attachment was scrubbed...


URL: <http://www.ietf.org/mail-archive/web/=
vrrp/attachments/20130226/cc6018e8/attachment.htm>


 


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


 


_______________________________________________


vrrp mailing list


vrrp@ietf.org


https://www.iet=
f.org/mailman/listinfo/vrrp


 


 


End of vrrp Digest, Vol 81, Issue 10


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


 




 




Disclaimer : 

This email communication may contain privileged and confidential informatio=
n and is intended for the use of the addressee only.If you are not an inten=
ded recipient you are requested not to reproduce, copy disseminate or in an=
y manner distribute this email communication
 as the same is strictly prohibited. If you have received this email in err=
or, please notify the sender immediately by return e-mail and delete the co=
mmunication 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.






--_000_A2BB90B33FFDF740876C5AAE307D83DB1C295D1Cxmbrcdx05ciscoc_--

From sreenatha.setty@ibtechnology.com  Thu Feb 28 21:03:14 2013
Return-Path: 
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 59FF221F8992 for ; Thu, 28 Feb 2013 21:03:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.298
X-Spam-Level: 
X-Spam-Status: No, score=-2.298 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_54=0.6]
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 wIrnDAjC5tlC for ; Thu, 28 Feb 2013 21:03:11 -0800 (PST)
Received: from ipinternal.indiabulls.com (ipinternal.indiabulls.com [202.54.119.192]) by ietfa.amsl.com (Postfix) with ESMTP id A0E0921F89E1 for ; Thu, 28 Feb 2013 21:03:08 -0800 (PST)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Aq0EADo2MFGsEQGd/2dsb2JhbABEgkOJZ7YJgRdzgh8BAQEBAwEBASpBCgEQCw0EBAEBAQkWAQcHCQMCAQIBFR8JCAYLAgEFAgEBBRKIBMESjToJEIE2BgUGAQaDOgOIaIVKjXSOFYFq
X-IronPort-AV: E=Sophos;i="4.84,759,1355077800"; d="scan'208,217";a="8374596"
X-IronPort-AV: E=Sophos;i="4.84,759,1355077800";  d="scan'208,217";a="103849813"
Received: from 110-234-12-145.del.tulipconnect.com (HELO [172.16.210.32]) ([110.234.12.145]) by ipgate.indiabulls.com with ESMTP; 01 Mar 2013 10:28:21 +0530
Message-ID: <5130366D.6070302@ibtechnology.com>
Date: Fri, 01 Mar 2013 10:32:37 +0530
From: sreenatha 
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/17.0 Thunderbird/17.0
MIME-Version: 1.0
To: "Anurag Kothari (ankothar)" 
References: <512F8815.5010204@ibtechnology.com> 
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------000206090703030206050006"
Cc: "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  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 01 Mar 2013 05:03:14 -0000

This is a multi-part message in MIME format.
--------------000206090703030206050006
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"; format="flowed"
Content-Transfer-Encoding: quoted-printable

Hi Anurag,
     One more point on original proposal of handling Maintenance Event.

Whether "Maintenance_Event" from user is allowed only in Master state or =

any other state?

If Maintenance_Event comes in other state(Init or Backup) apart from the =

Master state, what would be the behaviour of the router?

This point also we need to take care.

Thanks,
Sreenatha Setty


On 03/01/2013 01:31 AM, Anurag Kothari (ankothar) wrote:
>
> Hi Sreenatha
>
> Totally agree with your observation.
>
> Also as pointed out by some other participants the additional backup =

> router in my original analysis will never become master on seeing the =

> first ADVERTISEMENT with priority zero as it will keep resetting it's =

> Master_Down_Timer to Skew_Time in the storm of ADVERTISEMENTs with =

> zero priority and the Master_Down_Timer will never fire for the =

> additional backup router.
>
> Thanks
>
> -Anurag
>
> P.S. Noticed the typos: the additional lines in my email should be =

> numbered 706 and 707 (instead of 701 and 702) and probably yours =

> should be 426 and 427 (instead of 421 and 422).
>
> *From:*sreenatha [mailto:sreenatha.setty@ibtechnology.com]
> *Sent:* Thursday, February 28, 2013 11:39 AM
> *To:* vrrp@ietf.org
> *Cc:* Anurag Kothari (ankothar)
> *Subject:* Re: Proposal for Maintenance Event for VRRP [RFC-5798]
>
> Hi Anurag,
>     Modification to algorithm is correct. But this modification is =

> taking care only when Router is in Master state.
> What about if Backup router(priority value is zero) receives =

> ADVERTISEMENT message with priority value as zero?
>
> Same condition we will consider, where both VRRP routers priority is =

> set to zero, and both sending ADVERTISEMENT messages with priority as =

> zero. According to new modification any one router, lets take "Router =

> A", will remain in Master state and other router, lets say "Router B", =

> will transit to Backup state.
>
> Now according to RFC-5798:
> When "Router B" is in Backup state,
>
> (420) - If an ADVERTISEMENT is received, then:
>   =

>           (425) + If the Priority in the ADVERTISEMENT is zero, then:
>   =

>              (430) * Set the Master_Down_Timer to Skew_Time
>   =

>           (440) + else // priority non-zero
>   =

> So this lead to Master_Down_Timer to expire soon.
>   =

> Again in Backup state,
> (365) - If the Master_Down_Timer fires, then:
>   =

>           (370) + Send an ADVERTISEMENT
>                      |
>                      |
>                      ...
>                      =

>           (405) + Set the Adver_Timer to Advertisement_Interval
>   =

>           (410) + Transition to the {Master} state
>   =

> (415) -endif // Master_Down_Timer fire
>   =

> So this lead to continuous switch over from Backup to Master state and vi=
ce verse state transitions in "Router B".
>   =

> To avoid this condition,
> In Backup state also we need to do modification. Same as you suggested in=
 Master state, same extra condition we need to check in Backup state also.
> Modifications in Backup state as follows(Differences from RFC-5798 highli=
ghted with Underline):
>   =

>   =

> (420) - If an ADVERTISEMENT is received, then:
>   =

>           (425) + If the Priority in the ADVERTISEMENT is zero,
>           =

>           _(421) -+ and_
>   =

>           _(422) -+ Local Priority is greater than zero, then:_
>   =

>              (430) * Set the Master_Down_Timer to Skew_Time
>   =

>           (440) + else // priority non-zero or local-priority is zero
>               (Continue other logic)
>   =

> This will avoid state-transition flip-flap problem in "Router B".
>   =

> Thanks,
> Sreenatha Setty
>   =

>
>
> On 02/27/2013 01:30 AM, vrrp-request@ietf.org =

>  wrote:
>
>     Some concerns have been raised regarding the following situation / Co=
rner Case:
>
>     Due to congestion or some other fault in the network the ADVERTISEMEN=
Ts from the Master router do not reach backup router(s). The Master_Down_ti=
mer fires and one of the back router transitions to Master State at the sam=
e time the priority of this router and the original Master is set to zero. =
How would the network behave in this case?
>
>       =

>
>     For sure the probability of this happening would be very low (as it i=
s a double/multiple fault situation). Here is my analysis of the situation =
and solution for the same.
>
>       =

>
>     We will have two Master routers both sending ADVERTISEMENTs with Prio=
rity =3D 0. This will create a vicious circle of sending ADVERTISEMENTs (on=
e router triggering the other) at a fast rate. This would also cause the Vi=
rtual MAC to shuttle continuously between two ports on the switch(es) at a =
fast rate. Both of these can probably cause high CPU utilization on the rou=
ter and the LAN Switches.
>
>       =

>
>     If there is an additional backup router available then it will become=
 master on seeing the first Advertisement with Priority =3D 0 and both the =
Masters (with priority =3D 0) will transition to Backup on seeing the adver=
tisement with non-zero priority from the new Master.
>
>       =

>
>     For the situation where we do not have an additional backup router we=
 can avoid this by making following modifications (Differences from RFC-579=
8 highlighted in RED):
>
>       =

>
>     (700) - If an ADVERTISEMENT is received, then:
>
>       =

>
>         (705) -+ If the Priority in the ADVERTISEMENT is zero,
>
>       =

>
>         (701) -+ and
>
>       =

>
>         (702) -+ Local Priority is greater than zero, then:
>
>       =

>
>            (710) -* Send an ADVERTISEMENT
>
>       =

>
>            (715) -* Reset the Adver_Timer to Advertisement_Interval
>
>       =

>
>         (720) -+ else // priority was non-zero or local priority was zero
>
>       =

>
>            (725) -* If the Priority in the ADVERTISEMENT is greater
>
>            than the local Priority,
>
>       =

>
>            (730) -* or
>
>       =

>
>            (735) -* If the Priority in the ADVERTISEMENT is equal to
>
>            the local Priority and the primary IPvX Address of the
>
>            sender is greater than the local primary IPvX Address, then:
>
>       =

>
>               (740) -@ Cancel Adver_Timer
>
>       =

>
>               (745) -@ Set Master_Adver_Interval to Adver Interval
>
>               contained in the ADVERTISEMENT
>
>       =

>
>               (750) -@ Recompute the Skew_Time
>
>       =

>
>               (755) @ Recompute the Master_Down_Interval
>
>       =

>
>               (760) @ Set Master_Down_Timer to Master_Down_Interval
>
>       =

>
>               (765) @ Transition to the {Backup} state
>
>       =

>
>            (770) * else // new Master logic
>
>       =

>
>               (775) @ Discard ADVERTISEMENT
>
>       =

>
>            (780) *endif // new Master detected
>
>       =

>
>         (785) +endif // was priority zero?
>
>       =

>
>     (790) -endif // advert recv
>
>       =

>
>       =

>
>     Please let me know if I have missed something.
>
>       =

>
>     Thanks
>
>     -Anurag
>
>     -------------- next part --------------
>
>     An HTML attachment was scrubbed...
>
>     URL:  
>
>       =

>
>     ------------------------------
>
>       =

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

>
>       =

>
>     End of vrrp Digest, Vol 81, Issue 10
>
>     ************************************
>
>       =

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

Disclaimer : =

This email communication may contain privileged and confidential informatio=
n and is intended for the use of the addressee only.If you are not an inten=
ded recipient you are requested not to reproduce, copy disseminate or in an=
y manner distribute this email communication as the same is strictly prohib=
ited. If you have received this email in error, please notify the sender im=
mediately by return e-mail and delete the communication sent in error. Emai=
l communications cannot be guaranteed to be secure & error free and IB Tech=
nology is not liable for any errors in the email communication or for the p=
roper, timely and complete transmission thereof.

--------------000206090703030206050006
MIME-Version: 1.0
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


  
    
  
  
    
Hi Anurag,

          One more point on original proposal of ha=
ndling
        Maintenance Event. 

      

      Whether "Maintenance_Event" from user is allowed only in
        Master state or any other state?

      

      If Maintenance_Event comes in other state(Init or Backup)
        apart from the Master state, what would be the behaviour of the
        router?

      

      This point also we need to take care.

      

      Thanks,

      Sreenatha Setty

      

      

      On 03/01/2013 01:31 AM, Anurag Kothari (ankothar) wrote:

    

    

      
      
      
      

        
Hi
            Sreenatha

        
 

        
Totally
            agree with your observation.

        
 

        
Also
            as pointed out by some other participants the additional
            backup router in my original analysis will never become
            master on seeing the first ADVERTISEMENT with priority zero
            as it will keep resetting it’s Master_Down_Timer to
            Skew_Time in the storm of ADVERTISEMENTs with zero priority
            and the Master_Down_Timer will never fire for the additional
            backup router.

        
 

        
Thanks

        
-Anurag
            

        
 

        
P.S.
            Noticed the typos: the additional lines in my email should
            be numbered 706 and 707 (instead of 701 and 702) and
            probably yours should be 426 and 427 (instead of 421 and
            422).

        
 

        

          

            
From:
                sreenatha [mailto:sreenatha.setty@ibtechnology.com=
]
                

                Sent: Thursday, February 28, 2013 11:39 AM

                To: vrrp@ietf.org

                Cc: Anurag Kothari (ankothar)

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

          

        

        
 

        

          

            
Hi
                  Anurag,

                    Modification to algorithm is correct=
. But this
                  modification is taking care only when Router is in
                  Master state.

                What about if Backup router(priority value is zero)
                  receives ADVERTISEMENT message with priority value as
                  zero?

                

                Same condition we will consider, where both VRRP
                  routers priority is set to zero, and both sending
                  ADVERTISEMENT messages with priority as zero.
                  According to new modification any one router, lets
                  take "Router A", will remain in Master state and other
                  router, lets say "Router B", will transit to Backup
                  state.

                

                Now according to RFC-5798:

                When "Router B" is in Backup state,

            
(420) - If an ADVERTISEMENT is received, then:<=
/pre>
            
 

            
         (425) + I=
f the Priority in the ADVERTISEMENT is zero, then:

            
 

            
         &nbs=
p;  (430) * Set the Master_Down_Timer to Skew_Time

            
 

            
         (440) + e=
lse // priority non-zero

            
 

            
So this lead to Master_Down_Timer to expire soon. 

            
 

            
Again in Backup state,

            
(365) - If the Master_Down_Timer fires, then:
            
 

            
         (370) + S=
end an ADVERTISEMENT

            
          &nb=
sp;         |

            
         &nbs=
p;          |

            
         &nbs=
p;          ...
            
         &nbs=
p;          

            
         (405=
) + Set the Adver_Timer to Advertisement_Interval

            
 

            
         (410) + T=
ransition to the {Master} state

            
 

            
(415) -endif // Master_Down_Timer fire

            
 

            
So this lead to continuous switch over from Backup to Mast=
er state and vice verse state transitions in "Router B".

            
 

            
To avoid this condition,

            
In Backup state also we need to do modification. Same as y=
ou suggested in Master state, same extra condition we need to check in Back=
up state also.

            
Modifications in Backup state as follows(Differences from =
RFC-5798 highlighted with Underline):

            
 

            
 

            
(420) - If an ADVERTISEMENT is received, then:<=
/pre>
            
 

            
         (425) + I=
f the Priority in the ADVERTISEMENT is zero, 

            
         

            
         (=
421) -+ and

            
 

            
         (422) =
-+ Local Priority is greater than zero, then:

            
 

            
         &nbs=
p;  (430) * Set the Master_Down_Timer to Skew_Time

            
 

            
         (440) + e=
lse // priority non-zero or local-priority is zero

            
         &nbs=
p;   (Continue other logic)

            
 

            
This will avoid state-transition flip-flap problem in "Rou=
ter B".

            
 

            
Thanks,

            
Sreenatha Setty

            
 

            


              On 02/27/2013 01:30 AM, vrrp-request@ietf.org=

              wrote:

          

          

            
Some concerns have been raised regarding the following sit=
uation / Corner Case:

            
Due to congestion or some other fault in the network the A=
DVERTISEMENTs from the Master router do not reach backup router(s). The Mas=
ter_Down_timer fires and one of the back router transitions to Master State=
 at the same time the priority of this router and the original Master is se=
t to zero. How would the network behave in this case?

            
 

            
For sure the probability of this happening would be very l=
ow (as it is a double/multiple fault situation). Here is my analysis of the=
 situation and solution for the same.

            
 

            
We will have two Master routers both sending ADVERTISEMENT=
s with Priority =3D 0. This will create a vicious circle of sending ADVERTI=
SEMENTs (one router triggering the other) at a fast rate. This would also c=
ause the Virtual MAC to shuttle continuously between two ports on the switc=
h(es) at a fast rate. Both of these can probably cause high CPU utilization=
 on the router and the LAN Switches.

            
 

            
If there is an additional backup router available then it =
will become master on seeing the first Advertisement with Priority =3D 0 an=
d both the Masters (with priority =3D 0) will transition to Backup on seein=
g the advertisement with non-zero priority from the new Master.<=
/pre>
            
 

            
For the situation where we do not have an additional backu=
p router we can avoid this by making following modifications (Differences f=
rom RFC-5798 highlighted in RED):

            
 

            
(700) - If an ADVERTISEMENT is received, then:<=
/pre>
            
 

            
   (705) -+ If the Priority in the ADVERTISEMENT=
 is zero,

            
 

            
   (701) -+ and

            
 

            
   (702) -+ Local Priority is greater than zero,=
 then:

            
 

            
      (710) -* Send an ADVERTISEM=
ENT

            
 

            
      (715) -* Reset the Adver_Ti=
mer to Advertisement_Interval

            
 

            
   (720) -+ else // priority was non-zero or loc=
al priority was zero

            
 

            
      (725) -* If the Priority in=
 the ADVERTISEMENT is greater

            
      than the local Priority,

            
 

            
      (730) -* or

            
 

            
      (735) -* If the Priority in=
 the ADVERTISEMENT is equal to

            
      the local Priority and the =
primary IPvX Address of the

            
      sender is greater than the =
local primary IPvX Address, then:

            
 

            
         (740) -@ =
Cancel Adver_Timer

            
 

            
         (745) -@ =
Set Master_Adver_Interval to Adver Interval

            
         contained=
 in the ADVERTISEMENT

            
 

            
         (750) -@ =
Recompute the Skew_Time

            
 

            
         (755) @ R=
ecompute the Master_Down_Interval

            
 

            
         (760) @ S=
et Master_Down_Timer to Master_Down_Interval

            
 

            
         (765) @ T=
ransition to the {Backup} state

            
 

            
      (770) * else // new Master =
logic

            
 

            
         (775) @ D=
iscard ADVERTISEMENT

            
 

            
      (780) *endif // new Master =
detected

            
 

            
   (785) +endif // was priority zero?=


            
 

            
(790) -endif // advert recv

            
 

            
 

            
Please let me know if I have missed something.<=
/pre>
            
 

            
Thanks

            
-Anurag

            
-------------- next part --------------

            
An HTML attachment was scrubbed...

            
URL: <=
http://www.ietf.org/mail-archive/web/vrrp/attachments/20130226/cc6018e8/att=
achment.htm>

            
 

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

            
 

            
_______________________________________________=


            
vrrp mailing list

            
=
vrrp@ietf.org

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

            
 

            
 

            
End of vrrp Digest, Vol 81, Issue 10

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

            
 

          

          
 

        

        
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.<=
/p>
      

    

    

  
Disclaimer : 
This e=
mail communication may contain privileged and confidential information and =
is intended for the use of the addressee only.If you are not an intended re=
cipient you are requested not to reproduce, copy disseminate or in any mann=
er distribute this email communication as the same is strictly prohibited. =
If you have received this email in error, please notify the sender immediat=
ely by return e-mail and delete the communication sent in error. Email comm=
unications cannot be guaranteed to be secure & error free and IB Techno=
logy is not liable for any errors in the email communication or for the pro=
per, timely and complete transmission thereof.



--------------000206090703030206050006--