Subject: VRRP W.G. Minutes from Dec97 IETF

From: Bob Hinden <[email-masked]>
Date: Tue, 13 Jan 1998 10:32:14 -0800

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 <draft-ietf-vrrp-spec-04.txt> 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 [email-masked]. To subscribe to the general
  discussion, send a message to [email-masked] 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.		

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.

---------------