Internet DRAFT - draft-kothari-vrrp-graceful-failover

draft-kothari-vrrp-graceful-failover



 



Internet-Draft                                                A. Kothari
Updates: 5798, 6527 (if approved)                          Cisco Systems
Intended Status: Standards Track                          August 2, 2013
Expires: February 3, 2014                                               


                         VRRP Graceful Failover
                draft-kothari-vrrp-graceful-failover-00


Abstract

   This memo defines the use of priority zero in VRRP to failover from
   the Master router to one of the Backup routers either by operator
   input (i.e. manual failover) or automatically (e.g. on uplink
   interface going down). The procedure tries to be graceful (i.e.
   minimize outage) wherever possible. It is especially helpful in cases
   where preemption is disabled to avoid unnecessary churn.


Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as
   Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/1id-abstracts.html

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html


Copyright and License Notice

   Copyright (c) 2013 IETF Trust and the persons identified as the
   document authors. All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
 


Kothari                 Expires February 3, 2014                [Page 1]

Internet Draft           VRRP Graceful Failover           August 2, 2013


   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document. Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document. Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.



Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
     1.2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Updates  . . . . . . . . . . . . . . . . . . . . . . . . . . .  3
     2.1.  Summary of Updates . . . . . . . . . . . . . . . . . . . .  3
     2.2.  Updates to RFC5798:  . . . . . . . . . . . . . . . . . . .  4
       2.2.1.  Updates to Section 6-4-2 of RFC5798: Backup  . . . . .  4
       2.2.2.  Updates to Section 6-4-3 of RFC5798: Master  . . . . .  5
     2.3.  Updates to RFC6527:  . . . . . . . . . . . . . . . . . . .  6
       2.3.1.  Updates to Section 10 of RFC6527: Definitions  . . . .  6
   3.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . .  8
   4.  Security Considerations  . . . . . . . . . . . . . . . . . . .  8
   5.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  8
   6.  References . . . . . . . . . . . . . . . . . . . . . . . . . .  8
     6.1  Normative References  . . . . . . . . . . . . . . . . . . .  8
   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . .  8




















 


Kothari                 Expires February 3, 2014                [Page 2]

Internet Draft           VRRP Graceful Failover           August 2, 2013


1.  Introduction

   Virtual Router Redundancy Protocol (VRRP) [RFC5798] defines priority
   zero for the purpose of indicating that the Master router has stopped
   participating in VRRP and the Backup routers should quickly
   transition to Master without waiting for the current Master to
   timeout. It defines it's use only during the Shutdown event in Master
   State.

   This memo defines a new "Change event" and also makes priority zero
   for VRRP a user configurable value. It defines it use under this new
   "Change event" in Master state to initiate a failover to the Backup
   router especially when preemption is disabled. It uses a make before
   break approach to minimize outage wherever possible.

   This document is being discussed on the vrrp@ietf.org mailing list.

1.2.  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].


2.  Updates


2.1.  Summary of Updates

   This memo updates the following RFC sections:

      1)  Section 6.4.2. of [RFC5798]:
          o  Update steps 425, and 440 of Backup State.

      2)  Section 6.4.3. of [RFC5798]:
          o  Define Change event.
          o  Update step 680, 695, 705, and 720 of Master State.

      3)  Section 10. of [RFC6527]: 
          o  Update vrrpv3OperationsPriority OBJECT-TYPE.
          o  Update vrrpv3FullCompliance MODULE-COMPLIANCE.







 


Kothari                 Expires February 3, 2014                [Page 3]

Internet Draft           VRRP Graceful Failover           August 2, 2013


2.2.  Updates to RFC5798:

2.2.1.  Updates to Section 6-4-2 of RFC5798: Backup

   <snip>

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

         (425) + If the Priority in the ADVERTISEMENT is zero, and Local
         Priority is greater than zero, then:

            (430) * Set the Master_Down_Timer to Skew_Time

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

   <snip>































 


Kothari                 Expires February 3, 2014                [Page 4]

Internet Draft           VRRP Graceful Failover           August 2, 2013


2.2.2.  Updates to Section 6-4-3 of RFC5798: Master

   A Change event would be triggered by change in any one of the
   following parameters of the VRRP Packet:

      1)  "Priority" Section 5.2.4 of [RFC5798]

      2)  "Maximum Advertisement Interval (Max Adver Int)" Section 5.2.7
          of [RFC5798]

      3)  "IPvX Address(es)" Section 5.2.9 of [RFC5798]

   Handling of the Change event is only applicable in Master state as
   VRRP packets are not sent in other states.

   <snip>

      (680) - If the Adver_Timer fires, or Change event is received,
      then:

         (685) + Send an ADVERTISEMENT

         (690) + Reset the Adver_Timer to Advertisement_Interval

      (695) -endif // advertisement timer fired or Change event received

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

         (705) -+ If the Priority in the ADVERTISEMENT is zero, and
         Local Priority is greater than zero, then:

            (710) -* Send an ADVERTISEMENT

            (715) -* Reset the Adver_Timer to Advertisement_Interval

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

   <snip>









 


Kothari                 Expires February 3, 2014                [Page 5]

Internet Draft           VRRP Graceful Failover           August 2, 2013


2.3.  Updates to RFC6527:

2.3.1.  Updates to Section 10 of RFC6527: Definitions

   --  VRRPv3 Operations Table

   <snip>

       vrrpv3OperationsPriority OBJECT-TYPE
           SYNTAX       Unsigned32 (0..255)
           MAX-ACCESS   read-create
           STATUS       current
           DESCRIPTION
             "This object specifies the priority to be used for the
             virtual router master election process; higher values
             imply higher priority.

             A priority of '0', is sent by the master router to
             indicate that it wants to release the Master
             responsibility, and a backup virtual router should
             transition to become a new master.

             A priority of 255 is used for the router that owns the
             associated IP address(es) for VRRP over IPv4 and hence
             is not setable.

             Setting the values of this object to 255 should be
             rejected by the agents implementing this MIB module.  
             For example, an SNMP agent would return 'badValue(3)' 
             when a user tries to set the values 255 for this 
             object."

           REFERENCE "RFC 5798, Section 6.1"
           DEFVAL       { 100 }
           ::= { vrrpv3OperationsEntry 7 }

   <snip>











 


Kothari                 Expires February 3, 2014                [Page 6]

Internet Draft           VRRP Graceful Failover           August 2, 2013


   -- Compliance Statements

       vrrpv3FullCompliance MODULE-COMPLIANCE
           STATUS current
           DESCRIPTION
              "The compliance statement"
           MODULE -- this module
           MANDATORY-GROUPS  {
               vrrpv3OperationsGroup,
               vrrpv3StatisticsGroup,
               vrrpv3InfoGroup,
               vrrpv3NotificationsGroup
           }
           OBJECT        vrrpv3OperationsPriority
           WRITE-SYNTAX  Unsigned32 (0..254)
           DESCRIPTION  "Setable values are from 0 to 254."
           ::= { vrrpv3Compliances 1 }

   <snip>





























 


Kothari                 Expires February 3, 2014                [Page 7]

Internet Draft           VRRP Graceful Failover           August 2, 2013


3.  Acknowledgements

   The Author would like to thank Peter Hunt (one of the original
   authors of VRRP) for his inputs and review.

4.  Security Considerations

   No new Security Considerations are introduced by this memo. The
   Security Considerations from [RFC5798] and [RFC6527] are still
   applicable.

5.  IANA Considerations

   No new IANA Considerations are introduced by this memo. The IANA
   Considerations from [RFC5798] and [RFC6527] are still applicable.

6.  References

6.1  Normative References

   [RFC2119]         Bradner, S., "Key words for use in RFCs to Indicate
                     Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC5798]         Nadas, S., Ed., "Virtual Router Redundancy Protocol
                     (VRRP) Version 3 for IPv4 and IPv6", RFC 5798,
                     March 2010.

   [RFC6527]         Tata, K., "Definitions of Managed Objects for
                     Virtual Router Redundancy Protocol Version 3
                     (VRRPv3)", RFC 6527, March 2012.

Author's Address


   Anurag Kothari
   Cisco Systems
   7200 Kit Creek Road
   RTP, NC 27709
   USA


   EMail: ankothar@cisco.com









Kothari                 Expires February 3, 2014                [Page 8]