VRRP Working Group Meeting Chicago IETF August 25, 1998 Bob Hinden / Nokia, Chair Minutes taken by David Whipple / Microsoft ------------------------------------------------------------- Introduction ------------ Bob Hinden opened the meeting. Review Agenda ------------- 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) - Interop? Bob H. took an action to discuss with Bill from UNH. This will be scheduled sometime this fall. 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. ------------------ Meeting adjourned ------------------