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

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:

· Virtual Router Redundancy Protocol

· Definitions of Managed Objects for the Virtual Router Redundancy Protocol using SNMPv2

No Request For Comments

Current Meeting Report

Minutes of the Virtual Router Redundancy Protocol (vrrp) Working Group

Martin McNealus (sp?) from Cisco said a few words about the Cisco patent. Cisco claims VRRP infringes on the HSRP patent. Since HSRP was submitted to the working group, to standardize VRRP instead of HSRP would be an attempt to compromise patent rights.

[Note: Patents are public and there is no issue with standards documents infringing on patents. Infringement occurs when patented ideas are included in shipping products]

Feedback from the December IETF and e-mail list has been incorporated into the Rev 01 draft.

Fred Baker is assisting the MIB doc as the IETF official MIB representative.

Additional feedback has been incorporated into the Rev 02 draft.

Q. Some fields are per-interface (not per-interface AND per VRID), for example the authentication method and key, but are described by the MIB as per-interface and per VRID. This could result in a conflict in settings. How should this be resolved?

Discussion: Q. Are there any other fields similar to this in other MIBS. A. There's a similar object in RFC 2275 (SNMP V3 security).

Q. Do these have to be in the MIB or not?Q. Make it read-only instead of read-create?Comment: Another MIB can be obtained.Comment: OK to put this in by ifindex/VRid.

It was requested that specific suggestions be posted to the list.

Q. Why would the major key be the ifindex and the minor key be the VRID instead of the other way around?

A. The VRID has to be unique on a link, but it's possible to have the same VRID on different interfaces.

Q. What was the reason for not indexing by IP address for the vrrpAssoIpAddrEntry table. [indexed by { ifIndex, vrrpOperVrId, vrrpAssoIpAddrIndex }].

Brian said this is addressed in other MIBs (RFC 1903) and is a common problem in other MIBs. He'll consider and may post something to the mailing list.

Comment: in this case IPaddress will make the row unique.

The group was asked if there were any objections to making this change. There were none.

Brian said the 02 revision should be done in a month or so. Will incorporate any input received.

IV. IPv6 Changes for VRRP

Suggestion: Test with two IPv6 routers, cranking down the router advertisement frequency to see if a solution is needed. Hosts should switch when one router dies. If times are too long, we could change IPv6 or do something with VRRP for IPv6. It'd be nice not to need VRRP for IPv6.