2.5.11 Virtual Router Redundancy Protocol (vrrp)

NOTE: This charter is a snapshot of the 58th IETF Meeting in Minneapolis, Minnesota USA. It may now be out-of-date.

Last Modified: 2003-10-15

Chair(s):
Radia Perlman <radia.perlman@sun.com>
Mukesh Gupta <Mukesh.Gupta@nokia.com>
Routing Area Director(s):
Bill Fenner <fenner@research.att.com>
Alex Zinin <zinin@psg.com>
Routing Area Advisor:
Alex Zinin <zinin@psg.com>
Mailing Lists:
General Discussion: vrrp@ietf.org
To Subscribe: vrrp-request@ietf.org
In Body: subscribe vrrp
Archive: https://www1.ietf.org/mail-archive/working-groups/vrrp/current/index.html
Description of Working Group:
The purpose of this working group is to define and develop a standard virtual router redundancy protocol for IPv4 and IPv6. A virtual router redundancy protocol is a protocol which allows several routers on a multiaccess link to utilize the same virtual IP address. One router will be elected as a master with the other routers acting as backups in case of the failure of the master router. The primary motivation to using a virtual router redundancy protocol is that host systems may be configured (manually or via DHCP) with a single default gateway, rather than running an active routing protocol. The protocol should also support the ability to load share traffic when both routers are up.

The goals of this working group are: 1. Define and develop a standard virtual router redundancy protocol for IPv4 and IPv6.

2. Develop VRRP MIB(s).

3. Separate specifications will be developed for IPv4 and IPv6.

4. Determine whether static (configuration based) load sharing is adequate or if some amount of dynamic load sharing is required.

5. Working group will examine security issues to determine what security threats it is appropriate for the VRRP protocol to handle and include the appropriate mechanisms in the VRRP protocol.

6. The internet draft "Virtual Router Redundancy Protocol" (draft-hinden-vrrp-00.txt) will be use as the basis of virtual router redundancy protocol. The working group will also consider other Internet-Drafts related to this topic allowing for issues regarding change control, security, running code, etc.

7. Intellectual property issues regarding the technology to develop a virtual router redundancy protocol will be identified and addressed.

Goals and Milestones:
Done  Charter Working Group
Done  Issue new Internet Drafts for IPv4 version of the protocol.
Done  Review and finalize IPv4 Internet Drafts.
Done  Issue Internet Draft for IPv6 version of VRRP.
Done  Submit revised IPv4 Internet Drafts to IESG for proposed standard.
Done  Issue VRRP MIB drafts.
Done  Issue revised draft for IPv6 version of VRRP.
Done  Finalize MIB draft and submit to IESG.
Done  Resolve open issues with authentication methods
Done  Issue VRRPv3 (VRRP for IPv6) MIB drafts
Done  Submit updated version of VRRP (IPv4) for Draft Standard
Oct 03  Submit VRRP for IPv6 (VRRPv3) for Proposed Standard
Dec 03  Submit MIB for VRRPv3 for Proposed Standard
Dec 03  Review the WG goals and future potential
Internet-Drafts:
  • - draft-ietf-vrrp-spec-v2-09.txt
  • - draft-ietf-vrrp-ipv6-spec-05.txt
  • - draft-ietf-vrrp-ipv6-mib-00.txt
  • - draft-ietf-vrrp-unified-mib-00.txt
  • Request For Comments:
    RFCStatusTitle
    RFC2338 PS Virtual Router Redundancy Protocol
    RFC2787 PS Definitions of Managed Objects for the Virtual Router Redundancy Protocol using SNMPv2

    Current Meeting Report

    list.Virtual Router Redundancy Protocol WG (vrrp)
    Thursday, November 13, 2003 at 0900-1130 in Rochester Room
    
    Chairs:	
    Mukesh Gupta Mukesh.Gupta@nokia.com
    Radia Perlman radia.perlman@sun.com
    
    Minutes taken by Karen O'Donoghue.
    
    The chairs provided a proposed agenda as follows:
    Introduction and Review Agenda
    VRRP MIB
    Milestones/Plans
    Current Drafts' status
    VMACs vs ND
    CARP (Common Address Redundancy Protocol)
    Miscellaneous Issues
    
    A discussion of the appropriate approach for the VRRP MIB was led  by 
    Kalyan Tata. He presented a summary of the arguments for maintaining  a 
    separate MIB for IPv4 and IPv6 or for merging the two MIBs into a  single 
    unified MIB for both. Bert Wijnen clarified a misunderstanding  on the part 
    of the working group on the meaning of deprecation and the  impact on 
    backward compatibility. The consensus of the room was to  pursue the 
    unified MIB approach. 
    
    Mukesh Gupta discussed the current status of the working group efforts  
    including milestones and current drafts. A revised list of milestones  
    based on slight delays in current efforts was presented. VRRPv2 (for  
    IPv4) is in the IESG review process with some minor 
    clarifications being  completed. VRRPv3 (for IPv6) needs to resolve the 
    VMAC versus ND issue.  The VRRP MIB draft needs resolution of the 
    separated versus unified MIB  approaches. With the completion of these 
    remaining work items, the  working group needs to consider where to go 
    next. 
    
    Mark Hollinger led a discussion of the issue of Neighbor Discovery (ND)  
    versus Virtual  MAC (VMAC) for VRRPv3. He discussed the historical 
    context  of the use of VMAC. He also presented the advantages and 
    disadvantages for  using VMAC. A number of scenarios were presented along 
    with the performance  of VMAC in each scenario. Finally, a summary list of 
    changes were proposed  for the incorporation of ND into VRRPv3. Radia 
    Perlman asked the room who  wanted VMAC removed and who wanted ND used 
    instead. Bob Hinden pointed out  that a proper evaluation of the ND 
    approach could not be without seeing  the actual modifications to the 
    document. Bob Hinden and Mark Hollinger  agreed to discuss the details 
    offline. A decision can only be made once a  concrete proposal is on the 
    table. 
    
    Jun-ihiro itojun Hagino from the OpenBSD community presented the common  
    address redundancy protocol (CARP). Points of contact for the effort  
    include mcbride@openbsd and deraadt@openbs.org. The goal of the CARP  
    effort is to have a protocol in this problem space that is completely  
    patent-free. The CARP community has evaluated VRRP and believes both VRRP  
    and CARP do not infringe on any HSRP claims. Bob Hinden questioned the  
    validity of this analysis and whether or not Cisco would agree with that  
    analysis. The primary technical differences between CARP and VRRP were  
    summarized. The discussion evolved back to the topic of patents. Scott  
    Bradner expressed a concern about the CARP community not having 
    discussed  their analysis with Cisco. Bob Hinden questioned the 
    mechanics of the  reliability mechanism used by CARP. The conclusion of the 
    discussion was  that an internet-draft needs to be prepared in order to 
    seriously consider  CARP in the context of this working group. 
    
    The chairs asked if there were any additional topics from the floor. Mark  
    Hollinger asked about the status of the subsecond work discussed at the  
    Vienna IETF. Karen O'Donoghue admitted that she had not completed the  
    draft on this issue in time for the draft cutoff. The routing AD 
    indicated  that the BFD (bi-directional forwarding) work being 
    discussed in the routing  area should be considered here as well. The 
    routing AD agreed to forward the  BFD material to the VRRP WG.
    
    The meeting was adjourned. 
    

    Slides

    Agenda
    VRRP-MIB
    VMAC for VRRPv3?
    CARP: common address redundancy protocol