2.5.17 Virtual Router Redundancy Protocol (vrrp)

NOTE: This charter is a snapshot of the 40th IETF Meeting in Washington, DC. It may now be out-of-date. Last Modified: 28-Oct-97

Chair(s):

Bob Hinden <hinden@ipsilon.com>

Routing Area Director(s):

Joel Halpern <jhalpern@newbridge.com>

Routing Area Advisor:

Joel Halpern <jhalpern@newbridge.com>

Mailing Lists:

General Discussion:vrrp@drcoffsite.com
To Subscribe: listserv@drcoffsite.com w
In Body: subscribe vrrp <your_name>
Archive: ftp://ftp.ietf.org/ietf-mail-archive/vrrp/*

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:

Jun 97

  

Charter Working Group

Jul 97

  

Issue new Internet Drafts for IPv4 version of the protocol.

Aug 97

  

Issue Internet Draft for IPv6 version of VRRP.

Aug 97

  

Review and finalize IPv4 Internet Drafts.

Aug 97

  

Resolve any intellectual property issues regarding protocol.

Sep 97

  

Submit revised IPv4 Internet Drafts to IESG for proposed standard.

Oct 97

  

Issue VRRP MIB drafts.

Oct 97

  

Issue revised draft for IPv6 version of VRRP.

Dec 97

  

Review and finalize IPv6 Internet Drafts.

Dec 97

  

Finalize MIB draft and submit to IESG.

Jan 98

  

Submit revised IPv6 Internet Drafts to IESG for proposed standard.

Internet-Drafts:

No Request For Comments

Current Meeting Report

Minutes of the Virtual Router Redundancy Protocol (VRRP) WG

Chair: Bob Hinden

Reported by: Barbara Denny

Agenda

I. Introduction
II. Review Agenda
III. Changes in Current Draft <draft-ietf-vrrp-spec-04.txt> 02-Dec-97
IV. Advancing VRRP draft to Proposed Standard
V. Review VRRP MIB
VI. IPv6

I. Introduction

On June 12th, the working group charter was approved.

The mailing list is vrrp@drcoffsite.com. To subscribe to the general discussion, send a message to listserv@drcoffsite.com with subscribe vrrp <your_name> in the body of the message. The mail archive is : ftp://ftp.ietf.org/ietf-mail-archive/vrrp/*.

The Goals and Milestones for this working group are:

Jun 97 Charter Working Group
Jul 97 Issue new Internet Draft for IPv4 of the protocol.
Aug 97 Issue Internet Draft for IPv6 version of VRRP.
Aug 97 Review and finalize IPv4 Internet Draft.
Aug 97 Resolve any intellectual property issues regarding protocol.
Sep 97 Submit revised IPv4 Internet Draft to IESG for proposed standard.
Oct 97 Issue VRRP MIB drafts.
Oct 97 Issue revised draft for IPv6 version of VRRP.
Dec 97 Review and finalize IPv6 Internet Drafts.
Dec 97 Finalize MIB draft and submit to IESG.
Jan 98 Submit revised IPv6 Internet Draft to IESG for proposed standard.

II. Review Agenda

No modifications were made to the Agenda.

III. Changes in Current Draft

The changes made to the VRRP protocol from the draft presented at the Munich IETF are:

Summary of the modifications for each submitted version from the base spec are: (Note this is only for the record. This information was not presented during the meeting):

There were questions regarding whether ping and traceroute worked properly with VRRP. Ping is not a problem. Traceroute will also work okay. It will show the master router in the path. This is one way you can see VRRP working since the master router may not be the default router. Bob Hinden noted that maybe he should add something in the spec regarding VRRP and the use of common network debugging tools.

The question regarding intellectual property rights came up again as in the previous meeting. Cisco holds a patent (U.S. Patent 5,473,599) and has said nothing more from the previous meeting regarding the issue of a fair and non-discriminatory license. IBM stood up and said they may have a patent as well and in their search may have found 13 other patents that apply. They will send more information to the mailing list. In general, the fact that patents may exist is not a roadblock for the working group as long as there is a license which is fair and non-discriminatory. The IESG will not judge patents. It is the company that is releasing a product needs to decide what they want to do and whether there will be an infringement on the patent.

IV. Advancing VRRP Draft to Proposed Standard

At the last IETF meeting in Munich, VRRP was selected to be used as the protocol in the standards process. There was a question asked if the working group had considered using HSRP instead of VRRP. The answer was that this topic had been discussed at the previous meeting (Munich IETF) and that the working group had agreed to continue to work on VRRP with the goal of making it a standard.

The chair polled the attendees to see if there was a consensus to move the current VRRP draft to Proposed Standard. There was a rough consensus to submit it to the IESG for Proposed Standard. This will be done once the MAC prefix assignment has been obtained.

V. Review VRRP MIB

Brian Jewell of 3Com present the work that he and David Chuang have done on the draft. Probably due to submitting the draft very close to the deadline for this meeting, the MIB did not get posted as an internet-draft. The availability of the MIB, however, was advertised to the mailing list and those interested could have requested a copy from Brian. Unfortunately, during the meeting it looked like very few people had time to review the MIB. The discussion of the MIB will now occur on the mailing list and Brian will incorporate feedback in the next draft. Brian also has an action item to determine what had happened regarding the posting of the MIB.

There was some brief discussion regarding the design philosophy of the MIB. An attempt was made to design the MIB from an application perspective using network management platforms such as HP Openview and IBM's Netview. The thought was how would it look at a router running VRRP. This is reflected in the arrangement of the information in the MIB. It was mentioned that others in the group are taking the perspective that a network management application could be the one responsible for catching VRRP configuration problems since you need a more global view. You can't determine all errors from local knowledge.

It was pointed out that one of the scenarios, scenario 2, in the current draft is invalid. This will be fixed.

The author requested that people pay particular attention the SNMP trap section. There are currently three traps defined. He wants to know whether the objects in the trap are correct.

The author mentioned how he looked at other MIBs in drafting the current MIB. However, he pointed out there is a great lack of consistency in the MIBs right now. Joel Halpern mentioned there is a MIB advisory group and someone from that group needs to be identified to help with the VRRP MIB. Representatives from both the working group and the MIB advisory group can then perform the necessary review.

VI. IPv6

To solve the problem within Ipv6, two approaches are being investigated:

The working group chair is discussing the alternatives with the Neighbor Discovery authors and a time slot has been scheduled in the Friday IPng session.

Slides

None Received

Attendees List

go to list

Previous PageNext Page