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
Bob Hinden <firstname.lastname@example.org>
Routing Area Director(s):
Joel Halpern <email@example.com>
Routing Area Advisor:
Joel Halpern <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.
· Virtual Router Redundancy Protocol
No Request For Comments
Minutes of the Virtual Router Redundancy Protocol (VRRP) WG
Chair: Bob Hinden
Reported by: Barbara Denny
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
On June 12th, the working group charter was approved.
The mailing list is firstname.lastname@example.org. To subscribe to the general discussion, send a message to email@example.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:
· Use Real IP Addresses Instead of Virtual IP Addresses
- No assignment of Virtual IP addresses needed
- ICMP redirects supported
- sending rules complex; need to figure out which router the packet was sent to (this is not the IP destination field)
- Efficient with secondary addresses
- Makes network management much easier
- Requires careful management of Virtual MAC (need to make sure the physical address is not learned when you start running VRRP
· Revised Header Format
- Variable length now
- More efficient (you don't need one packet per subnet)
· Added Token Ring Support (Acee Lindem, IBM)
· Added IANA assignments
- multicast address
- protocol number
- MAC assignment is not done yet. IANA wants to think this over since they have not done this before. NOTE:
- IANA assignment in current assigned numbers is not correct.
- They thought the protocol was at the link layer. Working group may pursue getting assignment from somewhere else like Xerox PARC.
· Corrected text and references to HMAC-MD5-96 for MD5 authentication
· Improved terminology and clarified text
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):
· Version 02 - Use real instead of Virtual IP addresses (Major)
- Updated version number to 2
- Modified packet header
- New terminology (removed cluster, virtual IP address, etc.,
· added VRID, associated IP address(es), etc).
- Special case of priority = 255 for router owning VRID and associated IP address(es)
- Reworked examples
- Rewrote introductory and overview sections
- Added rules for redirects and ARP
- Added sending gratuitous ARP request when transitioning to Master
· Version 03
- Updated text and references to point to "The Use of HMAC-MD5-96 within ESP and AH" that is the correct reference for the use of IPSEC AH with MD5
· Version 04
- Added IANA assignments for protocol and multicast address. MAC prefix still needed.
- Added Token Ring specific procedures supplied by Acee Lindem and added him as an author.
- Tightened up terminology and definitions and made appropriate changes in the text.
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.
To solve the problem within Ipv6, two approaches are being investigated:
· Setting router advertisement parameters to small values
· Adding VRRP option to Neighbor Discovery
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.
go to list