VRRP Minutes - 40th IETF, Washington, D.C., 12/9/97 Bob Hinden - Chair Minutes taken by Barbara Denny Agenda ------ Introduction Review Agenda Changes in Current Draft 02-Dec-97 Advancing VRRP draft to Proposed Standard Review VRRP MIB IPv6 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 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. Review Agenda ------------------- No modifications were made to the Agenda. 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. 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. 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 3 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. IPv6 ------ 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.