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

"Adrian Farrel" <adrian@olddog.co.uk> Wed, 22 May 2013 16:12 UTC

Return-Path: <adrian@olddog.co.uk>
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 BFDF121F96C9 for <vrrp@ietfa.amsl.com>; Wed, 22 May 2013 09:12:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.472
X-Spam-Level:
X-Spam-Status: No, score=-2.472 tagged_above=-999 required=5 tests=[AWL=0.127, BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FqCBU8yDD1PG for <vrrp@ietfa.amsl.com>; Wed, 22 May 2013 09:12:10 -0700 (PDT)
Received: from asmtp3.iomartmail.com (asmtp3.iomartmail.com [62.128.201.159]) by ietfa.amsl.com (Postfix) with ESMTP id 760A821F96E7 for <vrrp@ietf.org>; Wed, 22 May 2013 09:12:09 -0700 (PDT)
Received: from asmtp3.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id r4MGC6qs014397; Wed, 22 May 2013 17:12:06 +0100
Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id r4MGC5Rr014376 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 22 May 2013 17:12:06 +0100
From: "Adrian Farrel" <adrian@olddog.co.uk>
To: <vrrp@ietf.org>
References: <512F8815.5010204@ibtechnology.com> <A2BB90B33FFDF740876C5AAE307D83DB1C295D1C@xmb-rcd-x05.cisco.com> <5130366D.6070302@ibtechnology.com> <A2BB90B33FFDF740876C5AAE307D83DB1C2963EE@xmb-rcd-x05.cisco.com> <5131B583.3000500@ibtechnology.com> <A2BB90B33FFDF740876C5AAE307D83DB1C297B31@xmb-rcd-x05.cisco.com>
In-Reply-To: <A2BB90B33FFDF740876C5AAE307D83DB1C297B31@xmb-rcd-x05.cisco.com>
Date: Wed, 22 May 2013 17:12:05 +0100
Message-ID: <026201ce5707$1a816bc0$4f844340$@olddog.co.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQHn+BVuC0d9lEynakgH2ZCVLHLX3AMQu56kAZ1jxcQBlJ/KbAMWSf5xAikaf26YggxCYA==
Content-Language: en-gb
Cc: "'fhrp-team\(mailer list\)'" <fhrp-team@cisco.com>
Subject: Re: [VRRP] Proposal for Maintenance Event for VRRP [RFC-5798]
X-BeenThere: vrrp@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: adrian@olddog.co.uk
List-Id: Virtual Router Redundancy Protocol <vrrp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/vrrp>, <mailto:vrrp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/vrrp>
List-Post: <mailto:vrrp@ietf.org>
List-Help: <mailto:vrrp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/vrrp>, <mailto:vrrp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 22 May 2013 16:12:15 -0000

Hi,

If you are wondering how to progress this in the IETF, the answer is...

- write an I-D
- discuss it (here)
- polish it
- ask me to sponsor it for publication as an RFC.

Cheers,
Adrian

> -----Original Message-----
> From: vrrp-bounces@ietf.org [mailto:vrrp-bounces@ietf.org] On Behalf Of
> Anurag Kothari (ankothar)
> Sent: 04 March 2013 23:43
> To: sreenatha; vrrp@ietf.org
> Cc: fhrp-team(mailer list)
> Subject: Re: [VRRP] Proposal for Maintenance Event for VRRP [RFC-5798]
> 
> Hi Sreenatha
> 
> If you mean "if I am not wrong" then yes what you have said below is correct.
> 
> Also I believe the objective (particularly in case of time sensitive
application) is to
> avoid any unnecessary switch overs; as already suggested earlier let's call
this a
> "Change Event" instead of "Maintenance Event". The "Change Event" would be
> triggered by change in one of the following parameters of the VRRP Packet :
> 
> 1) Priority (Section 5.2.4. of RFC-5798)
> 2) Max Adver Int (Section 5.2.7. of RFC-5798)
> 
> And possibly:
> 
> 3) IPvX Address(es) (Section 5.2.9.  of RFC-5798)
> 
> The "Change Event" would only be handled in Master State and ignored in other
> state as the VRRP Packets are only supposed to be sent by the Master.
> 
> So to rephrase the proposal:
> 
>     - If a Change event is received, then:
> 
>     + Send an ADVERTISEMENT
> 
>     + Reset the Adver_Timer to Advertisement_Interval
> 
>     -endif // Change recv
> 
> To cover the failover scenario (in the absence of preemption) Priority = 0
will now
> have to be allowed along with the previously discussed modifications to avoid
a
> storm of Priority = 0 Advertisements from two masters.
> 
> Please Share your thoughts.
> 
> Thanks
> -Anurag
> 
> -----Original Message-----
> From: sreenatha [mailto:sreenatha.setty@ibtechnology.com]
> Sent: Saturday, March 02, 2013 3:17 AM
> To: Anurag Kothari (ankothar)
> Cc: vrrp@ietf.org
> Subject: Re: Proposal for Maintenance Event for VRRP [RFC-5798]
> 
> Hi Anurag,
>      Thanks for clarification.
> 
>       If i am wrong, user is allowed to configure Priority value as zero(i.e.,
> Maintenance_Event), priority value will be changed. And handling of the
> Maintenance_Event is done only in Master state and ignored in Backup and Init
> state.
> 
> Thanks,
> Sreenatha
> 
> On 03/01/2013 08:31 PM, Anurag Kothari (ankothar) wrote:
> > Hi Sreenatha
> >
> > I don't think we need to define a "Maintenance_Event" when the router is in
> either Init or Backup State. The intention of the "Maintenance_Event" is to
> trigger a failover from "Master" to a "Backup" router as soon as possible
> (especially when preemption is not configured).
> >
> > But if you are asking if priority = 0 should be allowed (either by user
> configuration or dynamically) when the router is in "Init" or "Backup" state
then I
> think the answer should be yes, It should be treated just like any other
change in
> priority is treated when the router is in these states.
> >
> > Please let me know if I am missing something.
> >
> > Thanks
> > -Anurag
> >
> >
> 
> Disclaimer :
> This email communication may contain privileged and confidential information
> and is intended for the use of the addressee only.If you are not an intended
> recipient you are requested not to reproduce, copy disseminate or in any
manner
> distribute this email communication as the same is strictly prohibited. If you
have
> received this email in error, please notify the sender immediately by return
e-
> mail and delete the communication sent in error. Email communications cannot
> be guaranteed to be secure & error free and IB Technology is not liable for
any
> errors in the email communication or for the proper, timely and complete
> transmission thereof.
> 
> _______________________________________________
> vrrp mailing list
> vrrp@ietf.org
> https://www.ietf.org/mailman/listinfo/vrrp