NOTE: This charter is a snapshot of the 42nd IETF Meeting in Chicago, Illinois. It may now be out-of-date. Last Modified: 23-Jul-98
Bob Hinden <firstname.lastname@example.org>
Routing Area Director(s):
Rob Coltun <email@example.com>
Routing Area Advisor:
Rob Coltun <firstname.lastname@example.org>
To Subscribe: email@example.com w
In Body: subscribe vrrp <your_name>
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:
Charter Working Group
Issue new Internet Drafts for IPv4 version of the protocol.
Issue Internet Draft for IPv6 version of VRRP.
Review and finalize IPv4 Internet Drafts.
Resolve any intellectual property issues regarding protocol.
Submit revised IPv4 Internet Drafts to IESG for proposed standard.
Issue VRRP MIB drafts.
Issue revised draft for IPv6 version of VRRP.
Review and finalize IPv6 Internet Drafts.
Finalize MIB draft and submit to IESG.
Submit revised IPv6 Internet Drafts to IESG for proposed standard.
Request For Comments:
Virtual Router Redundancy Protocol
VRRP Working Group Meeting
Chicago IETF August 25, 1998
Bob Hinden / Nokia, Chair
Minutes taken by David Whipple / Microsoft
Bob Hinden opened the meeting.
The following agenda was presented:
- Introduction / Bob Hinden
- Review Agenda / Bob Hinden
- Move VRRP to draft standard / Bob Hinden
- Final review of VRRP MIB / Brian Jewell
Move VRRP to draft standard / Bob Hinden
After quick introductions the requirements for moving VRRP to draft standard were
reviewed by Bob Hinden.
The following requirements must be met:
- Six months after proposed standard
- Two or more independent implementations
- Insure no open issues with protocol
- Collect implementation information
- Interoperability testing
It was asked if more than one router can participate in a group? It was answered yes,
and briefly described how VRRP operates.
Several other general questions were asked such as "What happens if you send a 0
priority?" and it was decided to take these comments to the list...
Someone asked what the current status of the patent issues are? He replied was that
there had not been any change that he was aware of. Both Cisco and IBM have made
IPR claims regarding VRRP, and that any implementers of VRRP should do their own
review of the issues and make a decision as how they should proceed.
It was asked if we could add a rely on gratuitous ARP? It was noted this has discussed
on the list several times previously and that gratuitous ARP was not implemented on
many hosts reliably enough. The general consensus was that this is not a good idea.
Redundancy solutions that are not 100% effective are not helpful.
The question of whether or not a VRRP backup (which has become master) should
respond to ping. It was noted this is confusing for customers if they cannot ping the
router even though it is forwarding traffic. Much discussion ensued. The benefits of
not responding are it makes a down owner noticeable by network management. The
default behavior should be not to respond (although specific implementations may
implement a switch).
A question about whether or not we should discard a VRRP packet if its adver_interval
is not equal to the local routers adver_interval for a specific virtual router. Bob H.
agreed to take a look at the current specification and make sure this is the behavior.
The consensus was to discard the packet.
The issue of using a default TTL of 255 was brought up momentarily and we agreed
this had already been discussed on the list. No change.
An implementation template was presented. The intention is for implementers of VRRP
to fill this out. This will be utilized to show multiple independent implementations. The
template will be sent to the mailing list.
The subject of interoperability testing then came up. We agreed to organize a independent
test somewhere. Several locations where discussed. They included:
- University of New Hampshire. (this seemed to be the most popular)
Bob H. took an action to discuss with Bill from UNH. This will be scheduled sometime
Another issue was then discussed about the behavior of a VRRP router when being
configured. There was some confusion if a VRRP router should send a grat. ARP when
configured. The general consensus was that only the master should do so. Bob H. took
an action to check the draft to make sure this was how it is specified.
Final review of VRRP MIB / Brian Jewell
Brian Jewell of 3COM then presented an update on the VRRP MIB.
Revision 2 is currently on web site. A revision 3 will be posted soon.
Brian reviewed several required changes to the MIB:
He mentioned he was going to rewrite the portion on how rows in tables are deleted and
modified. He had lots of comments on this.
An issue with VRRP_OPER_AUTH_TYPE and VRRP_OPER_AUTH_KEY was
discussed. The issue was that the draft defines them per interface and the MIB per
Virtual router. Many options were discussed such as should we just leave them per
VR or should we define a new table? There was also some concern about whether
they should be read/write or only read.
The consensus was to change the draft to make them per VR to match the MIB.
It was asked if there are any other issues with the MIB. No...
The some discussion ensued about VRRP_OPER_CONTROL. A comment about
looking at how SNMPv2 row creation works was made. We agreed to take this
discussion to the list.
The plan is to do a working group last call once the next version of the MIB is published.
VIRTUAL ROUTER REDUNDANCY PROTOCOLWORKING GROUP
go to list