NOTE: This charter is a snapshot of the 41st IETF Meeting in Los Angeles, California. It may now be out-of-date. Last Modified: 12-Feb-98
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 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.
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:
· Virtual Router Redundancy Protocol
· Definitions of Managed Objects for the Virtual Router Redundancy Protocol using SNMPv2
No Request For Comments
Minutes of the Virtual Router Redundancy Protocol (vrrp) Working Group
Chair: Robert Hinden / Nokia,
Reported by Joe Eykholt / Nokia
Agenda
I. Agenda Bashing
II. Status
III. Intellectual Property Issues
IV. Review of VRRP MIB Draft
V. VRRP for IPv6
I. Status
IESG advanced VRRP to Proposed Standard on 18 Mar 1998, based on Draft 6.
II. Intellectual Property Issues
Two patents that may have impact on VRRP are:
· Cisco: Standby Routing Protocol, 5,473,599, December 5, 1995.
· IBM: Cluster patent, 5,371,852.
Patent information available via http://womplex.ibm.com/patent
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]
Q. Would Cisco license the patent to implementors of HSRP and/or VRRP?
A. HSRP yes, VRRP no.
Comments from others: The IBM patent may have precedence. Both patents may apply separately.
Cisco contacts for patent issues are Martin McNealus (sp?), Robert Barr (sp?) and Steve Gordon (sp?).
III. VRRP MIB - Brian Jewel, 3COM
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 }].
Danny Mitzel, Nokia, agreed with using the IP address - "it makes row creation clearer"
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.
None Received