From VRRP-owner@kahn.drcoffsite.com Wed Oct 29 09:33:49 1997 Delivery-Date: Wed, 29 Oct 1997 09:33:49 -0500 Return-Path: VRRP-owner@kahn.drcoffsite.com Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ietf.org (8.8.7/8.8.7a) with ESMTP id JAA16752 for ; Wed, 29 Oct 1997 09:33:48 -0500 (EST) Received: from kahn.drcoffsite.com (gw.drcoffsite.com [207.247.102.1]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with SMTP id JAA09501 for ; Wed, 29 Oct 1997 09:36:32 -0500 (EST) Received: from [192.208.46.20] by kahn.drcoffsite.com with ESMTP (SMTPD32-4.02) id ABF04590240; Wed, 29 Oct 1997 08:36:48 EST5EDT Received: from shand.reo.dec.com (shand.reo.dec.com [16.36.16.22]) by mail12.digital.com (8.7.5/UNX 1.5/1.0/WV) with SMTP id IAA04017; Wed, 29 Oct 1997 08:26:20 -0500 (EST) Received: from osicwg.reo.dec.com by shand.reo.dec.com (5.65/MS-010395) id AA00395; Wed, 29 Oct 1997 13:25:35 GMT Received: by localhost with Microsoft MAPI; Wed, 29 Oct 1997 13:24:43 -0000 Message-Id: <250F9C8DEB9ED011A14D08002BE4F64C6E56B5@wade.reo.dec.com> From: Mike Shand Reply-To: "shand@mail.dec.com" To: "'Acee Lindem'" , IETF VRRP List Subject: RE: VRRP Draft Date: Wed, 29 Oct 1997 13:23:49 -0000 Organization: Digital Equipment Co X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4211 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Precendence: bulk Sender: VRRP-owner@kahn.drcoffsite.com On Wednesday, October 29, 1997 12:59 AM, Acee Lindem [SMTP:acee@raleigh.ibm.com] wrote: > With the new draft, one thing that occurred to me is that > if one is the owner of Virtual Router (i.e., the addresses > associated with the virtual router are your own local IP addresses) > you must use the VRID virtual MAC in ARP requests as well as > ARP responses. The reason being that many ARP implementations > will update their ARP cache when a ARP request is received. > Absolutely. The current draft is supposed to have some text to describe this requirement, but it may be rather obscure. Its in section 8.2 where it says "They should only send ARP messages that include the Virtual MAC address". Perhaps we should make this more explicit by saying:- "When a Master router transmits an ARP request it MUST put its virtual MAC address in the Sender Hardware Address field of the ARP message". > Futhermore, the ARP requests must have the virtual MAC address > as the MAC header source address for all the same reasons as we > want the virtual MAC address to be the MAC header source address > in ARP responses. I'm not sure I understand this. Why do you think it is important for the MAC header source address to be "correct"? As far as I am aware, there are no RFCs which require any checks on this field, nor any implementations which actually perform such a check. If you know of any I would be very interested to know about them. Of course it could be argued that use of the correct MAC address might speed up bridge learning, but since we use the virtual MAC address as the source MAC address of the VRRP hellos, which are sent once per second by default, there seems to be very little to be gained. > Another complication is communications between routers. > When one receives an ARP request, one cannot determine if it > is from a host or router. Hence, all IP exchanges must use the > VRID MAC address. If one is running a state-full routing protocol > (e.g., OSPF), a backup virtual router will not only take over > forwarding packets as hosts but will also take over any > protocol-specific flows. This shouldn't be too much of a problem > since I would expect them to fail (however, not in a > deterministic manner). > Yes, that's true. Of course most of the OSPF protocol is sent in multicast packets which are addressed to specific MAC multicasts. i.e. the hellos and the normal database updates to and from the DR (and backup). The only messages that get unicast are the failure recovery packets. In the event of a router failing between the multicast transmit and the subsequent unicast recovery, then the packet will be delivered to the virtual MAC address and end up at the Master router which has adopted the failed router. However, as you correctly point out, since the packet is addressed to the failed router's IP address it will NOT be delivered to the master router's IP stack, and therefore will cause no interference. The loss of such a packet is immaterial to the correctness of the OSPF operation. Similar arguments apply to ping and SNMP packets addressed to the failed router. Not that it is possible that if only an interface on the 'failed' router has actually failed, there may be an alternate path to the router over which such packets may be delivered (depending on exactly how the routers advertise subnets and host routes {i.e. /32 routes}, and what TTL is set in the packet). I don't think any of this causes any problems. > When we had a separate virtual IP address these situations > could not occur since all ARP requests and routing protocol > exchanges could use the separate IP addresses. > > I'm not advocating a change back to the virtual IP address > approach - I just wanted to assure my thinking is correct. > > Thanks, > -- > Acee From VRRP-owner@kahn.drcoffsite.com Wed Oct 29 09:53:08 1997 Delivery-Date: Wed, 29 Oct 1997 09:53:09 -0500 Return-Path: VRRP-owner@kahn.drcoffsite.com Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ietf.org (8.8.7/8.8.7a) with ESMTP id JAA17277 for ; Wed, 29 Oct 1997 09:53:08 -0500 (EST) Received: from kahn.drcoffsite.com (gw.drcoffsite.com [207.247.102.1]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with SMTP id JAA09609 for ; Wed, 29 Oct 1997 09:55:55 -0500 (EST) Received: from [204.146.167.235] by kahn.drcoffsite.com with ESMTP (SMTPD32-4.02) id AA5230930230; Wed, 29 Oct 1997 09:38:10 EST5EDT Received: from rtpmail02.raleigh.ibm.com (rtpmail02.raleigh.ibm.com [9.37.172.48]) by fwns1.raleigh.ibm.com (AIX4.2/UCB 8.7/8.7RTP-FW1.1) with ESMTP id JAA49314; Wed, 29 Oct 1997 09:32:01 -0500 (EST) Received: from aceman.raleigh.ibm.com (aceman.raleigh.ibm.com [9.37.177.119]) by rtpmail02.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id JAA23812; Wed, 29 Oct 1997 09:32:02 -0500 Received: from loopback by aceman.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA23936; Wed, 29 Oct 1997 09:31:50 -0500 X-Sender: acee@raleigh.ibm.com Message-Id: <345748D6.15FB@raleigh.ibm.com> Date: Wed, 29 Oct 1997 09:31:50 -0500 From: Acee Lindem Organization: IBM Networking Divison X-Mailer: Mozilla 3.01 (X11; I; AIX 1) Mime-Version: 1.0 To: "shand@mail.dec.com" Cc: IETF VRRP List Subject: Re: VRRP Draft References: <250F9C8DEB9ED011A14D08002BE4F64C6E56B5@wade.reo.dec.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Precendence: bulk Sender: VRRP-owner@kahn.drcoffsite.com Mike Shand wrote: > > Futhermore, the ARP requests must have the virtual MAC address > > as the MAC header source address for all the same reasons as we > > want the virtual MAC address to be the MAC header source address > > in ARP responses. > I'm not sure I understand this. Why do you think it is important for the MAC > header source address to be "correct"? As far as I am aware, there are no RFCs > which require any checks on this field, nor any implementations which actually > perform such a check. If you know of any I would be very interested to know > about them. Of course it could be argued that use of the correct MAC address > might speed up bridge learning, but since we use the virtual MAC address as the > source MAC address of the VRRP hellos, which are sent once per second by > default, there seems to be very little to be gained. Although I haven't thought through all the scenarios, I'm mainly concerned about token ring where ARP implementations cache the source-route bridging RIF (Route Information Field) from the ARP MAC header. Within a couple weeks, I should be able to post more on token ring operation. -- Acee From VRRP-owner@kahn.drcoffsite.com Wed Oct 29 16:23:11 1997 Delivery-Date: Wed, 29 Oct 1997 16:23:11 -0500 Return-Path: VRRP-owner@kahn.drcoffsite.com Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ietf.org (8.8.7/8.8.7a) with ESMTP id QAA24282 for ; Wed, 29 Oct 1997 16:23:10 -0500 (EST) Received: from kahn.drcoffsite.com (gw.drcoffsite.com [207.247.102.1]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with SMTP id QAA11362 for ; Wed, 29 Oct 1997 16:26:12 -0500 (EST) Received: from [139.87.182.242] by kahn.drcoffsite.com with ESMTP (SMTPD32-4.02) id A7AABFF902A0; Wed, 29 Oct 1997 16:16:26 EST5EDT Received: from tdc97.ops.3com.com ([139.87.12.115]) by tdc.3com.com (Netscape Mail Server v2.02) with SMTP id AAA13311 for ; Wed, 29 Oct 1997 13:06:24 -0800 Message-Id: <3.0.32.19971029131448.0115f820@pop.nsd.3com.com> X-Sender: denny@pop.nsd.3com.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Wed, 29 Oct 1997 13:14:49 -0800 To: vrrp@drcoffsite.com From: Barbara Denny Subject: VRRP MIB Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Precendence: bulk Sender: VRRP-owner@kahn.drcoffsite.com Hi, We are working on the MIB for VRRP. Right now, we plan to write it to be compliant with snmp v1. If anyone has a strong reason for v2, please speak up! barbara From VRRP-owner@kahn.drcoffsite.com Wed Oct 29 16:40:17 1997 Delivery-Date: Wed, 29 Oct 1997 16:40:18 -0500 Return-Path: VRRP-owner@kahn.drcoffsite.com Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ietf.org (8.8.7/8.8.7a) with ESMTP id QAA24697 for ; Wed, 29 Oct 1997 16:40:17 -0500 (EST) Received: from kahn.drcoffsite.com (gw.drcoffsite.com [207.247.102.1]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with SMTP id QAA11409 for ; Wed, 29 Oct 1997 16:43:19 -0500 (EST) Received: from [129.192.64.25] by kahn.drcoffsite.com (SMTPD32-4.02) id AB632CAD0224; Wed, 29 Oct 1997 16:32:19 EST5EDT Received: from clover.acc.com.acc.com by fennel.acc.com (4.1/SMI-4.1) id AA27130; Wed, 29 Oct 97 13:30:36 PST From: evan@acc.com (Evan Caves) Message-Id: <9710292130.AA27130@fennel.acc.com> Subject: Re: VRRP MIB To: denny@3com.com (Barbara Denny) Date: Wed, 29 Oct 1997 13:30:50 -0800 (PST) Cc: vrrp@drcoffsite.com In-Reply-To: <3.0.32.19971029131448.0115f820@pop.nsd.3com.com> from "Barbara Denny" at Oct 29, 97 01:14:49 pm X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Precendence: bulk Sender: VRRP-owner@kahn.drcoffsite.com If you are saying that the VRRP MIB will be written using the SMIv1 syntax then yes this is a problem. I believe that all IETF MIB's that were to be submitted past a certain date (long since past) MUST be written using the SMIv2 syntax. evan - > > Hi, > > We are working on the MIB for VRRP. Right now, we plan > to write it to be compliant with snmp v1. If anyone has a strong > reason for v2, please speak up! > > barbara > > > From VRRP-owner@kahn.drcoffsite.com Thu Oct 30 18:13:12 1997 Delivery-Date: Thu, 30 Oct 1997 18:13:13 -0500 Return-Path: VRRP-owner@kahn.drcoffsite.com Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ietf.org (8.8.7/8.8.7a) with ESMTP id SAA20467 for ; Thu, 30 Oct 1997 18:13:06 -0500 (EST) Received: from kahn.drcoffsite.com (gw.drcoffsite.com [207.247.102.1]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with SMTP id SAA15966 for ; Thu, 30 Oct 1997 18:16:00 -0500 (EST) Received: from [205.226.5.12] by kahn.drcoffsite.com (SMTPD32-4.02) id A29416C0246; Thu, 30 Oct 1997 18:04:52 EST5EDT Received: from spruce.ipsilon.com (slip202-135-41-71.kw.jp.ibm.net [202.135.41.71]) by mailhost.Ipsilon.COM (8.6.11/8.6.10) with SMTP id PAA09902; Thu, 30 Oct 1997 15:02:57 -0800 Message-Id: <3.0.3.32.19971030150236.00a76100@mailhost.ipsilon.com> X-Sender: hinden@mailhost.ipsilon.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Thu, 30 Oct 1997 15:02:36 -0800 To: vrrp@drcoffsite.com From: Bob Hinden Subject: [40th IETF-WASHINGTON: VRRP] Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Precendence: bulk Sender: VRRP-owner@kahn.drcoffsite.com The VRRP w.g. will meet on Tuesday December 9 at the Washington IETF. Bob >X-Sender: mbeaulie@ietf.org >X-Mailer: Windows Eudora Pro Version 2.2 (32) >Date: Thu, 30 Oct 1997 17:43:07 -0500 >To: Bob Hinden >From: Marcia Beaulieu >Subject: 40th IETF-WASHINGTON: VRRP >Cc: jhalpern@newbridge.com > >This is to confirm one session for VRRP as follows: > > Tuesday, December 9 at 1545-1800 (two consecutive one-hour sessions) > (opposite grip, dnsind, ipsec, ids) > >Please submit an agenda (to agenda@ietf.org) for this meeting as soon >as possible. > >Thanks, > >Marcia > >********************************************************************** >Marcia Beaulieu >IETF Meeting Coordinator >Voice: 703-620-8990 ext. 210 >Fax: 703-758-5913 > > > From VRRP-owner@kahn.drcoffsite.com Thu Oct 30 23:03:49 1997 Delivery-Date: Thu, 30 Oct 1997 23:03:49 -0500 Return-Path: VRRP-owner@kahn.drcoffsite.com Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ietf.org (8.8.7/8.8.7a) with ESMTP id XAA28617 for ; Thu, 30 Oct 1997 23:03:49 -0500 (EST) Received: from kahn.drcoffsite.com (gw.drcoffsite.com [207.247.102.1]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with SMTP id XAA16599 for ; Thu, 30 Oct 1997 23:06:44 -0500 (EST) Received: from [129.213.128.99] by kahn.drcoffsite.com with ESMTP (SMTPD32-4.02) id A70E451025A; Thu, 30 Oct 1997 22:57:02 EST5EDT Received: from new-york.3com.com (new-york.3com.com [129.213.157.12]) by janus.3com.com (8.8.2/8.8.5) with ESMTP id TAA19001 for ; Thu, 30 Oct 1997 19:55:13 -0800 (PST) Received: from chicago.nsd.3com.com (chicago.nsd.3com.com [129.213.157.11]) by new-york.3com.com (8.8.2/8.8.5) with ESMTP id TAA10955 for ; Thu, 30 Oct 1997 19:54:11 -0800 (PST) Received: from towada.nsd.3com.com (towada.nsd.3com.com [129.213.48.46]) by chicago.nsd.3com.com (8.8.2/8.8.5) with ESMTP id TAA12614; Thu, 30 Oct 1997 19:55:12 -0800 (PST) From: David Tsao-Pin Chuang Received: (from dtc@localhost) by towada.nsd.3com.com (8.8.2/8.8.5) id TAA13903; Thu, 30 Oct 1997 19:57:06 -0800 (PST) Message-Id: <199710310357.TAA13903@towada.nsd.3com.com> Subject: Virtual Router MAC address To: vrrp@drcoffsite.com Date: Thu, 30 Oct 1997 19:57:05 -0800 (PST) Cc: dtc@ewd.3Com.com (David Tsao-Pin Chuang) X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Precendence: bulk Sender: VRRP-owner@kahn.drcoffsite.com Hi, In Vrrp Version 2, if a router support vrrp on more than one ports then the router will use the same Virtual Router MAC address on these ports. Is this going to cause any problem? (I think)Since they are on different networks, hopefully, the same virtual MAC address will not cause any problem. Best Regards, David From VRRP-owner@drcoffsite.com Fri Nov 7 12:46:19 1997 Delivery-Date: Fri, 07 Nov 1997 12:46:19 -0500 Return-Path: VRRP-owner@drcoffsite.com Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ietf.org (8.8.7/8.8.7a) with ESMTP id MAA09221 for ; Fri, 7 Nov 1997 12:46:13 -0500 (EST) Received: from drcoffsite.com (gw.drcoffsite.com [207.247.102.1]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with SMTP id MAA19841 for ; Fri, 7 Nov 1997 12:49:04 -0500 (EST) Received: from janus.3com.com [129.213.128.99] by drcoffsite.com with ESMTP (SMTPD32-4.02c) id A0B612C901AA; Fri, 07 Nov 1997 12:32:38 EST5EDT Received: from new-york.3com.com (new-york.3com.com [129.213.157.12]) by janus.3com.com (8.8.2/8.8.5) with ESMTP id JAA28639 for ; Fri, 7 Nov 1997 09:30:42 -0800 (PST) Received: from chicago.nsd.3com.com (chicago.nsd.3com.com [129.213.157.11]) by new-york.3com.com (8.8.2/8.8.5) with ESMTP id JAA19765 for ; Fri, 7 Nov 1997 09:28:26 -0800 (PST) Received: from fubar.nsd.3com.com (fubar.nsd.3com.com [129.213.16.41]) by chicago.nsd.3com.com (8.8.2/8.8.5) with ESMTP id JAA14540; Fri, 7 Nov 1997 09:30:32 -0800 (PST) From: Brian Jewell Received: (from bjewell@localhost) by fubar.nsd.3com.com (8.8.2/8.8.5) id JAA08015; Fri, 7 Nov 1997 09:30:19 -0800 (PST) Date: Fri, 7 Nov 1997 09:30:19 -0800 (PST) Message-Id: <199711071730.JAA08015@fubar.nsd.3com.com> To: vrrp@drcoffsite.com Subject: Clarification in VRRP Draft Cc: bjewell@ewd.3Com.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-MD5: l3dxU9sTM5WNCY7yzolYCg== Precendence: bulk Sender: VRRP-owner@drcoffsite.com Hi, Currently I am working on the draft VRRP MIB and wanted to point out an area of the VRRP Draft document that I felt needed some clarification. In Section 3.0, it states: "On an interface running VRRP, each VRRP router must be configured with a virtual router identifier for the addresses it owns... . In addition, each VRRP router is assigned a priority... ." In section 6.1.2, entitled "Parameters Per Virtual Router", both the VRID and the priority are listed. I assume that the term "virtual router" is being used in the context of "interface", as opposed to, say, a "physical" router. Thus, each interface (on a physical router) can have a unique VRID and "priority" assigned (or maybe different VRID's and the same priority - but not the same VRID's??). So to reiterate: a router using VRRP on multiple interfaces *must* have different VRID's assigned to each interface, and *may or may not* have different priorities assigned (to each interface). Let me know if I am interpreting this incorrectly. But, either way, I just wanted to point out that section 6.1.2 (along with the definition of "virtual router" in Section 1.2) could use some clarification such that these parameters are not interpreted as being "global", i.e., one per physical router. Thanks. Brian Jewell 3Com, Inc. From VRRP-owner@drcoffsite.com Fri Nov 7 17:42:03 1997 Delivery-Date: Fri, 07 Nov 1997 17:42:03 -0500 Return-Path: VRRP-owner@drcoffsite.com Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ietf.org (8.8.7/8.8.7a) with ESMTP id RAA13366 for ; Fri, 7 Nov 1997 17:42:02 -0500 (EST) Received: from drcoffsite.com (gw.drcoffsite.com [207.247.102.1]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with SMTP id RAA21040 for ; Fri, 7 Nov 1997 17:44:52 -0500 (EST) Received: from mail4.microsoft.com [131.107.3.29] by drcoffsite.com with ESMTP (SMTPD32-4.02c) id A6672810156; Fri, 07 Nov 1997 17:29:59 EST5EDT Received: by mail4.microsoft.com with Internet Mail Service (5.5.1960.3) id ; Fri, 7 Nov 1997 14:09:02 -0800 Message-ID: <4D0A23B3F74DD111ACCD00805F31D810697434@red-msg-50.dns.microsoft.com> From: David Whipple To: "'vrrp@drcoffsite.com'" Subject: VRRP over LANE Date: Fri, 7 Nov 1997 13:21:18 -0800 X-Mailer: Internet Mail Service (5.5.1960.3) Precendence: bulk Sender: VRRP-owner@drcoffsite.com I was wondering if there was any interest in running VRRP over LANE (LAN Emulation for ATM)? We have a specific application in which it would be very nice to have VRRP redundancy on a LANE network, but due to the nature of LANE, VRRP wouldn't directly work. Specifically, we have approx. 100 LEC's (ATM switches) which only point default at a router for network management. Of course whenver the router boots, we loose visiability to all our ATM switches via the LEC. At any rate, if any one else has interest in this let me know, and we could possibly add a section, or produce another draft. Thanks. David Whipple. From VRRP-owner@drcoffsite.com Mon Nov 10 00:55:08 1997 Delivery-Date: Mon, 10 Nov 1997 00:55:09 -0500 Return-Path: VRRP-owner@drcoffsite.com Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ietf.org (8.8.7/8.8.7a) with ESMTP id AAA10028 for ; Mon, 10 Nov 1997 00:55:05 -0500 (EST) Received: from drcoffsite.com (gw.drcoffsite.com [207.247.102.1]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with SMTP id AAA01419 for ; Mon, 10 Nov 1997 00:57:48 -0500 (EST) Received: from mailhost.detroit.mi.ameritech.net [206.141.193.243] by drcoffsite.com with ESMTP (SMTPD32-4.02c) id AD82EB9028C; Mon, 10 Nov 1997 00:37:06 EST5EDT Received: from ameritech.net (dyn-max3-47.detroit.mi.ameritech.net [206.141.225.47]) by mailhost.detroit.mi.ameritech.net (8.8.3/8.8.3-AIMS) with ESMTP id AAA17097; Mon, 10 Nov 1997 00:35:21 -0500 (EST) Message-ID: <34669D41.2D24C0F1@ameritech.net> Date: Mon, 10 Nov 1997 00:36:01 -0500 From: Rob Montgomery Reply-To: robm@null.net X-Mailer: Mozilla 4.03 [en] (Win95; U) MIME-Version: 1.0 To: vrrp@drcoffsite.com CC: hinden@ipsilon.com Subject: Virtual MAC Addresses in VRRP Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Precendence: bulk Sender: VRRP-owner@drcoffsite.com Hi all. Allow me to apologize in advance if this subject has been covered already (I did look through the archives, but it's always possible.) As a user of Cisco's HSRP, I am excited by the idea of a standards based solution. However, there is an operational issue with HSRP that has not been addressed in the VRRP draft. My concern with the VRRP protocol draft, as it stands, has to do with the virtual MAC address. While it will function fine in most networks, I have run across problems with Cisco's HSRP, and ATM's LAN Emulation. While things are slowly changing, most Proxy LEC's (Proxy LAN Emulation Client) that I have worked with have significant trouble with MAC Address mobility. In short, when a MAC address moves, it takes (in a default configuration) 300 seconds for the new location of the MAC address to be learned by all LEC's on the Emulated LAN. This gives us our 'black hole' again. The most common solution (that I have used/seen) involves placing both the primary and redundant routers behind the same LEC. However, we are now left with a single point of failure - The LEC. I would, therefore, propose that the concept of a Virtual MAC address be abandoned, and that we take advantage of the ARP protocol to do it's work. Should a fail over occur, would it not make sense for the new master router, upon becoming the master router, to transmit a broadcast ARP packet, with the op-code set to ares_op$REPLY. This packet should contain the Source IP address of the Virtual Router, the Source MAC Address of the Master Router, an unknown Target IP Address (probably 255.255.255.255) and an unknown Target MAC Address (probably FF:FF:FF:FF:FF:FF). By setting the op-code to 'reply', this would not generate a storm of ARP Responses. In this way, all devices on the broadcast domain would receive (through the broadcast MAC Address) an updated MAC to IP pairing for the virtual router (pairing the Virtual Router IP with the hard coded 48 Bit MAC Address of the Master Router), without disrupting any LANE LE_ARP Cache, or any other tables that might inhibit MAC Address mobility. I have attached the relevant portion of RFC-826. I hope this makes some sense, and any comments are, of course, eagerly anticipated. Thanks, Rob Montgomery robm@null.net --------------------------- RFC - 826, David C. Plummer, November 1982. An Ethernet Address Resolution Protocol or Converting Network Protocol Addresses to 48.bit Ethernet Address for Transmission on Ethernet Hardware Begin Quote--------------------------------------------------------- When an address resolution packet is received, the receiving Ethernet module gives the packet to the Address Resolution module which goes through an algorithm similar to the following. Negative conditionals indicate an end of processing and a discarding of the packet. ?Do I have the hardware type in ar$hrd? Yes: (almost definitely) [optionally check the hardware length ar$hln] ?Do I speak the protocol in ar$pro? Yes: [optionally check the protocol length ar$pln] Merge_flag := false If the pair is already in my translation table, update the sender hardware address field of the entry with the new information in the packet and set Merge_flag to true. ?Am I the target protocol address? Yes: If Merge_flag is false, add the triplet to the translation table. ?Is the opcode ares_op$REQUEST? (NOW look at the opcode!!) Yes: Swap hardware and protocol fields, putting the local hardware and protocol addresses in the sender fields. Set the ar$op field to ares_op$REPLY Send the packet to the (new) target hardware address on the same hardware on which the request was received. End Quote---------------------------------------------------------- Rob Montgomery robm@null.net From VRRP-owner@drcoffsite.com Mon Nov 10 02:37:17 1997 Delivery-Date: Mon, 10 Nov 1997 02:37:18 -0500 Return-Path: VRRP-owner@drcoffsite.com Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ietf.org (8.8.7/8.8.7a) with ESMTP id CAA10299 for ; Mon, 10 Nov 1997 02:37:16 -0500 (EST) Received: from drcoffsite.com (gw.drcoffsite.com [207.247.102.1]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with SMTP id CAA01496 for ; Mon, 10 Nov 1997 02:40:01 -0500 (EST) Received: from gw.treehouse.napa.ca.us [206.184.205.189] by drcoffsite.com with ESMTP (SMTPD32-4.02c) id A62B19E9028C; Mon, 10 Nov 1997 02:22:19 EST5EDT Received: from wd8oml.treehouse.napa.ca.us (wd8oml.treehouse.napa.ca.us [192.168.64.32]) by gw.treehouse.napa.ca.us with ESMTP id XAA01488 (8.7.4/IDA-1.6 for ); Sun, 9 Nov 1997 23:20:26 -0800 (PST) Received: (from paul@localhost) by wd8oml.treehouse.napa.ca.us (8.8.7/8.8.7) id XAA22596 for vrrp@drcoffsite.com; Sun, 9 Nov 1997 23:20:25 -0800 (PST) From: "G. Paul Ziemba" Message-Id: <199711100720.XAA22596@wd8oml.treehouse.napa.ca.us> Subject: seeking arp clarification To: vrrp@drcoffsite.com Date: Sun, 9 Nov 1997 23:20:23 -0800 (PST) X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Precendence: bulk Sender: VRRP-owner@drcoffsite.com In draft-ietf-vrrp-spec-03, Page 20 at the bottom (8.2 Host ARP Requests), the first paragraph of 8.2 concludes: The request MUST be handled as a standard ARP reply. I don't understand what this means. Could someone please clarify? thanks, ~!paul From VRRP-owner@drcoffsite.com Mon Nov 10 04:02:19 1997 Delivery-Date: Mon, 10 Nov 1997 04:02:19 -0500 Return-Path: VRRP-owner@drcoffsite.com Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ietf.org (8.8.7/8.8.7a) with ESMTP id EAA10592 for ; Mon, 10 Nov 1997 04:02:18 -0500 (EST) Received: from drcoffsite.com (gw.drcoffsite.com [207.247.102.1]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with SMTP id EAA01606 for ; Mon, 10 Nov 1997 04:05:14 -0500 (EST) Received: from mailhost.Ipsilon.COM [205.226.5.12] by drcoffsite.com (SMTPD32-4.02c) id A9BC3A18023A; Mon, 10 Nov 1997 03:45:48 EST5EDT Received: from mustang.ipsilon.com (mustang.Ipsilon.COM [205.226.1.196]) by mailhost.Ipsilon.COM (8.6.11/8.6.10) with ESMTP id AAA28158; Mon, 10 Nov 1997 00:43:49 -0800 Message-Id: <199711100843.AAA28158@mailhost.Ipsilon.COM> To: robm@null.net cc: vrrp@drcoffsite.com, hinden@Ipsilon.COM Subject: Re: Virtual MAC Addresses in VRRP In-reply-to: Your message of "Mon, 10 Nov 1997 00:36:01 EST." <34669D41.2D24C0F1@ameritech.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 10 Nov 1997 00:43:26 -0800 From: "Danny J. Mitzel" Precendence: bulk Sender: VRRP-owner@drcoffsite.com Rob Montgomery writes: >> I would, therefore, propose that the concept of a Virtual MAC >> address be abandoned, and that we take advantage of the ARP >> protocol to do it's work. abadoning the VMAC concept would most likely also simplify implementation on some platforms because it eliminates the need to grunge around with the link layer header. however I think there has been concern raised about IP stacks on a non-trivial number of deployed end-hosts that do not properly handle gratuitous ARP and changes to the IP/MAC mapping. thus the adoption of a fixed IP/VMAC mapping and the text at the end of section 8.2 mentioning how important it is to avoid any actions that could result in changes to the IP/MAC mapping over time. my personal take is that in the face of these incompatible options there is probably more interest/benefit in accommodating the broken end-host implementations than dealing with LANE limitations. From VRRP-owner@drcoffsite.com Mon Nov 10 04:05:12 1997 Delivery-Date: Mon, 10 Nov 1997 04:05:13 -0500 Return-Path: VRRP-owner@drcoffsite.com Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ietf.org (8.8.7/8.8.7a) with ESMTP id EAA10611 for ; Mon, 10 Nov 1997 04:05:12 -0500 (EST) Received: from drcoffsite.com (gw.drcoffsite.com [207.247.102.1]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with SMTP id EAA01613 for ; Mon, 10 Nov 1997 04:08:11 -0500 (EST) Received: from mailhost.Ipsilon.COM [205.226.5.12] by drcoffsite.com (SMTPD32-4.02c) id AB383D81023A; Mon, 10 Nov 1997 03:52:08 EST5EDT Received: from mustang.ipsilon.com (mustang.Ipsilon.COM [205.226.1.196]) by mailhost.Ipsilon.COM (8.6.11/8.6.10) with ESMTP id AAA28299; Mon, 10 Nov 1997 00:49:47 -0800 Message-Id: <199711100849.AAA28299@mailhost.Ipsilon.COM> To: "G. Paul Ziemba" cc: vrrp@drcoffsite.com Subject: Re: seeking arp clarification In-reply-to: Your message of "Sun, 09 Nov 1997 23:20:23 PST." <199711100720.XAA22596@wd8oml.treehouse.napa.ca.us> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 10 Nov 1997 00:49:24 -0800 From: "Danny J. Mitzel" Precendence: bulk Sender: VRRP-owner@drcoffsite.com "G. Paul Ziemba" writes: >> In draft-ietf-vrrp-spec-03, Page 20 at the bottom (8.2 Host ARP Requests), >> the first paragraph of 8.2 concludes: >> >> The request MUST be handled as a standard ARP reply. >> >> I don't understand what this means. Could someone please clarify? that paragraph does seem a bit unfocused. most of the paragraph is dealing with the requirements the virtual router must comply with when generating ARP reply. but then that last sentence appears to be addressing the end-host that generated the ARP request. and it just says that the ARP reply for a VRRP address is no different from any other ARP reply, thus the end host should process it in whatever its ``standard'' method is. cheers, From VRRP-owner@drcoffsite.com Mon Nov 10 04:24:10 1997 Delivery-Date: Mon, 10 Nov 1997 04:24:11 -0500 Return-Path: VRRP-owner@drcoffsite.com Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ietf.org (8.8.7/8.8.7a) with ESMTP id EAA10715 for ; Mon, 10 Nov 1997 04:24:09 -0500 (EST) Received: from drcoffsite.com (gw.drcoffsite.com [207.247.102.1]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with SMTP id EAA01637 for ; Mon, 10 Nov 1997 04:26:59 -0500 (EST) Received: from mail13.digital.com [192.208.46.30] by drcoffsite.com with ESMTP (SMTPD32-4.02c) id AF333ED0029E; Mon, 10 Nov 1997 04:09:07 EST5EDT Received: from shand.reo.dec.com (shand.reo.dec.com [16.36.16.22]) by mail13.digital.com (8.7.5/UNX 1.5/1.0/WV) with SMTP id DAA20426; Mon, 10 Nov 1997 03:56:36 -0500 (EST) Received: from osicwg.reo.dec.com by shand.reo.dec.com (5.65/MS-010395) id AA17098; Mon, 10 Nov 1997 08:57:10 GMT Received: by localhost with Microsoft MAPI; Mon, 10 Nov 1997 08:56:19 -0000 Message-Id: <250F9C8DEB9ED011A14D08002BE4F64C6E56CE@wade.reo.dec.com> From: Mike Shand Reply-To: "shand@mail.dec.com" To: "vrrp@drcoffsite.com" Cc: "bjewell@ewd.3Com.com" Subject: RE: Clarification in VRRP Draft Date: Mon, 10 Nov 1997 08:55:26 -0000 Organization: Digital Equipment Co X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4211 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Precendence: bulk Sender: VRRP-owner@drcoffsite.com Brian, I agree we could do with some tidying up of terminology. Certainly the term 'Virtual Router' applies on an interface basis, not just for the entire physical router. The reality is that each independent subnetwork (I use the term in the OSI sense, not the IP subnet sense; i.e. each set of router interfaces {on the same or different physical routers} that have mutual connectivity at layer 2), MUST have a non-overlapping set of VRIDs. Interfaces which attach to different independent subnetworks MAY have the same VRIDs, but if there is any possibility that the relevant subnetworks could become joined (for example by an accidental re-plugging, inconsistent bridge filtering configurations, etc, etc) then they SHOULD have non-overlapping sets of VRIDs. Priority is a matter of flexibility, not correctness, but in general it is useful to have independent priorities. On Friday, November 07, 1997 5:30 PM, Brian Jewell [SMTP:bjewell@3com.com] wrote: > Hi, > > Currently I am working on the draft VRRP MIB and wanted to point out an area > of > the VRRP Draft document that I felt needed some clarification. > > In Section 3.0, it states: "On an interface running VRRP, each VRRP router > must > be configured with a virtual router identifier for the addresses it owns... . > In > addition, each VRRP router is assigned a priority... ." > > In section 6.1.2, entitled "Parameters Per Virtual Router", both the VRID and > > the priority are listed. > > I assume that the term "virtual router" is being used in the context of > "interface", as opposed to, say, a "physical" router. Thus, each interface (on > a > physical router) can have a unique VRID and "priority" assigned (or maybe > different VRID's and the same priority - but not the same VRID's??). > > So to reiterate: a router using VRRP on multiple interfaces *must* have > different VRID's assigned to each interface, and *may or may not* have > different > priorities assigned (to each interface). > > Let me know if I am interpreting this incorrectly. But, either way, I just > wanted to point out that section 6.1.2 (along with the definition of "virtual > > router" in Section 1.2) could use some clarification such that these > parameters > are not interpreted as being "global", i.e., one per physical router. > > Thanks. > > Brian Jewell > 3Com, Inc. From VRRP-owner@drcoffsite.com Mon Nov 10 05:41:12 1997 Delivery-Date: Mon, 10 Nov 1997 05:41:12 -0500 Return-Path: VRRP-owner@drcoffsite.com Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ietf.org (8.8.7/8.8.7a) with ESMTP id FAA11123 for ; Mon, 10 Nov 1997 05:41:12 -0500 (EST) Received: from drcoffsite.com (gw.drcoffsite.com [207.247.102.1]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with SMTP id FAA01725 for ; Mon, 10 Nov 1997 05:44:01 -0500 (EST) Received: from mail13.digital.com [192.208.46.30] by drcoffsite.com with ESMTP (SMTPD32-4.02c) id A08F140E021A; Mon, 10 Nov 1997 05:23:11 EST5EDT Received: from shand.reo.dec.com (shand.reo.dec.com [16.36.16.22]) by mail13.digital.com (8.7.5/UNX 1.5/1.0/WV) with SMTP id FAA30672 for ; Mon, 10 Nov 1997 05:05:59 -0500 (EST) Received: from osicwg.reo.dec.com by shand.reo.dec.com (5.65/MS-010395) id AA17184; Mon, 10 Nov 1997 10:06:34 GMT Received: by localhost with Microsoft MAPI; Mon, 10 Nov 1997 10:05:43 -0000 Message-Id: <250F9C8DEB9ED011A14D08002BE4F64C6E56D0@wade.reo.dec.com> From: Mike Shand Reply-To: "shand@mail.dec.com" To: "vrrp@drcoffsite.com" Subject: RE: Virtual MAC Addresses in VRRP Date: Mon, 10 Nov 1997 10:04:50 -0000 Organization: Digital Equipment Co X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4211 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Precendence: bulk Sender: VRRP-owner@drcoffsite.com On Monday, November 10, 1997 8:43 AM, Danny J. Mitzel [SMTP:mitzel@Ipsilon.COM] wrote: > > my personal take is that in the face of these incompatible options there > is probably more interest/benefit in accommodating the broken end-host > implementations than dealing with LANE limitations. I would tend to agree. When we first started working on this stuff about 3 years ago there were certainly a fair number of hosts that didn't accept the ARP, despite what the RFC says. Things may have changed in the intervening years and I would certainly hope that new versions of implementations 'do the right thing', but there will still be a fair number of the broken ones out there. In many ways this is the worst possible scenario, since unless we could characterize ALL versions of ALL implementations we would never be sure it was going to work in any given environment. There is a second, perhaps less significant, issue with the ARP solution. Correct operation, even with correctly implemented hosts, relies on the successful reception of the ARP message. There are many reasons why a single ARP message may not be received by all hosts. Unlike (say) ICMP redirects which are merely optimizations (i.e. failure to receive them doesn't result in service failure), and which will auto-repeat (failure to receive will result in the next packet being sent to the original router and ANOTHER redirect will be generated), the ARP message is critical to the continued correct operation, and there is no mechanism to generate another one if the first one fails. Clearly an approximate solution can be devised where each ARP is sent (say) 3 times, in the hope that at least one will 'take', but there is always the possibility (for example a serious burst of overload related to the failure of the original router) that ALL the ARPs be lost. Continuously repeating the ARP (say) every 10 seconds *might* be a solution, but it is rather expensive, and inelegant! There is no simple way to know when it is safe to stop (if we propose listening for packets sent to the 'wrong' MAC address, we might as well be doing the virtual MAC solution!). Mike From VRRP-owner@drcoffsite.com Mon Nov 10 11:44:37 1997 Delivery-Date: Mon, 10 Nov 1997 11:44:37 -0500 Return-Path: VRRP-owner@drcoffsite.com Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ietf.org (8.8.7/8.8.7a) with ESMTP id LAA14990 for ; Mon, 10 Nov 1997 11:44:36 -0500 (EST) Received: from drcoffsite.com (gw.drcoffsite.com [207.247.102.1]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with SMTP id LAA03088 for ; Mon, 10 Nov 1997 11:47:22 -0500 (EST) Received: from fwns1.raleigh.ibm.com [204.146.167.235] by drcoffsite.com with ESMTP (SMTPD32-4.02c) id A66C8C40288; Mon, 10 Nov 1997 11:29:32 EST5EDT Received: from rtpmail01.raleigh.ibm.com ([9.37.172.24]) by fwns1.raleigh.ibm.com (AIX4.2/UCB 8.7/8.7RTP-FW1.1) with ESMTP id JAA28718; Mon, 10 Nov 1997 09:52:20 -0500 (EST) Received: from aceman.raleigh.ibm.com (aceman.raleigh.ibm.com [9.37.177.119]) by rtpmail01.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id JAA27968; Mon, 10 Nov 1997 09:52:20 -0500 Received: from loopback by aceman.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA26394; Mon, 10 Nov 1997 09:52:16 -0500 X-Sender: acee@raleigh.ibm.com Message-Id: <34671F9F.15FB@raleigh.ibm.com> Date: Mon, 10 Nov 1997 09:52:15 -0500 From: Acee Lindem Organization: IBM Networking Divison X-Mailer: Mozilla 3.01 (X11; I; AIX 1) Mime-Version: 1.0 To: robm@null.net Cc: vrrp@drcoffsite.com Subject: Re: Virtual MAC Addresses in VRRP References: <34669D41.2D24C0F1@ameritech.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Precendence: bulk Sender: VRRP-owner@drcoffsite.com Rob Montgomery wrote: > I would, therefore, propose that the concept of a Virtual MAC > address be abandoned, and that we take advantage of the ARP > protocol to do it's work. > > Should a fail over occur, would it not make sense for the > new master router, upon becoming the master router, to > transmit a broadcast ARP packet, with the op-code set > to ares_op$REPLY. This packet should contain the Source IP > address of the Virtual Router, the Source MAC Address of the > Master Router, an unknown Target IP Address (probably > 255.255.255.255) and an unknown Target MAC Address (probably > FF:FF:FF:FF:FF:FF). By setting the op-code to 'reply', this > would not generate a storm of ARP Responses. > > In this way, all devices on the broadcast domain would receive > (through the broadcast MAC Address) an updated MAC to IP pairing > for the virtual router (pairing the Virtual Router IP with the > hard coded 48 Bit MAC Address of the Master Router), without > disrupting any LANE LE_ARP Cache, or any other tables that > might inhibit MAC Address mobility. Rob, Unfortunately, many host TCP/IP stack implementations do not listen to gratuitous ARPs as documented in RFC 826. At this point, it makes more sense to provide MAC level transparency in the routers than to fix/update all the host implementations. However, I agree with you that in an RFC826-conformant world this would be a much cleaner solution. Thanks, -- Acee From VRRP-owner@drcoffsite.com Mon Nov 10 20:04:47 1997 Delivery-Date: Mon, 10 Nov 1997 20:04:48 -0500 Return-Path: VRRP-owner@drcoffsite.com Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ietf.org (8.8.7/8.8.7a) with ESMTP id UAA19828 for ; Mon, 10 Nov 1997 20:04:47 -0500 (EST) Received: from drcoffsite.com (gw.drcoffsite.com [207.247.102.1]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with SMTP id UAA05126 for ; Mon, 10 Nov 1997 20:07:21 -0500 (EST) Received: from mailhost.detroit.mi.ameritech.net [206.141.193.243] by drcoffsite.com with ESMTP (SMTPD32-4.02c) id ACAA2AFE0292; Mon, 10 Nov 1997 19:54:02 EST5EDT Received: from ameritech.net (dyn-max3-100.detroit.mi.ameritech.net [206.141.225.100]) by mailhost.detroit.mi.ameritech.net (8.8.3/8.8.3-AIMS) with ESMTP id TAA07912; Mon, 10 Nov 1997 19:52:26 -0500 (EST) Message-ID: <3467AC6A.4F3F9A9F@ameritech.net> Date: Mon, 10 Nov 1997 19:52:58 -0500 From: Rob Montgomery Reply-To: robm@null.net X-Mailer: Mozilla 4.03 [en] (Win95; U) MIME-Version: 1.0 To: vrrp@drcoffsite.com CC: robm@null.net Subject: Re: Virtual MAC Addresses in VRRP References: <199711100843.AAA28158@mailhost.Ipsilon.COM> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Precendence: bulk Sender: VRRP-owner@drcoffsite.com Based on the responses that came back today, and the archives that I've read, I've put together a list of reasons for using a virtual MAC Address, and reasons for only using gratuitous ARP. Obviously, this will come out fairly slanted as people don't tend to question things that haven't been proposed yet. Reason's for a Virtual MAC: 1. Responds better in the event of dropped announcements. 2. Not all devices fully support RFC 826.* Reason's for Gratuitous ARP: 1. Simplifies the protocol (speeds up vendor implementation, and reduces the cost of that implementation.) 2. Simplifies the protocol (by eliminating special MAC address filters, it alleviates a potential performance hit that can be taken by low end routers.) 3. Allows the protocol to operate over a wide variety of technologies (i.e. ATM/LANE and primitive VLAN's) that may not permit rapid MAC address mobility. 4. Simplifies operations in a Token Ring environment. 5. Simplifies operations in an FDDI environment. 6. Eliminates any conflicts between the registered MAC address of a Non Proxy LEC (LAN Emulation Client) and the virtual MAC address. *While I appreciate all concerns in regards RFC 826 compliance, I am concerned by the subtext of this action. By placing interoperability with proprietary implementations of a standards based protocol above interoperability with standards based networks, why even bother writing a standard? Thanks for listening. -Rob Montgomery robm@null.net ps. Can anyone give me an example of some implementations that don't work with Gratuitous ARP? I've been experimenting in the lab, but I haven't found any yet. I'd love to play with one. Thanks in advance. From VRRP-owner@drcoffsite.com Wed Nov 12 09:34:53 1997 Delivery-Date: Wed, 12 Nov 1997 09:34:53 -0500 Return-Path: VRRP-owner@drcoffsite.com Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ietf.org (8.8.7/8.8.7a) with ESMTP id JAA18631 for ; Wed, 12 Nov 1997 09:34:45 -0500 (EST) Received: from drcoffsite.com (gw.drcoffsite.com [207.247.102.1]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with SMTP id JAA10063 for ; Wed, 12 Nov 1997 09:37:30 -0500 (EST) Received: from wwwnni.us.newbridge.com [204.177.219.11] by drcoffsite.com with ESMTP (SMTPD32-4.02c) id A8ED403034E; Wed, 12 Nov 1997 09:10:53 EST5EDT Received: from herndon-gw1.us.newbridge.com (herndon-gw1 [204.177.219.66]) by wwwnni.us.newbridge.com (8.8.5/8.6.12) with SMTP id JAA05399; Wed, 12 Nov 1997 09:14:11 -0500 (EST) Received: from hernmaster.us.newbridge.com ([138.120.108.6]) by herndon-gw1.us.newbridge.com via smtpd (for wwwnni.us.newbridge.com [204.177.219.11]) with SMTP; 12 Nov 1997 14:08:38 UT Received: (from smap@localhost) by us.newbridge.com. (8.8.6/8.8.6) id JAA28433; Wed, 12 Nov 1997 09:08:37 -0500 (EST) Received: from mako.us.newbridge.com(138.120.108.44) by hernmaster.us.newbridge.com via smap (V1.3) id sma028430; Wed Nov 12 09:08:12 1997 Received: from lobster.nni by mako.us.newbridge.com (SMI-8.6/SMI-SVR4) id JAA17007; Wed, 12 Nov 1997 09:08:11 -0500 Received: from localhost by lobster.nni (SMI-8.6/SMI-SVR4) id JAA09534; Wed, 12 Nov 1997 09:08:10 -0500 Date: Wed, 12 Nov 1997 09:08:10 -0500 (EST) From: Joel Halpern X-Sender: jhalpern@lobster To: Rob Montgomery cc: vrrp@drcoffsite.com, hinden@ipsilon.com Subject: Re: Virtual MAC Addresses in VRRP In-Reply-To: <34669D41.2D24C0F1@ameritech.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Precendence: bulk Sender: VRRP-owner@drcoffsite.com There are other solutions in the ATM FOrum LANE case. There is a message in LANE V2 that is a gratuitous ARP which goes to everyone. That can be used to easily propagate the fact that the virtual MAC has moved. Yours, Joel M. Halpern jhalpern@newbridge.com Newbridge Networks Inc. From VRRP-owner@drcoffsite.com Wed Nov 12 12:00:27 1997 Delivery-Date: Wed, 12 Nov 1997 12:00:27 -0500 Return-Path: VRRP-owner@drcoffsite.com Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ietf.org (8.8.7/8.8.7a) with ESMTP id MAA21333 for ; Wed, 12 Nov 1997 12:00:26 -0500 (EST) Received: from drcoffsite.com (gw.drcoffsite.com [207.247.102.1]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with SMTP id MAA10970 for ; Wed, 12 Nov 1997 12:03:13 -0500 (EST) Received: from wwwnni.us.newbridge.com [204.177.219.11] by drcoffsite.com with ESMTP (SMTPD32-4.02c) id AD6A61F03BC; Wed, 12 Nov 1997 11:46:34 EST5EDT Received: from herndon-gw1.us.newbridge.com (herndon-gw1 [204.177.219.66]) by wwwnni.us.newbridge.com (8.8.5/8.6.12) with SMTP id LAA07443; Wed, 12 Nov 1997 11:49:48 -0500 (EST) Received: from hernmaster.us.newbridge.com ([138.120.108.6]) by herndon-gw1.us.newbridge.com via smtpd (for wwwnni.us.newbridge.com [204.177.219.11]) with SMTP; 12 Nov 1997 16:44:15 UT Received: (from smap@localhost) by us.newbridge.com. (8.8.6/8.8.6) id LAA04561; Wed, 12 Nov 1997 11:44:15 -0500 (EST) Received: from mako.us.newbridge.com(138.120.108.44) by hernmaster.us.newbridge.com via smap (V1.3) id sma004556; Wed Nov 12 11:43:53 1997 Received: from lobster.nni by mako.us.newbridge.com (SMI-8.6/SMI-SVR4) id LAA17942; Wed, 12 Nov 1997 11:43:51 -0500 Received: from localhost by lobster.nni (SMI-8.6/SMI-SVR4) id LAA09610; Wed, 12 Nov 1997 11:43:50 -0500 Date: Wed, 12 Nov 1997 11:43:50 -0500 (EST) From: Joel Halpern X-Sender: jhalpern@lobster To: Joel Halpern cc: Rob Montgomery , vrrp@drcoffsite.com, hinden@ipsilon.com Subject: Re: Virtual MAC Addresses in VRRP In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Precendence: bulk Sender: VRRP-owner@drcoffsite.com Slight problem in the above. I left of a letter set. The message I am referring to is a gratuitous LE-ARP, a LANE specific message that LANE devices are required to accept. On Wed, 12 Nov 1997, Joel Halpern wrote: > There are other solutions in the ATM FOrum LANE case. There is a message > in LANE V2 that is a gratuitous ARP which goes to everyone. That can be > used to easily propagate the fact that the virtual MAC has moved. > > Yours, > Joel M. Halpern jhalpern@newbridge.com > Newbridge Networks Inc. > > > Yours, Joel M. Halpern jhalpern@newbridge.com Newbridge Networks Inc. From VRRP-owner@drcoffsite.com Wed Nov 12 12:50:23 1997 Delivery-Date: Wed, 12 Nov 1997 12:50:23 -0500 Return-Path: VRRP-owner@drcoffsite.com Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ietf.org (8.8.7/8.8.7a) with ESMTP id MAA22026 for ; Wed, 12 Nov 1997 12:50:22 -0500 (EST) Received: from drcoffsite.com (gw.drcoffsite.com [207.247.102.1]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with SMTP id MAA11210 for ; Wed, 12 Nov 1997 12:52:21 -0500 (EST) Received: from w6yx.stanford.edu [36.55.0.50] by drcoffsite.com with ESMTP (SMTPD32-4.02c) id A9834D20336; Wed, 12 Nov 1997 12:38:11 EST5EDT Received: (from paul@localhost) by w6yx.stanford.edu (8.8.5/8.6.10) id JAA10041 for vrrp@drcoffsite.com; Wed, 12 Nov 1997 09:36:15 -0800 From: "G. Paul Ziemba" Message-Id: <199711121736.JAA10041@w6yx.stanford.edu> Subject: draft-ietf-vrrp-spec-03, Sec 8.2 proposal To: vrrp@drcoffsite.com Date: Wed, 12 Nov 1997 09:36:14 -0800 (PST) X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Precendence: bulk Sender: VRRP-owner@drcoffsite.com Earlier, I wrote: > In draft-ietf-vrrp-spec-03, Page 20 at the bottom (8.2 Host ARP Requests), > the first paragraph of 8.2 concludes: > > The request MUST be handled as a standard ARP reply. > > I don't understand what this means. Could someone please clarify? Danny J. Mitzel replied: > that paragraph does seem a bit unfocused. most of the paragraph is > dealing with the requirements the virtual router must comply with when > generating ARP reply. but then that last sentence appears to be addressing > the end-host that generated the ARP request. and it just says that the > ARP reply for a VRRP address is no different from any other ARP reply, > thus the end host should process it in whatever its ``standard'' method is. I propose that the last sentence of the first paragraph of 8.2 be deleted, because: 1. it is nonsensical (request != reply) 2. it ostensibly prescribes behavior of the client (host), which is beyond the scope of the specification. I am left with some nagging doubt, however, because the author of this sentence must have had _something_ in mind when writing "MUST". Would it make more sense to replace the sentence with something along the lines of: It is expected that the client will treat the Master router's ARP reply in the normal fashion, viz., installing the virtual MAC address in its arp table as the referent of the virtual router's IP address. ~!paul From VRRP-owner@drcoffsite.com Wed Nov 12 22:17:26 1997 Delivery-Date: Wed, 12 Nov 1997 22:17:27 -0500 Return-Path: VRRP-owner@drcoffsite.com Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ietf.org (8.8.7/8.8.7a) with ESMTP id WAA28889 for ; Wed, 12 Nov 1997 22:17:26 -0500 (EST) Received: from drcoffsite.com (gw.drcoffsite.com [207.247.102.1]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with SMTP id WAA13106 for ; Wed, 12 Nov 1997 22:20:23 -0500 (EST) Received: from mailhost.detroit.mi.ameritech.net [206.141.193.243] by drcoffsite.com with ESMTP (SMTPD32-4.02c) id AC3867E0338; Wed, 12 Nov 1997 21:55:52 EST5EDT Received: from ameritech.net (dyn-max3-125.detroit.mi.ameritech.net [206.141.225.125]) by mailhost.detroit.mi.ameritech.net (8.8.3/8.8.3-AIMS) with ESMTP id VAA12947; Wed, 12 Nov 1997 21:54:04 -0500 (EST) Message-ID: <346A6BF1.3FE2132A@ameritech.net> Date: Wed, 12 Nov 1997 21:54:41 -0500 From: Rob Montgomery Reply-To: robm@null.net X-Mailer: Mozilla 4.03 [en] (Win95; U) MIME-Version: 1.0 To: Joel Halpern CC: vrrp@drcoffsite.com, hinden@ipsilon.com, robm@null.net Subject: Re: Virtual MAC Addresses in VRRP References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Precendence: bulk Sender: VRRP-owner@drcoffsite.com I appreciate the heads up. If there is widespread support of this 'Targetless LE_ARP_REQUEST' feature, this should minimize the effects of this problem for routers behind a proxy-LEC. I'm still concerned by the optional nature of this clause, and by the fact that I haven't found a solution to the problems associated with dynamic MAC addressing on ATM Attached Routers. If a client sends an LE_REGISTER_REQUEST for a (virtual) MAC Address that has not been unregistered by the previous owner, are there any guarantees that a LES will not reject the registration attempt? Thanks, -Rob Montgomery robm@null.net Joel Halpern wrote: > > Slight problem in the above. I left of a letter set. > The message I am referring to is a gratuitous LE-ARP, a LANE specific > message that LANE devices are required to accept. > > On Wed, 12 Nov 1997, Joel Halpern wrote: > > > There are other solutions in the ATM FOrum LANE case. There is a message > > in LANE V2 that is a gratuitous ARP which goes to everyone. That can be > > used to easily propagate the fact that the virtual MAC has moved. > > > > Yours, > > Joel M. Halpern jhalpern@newbridge.com > > Newbridge Networks Inc. > > > > > > > > Yours, > Joel M. Halpern jhalpern@newbridge.com > Newbridge Networks Inc. From VRRP-owner@drcoffsite.com Thu Nov 13 10:00:02 1997 Delivery-Date: Thu, 13 Nov 1997 10:00:03 -0500 Return-Path: VRRP-owner@drcoffsite.com Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ietf.org (8.8.7/8.8.7a) with ESMTP id JAA08734 for ; Thu, 13 Nov 1997 09:59:58 -0500 (EST) Received: from drcoffsite.com (gw.drcoffsite.com [207.247.102.1]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with SMTP id KAA14034 for ; Thu, 13 Nov 1997 10:02:49 -0500 (EST) Received: from wwwnni.us.newbridge.com [204.177.219.11] by drcoffsite.com with ESMTP (SMTPD32-4.02c) id A403426B02A8; Thu, 13 Nov 1997 09:51:47 EST5EDT Received: from herndon-gw1.us.newbridge.com (herndon-gw1 [204.177.219.66]) by wwwnni.us.newbridge.com (8.8.5/8.6.12) with SMTP id JAA17764; Thu, 13 Nov 1997 09:55:02 -0500 (EST) Received: from hernmaster.us.newbridge.com ([138.120.108.6]) by herndon-gw1.us.newbridge.com via smtpd (for wwwnni.us.newbridge.com [204.177.219.11]) with SMTP; 13 Nov 1997 14:49:29 UT Received: (from smap@localhost) by us.newbridge.com. (8.8.6/8.8.6) id JAA24035; Thu, 13 Nov 1997 09:49:24 -0500 (EST) Received: from mako.us.newbridge.com(138.120.108.44) by hernmaster.us.newbridge.com via smap (V1.3) id sma024016; Thu Nov 13 09:49:19 1997 Received: from lobster.nni by mako.us.newbridge.com (SMI-8.6/SMI-SVR4) id JAA24130; Thu, 13 Nov 1997 09:49:18 -0500 Received: from localhost by lobster.nni (SMI-8.6/SMI-SVR4) id JAA09921; Thu, 13 Nov 1997 09:49:18 -0500 Date: Thu, 13 Nov 1997 09:49:18 -0500 (EST) From: Joel Halpern X-Sender: jhalpern@lobster To: Rob Montgomery cc: vrrp@drcoffsite.com, hinden@ipsilon.com, robm@null.net Subject: Re: Virtual MAC Addresses in VRRP In-Reply-To: <346A6BF1.3FE2132A@ameritech.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Precendence: bulk Sender: VRRP-owner@drcoffsite.com On Wed, 12 Nov 1997, Rob Montgomery wrote: > > If a client sends an LE_REGISTER_REQUEST for a (virtual) > MAC Address that has not been unregistered by the previous > owner, are there any guarantees that a LES will not reject > the registration attempt? If a client drops his LANE Control Direct VC (the VC over which one does registrations), then all of ones registrations are deleted. The speed of propagation of this information (assuming the proposed LANE V2 LNNI operation) is faster than the VRRP detection time. So, if the router failure brings down the VC (as it should), then the registration will go away. There is one "corner" case. If the router fails "soft", in such a way that his VCs don't go down, then the registration won't go away. I would not consider this a big case. If we want to fix it, all VRRP routers can be Proxy LECs, and not register the virtual MAC address. The price ist that the routers will get more LE-ARPs. (Note, if the router is also a bridge then it already was a Proxy LEC.) Yours, Joel M. Halpern jhalpern@newbridge.com Newbridge Networks Inc. From VRRP-owner@drcoffsite.com Mon Nov 17 20:08:59 1997 Delivery-Date: Mon, 17 Nov 1997 20:08:59 -0500 Return-Path: VRRP-owner@drcoffsite.com Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ietf.org (8.8.7/8.8.7a) with ESMTP id UAA24098 for ; Mon, 17 Nov 1997 20:08:54 -0500 (EST) Received: from drcoffsite.com (gw.drcoffsite.com [207.247.102.1]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with SMTP id UAA05809 for ; Mon, 17 Nov 1997 20:11:50 -0500 (EST) Received: from mailhost.Ipsilon.COM [205.226.5.12] by drcoffsite.com (SMTPD32-4.03) id A8771B83011A; Mon, 17 Nov 1997 19:59:35 +03d00 Received: from spruce.ipsilon.com (spruce.Ipsilon.COM [205.226.1.63]) by mailhost.Ipsilon.COM (8.6.11/8.6.10) with SMTP id QAA11475; Mon, 17 Nov 1997 16:57:59 -0800 Message-Id: <3.0.3.32.19971117165723.0096e900@mailhost.ipsilon.com> X-Sender: hinden@mailhost.ipsilon.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Mon, 17 Nov 1997 16:57:23 -0800 To: vrrp@drcoffsite.com From: Bob Hinden Subject: Request for Agenda Items Cc: hinden@Ipsilon.COM Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Precedence: bulk Sender: VRRP-owner@drcoffsite.com The VRRP w.g. will meet on Tuesday December 9 at the Washington IETF. Please let me know if you have an agenda item for the meeting. Please include topic and length of time required. Thanks, Bob From VRRP-owner@drcoffsite.com Thu Nov 20 12:07:51 1997 Delivery-Date: Thu, 20 Nov 1997 12:07:55 -0500 Return-Path: VRRP-owner@drcoffsite.com Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id MAA25371 for ; Thu, 20 Nov 1997 12:07:48 -0500 (EST) Received: from drcoffsite.com (gw.drcoffsite.com [207.247.102.1]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with SMTP id MAA16746 for ; Thu, 20 Nov 1997 12:10:39 -0500 (EST) Received: from janus.3com.com [129.213.128.99] by drcoffsite.com with ESMTP (SMTPD32-4.03) id AA3834AF019E; Thu, 20 Nov 1997 11:50:00 +03d00 Received: from new-york.3com.com (new-york.3com.com [129.213.157.12]) by janus.3com.com (8.8.2/8.8.5) with ESMTP id IAA17926 for ; Thu, 20 Nov 1997 08:47:56 -0800 (PST) Received: from chicago.nsd.3com.com (chicago.nsd.3com.com [129.213.157.11]) by new-york.3com.com (8.8.2/8.8.5) with ESMTP id IAA29353 for ; Thu, 20 Nov 1997 08:43:34 -0800 (PST) Received: from fubar.nsd.3com.com (fubar.nsd.3com.com [129.213.16.41]) by chicago.nsd.3com.com (8.8.2/8.8.5) with ESMTP id IAA02928; Thu, 20 Nov 1997 08:37:33 -0800 (PST) From: Brian Jewell Received: (from bjewell@localhost) by fubar.nsd.3com.com (8.8.2/8.8.5) id IAA20632; Thu, 20 Nov 1997 08:38:17 -0800 (PST) Date: Thu, 20 Nov 1997 08:38:17 -0800 (PST) Message-Id: <199711201638.IAA20632@fubar.nsd.3com.com> To: vrrp@drcoffsite.com Subject: Draft of VRRP MIB is available Cc: denny@ewd.3Com.com, vsp@ewd.3Com.com, frp@ewd.3Com.com, dtc@ewd.3Com.com, bjewell@ewd.3Com.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-MD5: A+UHLvEM6VlSOqt802PIVw== Precedence: bulk Sender: VRRP-owner@drcoffsite.com Everyone, I have released an Internet Draft of a proposed VRRP MIB to the IETF entitled draft-ietf-vrrp-mib-01 Since the WG meeting is approaching, I was concerned that it might not become available on the IETF web site in time. The file is also somewhat large to be propagating to the mailing list. So, for those who are interested in the subject of VRRP management, if you send a request to bjewell@3com.com I will gladly forward you a copy. Bob Hinden has agreed to include the VRRP MIB as an agenda item in the upcoming WG meeting. The MIB attempts to provide tables and objects to more effectively manage VRRP routers. One of the problems with HSRP is that it tends to confuse topology managers, such as HP Openview and NetView/AIX. A well-designed VRRP MIB can provide a means for applications to effectively sort out the logical relocation of an IP address when a backup router takes-over. I would welcome any questions or feedback that can be posted to the mailing list. But I will be on vacation the week of Thanksgiving, so there might be a "black hole" during which time there won't be a response. Thanks. -Brian Jewell -3Com, Inc. From VRRP-owner@drcoffsite.com Fri Nov 21 20:22:57 1997 Delivery-Date: Fri, 21 Nov 1997 20:22:58 -0500 Return-Path: VRRP-owner@drcoffsite.com Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id UAA24992 for ; Fri, 21 Nov 1997 20:22:57 -0500 (EST) Received: from drcoffsite.com (gw.drcoffsite.com [207.247.102.1]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with SMTP id UAA23338 for ; Fri, 21 Nov 1997 20:25:34 -0500 (EST) Received: from mailhost.Ipsilon.COM [205.226.5.12] by drcoffsite.com (SMTPD32-4.03) id AFD28A9034A; Fri, 21 Nov 1997 20:05:22 +03d00 Received: from spruce.ipsilon.com (spruce.Ipsilon.COM [205.226.1.63]) by mailhost.Ipsilon.COM (8.6.11/8.6.10) with SMTP id RAA26475; Fri, 21 Nov 1997 17:03:41 -0800 Message-Id: <3.0.3.32.19971121170313.009b1990@mailhost.ipsilon.com> X-Sender: hinden@mailhost.ipsilon.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Fri, 21 Nov 1997 17:03:13 -0800 To: vrrp@drcoffsite.com From: Bob Hinden Subject: New VRRP Draft Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Precedence: bulk Sender: VRRP-owner@drcoffsite.com I submitted a new version of the VRRP draft. It should appear as an ID next week. In the mean time it can be found as: ftp://playground.sun.com/pub/hinden/vrrp/draft-ietf-vrrp-spec-04.txt The changes include: - 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. It turned out that the IANA had never assigned any unicast MAC addresses from it's IEEE 802 block and wanted more time to think about it. I suspect this will be resolved soon. Bob From daemon Wed Dec 3 12:48:55 1997 Delivery-Date: Wed, 03 Dec 1997 12:57:35 -0500 Return-Path: daemon Received: (from daemon@localhost) by ns.ietf.org (8.8.7/8.8.7a) id MAA23776 for ietf-123-outbound.10@ietf.org; Wed, 3 Dec 1997 12:48:42 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id MAA23721; Wed, 3 Dec 1997 12:47:54 -0500 (EST) Message-Id: <199712031747.MAA23721@ns.ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce Cc: vrrp@drcoffsite.com From: Internet-Drafts@ns.ietf.org Reply-to: Internet-Drafts@ns.ietf.org Subject: I-D ACTION:draft-ietf-vrrp-spec-04.txt Date: Wed, 03 Dec 1997 12:47:46 -0500 Sender: cclark@cnri.reston.va.us --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Virtual Router Redundancy Protocol Working Group of the IETF. Title : Virtual Router Redundancy Protocol Author(s) : P. Higginson, B. Hinden, S. Knight, A. Lindem, D. Mitzel, M. Shand, D. Whipple, D. Weaver, P. Hunt Filename : draft-ietf-vrrp-spec-04.txt Pages : 30 Date : 02-Dec-97 This memo defines the Virtual Router Redundancy Protocol (VRRP). VRRP specifies an election protocol that dynamically assigns responsibility for a virtual router to one of the VRRP routers on a LAN. The VRRP router controlling the IP address(es) associated with a virtual router is called the Master, and forwards packets sent to these IP addresses. The election process provides dynamic fail over in the forwarding responsibility should the Master become unavailable. This allows any of the virtual router IP addresses on the LAN to be used as the default first hop router by end-hosts. The advantage gained from using VRRP is a higher availability default path without requiring configuration of dynamic routing or router discovery protocols on every end-host. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-vrrp-spec-04.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-vrrp-spec-04.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-vrrp-spec-04.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19971202132012.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-vrrp-spec-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-vrrp-spec-04.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19971202132012.I-D@ietf.org> --OtherAccess-- --NextPart-- From VRRP-owner@drcoffsite.com Wed Dec 3 13:13:01 1997 Delivery-Date: Wed, 03 Dec 1997 13:13:01 -0500 Return-Path: VRRP-owner@drcoffsite.com Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id NAA24480 for ; Wed, 3 Dec 1997 13:13:00 -0500 (EST) Received: from drcoffsite.com (gw.drcoffsite.com [207.247.102.1]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with SMTP id NAA13285 for ; Wed, 3 Dec 1997 13:15:27 -0500 (EST) Received: from ns.ietf.org [132.151.1.19] by drcoffsite.com with ESMTP (SMTPD32-4.03) id ABC533C0214; Wed, 03 Dec 1997 12:49:57 +03d00 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id MAA23721; Wed, 3 Dec 1997 12:47:54 -0500 (EST) Message-Id: <199712031747.MAA23721@ns.ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce@ns.ietf.org Cc: vrrp@drcoffsite.com From: Internet-Drafts@ns.ietf.org Reply-to: Internet-Drafts@ns.ietf.org Subject: I-D ACTION:draft-ietf-vrrp-spec-04.txt Date: Wed, 03 Dec 1997 12:47:46 -0500 X-Sender: cclark@cnri.reston.va.us Precedence: bulk Sender: VRRP-owner@drcoffsite.com --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Virtual Router Redundancy Protocol Working Group of the IETF. Title : Virtual Router Redundancy Protocol Author(s) : P. Higginson, B. Hinden, S. Knight, A. Lindem, D. Mitzel, M. Shand, D. Whipple, D. Weaver, P. Hunt Filename : draft-ietf-vrrp-spec-04.txt Pages : 30 Date : 02-Dec-97 This memo defines the Virtual Router Redundancy Protocol (VRRP). VRRP specifies an election protocol that dynamically assigns responsibility for a virtual router to one of the VRRP routers on a LAN. The VRRP router controlling the IP address(es) associated with a virtual router is called the Master, and forwards packets sent to these IP addresses. The election process provides dynamic fail over in the forwarding responsibility should the Master become unavailable. This allows any of the virtual router IP addresses on the LAN to be used as the default first hop router by end-hosts. The advantage gained from using VRRP is a higher availability default path without requiring configuration of dynamic routing or router discovery protocols on every end-host. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-vrrp-spec-04.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-vrrp-spec-04.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-vrrp-spec-04.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19971202132012.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-vrrp-spec-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-vrrp-spec-04.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19971202132012.I-D@ietf.org> --OtherAccess-- --NextPart-- From VRRP-owner@drcoffsite.com Thu Dec 4 07:01:18 1997 Delivery-Date: Thu, 04 Dec 1997 07:01:19 -0500 Return-Path: VRRP-owner@drcoffsite.com Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id HAA13315 for ; Thu, 4 Dec 1997 07:01:18 -0500 (EST) Received: from drcoffsite.com (gw.drcoffsite.com [207.247.102.1]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with SMTP id HAA16027 for ; Thu, 4 Dec 1997 07:03:54 -0500 (EST) Received: from fsnt.future.futsoft.com [38.242.192.5] by drcoffsite.com with ESMTP (SMTPD32-4.03) id A7621E4C0320; Thu, 04 Dec 1997 06:43:30 +03d00 Received: from kailash.future.futsoft.com (unverified [38.242.192.4]) by fsnt.future.futsoft.com (Integralis SMTPRS 2.04) with ESMTP id ; Thu, 04 Dec 1997 16:59:33 +0530 Received: from msgate.future.futsoft.com (msgate.future.futsoft.com [10.0.8.4]) by kailash.future.futsoft.com (8.7.1/8.7.1) with SMTP id QAA32132 for ; Thu, 4 Dec 1997 16:43:20 +0530 Received: by msgate.future.futsoft.com with Microsoft Mail id <3487543A@msgate.future.futsoft.com>; Thu, 04 Dec 97 17:09:14 PST From: raovrn To: vrrp Subject: Some Questions Date: Thu, 04 Dec 97 17:00:00 PST Message-Id: <3487543A@msgate.future.futsoft.com> Encoding: 27 TEXT X-Mailer: Microsoft Mail V3.0 Precedence: bulk Sender: VRRP-owner@drcoffsite.com Hi, We have gone through the IETF Draft specification and have the following questions. 1). Is the Virtual MAC address, a Multicast MAC address ? 2). If yes, then the Virtual MAC address should have been "01-00-5E-XX-XX-VRID". 3). What should be the destination MAC address in the VRRP packets that need to be transmitted ? We would appreciate if someone in the mailing list could help us in clarifying these questions. Thanks in advance, Rao & Basil V.R.N. Rao Future Software Pvt., Ltd., 481, Nandanam, Madras - 600 035. Voice : 91-44-4340323, 4330550 (Extn : 331) Fax : 91-44-4344157, 4834551, 4834661 Email : raovrn@future.futsoft.com From VRRP-owner@drcoffsite.com Thu Dec 4 08:06:22 1997 Delivery-Date: Thu, 04 Dec 1997 08:06:24 -0500 Return-Path: VRRP-owner@drcoffsite.com Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id IAA14236 for ; Thu, 4 Dec 1997 08:06:21 -0500 (EST) Received: from drcoffsite.com (gw.drcoffsite.com [207.247.102.1]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with SMTP id IAA16213 for ; Thu, 4 Dec 1997 08:09:00 -0500 (EST) Received: from mail12.digital.com [192.208.46.20] by drcoffsite.com with ESMTP (SMTPD32-4.03) id A6DE2D70326; Thu, 04 Dec 1997 07:49:34 +03d00 Received: from shand.reo.dec.com (shand.reo.dec.com [16.36.16.22]) by mail12.digital.com (8.7.5/UNX 1.5/1.0/WV) with SMTP id HAA29341; Thu, 4 Dec 1997 07:40:02 -0500 (EST) Received: from osicwg.reo.dec.com by shand.reo.dec.com (5.65/MS-010395) id AA00300; Thu, 4 Dec 1997 12:38:24 GMT Received: by localhost with Microsoft MAPI; Thu, 4 Dec 1997 12:39:55 -0000 Message-Id: <250F9C8DEB9ED011A14D08002BE4F64C6E571A@wade.reo.dec.com> From: Mike Shand Reply-To: "shand@mail.dec.com" To: "'raovrn'" , "'vrrp@drcoffsite.com'" Subject: RE: Some Questions Date: Thu, 4 Dec 1997 12:38:39 -0000 Organization: Digital Equipment Co X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4211 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Precedence: bulk Sender: VRRP-owner@drcoffsite.com On Friday, December 05, 1997 1:00 AM, raovrn [SMTP:raovrn@future.futsoft.com] wrote: > > Hi, > > We have gone through the IETF Draft specification > and have the following questions. > > 1). Is the Virtual MAC address, a Multicast MAC address ? NO. Its a unicast address. > 2). If yes, then the Virtual MAC address should have been > "01-00-5E-XX-XX-VRID". NO > 3). What should be the destination MAC address in the VRRP packets that need > to be transmitted ? Its a multicast address (TBA, as I recall) > > We would appreciate if someone in the mailing list could help us in > clarifying these questions. > > Thanks in advance, > Rao & Basil > > > V.R.N. Rao > Future Software Pvt., Ltd., > 481, Nandanam, > Madras - 600 035. > > Voice : 91-44-4340323, 4330550 (Extn : 331) > Fax : 91-44-4344157, 4834551, 4834661 > Email : raovrn@future.futsoft.com From VRRP-owner@drcoffsite.com Thu Dec 4 11:34:02 1997 Delivery-Date: Thu, 04 Dec 1997 11:34:03 -0500 Return-Path: VRRP-owner@drcoffsite.com Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id LAA19719 for ; Thu, 4 Dec 1997 11:34:02 -0500 (EST) Received: from drcoffsite.com (gw.drcoffsite.com [207.247.102.1]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with SMTP id LAA17211 for ; Thu, 4 Dec 1997 11:36:43 -0500 (EST) Received: from mailhost.Ipsilon.COM [205.226.5.12] by drcoffsite.com (SMTPD32-4.03) id A7FD9D6023A; Thu, 04 Dec 1997 11:19:09 +03d00 Received: from pfinger.ipsilon.com (pfinger.Ipsilon.COM [205.226.1.149]) by mailhost.Ipsilon.COM (8.6.11/8.6.10) with ESMTP id IAA29591; Thu, 4 Dec 1997 08:17:20 -0800 Received: from localhost (localhost [127.0.0.1]) by pfinger.ipsilon.com (8.6.12/8.6.12) with SMTP id IAA12885; Thu, 4 Dec 1997 08:17:20 -0800 Message-Id: <199712041617.IAA12885@pfinger.ipsilon.com> X-Authentication-Warning: pfinger.ipsilon.com: Host localhost didn't use HELO protocol X-Mailer: exmh version 2.0beta 12/23/96 To: "shand@mail.dec.com" cc: "'raovrn'" , "'vrrp@drcoffsite.com'" Subject: Re: Some Questions In-reply-to: Your message of "Thu, 04 Dec 1997 12:38:39 GMT." <250F9C8DEB9ED011A14D08002BE4F64C6E571A@wade.reo.dec.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 04 Dec 1997 08:17:19 -0800 From: Peter Hunt Precedence: bulk Sender: VRRP-owner@drcoffsite.com > > 3). What should be the destination MAC address in the VRRP packets that need > > to be transmitted ? > Its a multicast address (TBA, as I recall) We do actually have an assignment for the destination IP address for advertisements; it was granted just before the latest draft was published (and is included in that draft). The destination IP address for advertisements is 224.0.0.18, so I guess the destination MAC address for advertisements is 01-00-5E-00-00-12 (on i802 media, anyway). Peter. From VRRP-owner@drcoffsite.com Thu Dec 4 13:20:29 1997 Delivery-Date: Thu, 04 Dec 1997 13:20:29 -0500 Return-Path: VRRP-owner@drcoffsite.com Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id NAA23071 for ; Thu, 4 Dec 1997 13:20:28 -0500 (EST) Received: from drcoffsite.com (gw.drcoffsite.com [207.247.102.1]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with SMTP id NAA17881 for ; Thu, 4 Dec 1997 13:23:00 -0500 (EST) Received: from mailhost.Ipsilon.COM [205.226.5.12] by drcoffsite.com (SMTPD32-4.03) id ACD02988018E; Thu, 04 Dec 1997 11:39:44 +03d00 Received: from pfinger.ipsilon.com (pfinger.Ipsilon.COM [205.226.1.149]) by mailhost.Ipsilon.COM (8.6.11/8.6.10) with ESMTP id IAA00308; Thu, 4 Dec 1997 08:38:01 -0800 Received: from localhost (localhost [127.0.0.1]) by pfinger.ipsilon.com (8.6.12/8.6.12) with SMTP id IAA13028; Thu, 4 Dec 1997 08:37:59 -0800 Message-Id: <199712041637.IAA13028@pfinger.ipsilon.com> X-Authentication-Warning: pfinger.ipsilon.com: Host localhost didn't use HELO protocol X-Mailer: exmh version 2.0beta 12/23/96 To: Peter Hunt cc: "shand@mail.dec.com" , "'raovrn'" , "'vrrp@drcoffsite.com'" Subject: Re: Some Questions In-reply-to: Your message of "Thu, 04 Dec 1997 08:17:19 PST." <199712041617.IAA12885@pfinger.ipsilon.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 04 Dec 1997 08:37:59 -0800 From: Peter Hunt Precedence: bulk Sender: VRRP-owner@drcoffsite.com > The destination IP address for advertisements is 224.0.0.18, so I guess > the destination MAC address for advertisements is 01-00-5E-00-00-12 > (on i802 media, anyway). ... or more accurately, it's 01-00-5E-00-00-12 for ethernet and FDDI, and 03-00-00-20-00-00 for token ring. Peter. From VRRP-owner@drcoffsite.com Sun Dec 7 00:54:52 1997 Delivery-Date: Sun, 07 Dec 1997 00:55:01 -0500 Return-Path: VRRP-owner@drcoffsite.com Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id AAA06188 for ; Sun, 7 Dec 1997 00:54:47 -0500 (EST) Received: from drcoffsite.com (gw.drcoffsite.com [207.247.102.1]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with SMTP id AAA26301 for ; Sun, 7 Dec 1997 00:57:20 -0500 (EST) Received: from mailhost.Ipsilon.COM [205.226.5.12] by drcoffsite.com (SMTPD32-4.03) id A4D112AC022A; Sun, 07 Dec 1997 00:32:01 +03d00 Received: from spruce.ipsilon.com ([205.226.22.76]) by mailhost.Ipsilon.COM (8.6.11/8.6.10) with SMTP id VAA08832; Sat, 6 Dec 1997 21:29:45 -0800 Message-Id: <3.0.3.32.19971206212824.00866100@mailhost.ipsilon.com> X-Sender: hinden@mailhost.ipsilon.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Sat, 06 Dec 1997 21:28:24 -0800 To: Brian Jewell From: Bob Hinden Subject: Re: Draft of VRRP MIB is available Cc: vrrp@drcoffsite.com, denny@ewd.3Com.com, vsp@ewd.3Com.com, frp@ewd.3Com.com, dtc@ewd.3Com.com, bjewell@ewd.3Com.com In-Reply-To: <199711201638.IAA20632@fubar.nsd.3com.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Precedence: bulk Sender: VRRP-owner@drcoffsite.com Brian, Was this submitted to be an internet draft (e.g., sent to internet-drafts@ietf.org). I can find it. I had assumed that you were going to submit it. Bob From VRRP-owner@drcoffsite.com Sun Dec 7 00:59:28 1997 Delivery-Date: Sun, 07 Dec 1997 00:59:29 -0500 Return-Path: VRRP-owner@drcoffsite.com Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id AAA06279 for ; Sun, 7 Dec 1997 00:59:28 -0500 (EST) Received: from drcoffsite.com (gw.drcoffsite.com [207.247.102.1]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with SMTP id BAA26312 for ; Sun, 7 Dec 1997 01:02:09 -0500 (EST) Received: from mailhost.Ipsilon.COM [205.226.5.12] by drcoffsite.com (SMTPD32-4.03) id A7631CD0024E; Sun, 07 Dec 1997 00:42:59 +03d00 Received: from spruce.ipsilon.com ([205.226.22.76]) by mailhost.Ipsilon.COM (8.6.11/8.6.10) with SMTP id VAA09046; Sat, 6 Dec 1997 21:41:12 -0800 Message-Id: <3.0.3.32.19971206214006.00866960@mailhost.ipsilon.com> X-Sender: hinden@mailhost.ipsilon.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Sat, 06 Dec 1997 21:40:06 -0800 To: vrrp@drcoffsite.com From: Bob Hinden Subject: Draft VRRP w.g. Agenda Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Precedence: bulk Sender: VRRP-owner@drcoffsite.com Attached is the draft VRRP w.g. agenda for next weeks IETF meeting. Please send corrections, changes, additions to me. Thanks, Bob -------------------------------- TUESDAY, December 9, 1997, 1545-1800 (Hampton Room) o Introduction o Review Agenda o Review Changes in Current Draft Title : Virtual Router Redundancy Protocol Author(s) : P. Higginson, B. Hinden, S. Knight, A. Lindem, D. Mitzel, M. Shand, D. Whipple, D. Weaver, P. Hunt Filename : draft-ietf-vrrp-spec-04.txt Pages : 30 Date : 02-Dec-97 o Discuss advancing VRRP draft to Proposed Standard o Review VRRP MIB Draft / B. Jewell o VRRP for IPv6 From VRRP-owner@drcoffsite.com Wed Dec 17 21:09:52 1997 Delivery-Date: Wed, 17 Dec 1997 21:09:53 -0500 Return-Path: VRRP-owner@drcoffsite.com Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id VAA29394 for ; Wed, 17 Dec 1997 21:09:47 -0500 (EST) Received: from drcoffsite.com (gw.drcoffsite.com [207.247.102.1]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with SMTP id VAA13292 for ; Wed, 17 Dec 1997 21:12:25 -0500 (EST) Received: from mailhost.detroit.mi.ameritech.net [206.141.193.243] by drcoffsite.com with ESMTP (SMTPD32-4.03) id AEEB2AC020A; Wed, 17 Dec 1997 20:39:55 EST Received: from ameritech.net (dyn-max12-243.detroit.mi.ameritech.net [206.141.229.243]) by mailhost.detroit.mi.ameritech.net (8.8.3/8.8.3-AIMS) with ESMTP id UAA06276; Wed, 17 Dec 1997 20:38:09 -0500 (EST) Message-ID: <34987E87.E900A399@ameritech.net> Date: Wed, 17 Dec 1997 20:38:15 -0500 From: Rob Montgomery Reply-To: robm@null.net X-Mailer: Mozilla 4.03 [en] (Win95; U) MIME-Version: 1.0 To: vrrp@drcoffsite.com CC: hinden@ipsilon.com, jhalpern@us.newbridge.com, robm@null.net Subject: Virtual MAC Addresses... again. Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Precedence: bulk Sender: VRRP-owner@drcoffsite.com I apologize in advance if I'm beating a dead horse, but upon reading the Nov. 21 draft, I was reminded of one question which, at least to me, remains unanswered. What is the overall purpose of the 'Virtual MAC Address'? What does it accomplish that can't be accomplished by the gratuitous ARP? Thanks, -Rob Montgomery robm@null.net From VRRP-owner@drcoffsite.com Thu Dec 18 07:01:53 1997 Delivery-Date: Thu, 18 Dec 1997 07:01:54 -0500 Return-Path: VRRP-owner@drcoffsite.com Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id HAA08562 for ; Thu, 18 Dec 1997 07:01:53 -0500 (EST) Received: from drcoffsite.com (gw.drcoffsite.com [207.247.102.1]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with SMTP id HAA14067 for ; Thu, 18 Dec 1997 07:04:25 -0500 (EST) Received: from mail13.digital.com [192.208.46.30] by drcoffsite.com with ESMTP (SMTPD32-4.03) id AA59142D0196; Thu, 18 Dec 1997 06:34:49 EST Received: from reohub2.reo.dec.com (reohub2.reo.dec.com [16.37.21.19]) by mail13.digital.com (8.7.5/UNX 1.5/1.0/WV) with SMTP id GAA21362 for ; Thu, 18 Dec 1997 06:16:12 -0500 (EST) Received: by reohub2.reo.dec.com with SMTP (Microsoft Exchange Server Internet Mail Connector Version 4.0.996.35) id <01BD0BA5.F670AA10@reohub2.reo.dec.com>; Thu, 18 Dec 1997 11:13:26 -0000 Message-ID: From: Peter Higginson To: "'robm@null.net'" , "'vrrp@drcoffsite.com'" Cc: "'hinden@ipsilon.com'" Subject: RE: Virtual MAC Addresses... again. Date: Thu, 18 Dec 1997 11:06:22 -0000 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.996.35 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Precedence: bulk Sender: VRRP-owner@drcoffsite.com The purpose of the virtual MAC address in vrrp (and the similar mechanisms in the Cisco scheme) is to switch to a backup router without any action by the host. Some hosts use gratuitous ARP successfully because most routers listen to and process all ARPs they receive. It doesn't work the other way round - when we tested this we found hosts that ignored ARPs they were not expecting and recovered only in the 5 minute ARP timeout. The rules for processing ARPs in the RFC have only a "suggested" status and therefore you cannot rely on a host processing to source field of an ARP request that is targeted at another node. There is no statement anywhere that I have ever found to say that hosts must do this. There is also no allowance in the specs for broadcasting an ARP response (which might be another alternative). Using the virtual MAC address allows the routers to control the timing of the failover and do it deterministically. An ARP mechanism would require retransmissions to ensure that all hosts had heard the message, even if all implementations were fixed. Peter >-----Original Message----- >From: Rob Montgomery [SMTP:murdock@ameritech.net] >Sent: 18 December 1997 01:38 >To: vrrp@drcoffsite.com >Cc: hinden@ipsilon.com; jhalpern@us.newbridge.com; robm@null.net >Subject: Virtual MAC Addresses... again. > >I apologize in advance if I'm beating a dead horse, but upon reading >the Nov. 21 draft, I was reminded of one question which, at least to me, >remains unanswered. What is the overall purpose of the 'Virtual MAC >Address'? What does it accomplish that can't be accomplished by the >gratuitous ARP? > >Thanks, > >-Rob Montgomery >robm@null.net > From VRRP-owner@drcoffsite.com Fri Dec 19 01:25:49 1997 Delivery-Date: Fri, 19 Dec 1997 01:25:50 -0500 Return-Path: VRRP-owner@drcoffsite.com Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id BAA24019 for ; Fri, 19 Dec 1997 01:25:49 -0500 (EST) Received: from drcoffsite.com (gw.drcoffsite.com [207.247.102.1]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with SMTP id BAA17837 for ; Fri, 19 Dec 1997 01:28:19 -0500 (EST) Received: from mailhost.detroit.mi.ameritech.net [206.141.193.243] by drcoffsite.com with ESMTP (SMTPD32-4.03) id ACB464500E4; Fri, 19 Dec 1997 00:57:08 EST Received: from ameritech.net (dyn-max2-146.detroit.mi.ameritech.net [206.141.224.146]) by mailhost.detroit.mi.ameritech.net (8.8.3/8.8.3-AIMS) with ESMTP id AAA00093; Fri, 19 Dec 1997 00:53:20 -0500 (EST) Message-ID: <349A0BE4.A7D89856@ameritech.net> Date: Fri, 19 Dec 1997 00:53:40 -0500 From: Rob Montgomery Reply-To: robm@null.net X-Mailer: Mozilla 4.03 [en] (Win95; U) MIME-Version: 1.0 To: Peter Higginson CC: "'robm@null.net'" , "'vrrp@drcoffsite.com'" , "'hinden@ipsilon.com'" Subject: Re: Virtual MAC Addresses... again. References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Precedence: bulk Sender: VRRP-owner@drcoffsite.com Correct me if I'm wrong, but RFC 826 doesn't exactly read as a 'suggestion.' The relavent portion states: --------------------------- RFC - 826, David C. Plummer, November 1982. An Ethernet Address Resolution Protocol or Converting Network Protocol Addresses to 48.bit Ethernet Address for Transmission on Ethernet Hardware Begin Quote--------------------------------------------------------- When an address resolution packet is received, the receiving Ethernet module gives the packet to the Address Resolution module which goes through an algorithm similar to the following. Negative conditionals indicate an end of processing and a discarding of the packet. ?Do I have the hardware type in ar$hrd? Yes: (almost definitely) [optionally check the hardware length ar$hln] ?Do I speak the protocol in ar$pro? Yes: [optionally check the protocol length ar$pln] Merge_flag := false If the pair is already in my translation table, update the sender hardware address field of the entry with the new information in the packet and set Merge_flag to true. ?Am I the target protocol address? Yes: If Merge_flag is false, add the triplet to the translation table. ?Is the opcode ares_op$REQUEST? (NOW look at the opcode!!) Yes: Swap hardware and protocol fields, putting the local hardware and protocol addresses in the sender fields. Set the ar$op field to ares_op$REPLY Send the packet to the (new) target hardware address on the same hardware on which the request was received. End Quote---------------------------------------------------------- Based on this, a broadcast ARP-Response (Source Protocol Address = Router, Source Hardware Address = Router, Target Protocol Address = Broadcast, Target MAC Address = Broadcast) is going to be processed, and the ARP-Cache will be updated accordingly. Are there devices out there that don't comply with this RFC? Yes. But allow me to point out section 2.1 of your draft: Begin Quote------------------------------------------------------- 2.1 IP Address Backup Backup of IP addresses is the primary function of the Virtual Router Redundancy Protocol. While providing election of a Virtual Router Master and the additional functionality described below, the protocol should strive to: - Minimize the duration of black holes. - Minimize the steady state bandwidth overhead and processing complexity. - Function over a wide variety of multiaccess LAN technologies capable of supporting IP traffic. - Provide for election of multiple virtual routers on a network for load balancing - Support of multiple logical IP subnets on a single LAN segment. End Quote---------------------------------------------------------- Does the use of a Virtual MAC Address minimize processing complexity? Does it function over a 'wide variety of multiaccess LAN technologies?' Am I missing the statement that says ' - Support all proprietary implementations of ARP'? The concept of a virtual MAC address directly contradicts these purposes. Also, it's not just LANE that has an issue. Again, I quote from your draft: Begin Quote-------------------------------------------------------- Unicast mode on token ring has one limitation which should be considered. If there are VRID routers on different source-route bridge segments and there are host implementations which keep their source-route information in the ARP cache and do not listen to gratuitous ARPs, these hosts will not update their ARP source-route information correctly when a switch-over occurs. The only possible solution is to put all routers with the same VRID on the same source- bridge segment and use techniques to prevent that bridge segment from being a single point of failure. These techniques are beyond the scope this document. End Quote----------------------------------------------------------- Does this mean that I can use VRRP is a fully source-route environment, but I still have a single point of failure? Please understand that VRRP is going to be very important to mission critical networks throughout the word, and easy interoperation with standards compliant hardware/software will be instrumental to it's success. By concentrating on support for proprietary implementations of ARP, you have increased the operational complexity of the protocol, made Token Ring and FDDI implementations more difficult, made LANE 1.0 (and some future 'compliant' 2.0) implemtations unworkable. I apologize for my rant, but please understand my frustration. VRRP is, at this point, a good looking protocol that, in my opinion, will be very important. I cannot express, enough of my appreciation to the whole working group for your work on this protocol. As an end-user it will be extremely helpful. But please, seriously consider the ramafications of using the Virtual MAC Address. Thanks for your consideration, -Rob Montgomery robm@null.net From VRRP-owner@drcoffsite.com Fri Dec 19 12:18:58 1997 Delivery-Date: Fri, 19 Dec 1997 12:18:58 -0500 Return-Path: VRRP-owner@drcoffsite.com Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id MAA28825 for ; Fri, 19 Dec 1997 12:18:57 -0500 (EST) Received: from drcoffsite.com (gw.drcoffsite.com [207.247.102.1]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with SMTP id MAA19196 for ; Fri, 19 Dec 1997 12:21:34 -0500 (EST) Received: from joshua.drcoffsite.com [207.247.102.12] by drcoffsite.com (SMTPD32-4.03) id A77DE5D0204; Fri, 19 Dec 1997 11:57:33 EST Received: from mailhost.Ipsilon.COM [205.226.5.12] by joshua.drcoffsite.com (SMTPD32-4.03) id A78EAA700E8; Fri, 19 Dec 1997 11:57:50 EST Received: from spruce.ipsilon.com (spruce.Ipsilon.COM [205.226.1.63]) by mailhost.Ipsilon.COM (8.6.11/8.6.10) with SMTP id IAA23036; Fri, 19 Dec 1997 08:54:13 -0800 Message-Id: <3.0.3.32.19971219085400.00919850@mailhost.ipsilon.com> X-Sender: hinden@mailhost.ipsilon.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Fri, 19 Dec 1997 08:54:00 -0800 To: robm@null.net From: Bob Hinden Subject: Re: Virtual MAC Addresses... again. Cc: vrrp@drcoffsite.com In-Reply-To: <349A0BE4.A7D89856@ameritech.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Precedence: bulk Sender: VRRP-owner@drcoffsite.com Rob, I think the underlying issue is current practice, not specifications. In practice hosts implement the specifications in various ways and there is considerable experience that just doing gratuitous ARP is not sufficient. It does not work with all deployed hosts. A solution was needed that works with all deployed hosts. Hope this helps. Bob From VRRP-owner@drcoffsite.com Fri Dec 19 19:35:59 1997 Delivery-Date: Fri, 19 Dec 1997 19:36:00 -0500 Return-Path: VRRP-owner@drcoffsite.com Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id TAA03680 for ; Fri, 19 Dec 1997 19:35:59 -0500 (EST) Received: from drcoffsite.com (gw.drcoffsite.com [207.247.102.1]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with SMTP id TAA20738 for ; Fri, 19 Dec 1997 19:38:49 -0500 (EST) Received: from mailhost.detroit.mi.ameritech.net [206.141.193.243] by drcoffsite.com with ESMTP (SMTPD32-4.03) id AC4C54250204; Fri, 19 Dec 1997 19:07:40 EST Received: from ameritech.net (dyn-max2-244.detroit.mi.ameritech.net [206.141.224.244]) by mailhost.detroit.mi.ameritech.net (8.8.3/8.8.3-AIMS) with ESMTP id TAA15991; Fri, 19 Dec 1997 19:04:25 -0500 (EST) Message-ID: <349B0BAE.D73DEAFB@ameritech.net> Date: Fri, 19 Dec 1997 19:05:02 -0500 From: Rob Montgomery Reply-To: robm@null.net X-Mailer: Mozilla 4.03 [en] (Win95; U) MIME-Version: 1.0 To: Bob Hinden CC: robm@null.net, vrrp@drcoffsite.com Subject: Re: Virtual MAC Addresses... again. References: <3.0.3.32.19971219085400.00919850@mailhost.ipsilon.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Precedence: bulk Sender: VRRP-owner@drcoffsite.com Bob, I still disagree, but I know when I'm on the losing side. May I suggest, however, that the spirit that you've put forth below be properly represented in section 2.1. Thanks, - Rob Montgomery robm@null.net Bob Hinden wrote: > > Rob, > > I think the underlying issue is current practice, not specifications. In > practice hosts implement the specifications in various ways and there is > considerable experience that just doing gratuitous ARP is not sufficient. > It does not work with all deployed hosts. A solution was needed that works > with all deployed hosts. > > Hope this helps. > > Bob From VRRP-owner@drcoffsite.com Wed Dec 24 10:31:28 1997 Delivery-Date: Wed, 24 Dec 1997 10:31:28 -0500 Return-Path: VRRP-owner@drcoffsite.com Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id KAA29942 for ; Wed, 24 Dec 1997 10:31:27 -0500 (EST) Received: from drcoffsite.com (gw.drcoffsite.com [209.150.7.1]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with SMTP id KAA07716 for ; Wed, 24 Dec 1997 10:34:04 -0500 (EST) Received: from ns.ietf.org [132.151.1.19] by drcoffsite.com with ESMTP (SMTPD32-4.03) id A7754CBD0230; Wed, 24 Dec 1997 10:17:09 EST Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id KAA29479; Wed, 24 Dec 1997 10:15:22 -0500 (EST) Message-Id: <199712241515.KAA29479@ns.ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce@ns.ietf.org Cc: vrrp@drcoffsite.com From: Internet-Drafts@ns.ietf.org Reply-to: Internet-Drafts@ns.ietf.org Subject: I-D ACTION:draft-ietf-vrrp-mib-00.txt Date: Wed, 24 Dec 1997 10:15:18 -0500 X-Sender: cclark@cnri.reston.va.us Precedence: bulk Sender: VRRP-owner@drcoffsite.com --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Virtual Router Redundancy Protocol Working Group of the IETF. Title : Definitions of Managed Objects for the Virtual Router Redundancy Protocol using SNMPv2 Author(s) : B. Jewell, D. Chuang Filename : draft-ietf-vrrp-mib-00.txt Pages : 26 Date : 23-Dec-97 This specification defines an extension to the Management Information Base (MIB) for use with SNMP-based network management. In particular, it defines objects for configuring, monitoring, and controlling routers that employ the Virtual Router Redundancy Protocol (VRRP) [1]. This memo specifies a MIB module in a manner that is both compliant to the SNMPv2 SMI [2], and semantically identical to the SNMPv1 definitions [3]. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-vrrp-mib-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-vrrp-mib-00.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-vrrp-mib-00.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19971224100214.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-vrrp-mib-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-vrrp-mib-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19971224100214.I-D@ietf.org> --OtherAccess-- --NextPart-- From adm Wed Dec 24 11:22:13 1997 Delivery-Date: Wed, 24 Dec 1997 11:31:20 -0500 Return-Path: adm Received: (from adm@localhost) by ns.ietf.org (8.8.7/8.8.7a) id LAA01315 for ietf-123-outbound.10@ietf.org; Wed, 24 Dec 1997 11:22:03 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id KAA29479; Wed, 24 Dec 1997 10:15:22 -0500 (EST) Message-Id: <199712241515.KAA29479@ns.ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce Cc: vrrp@drcoffsite.com From: Internet-Drafts@ns.ietf.org Reply-to: Internet-Drafts@ns.ietf.org Subject: I-D ACTION:draft-ietf-vrrp-mib-00.txt Date: Wed, 24 Dec 1997 10:15:18 -0500 Sender: cclark@cnri.reston.va.us --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Virtual Router Redundancy Protocol Working Group of the IETF. Title : Definitions of Managed Objects for the Virtual Router Redundancy Protocol using SNMPv2 Author(s) : B. Jewell, D. Chuang Filename : draft-ietf-vrrp-mib-00.txt Pages : 26 Date : 23-Dec-97 This specification defines an extension to the Management Information Base (MIB) for use with SNMP-based network management. In particular, it defines objects for configuring, monitoring, and controlling routers that employ the Virtual Router Redundancy Protocol (VRRP) [1]. This memo specifies a MIB module in a manner that is both compliant to the SNMPv2 SMI [2], and semantically identical to the SNMPv1 definitions [3]. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-vrrp-mib-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-vrrp-mib-00.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-vrrp-mib-00.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19971224100214.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-vrrp-mib-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-vrrp-mib-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19971224100214.I-D@ietf.org> --OtherAccess-- --NextPart-- From VRRP-owner@drcoffsite.com Mon Dec 29 09:01:57 1997 Delivery-Date: Mon, 29 Dec 1997 09:01:57 -0500 Return-Path: VRRP-owner@drcoffsite.com Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id JAA13887 for ; Mon, 29 Dec 1997 09:01:52 -0500 (EST) Received: from drcoffsite.com (gw.drcoffsite.com [209.150.7.1]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with SMTP id JAA01562 for ; Mon, 29 Dec 1997 09:04:29 -0500 (EST) Received: from fsnt.future.futsoft.com [38.242.192.5] by drcoffsite.com with ESMTP (SMTPD32-4.03) id A9A01B90448; Mon, 29 Dec 1997 08:46:08 EST Received: from kailash.future.futsoft.com (unverified [38.242.192.4]) by fsnt.future.futsoft.com (Integralis SMTPRS 2.04) with ESMTP id ; Mon, 29 Dec 1997 19:11:42 +0530 Received: from msgate.future.futsoft.com (msgate.future.futsoft.com [10.0.8.4]) by kailash.future.futsoft.com (8.7.1/8.7.1) with SMTP id SAA11289 for ; Mon, 29 Dec 1997 18:43:32 +0530 Received: by msgate.future.futsoft.com with Microsoft Mail id <34A8664B@msgate.future.futsoft.com>; Mon, 29 Dec 97 19:11:07 PST From: raovrn To: "'vrrpmls'" Cc: basila Subject: Doubt regarding Cache updation in Host Date: Mon, 29 Dec 97 17:51:00 PST Message-Id: <34A8664B@msgate.future.futsoft.com> Encoding: 83 TEXT X-Mailer: Microsoft Mail V3.0 Precedence: bulk Sender: VRRP-owner@drcoffsite.com Hi, We have the following doubts regarding the operational aspects of VRRP. 1. Let us consider the following configuration given in VRRP Draft section 4.2. >4.2 Sample Configuration 2 > > The following figure shows a configuration with two virtual routers > with the hosts spitting their traffic between them. > > VRID=1 VRID=2 > +-----+ +-----+ > | MR1 | | MR2 | > | & | | & | > | BR2 | | BR1 | > +-----+ +-----+ > IP A ---------->* *<---------- IP B > | | > | | > | | > ------------------+------------+-----+--------+--------+--------+-- > ^ ^ ^ ^ > | | | | > (IP A) (IP A) (IP B) (IP B) > | | | | > +--+--+ +--+--+ +--+--+ +--+--+ > | H1 | | H2 | | H3 | | H4 | > +-----+ +-----+ +--+--+ +--+--+ > > Legend: > ---+---+---+-- = 802 network, Ethernet or FDDI > H = Host computer > MR = Master Router > BR = Backup Router > * = IP Address > (IP) = default router for hosts In the virtual router VRID 1, the Master IP Address is IP "A", and associated IP Address is IP "B". Similarly, for VRID 2, the Master IP Address is IP "B", and associated IP Address is IP "A". When router VRID 1 sends the gratuitous ARP request, the ARP cache in all the hosts will be updated with the virtual MAC address "00 00 5E XX XX 01". Host H3 and H4 ARP cache should be updated with virtual MAC address "00 00 5E XX XX 02" which will not happen because gratuitous ARP request is sent to all the associated IP addresses also. A similar situation arises, if VRID 2 sends gratuitous request. Pl. correct us if we are wrong on this assumption. If this assumption is correct, how do we make the hosts H3 and H4 have virtual MAC address "00 00 5E XX XX 02". How does load sharing occur, if all the hosts have the same virtual MAC address. 2. Also, we are curious to know how the virtual MAC address gets filled up during ARP request/reply as source MAC address ? We would appreciate if someone in the mailing list could help us in clarifying these questions. Regards, Rao & Basil V.R.N. Rao & Anton Basil Future Software Pvt., Ltd., 481, Nandanam, Madras - 600 035. Voice : 91-44-4340323, 4330550 (Extn : 331) Fax : 91-44-4344157, 4834551, 4834661 Email : raovrn@future.futsoft.com, basila@future.futsoft.com From VRRP-owner@drcoffsite.com Mon Dec 29 16:55:46 1997 Delivery-Date: Mon, 29 Dec 1997 16:55:46 -0500 Return-Path: VRRP-owner@drcoffsite.com Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id QAA20862 for ; Mon, 29 Dec 1997 16:55:45 -0500 (EST) Received: from drcoffsite.com (gw.drcoffsite.com [209.150.7.1]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with SMTP id QAA02670 for ; Mon, 29 Dec 1997 16:58:23 -0500 (EST) Received: from mail13.digital.com [192.208.46.30] by drcoffsite.com with ESMTP (SMTPD32-4.03) id AA211C340170; Mon, 29 Dec 1997 16:46:09 EST Received: from reohub2.reo.dec.com (reohub2.reo.dec.com [16.37.21.19]) by mail13.digital.com (8.7.5/UNX 1.5/1.0/WV) with SMTP id QAA19956 for ; Mon, 29 Dec 1997 16:39:25 -0500 (EST) Received: by reohub2.reo.dec.com with SMTP (Microsoft Exchange Server Internet Mail Connector Version 4.0.996.35) id <01BD14A2.0BA593A0@reohub2.reo.dec.com>; Mon, 29 Dec 1997 21:38:04 -0000 Message-ID: From: Peter Higginson To: "'raovrn'" , "'vrrpmls'" Cc: "'basila'" Subject: RE: Doubt regarding Cache updation in Host Date: Mon, 29 Dec 1997 21:37:48 -0000 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.996.35 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Precedence: bulk Sender: VRRP-owner@drcoffsite.com The host ARP table can contain many entries, in the example you give, it will get IP A -> 00 00 5E XX XX 01 IP B -> 00 00 5E XX XX 02 in all the hosts (or they may get just the ones they need if they fill their tables from replies to their own requests). So when hosts H3 and H4 look for the MAC address associated with their default router (IP B) they get the second MAC address. Similarly H1 and H2 look for the MAC address associated with IP A and get the first MAC address. This does not require a gratuitous ARP (but may make use of it), if the host needs the MAC address, it will send an ARP request and get the correct reply. For your second question, it depends whether you mean the source MAC address at frame level or the source IP address/MAC address pair in the ARP data. Assuming the second, each router uses its master IP address and the corresponding MAC address. Regards, Peter >-----Original Message----- >From: raovrn [SMTP:raovrn@future.futsoft.com] >Sent: 30 December 1997 01:51 >To: 'vrrpmls' >Cc: basila >Subject: Doubt regarding Cache updation in Host > > >Hi, > >We have the following doubts regarding the operational aspects of VRRP. > >1. Let us consider the following configuration given in VRRP Draft section >4.2. > > >>4.2 Sample Configuration 2 >> >> The following figure shows a configuration with two virtual routers >> with the hosts spitting their traffic between them. >> >> VRID=1 VRID=2 >> +-----+ +-----+ >> | MR1 | | MR2 | >> | & | | & | >> | BR2 | | BR1 | >> +-----+ +-----+ >> IP A ---------->* *<---------- IP B >> | | >> | | >> | | >> ------------------+------------+-----+--------+--------+--------+-- >> ^ ^ ^ ^ >> | | | | >> (IP A) (IP A) (IP B) (IP B) >> | | | | >> +--+--+ +--+--+ +--+--+ +--+--+ >> | H1 | | H2 | | H3 | | H4 | >> +-----+ +-----+ +--+--+ +--+--+ >> >> Legend: >> ---+---+---+-- = 802 network, Ethernet or FDDI >> H = Host computer >> MR = Master Router >> BR = Backup Router >> * = IP Address >> (IP) = default router for hosts > > >In the virtual router VRID 1, the Master IP Address is IP "A", and >associated IP Address is IP "B". Similarly, for VRID 2, the Master IP >Address is IP "B", and associated IP Address is IP "A". > >When router VRID 1 sends the gratuitous ARP request, the ARP cache in all >the hosts will be updated with the virtual MAC address "00 00 5E XX XX 01". >Host H3 and H4 ARP cache should be updated with virtual MAC address "00 00 >5E XX XX 02" which will not happen because gratuitous ARP request is sent to >all the associated IP addresses also. A similar situation arises, if VRID 2 >sends gratuitous request. > >Pl. correct us if we are wrong on this assumption. > > >If this assumption is correct, how do we make the hosts H3 and H4 have >virtual MAC address "00 00 5E XX XX 02". > >How does load sharing occur, if all the hosts have the same virtual MAC >address. > > > >2. Also, we are curious to know how the virtual MAC address gets filled up >during ARP request/reply as source MAC address ? > >We would appreciate if someone in the mailing list could help us in >clarifying these questions. > >Regards, >Rao & Basil > > >V.R.N. Rao & Anton Basil >Future Software Pvt., Ltd., >481, Nandanam, >Madras - 600 035. > >Voice : 91-44-4340323, 4330550 (Extn : 331) >Fax : 91-44-4344157, 4834551, 4834661 >Email : raovrn@future.futsoft.com, basila@future.futsoft.com > From VRRP-owner@drcoffsite.com Tue Dec 30 09:32:42 1997 Delivery-Date: Tue, 30 Dec 1997 09:32:42 -0500 Return-Path: VRRP-owner@drcoffsite.com Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id JAA03333 for ; Tue, 30 Dec 1997 09:32:41 -0500 (EST) Received: from drcoffsite.com (gw.drcoffsite.com [209.150.7.1]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with SMTP id JAA03735 for ; Tue, 30 Dec 1997 09:35:08 -0500 (EST) Received: from fwns1.raleigh.ibm.com [204.146.167.235] by drcoffsite.com with ESMTP (SMTPD32-4.03) id A0CA11510186; Tue, 30 Dec 1997 09:10:18 EST Received: from rtpmail01.raleigh.ibm.com ([9.37.172.24]) by fwns1.raleigh.ibm.com (AIX4.2/UCB 8.7/8.7RTP-FW1.1) with ESMTP id PAA16590; Mon, 29 Dec 1997 15:29:25 -0500 (EST) Received: from aceman.raleigh.ibm.com (aceman.raleigh.ibm.com [9.37.177.119]) by rtpmail01.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id PAA31800; Mon, 29 Dec 1997 15:29:26 -0500 Received: from localhost by aceman.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA16872; Mon, 29 Dec 1997 15:29:22 -0500 Date: Mon, 29 Dec 1997 15:29:22 -0500 (EST) From: Acee Lindem To: raovrn Cc: "'vrrpmls'" , basila Subject: Re: Doubt regarding Cache updation in Host In-Reply-To: <34A8664B@msgate.future.futsoft.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Precedence: bulk Sender: VRRP-owner@drcoffsite.com On Mon, 29 Dec 1997, raovrn wrote: > > Hi, > > We have the following doubts regarding the operational aspects of VRRP. > > 1. Let us consider the following configuration given in VRRP Draft section > 4.2. > > > >4.2 Sample Configuration 2 > > > > The following figure shows a configuration with two virtual routers > > with the hosts spitting their traffic between them. > > > > VRID=1 VRID=2 > > +-----+ +-----+ > > | MR1 | | MR2 | > > | & | | & | > > | BR2 | | BR1 | > > +-----+ +-----+ > > IP A ---------->* *<---------- IP B > > | | > > | | > > | | > > ------------------+------------+-----+--------+--------+--------+-- > > ^ ^ ^ ^ > > | | | | > > (IP A) (IP A) (IP B) (IP B) > > | | | | > > +--+--+ +--+--+ +--+--+ +--+--+ > > | H1 | | H2 | | H3 | | H4 | > > +-----+ +-----+ +--+--+ +--+--+ > > > > Legend: > > ---+---+---+-- = 802 network, Ethernet or FDDI > > H = Host computer > > MR = Master Router > > BR = Backup Router > > * = IP Address > > (IP) = default router for hosts > > > In the virtual router VRID 1, the Master IP Address is IP "A", and > associated IP Address is IP "B". Similarly, for VRID 2, the Master IP > Address is IP "B", and associated IP Address is IP "A". > > When router VRID 1 sends the gratuitous ARP request, the ARP cache in all > the hosts will be updated with the virtual MAC address "00 00 5E XX XX 01". > Host H3 and H4 ARP cache should be updated with virtual MAC address "00 00 > 5E XX XX 02" which will not happen because gratuitous ARP request is sent to > all the associated IP addresses also. A similar situation arises, if VRID 2 > sends gratuitous request. > > Pl. correct us if we are wrong on this assumption. > > > If this assumption is correct, how do we make the hosts H3 and H4 have > virtual MAC address "00 00 5E XX XX 02". > > How does load sharing occur, if all the hosts have the same virtual MAC > address. H1 and H2 have IP A as their default gateway address while H3 and H4 have IP B as their default address. So, when both VR's are available you have the 4 hosts distributed equally over the 2 routers. > > > > 2. Also, we are curious to know how the virtual MAC address gets filled up > during ARP request/reply as source MAC address ? You need a layer-2 API to provide the source MAC address when sending packets. Luckily, we already had a fast-path interface to provide a previously cached MAC header. Hence this wasn't much of a problem for us. Acee From VRRP-owner@drcoffsite.com Tue Jan 13 13:57:59 1998 Delivery-Date: Tue, 13 Jan 1998 13:57:59 -0500 Return-Path: VRRP-owner@drcoffsite.com Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id NAA09231 for ; Tue, 13 Jan 1998 13:57:54 -0500 (EST) Received: from drcoffsite.com (gw.drcoffsite.com [209.150.7.1]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with SMTP id OAA07623 for ; Tue, 13 Jan 1998 14:00:21 -0500 (EST) Received: from mailhost.Ipsilon.COM [205.226.5.12] by drcoffsite.com (SMTPD32-4.03) id A2F78E4C004A; Tue, 13 Jan 1998 13:31:19 EST Received: from spruce.ipsilon.com (spruce.Ipsilon.COM [205.226.1.63]) by mailhost.Ipsilon.COM (8.6.11/8.6.10) with SMTP id KAA28130; Tue, 13 Jan 1998 10:28:44 -0800 Message-Id: <3.0.3.32.19980113103214.00a7b430@mailhost.ipsilon.com> X-Sender: hinden@mailhost.ipsilon.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Tue, 13 Jan 1998 10:32:14 -0800 To: minutes@ns.ietf.org From: Bob Hinden Subject: VRRP W.G. Minutes from Dec97 IETF Cc: vrrp@drcoffsite.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Precedence: bulk Sender: VRRP-owner@drcoffsite.com 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. --------------- From VRRP-owner@drcoffsite.com Thu Jan 15 04:51:12 1998 Delivery-Date: Thu, 15 Jan 1998 04:51:12 -0500 Return-Path: VRRP-owner@drcoffsite.com Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id EAA25471 for ; Thu, 15 Jan 1998 04:51:12 -0500 (EST) Received: from drcoffsite.com (gw.drcoffsite.com [209.150.7.1]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with SMTP id EAA13642 for ; Thu, 15 Jan 1998 04:53:40 -0500 (EST) Received: from fsnt.future.futsoft.com [38.242.192.5] by drcoffsite.com with ESMTP (SMTPD32-4.03) id A78E80A0334; Thu, 15 Jan 1998 04:31:58 EST Received: from kailash.future.futsoft.com (unverified [38.242.192.4]) by fsnt.future.futsoft.com (Integralis SMTPRS 2.04) with ESMTP id ; Thu, 15 Jan 1998 14:55:56 +0530 Received: from msgate.future.futsoft.com (msgate.future.futsoft.com [10.0.8.4]) by kailash.future.futsoft.com (8.7.1/8.7.1) with SMTP id OAA13931 for ; Thu, 15 Jan 1998 14:32:03 +0530 Received: by msgate.future.futsoft.com with Microsoft Mail id <34BE93BE@msgate.future.futsoft.com>; Thu, 15 Jan 98 14:54:54 PST From: basila To: "'SMTP:vrrp@drcoffsite.com'" Subject: Doubt regarding ARP cache updation Date: Thu, 15 Jan 98 14:46:00 PST Message-Id: <34BE93BE@msgate.future.futsoft.com> Encoding: 74 TEXT X-Mailer: Microsoft Mail V3.0 Precedence: bulk Sender: VRRP-owner@drcoffsite.com Hi, We have a doubt in the ARP cache updation in the hosts which affects load sharing Lets consider the following cofiguration specified in "draft-ietf-vrrp-spec-04.txt" (Section 4.2) for explaining load sharing. > The following figure shows a configuration with two virtual routers > with the hosts spitting their traffic between them. > > VRID=1 VRID=2 > +-----+ +-----+ > | MR1 | | MR2 | > | & | | & | > | BR2 | | BR1 | > +-----+ +-----+ > IP A ---------->* *<---------- IP B > | | > | | > | | > ------------------+------------+-----+--------+--------+--------+-- > ^ ^ ^ ^ > | | | | > (IP A) (IP A) (IP B) (IP B) > | | | | > +--+--+ +--+--+ +--+--+ +--+--+ > | H1 | | H2 | | H3 | | H4 | > +-----+ +-----+ +--+--+ +--+--+ > > Legend: > ---+---+---+-- = 802 network, Ethernet or FDDI > H = Host computer > MR = Master Router > BR = Backup Router > * = IP Address > (IP) = default router for hosts In the above configuration, Virtual router VRID 1 will send gratuitous ARP for IP A as well as IP B since the specification says the gratuitous arp should be sent for all the IP address it owns. In this case all the four hosts ARP cache will be updated with virtual MAC "00 00 5E XX XX 01". When the hosts H1 and H2 send data to IP A its MAC address will be the one that of virtual router VRID1 (00 00 5E XX XX 01) and when the hosts H3 and H4 send data to IP B its MAC address will also be the one that of virtual router VRID1 (00 00 5E XX XX 01) So in the above configuration all the four hosts will effectively send data to virtual router VRID 1 and Load sharing will not happen. We would appreciate if someone in the mailing list could help us in clarifying the doubt. Regards, Rao & Basil V.R.N. Rao & Anton Basil Future Software Pvt., Ltd., 481, Nandanam, Madras - 600 035. Voice : 91-44-4340323, 4330550 (Extn : 331) Fax : 91-44-4344157, 4834551, 4834661 Email : raovrn@future.futsoft.com, basila@future.futsoft.com From VRRP-owner@drcoffsite.com Thu Jan 15 12:21:49 1998 Delivery-Date: Thu, 15 Jan 1998 12:21:49 -0500 Return-Path: VRRP-owner@drcoffsite.com Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id MAA04370 for ; Thu, 15 Jan 1998 12:21:48 -0500 (EST) Received: from drcoffsite.com (gw.drcoffsite.com [209.150.7.1]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with SMTP id MAA14999 for ; Thu, 15 Jan 1998 12:24:21 -0500 (EST) Received: from mailhost.Ipsilon.COM [205.226.5.12] by drcoffsite.com (SMTPD32-4.03) id AFBF8BB0218; Thu, 15 Jan 1998 11:56:31 EST Received: from dialup.ipsilon.com (maxdialin6.Ipsilon.COM [205.226.20.236]) by mailhost.Ipsilon.COM (8.6.11/8.6.10) with SMTP id IAA19214; Thu, 15 Jan 1998 08:54:35 -0800 Message-ID: <34BE3FA0.5BC0@ipsilon.com> Date: Thu, 15 Jan 1998 08:56:00 -0800 From: Peter Hunt Reply-To: hunt@Ipsilon.COM Organization: Ipsilon Networks Inc. X-Mailer: Mozilla 3.01 (Win95; I) MIME-Version: 1.0 To: basila CC: "'SMTP:vrrp@drcoffsite.com'" Subject: Re: Doubt regarding ARP cache updation References: <34BE93BE@msgate.future.futsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Precedence: bulk Sender: VRRP-owner@drcoffsite.com Rao & Basil, > In the above configuration, > > Virtual router VRID 1 will send gratuitous ARP for IP A as well as > IP B since the specification says the gratuitous arp should be > sent for all the IP address it owns. In this case all the four > hosts ARP cache will be updated with virtual MAC "00 00 5E XX XX 01". The router on the left owns IP A, and the router on the right owns IP B. When the left router comes up, it will become master of virtual router 1, and will send a gratuitous ARP for IP A, with MAC address 00 00 5E XX XX 01. When the router on the right comes up, it will become master of virtual router 2, and will send a gratuitous ARP for IP B, with MAC address 00 00 5E XX XX 02. So the MAC address used by H1 and H2 to reach IP A will be different from the MAC address used by H3 and H4 to reach IP B. If the router on the right fails, router A will become master of virtual router 2, and will adopt its address (IP B). It will then send out a gratuitous ARP for IP B, with MAC address 00 00 5E XX XX 02. It will also respond to ARP requests for IP B with 00 00 5E XX XX 02. That is, it has taken over the whole virtual router, including the IP address and the VRID (which determines the MAC address). So the hosts' ARP entries for IP A and IP B will always valid, regardless of which VRRP router is master. -- | Peter Hunt | Phone: +1 408 990 2093 | Ipsilon Networks Inc. | Fax: +1 408 743 5677 | 232 Java Drive, Sunnyvale CA 94089-1318 | Email: hunt@ipsilon.com From VRRP-owner@drcoffsite.com Fri Jan 16 23:27:22 1998 Delivery-Date: Fri, 16 Jan 1998 23:27:23 -0500 Return-Path: VRRP-owner@drcoffsite.com Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id XAA14662 for ; Fri, 16 Jan 1998 23:27:17 -0500 (EST) Received: from drcoffsite.com (gw.drcoffsite.com [209.150.7.1]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with SMTP id XAA21509 for ; Fri, 16 Jan 1998 23:29:46 -0500 (EST) Received: from fsnt.future.futsoft.com [38.242.192.5] by drcoffsite.com with ESMTP (SMTPD32-4.03) id AD58531004A; Fri, 16 Jan 1998 23:02:32 EST Received: from kailash.future.futsoft.com (unverified [38.242.192.4]) by fsnt.future.futsoft.com (Integralis SMTPRS 2.04) with ESMTP id ; Sat, 17 Jan 1998 09:26:09 +0530 Received: from msgate.future.futsoft.com (msgate.future.futsoft.com [10.0.8.4]) by kailash.future.futsoft.com (8.7.1/8.7.1) with SMTP id IAA06824; Sat, 17 Jan 1998 08:55:04 +0530 Received: by msgate.future.futsoft.com with Microsoft Mail id <34C0E977@msgate.future.futsoft.com>; Sat, 17 Jan 98 09:25:11 PST From: basila To: basila , Peter Hunt Cc: "'SMTP:vrrp@drcoffsite.com'" Subject: Re: Doubt regarding ARP cache updation Date: Sat, 17 Jan 98 08:24:00 PST Message-Id: <34C0E977@msgate.future.futsoft.com> Encoding: 45 TEXT X-Mailer: Microsoft Mail V3.0 Precedence: bulk Sender: VRRP-owner@drcoffsite.com Peter, >> In the above configuration, >> >> Virtual router VRID 1 will send gratuitous ARP for IP A as well as >> IP B since the specification says the gratuitous arp should be >> sent for all the IP address it owns. In this case all the four >> hosts ARP cache will be updated with virtual MAC "00 00 5E XX XX 01". > The router on the left owns IP A, and the router on the > right owns IP B. > > When the left router comes up, it will become master of > virtual router 1, and will send a gratuitous ARP for IP A, with > MAC address 00 00 5E XX XX 01. When the router on the right comes > up, it will become master of virtual router 2, and will send a > gratuitous ARP for IP B, with MAC address 00 00 5E XX XX 02. > > So the MAC address used by H1 and H2 to reach IP A will > be different from the MAC address used by H3 and H4 to reach IP B. Thanks a lot for your reply. We have few thing to get clarified. You have considered the case where gratuitous ARP is sent for IP A by virtual router VRID1. But in the "draft-ietf-vrrp-spec-04.txt" section 8.2 paragraph 2 , it says gratuitous ARP should be sent for each IP Address on that interface (all IP Address it owns). So gratuitous ARP will be sent to both IP A as well as IP B and all the four hosts will be updated with the virtual address of VRID1 and Load sharing will not happen. Regards Rao & Basil V.R.N. Rao & Anton Basil Future Software Pvt., Ltd., 481, Nandanam, Madras - 600 035. Voice : 91-44-4340323, 4330550 (Extn : 331) Fax : 91-44-4344157, 4834551, 4834661 Email : raovrn@future.futsoft.com, basila@future.futsoft.com From VRRP-owner@drcoffsite.com Mon Jan 19 14:54:03 1998 Delivery-Date: Mon, 19 Jan 1998 14:54:03 -0500 Return-Path: VRRP-owner@drcoffsite.com Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id OAA21779 for ; Mon, 19 Jan 1998 14:54:00 -0500 (EST) Received: from drcoffsite.com (gw.drcoffsite.com [209.150.7.1]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with SMTP id OAA03763 for ; Mon, 19 Jan 1998 14:56:33 -0500 (EST) Received: from mailhost.Ipsilon.COM [205.226.5.12] by drcoffsite.com (SMTPD32-4.03) id A9531B30304; Mon, 19 Jan 1998 14:28:19 EST Received: from pfinger.ipsilon.com (pfinger.Ipsilon.COM [205.226.1.149]) by mailhost.Ipsilon.COM (8.6.11/8.6.10) with ESMTP id LAA09020; Mon, 19 Jan 1998 11:26:06 -0800 Received: from localhost (localhost [127.0.0.1]) by pfinger.ipsilon.com (8.6.12/8.6.12) with SMTP id LAA05428; Mon, 19 Jan 1998 11:26:05 -0800 Message-Id: <199801191926.LAA05428@pfinger.ipsilon.com> X-Authentication-Warning: pfinger.ipsilon.com: Host localhost didn't use HELO protocol X-Mailer: exmh version 2.0beta 12/23/96 To: basila cc: Peter Hunt , "'SMTP:vrrp@drcoffsite.com'" Subject: Re: Doubt regarding ARP cache updation In-reply-to: Your message of "Sat, 17 Jan 1998 08:24:00 PST." <34C0E977@msgate.future.futsoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 19 Jan 1998 11:26:05 -0800 From: Peter Hunt Precedence: bulk Sender: VRRP-owner@drcoffsite.com Rao & Basil, > Thanks a lot for your reply. We have few thing to get clarified. I hope I can help clarify them. > You have considered the case where gratuitous ARP is sent for IP A by > virtual router VRID1. But in the "draft-ietf-vrrp-spec-04.txt" section 8.2 > paragraph 2 , it says gratuitous ARP should be sent for each IP Address on > that interface (all IP Address it owns). That is correct. Section 8.2 Paragraph 2 states: - When configuring an interface, VRRP routers should broadcast a gratuitous ARP request containing the virtual router MAC address for each IP address on that interface. So, in the diagram you included in your initial mail message: VRID=1 VRID=2 +-----+ +-----+ | MR1 | | MR2 | | & | | & | | BR2 | | BR1 | +-----+ +-----+ IP A ---------->* *<---------- IP B | | | | | | ------------------+------------+-----+--------+--------+--------+-- ^ ^ ^ ^ | | | | (IP A) (IP A) (IP B) (IP B) | | | | +--+--+ +--+--+ +--+--+ +--+--+ | H1 | | H2 | | H3 | | H4 | +-----+ +-----+ +--+--+ +--+--+ Legend: ---+---+---+-- = 802 network, Ethernet or FDDI H = Host computer MR = Master Router BR = Backup Router * = IP Address (IP) = default router for hosts ... the router on the left only has one IP address configured on its LAN interface: IP A. Therefore, the router on the left will *only* send a gratuitous ARP for IP A, and the MAC address in the ARP request will be the virtual router MAC address for VRID 1 (ie. 00 00 5E XX XX 01). > So gratuitous ARP will be sent to both IP A as well as IP B and all > the four hosts will be updated with the virtual address of VRID1 and > Load sharing will not happen. This is where we start to disagree :). The only case in which the router on the left will send a gratuitous ARP request for IP B is if the router on the right fails. In that case, the router on the left adopts all the virtual router information from the failed router, including the failed router's VRID, in addition to its own. So, while it's true that in this situation, the router on the left will have both IP A and IP B configured on its LAN interface, IP B will still be associated with VRID 2. So when the router on the left sends out the gratuitous ARP message for IP B, it will contain the virtual router MAC address for VRID 2 (ie. 00 00 5E XX XX 02). Any ARP responses sent for IP A will still contain the virtual router MAC address for VRID 1 (ie. 00 00 5E XX XX 01). I hope some of this helps. If I'm still not considering the situation you're thinking of, please describe the situation in more detail. Thanks and regards, Peter From VRRP-owner@drcoffsite.com Tue Jan 20 04:05:59 1998 Delivery-Date: Tue, 20 Jan 1998 04:05:59 -0500 Return-Path: VRRP-owner@drcoffsite.com Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id EAA05189 for ; Tue, 20 Jan 1998 04:05:58 -0500 (EST) Received: from drcoffsite.com (gw.drcoffsite.com [209.150.7.1]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with SMTP id EAA05398 for ; Tue, 20 Jan 1998 04:08:22 -0500 (EST) Received: from fsnt.future.futsoft.com [38.242.192.5] by drcoffsite.com with ESMTP (SMTPD32-4.03) id A33C1E54017C; Tue, 20 Jan 1998 03:41:32 EST Received: from kailash.future.futsoft.com (unverified [38.242.192.4]) by fsnt.future.futsoft.com (Integralis SMTPRS 2.04) with ESMTP id ; Tue, 20 Jan 1998 14:05:35 +0530 Received: from msgate.future.futsoft.com (msgate.future.futsoft.com [10.0.8.4]) by kailash.future.futsoft.com (8.7.1/8.7.1) with SMTP id NAA14457; Tue, 20 Jan 1998 13:34:43 +0530 Received: by msgate.future.futsoft.com with Microsoft Mail id <34C51F42@msgate.future.futsoft.com>; Tue, 20 Jan 98 14:03:46 PST From: basila To: basila , Peter Hunt Cc: "'SMTP:vrrp@drcoffsite.com'" Subject: Re: Doubt regarding ARP cache updation Date: Tue, 20 Jan 98 14:03:00 PST Message-Id: <34C51F42@msgate.future.futsoft.com> Encoding: 184 TEXT X-Mailer: Microsoft Mail V3.0 Precedence: bulk Sender: VRRP-owner@drcoffsite.com Peter, Thanks for your reply. The following is the scenario i am thinking of. VRID=2 VRID=1 +-----------------------------------------------------+ +----------------+---------------------------------+ | | +-----+ | +-----+ +-----+ | +-----+ | | | | | | MR1 | | MR2 | | | | | | | BR1 | | | & | | & | | | BR2 | | | | | | | BR2 | | BR1 | | | | | | +-----+ | +-----+ +-----+ | +-----+ | | IP C --->* |IP A --->* *<--- IP B | *<--- IP D | | | | | | | | | +----------+-----+---------+------------+----------+ | | | +---------+------------+-------------------+----------+ | | | | --------+---------------+------------+-----+--------+----+---+--------+----- --- ^ ^ ^ ^ | | | | (IP A) (IP B) (IP C) (IP D) | | | | +--+--+ +--+--+ +--+--+ +--+--+ | H1 | | H2 | | H3 | | H4 | +-----+ +-----+ +--+--+ +--+--+ Legend: ---+---+---+-- = 802 network, Ethernet or FDDI H = Host computer MR = Master Router BR = Backup Router * = IP Address (IP) = default router for hosts There are two virtual routers VRID1 and VRID2. VRID 1 consists of three VRRP routers, IP A, IP B and IP C and IP A is the Master router. VRID2 consist of three VRRP routers IP A, IP B and IP D and IP B is the Master router. The following are the doubts: 1) Whether the topology depicted above is allowed? What i feel it is the extension of the sample configuration specified in section 4.2 of "draft-ietf-vrrp-spec-04.txt" If the topology depicted above is allowed, i have the following doubts 2) When IP A becomes master router for VRID 1, it is responsible for forwarding IP packets sent for IP A, IP B and IP C. Am i correct? If i am correct the packet addressed for IP B will be forwarded by VRID1 as well as VRID 2. 3) When IP A becomes Master router for VRID1, Whether gratuitous is sent for the Master router (IP A) alone or even for Backup routers (IP B and IP C). 4) If the gratuitous ARP is sent for Backup routers also, then the IP packets addressed for IP B will be forwarded by VRID1 instead of VRID2. Is it allowed? If the above topology is not allowed, even the configuration specified in section 4.2 of "draft-ietf-vrrp-spec-04.txt" should not allowed. Since both the topologies have the master router in one particular virtual router being backup router in another virtual router. Regards Rao & Basil V.R.N. Rao & Anton Basil Future Software Pvt., Ltd., 481, Nandanam, Madras - 600 035. Voice : 91-44-4340323, 4330550 (Extn : 331) Fax : 91-44-4344157, 4834551, 4834661 Email : raovrn@future.futsoft.com, basila@future.futsoft.com ---------- From: Peter Hunt To: basila Cc: Peter Hunt; 'SMTP:vrrp@drcoffsite.com' Subject: Re: Doubt regarding ARP cache updation Date: Monday, January 19, 1998 11:26AM Rao & Basil, > Thanks a lot for your reply. We have few thing to get clarified. I hope I can help clarify them. > You have considered the case where gratuitous ARP is sent for IP A by > virtual router VRID1. But in the "draft-ietf-vrrp-spec-04.txt" section 8.2 > paragraph 2 , it says gratuitous ARP should be sent for each IP Address on > that interface (all IP Address it owns). That is correct. Section 8.2 Paragraph 2 states: - When configuring an interface, VRRP routers should broadcast a gratuitous ARP request containing the virtual router MAC address for each IP address on that interface. So, in the diagram you included in your initial mail message: VRID=1 VRID=2 +-----+ +-----+ | MR1 | | MR2 | | & | | & | | BR2 | | BR1 | +-----+ +-----+ IP A ---------->* *<---------- IP B | | | | | | ------------------+------------+-----+--------+--------+--------+-- ^ ^ ^ ^ | | | | (IP A) (IP A) (IP B) (IP B) | | | | +--+--+ +--+--+ +--+--+ +--+--+ | H1 | | H2 | | H3 | | H4 | +-----+ +-----+ +--+--+ +--+--+ Legend: ---+---+---+-- = 802 network, Ethernet or FDDI H = Host computer MR = Master Router BR = Backup Router * = IP Address (IP) = default router for hosts ... the router on the left only has one IP address configured on its LAN interface: IP A. Therefore, the router on the left will *only* send a gratuitous ARP for IP A, and the MAC address in the ARP request will be the virtual router MAC address for VRID 1 (ie. 00 00 5E XX XX 01). > So gratuitous ARP will be sent to both IP A as well as IP B and all > the four hosts will be updated with the virtual address of VRID1 and > Load sharing will not happen. This is where we start to disagree :). The only case in which the router on the left will send a gratuitous ARP request for IP B is if the router on the right fails. In that case, the router on the left adopts all the virtual router information from the failed router, including the failed router's VRID, in addition to its own. So, while it's true that in this situation, the router on the left will have both IP A and IP B configured on its LAN interface, IP B will still be associated with VRID 2. So when the router on the left sends out the gratuitous ARP message for IP B, it will contain the virtual router MAC address for VRID 2 (ie. 00 00 5E XX XX 02). Any ARP responses sent for IP A will still contain the virtual router MAC address for VRID 1 (ie. 00 00 5E XX XX 01). I hope some of this helps. If I'm still not considering the situation you're thinking of, please describe the situation in more detail. Thanks and regards, Peter From owner-nat@livingston.com Wed Jan 21 07:08:32 1998 Delivery-Date: Wed, 21 Jan 1998 07:08:32 -0500 Return-Path: owner-nat@livingston.com Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id HAA23708 for ; Wed, 21 Jan 1998 07:08:31 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id EAA01204; Wed, 21 Jan 1998 04:00:40 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id EAA17129 for nat-outgoing; Wed, 21 Jan 1998 04:01:38 -0800 (PST) From: "John Tavs" To: , , Cc: "Joel Halpern" , "Scott Bradner" Subject: (NAT) 5,371,852 Method and Apparatus for Making A Cluster of Computers Appear as a Single Host on A Network Date: Tue, 20 Jan 1998 12:28:37 -0500 Message-ID: <01bd25c8$d7738140$36512509@webhead.raleigh.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.71.1712.3 X-MimeOLE: Produced By Microsoft MimeOLE V4.71.1712.3 Sender: owner-nat@livingston.com Precedence: bulk Reply-To: "John Tavs" IBM has indentified a patent which it believes relates to the NAT and VRRP working groupss,and in accordance with the intellectual property rights procedures of the IETF standards process , IBM is willing to offer non-exclusive licenses under reasonable and non-discriminatory terms and conditions. Any party wishing to request a license should write to: IBM Director of Licensing IBM Corporation 500 Columbus Avenue Thornwood, New York 10594 John Tavs (t) 919-254-7610 (p)800-541-4651 Mgr, TCP/IP Technology - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe nat' in the body of the message. From VRRP-owner@drcoffsite.com Wed Jan 21 07:12:55 1998 Delivery-Date: Wed, 21 Jan 1998 07:12:55 -0500 Return-Path: VRRP-owner@drcoffsite.com Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id HAA23731 for ; Wed, 21 Jan 1998 07:12:50 -0500 (EST) Received: from drcoffsite.com (gw.drcoffsite.com [209.150.7.1]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with SMTP id HAA09229 for ; Wed, 21 Jan 1998 07:15:26 -0500 (EST) Received: from fwns2.raleigh.ibm.com [204.146.167.236] by drcoffsite.com with ESMTP (SMTPD32-4.03) id A3BB1785024A; Wed, 21 Jan 1998 07:02:03 EST Received: from rtpmail02.raleigh.ibm.com (rtpmail02.raleigh.ibm.com [9.37.172.48]) by fwns2.raleigh.ibm.com (AIX4.2/UCB 8.7/8.7RTP-FW1.1) with ESMTP id HAA32924; Wed, 21 Jan 1998 07:00:04 -0500 (EST) Received: from webhead.raleigh.ibm.com (lig32-225-143-234.us.lig-dial.ibm.com [32.225.143.234]) by rtpmail02.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id GAA23718; Wed, 21 Jan 1998 06:59:49 -0500 From: "John Tavs" To: , , Cc: "Joel Halpern" , "Scott Bradner" Subject: 5,371,852 Method and Apparatus for Making A Cluster of Computers Appear as a Single Host on A Network Date: Tue, 20 Jan 1998 12:28:37 -0500 Message-ID: <01bd25c8$d7738140$36512509@webhead.raleigh.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.71.1712.3 X-MimeOLE: Produced By Microsoft MimeOLE V4.71.1712.3 Precedence: bulk Sender: VRRP-owner@drcoffsite.com IBM has indentified a patent which it believes relates to the NAT and VRRP working groupss,and in accordance with the intellectual property rights procedures of the IETF standards process , IBM is willing to offer non-exclusive licenses under reasonable and non-discriminatory terms and conditions. Any party wishing to request a license should write to: IBM Director of Licensing IBM Corporation 500 Columbus Avenue Thornwood, New York 10594 John Tavs (t) 919-254-7610 (p)800-541-4651 Mgr, TCP/IP Technology From VRRP-owner@drcoffsite.com Wed Jan 21 11:49:05 1998 Delivery-Date: Wed, 21 Jan 1998 11:49:05 -0500 Return-Path: VRRP-owner@drcoffsite.com Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id LAA25987 for ; Wed, 21 Jan 1998 11:49:05 -0500 (EST) Received: from drcoffsite.com (gw.drcoffsite.com [209.150.7.1]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with SMTP id LAA10196 for ; Wed, 21 Jan 1998 11:51:45 -0500 (EST) Received: from mailhost.Ipsilon.COM [205.226.5.12] by drcoffsite.com (SMTPD32-4.03) id A4B33301FC; Wed, 21 Jan 1998 11:39:15 EST Received: from dialup.ipsilon.com (maxdialin7.Ipsilon.COM [205.226.20.237]) by mailhost.Ipsilon.COM (8.6.11/8.6.10) with SMTP id IAA26001; Wed, 21 Jan 1998 08:37:20 -0800 Message-ID: <34C6247A.677E@ipsilon.com> Date: Wed, 21 Jan 1998 08:38:45 -0800 From: Peter Hunt Reply-To: hunt@Ipsilon.COM Organization: Ipsilon Networks Inc. X-Mailer: Mozilla 3.01 (Win95; I) MIME-Version: 1.0 To: basila CC: "'SMTP:vrrp@drcoffsite.com'" Subject: Re: Doubt regarding ARP cache updation References: <34C51F42@msgate.future.futsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Precedence: bulk Sender: VRRP-owner@drcoffsite.com Rao & Basil, thanks for giving more detail; sorry I didn't get back to you yesterday. I think I can help clarify things. > The following are the doubts: > > 1) Whether the topology depicted above is allowed? What i feel it > is the extension of the sample configuration specified in > section 4.2 of "draft-ietf-vrrp-spec-04.txt" Yes, the configuration you've described is allowed. > If the topology depicted above is allowed, i have the following doubts > > 2) When IP A becomes master router for VRID 1, it is responsible for > forwarding IP packets sent for IP A, IP B and IP C. Am i correct? No, that is not correct. A virtual router only contains the IP addresses for one of the routers. Or, to put it another way, backup routers of a virtual router don't have their addresses backed up by that virtual router. Let me illustrate this using a simpler configuration, and then I'll come back to the configuration you've described: VRID=1 +-----+ +-----+ | | | | | MR1 | | BR1 | | | | | +-----+ +-----+ IP A ---------->* *<---------- IP B | | | | | | ------------------+------------+-------------- In this configuration, IPA is backed up using virtual router VRID1. The router on the left is the owner of IP A; whenever it is up, it will forward packets for IP A. The router on the right is a backup router for VRID1. Whenever the router on the left fails, it will take over responsibility for forwarding packets for IP A. The router on the right is configured with IP B, which it uses to access the LAN. IP B is not backed up using VRID 1. If the router on the right fails, nothing adopts IP B. In order to back up IP B, you'd have to configure a second virtual router, with the router on the right as owner, and the router on the left as backup. When first configured, the router on the left will send a gratuitous ARP request for IP A, using 00:00:5E:XX:XX:01. The router on the right will send one for IP B using it's device's physical MAC address. The two routers will respond to ARP requests the same way. If the router on the left fails, the router on the right will adopt the information for VRID 1. Until the router on the left comes back, the router on the right will respond to ARP requests for IP A, using 00:00:5E:XX:XX:01, *and* respond to ARP requests for IP B using it's device's physical MAC address. In the configuration you've specified, IP A will be backed up by VRID 1, and IP B will be backed up by VRID 2. IP C and IP D won't be backed up; you would need another virtual router for each of these addresses to implement failover for them. So whoever is master of VRID 1 will respond to ARP requests for IP A, using 00:00:5E:XX:XX:01, and whoever is master of VRID 2 will respond to ARP requests for IP B, using 00:00:5E:XX:XX:02. ARP requests for IP C and IP D will only ever be responded to by the routers which are shown to have them now. Those responses will contain the physical LAN addresses of those routers. I hope this helps clarify how virtual routers work in VRRP2. I also hope I haven't put you to sleep with my long-winded description. Your question makes me think that we may need to clarify the definitions and example text in the draft to explain this better. Do you think we need to do this? -- | Peter Hunt | Phone: +1 408 990 2093 | Ipsilon Networks Inc. | Fax: +1 408 743 5677 | 232 Java Drive, Sunnyvale CA 94089-1318 | Email: hunt@ipsilon.com From owner-nat@livingston.com Wed Jan 21 16:00:22 1998 Delivery-Date: Wed, 21 Jan 1998 16:00:22 -0500 Return-Path: owner-nat@livingston.com Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id QAA27674 for ; Wed, 21 Jan 1998 16:00:21 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id MAA17182; Wed, 21 Jan 1998 12:53:44 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id MAA21750 for nat-outgoing; Wed, 21 Jan 1998 12:57:59 -0800 (PST) Message-Id: <3.0.5.32.19980121132247.00818d60@lint.cisco.com> X-Sender: pferguso@lint.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Wed, 21 Jan 1998 13:22:47 -0500 To: "John Tavs" From: Paul Ferguson Subject: Re: (NAT) 5,371,852 Method and Apparatus for Making A Cluster of Computers Appear as a Single Host on A Network Cc: , , , "Joel Halpern" , "Scott Bradner" In-Reply-To: <01bd25c8$d7738140$36512509@webhead.raleigh.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-nat@livingston.com Precedence: bulk Reply-To: Paul Ferguson Hello, Would it be possible to provide a patent number as a reference? Thank you, - paul At 12:28 PM 1/20/98 -0500, John Tavs wrote: >IBM has indentified a patent which it believes relates to the NAT and >VRRP working groupss,and in accordance with the intellectual property > rights procedures of the IETF standards process , >IBM is willing to offer non-exclusive licenses under reasonable > and non-discriminatory terms and conditions. Any party wishing >to request a license should write to: > >IBM Director of Licensing >IBM Corporation >500 Columbus Avenue >Thornwood, New York 10594 > >John Tavs (t) 919-254-7610 (p)800-541-4651 >Mgr, TCP/IP Technology > -- Paul Ferguson || || Consulting Engineering || || Herndon, Virginia USA |||| |||| tel: +1.703.397.5938 ..:||||||:..:||||||:.. mailto:ferguson@cisco.com c i s c o S y s t e m s - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe nat' in the body of the message. From VRRP-owner@drcoffsite.com Wed Jan 21 16:16:25 1998 Delivery-Date: Wed, 21 Jan 1998 16:16:25 -0500 Return-Path: VRRP-owner@drcoffsite.com Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id QAA27788 for ; Wed, 21 Jan 1998 16:16:25 -0500 (EST) Received: from drcoffsite.com (gw.drcoffsite.com [209.150.7.1]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with SMTP id QAA11290 for ; Wed, 21 Jan 1998 16:19:02 -0500 (EST) Received: from diablo.cisco.com [171.68.223.106] by drcoffsite.com with ESMTP (SMTPD32-4.03) id A1D6CC01FE; Wed, 21 Jan 1998 16:00:06 EST Received: from big-dawgs.cisco.com (sj-dial-1-20.cisco.com [171.68.180.21]) by diablo.cisco.com (8.8.5/CISCO.SERVER.1.2) with SMTP id MAA08689; Wed, 21 Jan 1998 12:58:14 -0800 (PST) Message-Id: <3.0.5.32.19980121132247.00818d60@lint.cisco.com> X-Sender: pferguso@lint.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Wed, 21 Jan 1998 13:22:47 -0500 To: "John Tavs" From: Paul Ferguson Subject: Re: (NAT) 5,371,852 Method and Apparatus for Making A Cluster of Computers Appear as a Single Host on A Network Cc: , , , "Joel Halpern" , "Scott Bradner" In-Reply-To: <01bd25c8$d7738140$36512509@webhead.raleigh.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Precedence: bulk Sender: VRRP-owner@drcoffsite.com Hello, Would it be possible to provide a patent number as a reference? Thank you, - paul At 12:28 PM 1/20/98 -0500, John Tavs wrote: >IBM has indentified a patent which it believes relates to the NAT and >VRRP working groupss,and in accordance with the intellectual property > rights procedures of the IETF standards process , >IBM is willing to offer non-exclusive licenses under reasonable > and non-discriminatory terms and conditions. Any party wishing >to request a license should write to: > >IBM Director of Licensing >IBM Corporation >500 Columbus Avenue >Thornwood, New York 10594 > >John Tavs (t) 919-254-7610 (p)800-541-4651 >Mgr, TCP/IP Technology > -- Paul Ferguson || || Consulting Engineering || || Herndon, Virginia USA |||| |||| tel: +1.703.397.5938 ..:||||||:..:||||||:.. mailto:ferguson@cisco.com c i s c o S y s t e m s From owner-nat@livingston.com Wed Jan 21 16:32:39 1998 Delivery-Date: Wed, 21 Jan 1998 16:32:39 -0500 Return-Path: owner-nat@livingston.com Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id QAA27904 for ; Wed, 21 Jan 1998 16:32:38 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id NAA17993; Wed, 21 Jan 1998 13:25:59 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id NAA24746 for nat-outgoing; Wed, 21 Jan 1998 13:31:11 -0800 (PST) From: Bill Manning Message-Id: <199801212129.NAA23014@zephyr.isi.edu> Subject: Re: (NAT) 5,371,852 Method and Apparatus for Making A Cluster To: ferguson@cisco.com (Paul Ferguson) Date: Wed, 21 Jan 1998 13:29:24 -0800 (PST) Cc: tavs@raleigh.ibm.com, nat@livingston.com, vrrp@drcoffsite.com, scoya@ns.ietf.org, jhalpern@us.newbridge.com, sob@harvard.edu In-Reply-To: <3.0.5.32.19980121132247.00818d60@lint.cisco.com> from "Paul Ferguson" at Jan 21, 98 01:22:47 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-nat@livingston.com Precedence: bulk Reply-To: Bill Manning > > Hello, > > Would it be possible to provide a patent number as a reference? > > Thank you, > > - paul The patent number is in the subject field. -- --bill - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe nat' in the body of the message. From VRRP-owner@drcoffsite.com Wed Jan 21 16:37:17 1998 Delivery-Date: Wed, 21 Jan 1998 16:37:18 -0500 Return-Path: VRRP-owner@drcoffsite.com Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id QAA27947 for ; Wed, 21 Jan 1998 16:37:17 -0500 (EST) Received: from drcoffsite.com (gw.drcoffsite.com [209.150.7.1]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with SMTP id QAA11354 for ; Wed, 21 Jan 1998 16:39:56 -0500 (EST) Received: from zephyr.isi.edu [128.9.160.160] by drcoffsite.com with ESMTP (SMTPD32-4.03) id A99BE7E01F8; Wed, 21 Jan 1998 16:33:15 EST Received: (from bmanning@localhost) by zephyr.isi.edu (8.8.7/8.8.6) id NAA23014; Wed, 21 Jan 1998 13:29:24 -0800 (PST) From: Bill Manning Message-Id: <199801212129.NAA23014@zephyr.isi.edu> Subject: Re: (NAT) 5,371,852 Method and Apparatus for Making A Cluster To: ferguson@cisco.com (Paul Ferguson) Date: Wed, 21 Jan 1998 13:29:24 -0800 (PST) Cc: tavs@raleigh.ibm.com, nat@livingston.com, vrrp@drcoffsite.com, scoya@ns.ietf.org, jhalpern@us.newbridge.com, sob@harvard.edu In-Reply-To: <3.0.5.32.19980121132247.00818d60@lint.cisco.com> from "Paul Ferguson" at Jan 21, 98 01:22:47 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Precedence: bulk Sender: VRRP-owner@drcoffsite.com > > Hello, > > Would it be possible to provide a patent number as a reference? > > Thank you, > > - paul The patent number is in the subject field. -- --bill From owner-nat@livingston.com Wed Jan 21 20:55:18 1998 Delivery-Date: Wed, 21 Jan 1998 20:55:19 -0500 Return-Path: owner-nat@livingston.com Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id UAA29782 for ; Wed, 21 Jan 1998 20:55:18 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id RAA26751; Wed, 21 Jan 1998 17:48:32 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id RAA15154 for nat-outgoing; Wed, 21 Jan 1998 17:53:30 -0800 (PST) Message-Id: <3.0.5.32.19980121205308.00804eb0@lint.cisco.com> X-Sender: pferguso@lint.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Wed, 21 Jan 1998 20:53:08 -0500 To: Bill Manning From: Paul Ferguson Subject: Re: (NAT) 5,371,852 Method and Apparatus for Making A Cluster Cc: tavs@raleigh.ibm.com, nat@livingston.com, vrrp@drcoffsite.com, scoya@ns.ietf.org, jhalpern@us.newbridge.com, sob@harvard.edu In-Reply-To: <199801212129.NAA23014@zephyr.isi.edu> References: <3.0.5.32.19980121132247.00818d60@lint.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-nat@livingston.com Precedence: bulk Reply-To: Paul Ferguson Thanks -- I realized that after I had sent the message. :-/ - paul At 01:29 PM 1/21/98 -0800, Bill Manning wrote: > >The patent number is in the subject field. > >-- >--bill > > - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe nat' in the body of the message. From VRRP-owner@drcoffsite.com Wed Jan 21 21:02:01 1998 Delivery-Date: Wed, 21 Jan 1998 21:02:01 -0500 Return-Path: VRRP-owner@drcoffsite.com Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id VAA29849 for ; Wed, 21 Jan 1998 21:02:00 -0500 (EST) Received: from drcoffsite.com (gw.drcoffsite.com [209.150.7.1]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with SMTP id VAA12071 for ; Wed, 21 Jan 1998 21:04:42 -0500 (EST) Received: from diablo.cisco.com [171.68.223.106] by drcoffsite.com with ESMTP (SMTPD32-4.03) id A715141B01F6; Wed, 21 Jan 1998 20:55:33 EST Received: from big-dawgs.cisco.com (sj-dial-1-4.cisco.com [171.68.180.5]) by diablo.cisco.com (8.8.5/CISCO.SERVER.1.2) with SMTP id RAA16187; Wed, 21 Jan 1998 17:53:10 -0800 (PST) Message-Id: <3.0.5.32.19980121205308.00804eb0@lint.cisco.com> X-Sender: pferguso@lint.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Wed, 21 Jan 1998 20:53:08 -0500 To: Bill Manning From: Paul Ferguson Subject: Re: (NAT) 5,371,852 Method and Apparatus for Making A Cluster Cc: tavs@raleigh.ibm.com, nat@livingston.com, vrrp@drcoffsite.com, scoya@ns.ietf.org, jhalpern@us.newbridge.com, sob@harvard.edu In-Reply-To: <199801212129.NAA23014@zephyr.isi.edu> References: <3.0.5.32.19980121132247.00818d60@lint.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Precedence: bulk Sender: VRRP-owner@drcoffsite.com Thanks -- I realized that after I had sent the message. :-/ - paul At 01:29 PM 1/21/98 -0800, Bill Manning wrote: > >The patent number is in the subject field. > >-- >--bill > > From VRRP-owner@drcoffsite.com Thu Jan 22 07:10:02 1998 Delivery-Date: Thu, 22 Jan 1998 07:10:03 -0500 Return-Path: VRRP-owner@drcoffsite.com Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id HAA10026 for ; Thu, 22 Jan 1998 07:10:01 -0500 (EST) Received: from drcoffsite.com (gw.drcoffsite.com [209.150.7.1]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with SMTP id HAA12817 for ; Thu, 22 Jan 1998 07:12:41 -0500 (EST) Received: from fsnt.future.futsoft.com [38.242.192.5] by drcoffsite.com with ESMTP (SMTPD32-4.03) id A52379B001F2; Thu, 22 Jan 1998 07:01:39 EST Received: from kailash.future.futsoft.com (unverified [38.242.192.4]) by fsnt.future.futsoft.com (Integralis SMTPRS 2.04) with ESMTP id ; Thu, 22 Jan 1998 17:25:59 +0530 Received: from msgate.future.futsoft.com (msgate.future.futsoft.com [10.0.8.4]) by kailash.future.futsoft.com (8.7.1/8.7.1) with SMTP id QAA08567; Thu, 22 Jan 1998 16:55:48 +0530 Received: by msgate.future.futsoft.com with Microsoft Mail id <34C7F127@msgate.future.futsoft.com>; Thu, 22 Jan 98 17:23:51 PST From: basila To: basila , Peter Hunt Cc: "'SMTP:vrrp@drcoffsite.com'" Subject: Re: Doubt regarding ARP cache updation Date: Thu, 22 Jan 98 17:23:00 PST Message-Id: <34C7F127@msgate.future.futsoft.com> Encoding: 118 TEXT X-Mailer: Microsoft Mail V3.0 Precedence: bulk Sender: VRRP-owner@drcoffsite.com Peter, Thanks for detailed explanation. It helped us a lot to understand the draft better. As you said the draft should be updated to explain better. Even some of the explanation you have given can also get into the draft. Thanks a lot once again Regards Rao & Basil V.R.N. Rao & Anton Basil Future Software Pvt., Ltd., 481, Nandanam, Madras - 600 035. Voice : 91-44-4340323, 4330550 (Extn : 331) Fax : 91-44-4344157, 4834551, 4834661 Email : raovrn@future.futsoft.com, basila@future.futsoft.com ---------- From: Peter Hunt To: basila Cc: 'SMTP:vrrp@drcoffsite.com' Subject: Re: Doubt regarding ARP cache updation Date: Wednesday, January 21, 1998 8:38AM Rao & Basil, thanks for giving more detail; sorry I didn't get back to you yesterday. I think I can help clarify things. > The following are the doubts: > > 1) Whether the topology depicted above is allowed? What i feel it > is the extension of the sample configuration specified in > section 4.2 of "draft-ietf-vrrp-spec-04.txt" Yes, the configuration you've described is allowed. > If the topology depicted above is allowed, i have the following doubts > > 2) When IP A becomes master router for VRID 1, it is responsible for > forwarding IP packets sent for IP A, IP B and IP C. Am i correct? No, that is not correct. A virtual router only contains the IP addresses for one of the routers. Or, to put it another way, backup routers of a virtual router don't have their addresses backed up by that virtual router. Let me illustrate this using a simpler configuration, and then I'll come back to the configuration you've described: VRID=1 +-----+ +-----+ | | | | | MR1 | | BR1 | | | | | +-----+ +-----+ IP A ---------->* *<---------- IP B | | | | | | ------------------+------------+-------------- In this configuration, IPA is backed up using virtual router VRID1. The router on the left is the owner of IP A; whenever it is up, it will forward packets for IP A. The router on the right is a backup router for VRID1. Whenever the router on the left fails, it will take over responsibility for forwarding packets for IP A. The router on the right is configured with IP B, which it uses to access the LAN. IP B is not backed up using VRID 1. If the router on the right fails, nothing adopts IP B. In order to back up IP B, you'd have to configure a second virtual router, with the router on the right as owner, and the router on the left as backup. When first configured, the router on the left will send a gratuitous ARP request for IP A, using 00:00:5E:XX:XX:01. The router on the right will send one for IP B using it's device's physical MAC address. The two routers will respond to ARP requests the same way. If the router on the left fails, the router on the right will adopt the information for VRID 1. Until the router on the left comes back, the router on the right will respond to ARP requests for IP A, using 00:00:5E:XX:XX:01, *and* respond to ARP requests for IP B using it's device's physical MAC address. In the configuration you've specified, IP A will be backed up by VRID 1, and IP B will be backed up by VRID 2. IP C and IP D won't be backed up; you would need another virtual router for each of these addresses to implement failover for them. So whoever is master of VRID 1 will respond to ARP requests for IP A, using 00:00:5E:XX:XX:01, and whoever is master of VRID 2 will respond to ARP requests for IP B, using 00:00:5E:XX:XX:02. ARP requests for IP C and IP D will only ever be responded to by the routers which are shown to have them now. Those responses will contain the physical LAN addresses of those routers. I hope this helps clarify how virtual routers work in VRRP2. I also hope I haven't put you to sleep with my long-winded description. Your question makes me think that we may need to clarify the definitions and example text in the draft to explain this better. Do you think we need to do this? -- | Peter Hunt | Phone: +1 408 990 2093 | Ipsilon Networks Inc. | Fax: +1 408 743 5677 | 232 Java Drive, Sunnyvale CA 94089-1318 | Email: hunt@ipsilon.com From VRRP-owner@drcoffsite.com Tue Jan 27 16:10:53 1998 Delivery-Date: Tue, 27 Jan 1998 16:10:53 -0500 Return-Path: VRRP-owner@drcoffsite.com Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id QAA14166 for ; Tue, 27 Jan 1998 16:10:48 -0500 (EST) Received: from drcoffsite.com (gw.drcoffsite.com [209.150.7.1]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with SMTP id QAA08460 for ; Tue, 27 Jan 1998 16:13:30 -0500 (EST) Received: from drawbridge.ascend.com [198.4.92.1] by drcoffsite.com (SMTPD32-4.03) id AA654F3B006E; Tue, 27 Jan 1998 15:58:13 EST Received: from spud.ascend.com (fw-ext.ascend.com [198.4.92.5]) by drawbridge.ascend.com (8.6.12/8.6.12) with ESMTP id MAA01661 for ; Tue, 27 Jan 1998 12:56:33 -0800 Received: from ascend.com by ascend.com with ESMTP id MAA12729 for ; Tue, 27 Jan 1998 12:56:30 -0800 Received: from ascend.com by ascend.com id MAA03474; Tue, 27 Jan 1998 12:53:20 -0800 Message-Id: <3.0.5.32.19980127125435.008fd480@darla> X-Sender: mhold@darla X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Tue, 27 Jan 1998 12:54:35 -0800 To: vrrp@drcoffsite.com From: Matt Holdrege Subject: Cisco patent issues affecting VRRP Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Precedence: bulk Sender: VRRP-owner@drcoffsite.com Folks who have attended the last two IETF VRRP meetings will recall that I have raised the ugly issue of patents. I mentioned that I was told (about a year ago) that Cisco had threatened suit over our use of home-grown code that resembled HSRP/VRRP. Many folks including some of the Cisco reps in the VRRP WG meeting have asked me for more details as they believe that Cisco intends to have "fair and equitable" licensing. So here it is. Below is a message from our business manager who tried to get "fair and equitable" treatment from Cisco. DISCLAIMER!!! I am not a laywer and this should be treated as hearsay!!! I am Xing out the names out for fear of legal retribution. :) :) ============================================================================ I started with Mr X. After a few phone calls he ceased returning my calls. Then I called Mr Y. He is VP of IOS Licensing or something akin to that. He refered me to Mr. Z. I thought we were going to succeed with him, but he quit returning calls when the IETF decided to go with VRRP. In Mr Y's case I told him where to find a copy of the Cisco Patent and suggested a modest one time paid up worldwide license fee might be a reasonable position for Cisco to take since they offered it at an IETF meeting. I told him we were not interested in receiving any deliverables from Cisco, just the rights to use and distribute the code we have already developed that MIGHT infringe on their patent. ============================================================================ If anyone from Cisco can help us get fair treatment, I'd appreciate it. If anyone from Cisco wants me to fill in the above names, let me know. Matt Holdrege http://www.ascend.com matt@ascend.com From VRRP-owner@drcoffsite.com Tue Jan 27 18:56:37 1998 Delivery-Date: Tue, 27 Jan 1998 18:56:37 -0500 Return-Path: VRRP-owner@drcoffsite.com Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id SAA16714 for ; Tue, 27 Jan 1998 18:56:33 -0500 (EST) Received: from drcoffsite.com (gw.drcoffsite.com [209.150.7.1]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with SMTP id SAA09208 for ; Tue, 27 Jan 1998 18:59:14 -0500 (EST) Received: from red.juniper.net [208.197.169.254] by drcoffsite.com with ESMTP (SMTPD32-4.03) id A34911BC00A4; Tue, 27 Jan 1998 18:52:41 EST Received: from chimp.juniper.net (chimp.juniper.net [208.197.169.196]) by red.juniper.net (8.8.5/8.8.5) with ESMTP id PAA03999; Tue, 27 Jan 1998 15:50:56 -0800 (PST) Received: (from tli@localhost) by chimp.juniper.net (8.7.6/8.7.3) id PAA00401; Tue, 27 Jan 1998 15:50:46 -0800 (PST) Date: Tue, 27 Jan 1998 15:50:46 -0800 (PST) Message-Id: <199801272350.PAA00401@chimp.juniper.net> From: Tony Li To: matt@ascend.com CC: vrrp@drcoffsite.com In-reply-to: <3.0.5.32.19980127125435.008fd480@darla> (message from Matt Holdrege on Tue, 27 Jan 1998 12:54:35 -0800) Subject: Re: Cisco patent issues affecting VRRP Precedence: bulk Sender: VRRP-owner@drcoffsite.com Matt, In draft-li-hsrp-01.txt, you will find the statement: 2 Conditions of Use US Patent number 5,473,599 [2], assigned to Cisco Systems, Inc. may be applicable to HSRP. If an implementation requires the use of any claims of patent no. 5,473,599, Cisco will license such claims on reasonable, nondiscriminatory terms for use in practicing the standard. More specifically, such license will be available for a one-time, paid up fee. You might note that this paragraph was added to comply with RFC 2026, section 10.3.2, paragraph C, which reads in part: (C) Where the IESG knows of rights, or claimed rights under (A), the IETF Executive Director shall attempt to obtain from the claimant of such rights, a written assurance that upon approval by the IESG of the relevant Internet standards track specification(s), any party will be able to obtain the right to implement, use and distribute the technology or works when implementing, using or distributing technology based upon the specific specification(s) under openly specified, reasonable, non-discriminatory terms. Note that this paragraph has the operative words "upon approval". While Cisco's paragraph clearly does not have a contingency for HSRP not being approved, I would find it hard to find fault with them for not honoring those conditions when it is clear (at least in my humble understanding) that to do so is not in their financial interest. I'm sure that this irks you. I find it bothersome as well. However, before you flame me, please understand that I am something of a bystander here. What does this mean to you? Well, if you feel that your VRRP implementation would infringe upon Cisco's HSRP patent, you're basically at their mercy. In my non-lawyer opinion, implementing VRRP does infringe and I sincerely doubt that Cisco will ever actually license HSRP to anyone. I suspect that this makes VRRP effectively unimplementable and thereby assures Cisco of a vendor lock on the technology. Oh well. The irony of having a working group devoted to creating an open standard for the technology end up precluding the open standard I find highly ironic. Tony From VRRP-owner@drcoffsite.com Tue Jan 27 19:56:33 1998 Delivery-Date: Tue, 27 Jan 1998 19:56:34 -0500 Return-Path: VRRP-owner@drcoffsite.com Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id TAA17088 for ; Tue, 27 Jan 1998 19:56:33 -0500 (EST) Received: from drcoffsite.com (gw.drcoffsite.com [209.150.7.1]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with SMTP id TAA09350 for ; Tue, 27 Jan 1998 19:59:14 -0500 (EST) Received: from drawbridge.ascend.com [198.4.92.1] by drcoffsite.com (SMTPD32-4.03) id A0918DE00C4; Tue, 27 Jan 1998 19:49:21 EST Received: from spud.ascend.com (fw-ext.ascend.com [198.4.92.5]) by drawbridge.ascend.com (8.6.12/8.6.12) with ESMTP id QAA16955; Tue, 27 Jan 1998 16:47:50 -0800 Received: from ascend.com by ascend.com with ESMTP id QAA07528; Tue, 27 Jan 1998 16:47:49 -0800 Received: from ascend.com by ascend.com id QAA05509; Tue, 27 Jan 1998 16:44:40 -0800 Message-Id: <3.0.5.32.19980127164730.0090c9c0@darla> X-Sender: mhold@darla X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Tue, 27 Jan 1998 16:47:30 -0800 To: Tony Li From: Matt Holdrege Subject: Re: Cisco patent issues affecting VRRP Cc: vrrp@drcoffsite.com In-Reply-To: <199801272350.PAA00401@chimp.juniper.net> References: <3.0.5.32.19980127125435.008fd480@darla> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Precedence: bulk Sender: VRRP-owner@drcoffsite.com At 03:50 PM 1/27/98 -0800, Tony Li wrote: > (C) Where the IESG knows of rights, or claimed rights under (A), the > IETF Executive Director shall attempt to obtain from the claimant > of such rights, a written assurance that upon approval by the IESG > of the relevant Internet standards track specification(s), any > party will be able to obtain the right to implement, use and > distribute the technology or works when implementing, using or > distributing technology based upon the specific specification(s) > under openly specified, reasonable, non-discriminatory terms. > >Note that this paragraph has the operative words "upon approval". While >Cisco's paragraph clearly does not have a contingency for HSRP not being >approved, I would find it hard to find fault with them for not honoring >those conditions when it is clear (at least in my humble understanding) >that to do so is not in their financial interest. This is way too much legalese for an IETF WG, but... The AD said that if VRRP made it to standards track that the IESG would fully expect Cisco to comply with the above. Again, the reason I posted to the list was due to many requests from the meeting attendents including those from Cisco. I'm not expecting it to be magically resolved anytime soon. Matt Holdrege http://www.ascend.com matt@ascend.com From VRRP-owner@drcoffsite.com Tue Jan 27 20:05:43 1998 Delivery-Date: Tue, 27 Jan 1998 20:05:43 -0500 Return-Path: VRRP-owner@drcoffsite.com Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id UAA17120 for ; Tue, 27 Jan 1998 20:05:42 -0500 (EST) Received: from drcoffsite.com (gw.drcoffsite.com [209.150.7.1]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with SMTP id UAA09366 for ; Tue, 27 Jan 1998 20:08:22 -0500 (EST) Received: from hammurabi.nh.ultra.net [205.162.79.24] by drcoffsite.com with ESMTP (SMTPD32-4.03) id A3BDE5600C4; Tue, 27 Jan 1998 20:02:53 EST Received: from ewg.nh.ultranet.com (ewg.bluefin.net [205.162.67.129]) by hammurabi.nh.ultra.net (8.8.5/ult.n14767) with SMTP id UAA24922; Tue, 27 Jan 1998 20:01:21 -0500 (EST) Message-ID: <34CE829C.257F@nh.ultranet.com> Date: Tue, 27 Jan 1998 19:58:04 -0500 From: Eric W Gray Reply-To: eric.gray@nh.ultranet.com X-Mailer: Mozilla 3.01Gold (Win95; I) MIME-Version: 1.0 To: VRRP-owner@drcoffsite.com CC: matt@ascend.com, vrrp@drcoffsite.com Subject: Re: Cisco patent issues affecting VRRP References: <199801272350.PAA00401@chimp.juniper.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Precedence: bulk Sender: VRRP-owner@drcoffsite.com One of the nice things about not being a lawyer is that anyone trying to come after me for my malpractice insurance after listening to my advice is wasting their time. However. If "a representative of a corporate entity" makes a statement of intent based on which you take action potentially detrimental to your own best interests and subsequently fails to carry out on their expressed intent, they are in breach of contract. Something any of you who has waited to get an offer letter in hand before resigning probably already knows. Deciding to use a potentially licensable technology on the belief that licenses would be granted is certainly such an "action". But does a Internet Draft represent a corporate entity? How about when it is co-authored by a couple of employees of the corporate entity? These are interesting questions... VRRP-owner@drcoffsite.com wrote: > > Matt, > > In draft-li-hsrp-01.txt, you will find the statement: > > 2 Conditions of Use > > US Patent number 5,473,599 [2], assigned to Cisco Systems, Inc. may > be applicable to HSRP. If an implementation requires the use of any > claims of patent no. 5,473,599, Cisco will license such claims on > reasonable, nondiscriminatory terms for use in practicing the > standard. More specifically, such license will be available for a > one-time, paid up fee. > > You might note that this paragraph was added to comply with RFC 2026, > section 10.3.2, paragraph C, which reads in part: > > (C) Where the IESG knows of rights, or claimed rights under (A), > the IETF Executive Director shall attempt to obtain from the > claimant of such rights, a written assurance that upon approval by > the IESG of the relevant Internet standards track specification(s), > any party will be able to obtain the right to implement, use and > distribute the technology or works when implementing, using or > distributing technology based upon the specific specification(s) > under openly specified, reasonable, non-discriminatory terms. > > Note that this paragraph has the operative words "upon approval". > While Cisco's paragraph clearly does not have a contingency for > HSRP not being approved, I would find it hard to find fault with > them for not honoring those conditions when it is clear (at least > in my humble understanding) that to do so is not in their financial > interest. > > I'm sure that this irks you. I find it bothersome as well. > However, before you flame me, please understand that I am > something of a bystander here. > > What does this mean to you? Well, if you feel that your VRRP > implementation would infringe upon Cisco's HSRP patent, you're > basically at their mercy. > > In my non-lawyer opinion, implementing VRRP does infringe and I > sincerely doubt that Cisco will ever actually license HSRP to > anyone. I suspect that this makes VRRP effectively unimplementable > and thereby assures Cisco of a vendor lock on the technology. Oh > well. The irony of having a working group devoted to creating an > open standard for the technology end up precluding the open standard > I find highly ironic. > > Tony -- Eric Gray EMail at mailto:eric.gray@nh.ultranet.com Phone (603) 659-6859 From VRRP-owner@drcoffsite.com Tue Jan 27 20:05:43 1998 Delivery-Date: Tue, 27 Jan 1998 20:05:43 -0500 Return-Path: VRRP-owner@drcoffsite.com Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id UAA17120 for ; Tue, 27 Jan 1998 20:05:42 -0500 (EST) Received: from drcoffsite.com (gw.drcoffsite.com [209.150.7.1]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with SMTP id UAA09366 for ; Tue, 27 Jan 1998 20:08:22 -0500 (EST) Received: from hammurabi.nh.ultra.net [205.162.79.24] by drcoffsite.com with ESMTP (SMTPD32-4.03) id A3BDE5600C4; Tue, 27 Jan 1998 20:02:53 EST Received: from ewg.nh.ultranet.com (ewg.bluefin.net [205.162.67.129]) by hammurabi.nh.ultra.net (8.8.5/ult.n14767) with SMTP id UAA24922; Tue, 27 Jan 1998 20:01:21 -0500 (EST) Message-ID: <34CE829C.257F@nh.ultranet.com> Date: Tue, 27 Jan 1998 19:58:04 -0500 From: Eric W Gray Reply-To: eric.gray@nh.ultranet.com X-Mailer: Mozilla 3.01Gold (Win95; I) MIME-Version: 1.0 To: VRRP-owner@drcoffsite.com CC: matt@ascend.com, vrrp@drcoffsite.com Subject: Re: Cisco patent issues affecting VRRP References: <199801272350.PAA00401@chimp.juniper.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Precedence: bulk Sender: VRRP-owner@drcoffsite.com One of the nice things about not being a lawyer is that anyone trying to come after me for my malpractice insurance after listening to my advice is wasting their time. However. If "a representative of a corporate entity" makes a statement of intent based on which you take action potentially detrimental to your own best interests and subsequently fails to carry out on their expressed intent, they are in breach of contract. Something any of you who has waited to get an offer letter in hand before resigning probably already knows. Deciding to use a potentially licensable technology on the belief that licenses would be granted is certainly such an "action". But does a Internet Draft represent a corporate entity? How about when it is co-authored by a couple of employees of the corporate entity? These are interesting questions... VRRP-owner@drcoffsite.com wrote: > > Matt, > > In draft-li-hsrp-01.txt, you will find the statement: > > 2 Conditions of Use > > US Patent number 5,473,599 [2], assigned to Cisco Systems, Inc. may > be applicable to HSRP. If an implementation requires the use of any > claims of patent no. 5,473,599, Cisco will license such claims on > reasonable, nondiscriminatory terms for use in practicing the > standard. More specifically, such license will be available for a > one-time, paid up fee. > > You might note that this paragraph was added to comply with RFC 2026, > section 10.3.2, paragraph C, which reads in part: > > (C) Where the IESG knows of rights, or claimed rights under (A), > the IETF Executive Director shall attempt to obtain from the > claimant of such rights, a written assurance that upon approval by > the IESG of the relevant Internet standards track specification(s), > any party will be able to obtain the right to implement, use and > distribute the technology or works when implementing, using or > distributing technology based upon the specific specification(s) > under openly specified, reasonable, non-discriminatory terms. > > Note that this paragraph has the operative words "upon approval". > While Cisco's paragraph clearly does not have a contingency for > HSRP not being approved, I would find it hard to find fault with > them for not honoring those conditions when it is clear (at least > in my humble understanding) that to do so is not in their financial > interest. > > I'm sure that this irks you. I find it bothersome as well. > However, before you flame me, please understand that I am > something of a bystander here. > > What does this mean to you? Well, if you feel that your VRRP > implementation would infringe upon Cisco's HSRP patent, you're > basically at their mercy. > > In my non-lawyer opinion, implementing VRRP does infringe and I > sincerely doubt that Cisco will ever actually license HSRP to > anyone. I suspect that this makes VRRP effectively unimplementable > and thereby assures Cisco of a vendor lock on the technology. Oh > well. The irony of having a working group devoted to creating an > open standard for the technology end up precluding the open standard > I find highly ironic. > > Tony -- Eric Gray EMail at mailto:eric.gray@nh.ultranet.com Phone (603) 659-6859 From VRRP-owner@drcoffsite.com Tue Jan 27 20:48:04 1998 Delivery-Date: Tue, 27 Jan 1998 20:48:04 -0500 Return-Path: VRRP-owner@drcoffsite.com Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id UAA17323 for ; Tue, 27 Jan 1998 20:48:03 -0500 (EST) Received: from drcoffsite.com (gw.drcoffsite.com [209.150.7.1]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with SMTP id UAA09443 for ; Tue, 27 Jan 1998 20:50:43 -0500 (EST) Received: from red.juniper.net [208.197.169.254] by drcoffsite.com with ESMTP (SMTPD32-4.03) id AC585605006E; Tue, 27 Jan 1998 20:39:36 EST Received: from chimp.juniper.net (chimp.juniper.net [208.197.169.196]) by red.juniper.net (8.8.5/8.8.5) with ESMTP id RAA09068; Tue, 27 Jan 1998 17:38:03 -0800 (PST) Received: (from tli@localhost) by chimp.juniper.net (8.7.6/8.7.3) id RAA00909; Tue, 27 Jan 1998 17:37:52 -0800 (PST) Date: Tue, 27 Jan 1998 17:37:52 -0800 (PST) Message-Id: <199801280137.RAA00909@chimp.juniper.net> From: Tony Li To: eric.gray@nh.ultranet.com CC: VRRP-owner@drcoffsite.com, matt@ascend.com, vrrp@drcoffsite.com In-reply-to: <34CE829C.257F@nh.ultranet.com> (message from Eric W Gray on Tue, 27 Jan 1998 19:58:04 -0500) Subject: Re: Cisco patent issues affecting VRRP Precedence: bulk Sender: VRRP-owner@drcoffsite.com | If "a representative of a corporate entity" makes a statement of intent | based on which you take action potentially detrimental to your own best | interests and subsequently fails to carry out on their expressed intent, | they are in breach of contract. Something any of you who has waited to | get an offer letter in hand before resigning probably already knows. While that's true, I think an interesting question was that of intent. When we asked Cisco for a statement, it was clear (at least to me ;-) that the intent was to comply with RFC 2026. I think that anyone arguing intent would have to show that Cisco's intent was to make it a blanket license, regardless of advancement. Given that the statement was specifically about HSRP and not about all implementations, I think that one would have a tough job. | Deciding to use a potentially licensable technology on the belief that | licenses would be granted is certainly such an "action". But does a | Internet Draft represent a corporate entity? How about when it is | co-authored by a couple of employees of the corporate entity? How about when it is co-authored by a couple of employees of a different corporate entity? ;-) | These are interesting questions... Inded. | The AD said that if VRRP made it to standards track that the IESG would | fully expect Cisco to comply with the above. I wonder if Cisco even knows about those expectations... or cares... ;-) Tony From VRRP-owner@drcoffsite.com Thu Jan 29 12:29:18 1998 Delivery-Date: Thu, 29 Jan 1998 12:29:19 -0500 Return-Path: VRRP-owner@drcoffsite.com Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id MAA25491 for ; Thu, 29 Jan 1998 12:29:14 -0500 (EST) Received: from drcoffsite.com (gw.drcoffsite.com [209.150.7.1]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with SMTP id MAA15532 for ; Thu, 29 Jan 1998 12:31:50 -0500 (EST) Received: from mailhost.Ipsilon.COM [205.226.5.12] by drcoffsite.com (SMTPD32-4.03) id AAA8E47D0068; Thu, 29 Jan 1998 12:21:44 EST Received: from spruce.ipsilon.com (spruce.Ipsilon.COM [205.226.1.63]) by mailhost.Ipsilon.COM (8.6.11/8.6.10) with SMTP id JAA13456; Thu, 29 Jan 1998 09:20:02 -0800 Message-Id: <3.0.3.32.19980129092315.00956250@mailhost.ipsilon.com> X-Sender: hinden@mailhost.ipsilon.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Thu, 29 Jan 1998 09:23:15 -0800 To: vrrp@drcoffsite.com From: Bob Hinden Subject: VRRP MAC Assignment Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Precedence: bulk Sender: VRRP-owner@drcoffsite.com I am please to report that we now have a IANA MAC assignment. It is: 00-00-5E-00-01-{VRID} (in hex in internet standard bit-order) A new draft will be issued shortly. Bob From VRRP-owner@drcoffsite.com Wed Feb 4 09:29:11 1998 Delivery-Date: Wed, 04 Feb 1998 09:29:11 -0500 Return-Path: VRRP-owner@drcoffsite.com Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id JAA10588 for ; Wed, 4 Feb 1998 09:29:10 -0500 (EST) Received: from drcoffsite.com (gw.drcoffsite.com [209.150.7.1]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with SMTP id JAA20780 for ; Wed, 4 Feb 1998 09:31:50 -0500 (EST) Received: from ns.ietf.org [132.151.1.19] by drcoffsite.com with ESMTP (SMTPD32-4.03) id A8C930116; Wed, 04 Feb 1998 09:18:49 EST Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id JAA10135; Wed, 4 Feb 1998 09:17:21 -0500 (EST) Message-Id: <199802041417.JAA10135@ns.ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce@ns.ietf.org Cc: vrrp@drcoffsite.com From: Internet-Drafts@ns.ietf.org Reply-to: Internet-Drafts@ns.ietf.org Subject: I-D ACTION:draft-ietf-vrrp-spec-05.txt Date: Wed, 04 Feb 1998 09:17:19 -0500 X-Sender: cclark@cnri.reston.va.us Precedence: bulk Sender: VRRP-owner@drcoffsite.com --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Virtual Router Redundancy Protocol Working Group of the IETF. Title : Virtual Router Redundancy Protocol Author(s) : P. Higginson, B. Hinden, S. Knight, A. Lindem, D. Mitzel, M. Shand, D. Whipple, D. Weaver, P. Hunt Filename : draft-ietf-vrrp-spec-05.txt Pages : 30 Date : 03-Feb-98 This memo defines the Virtual Router Redundancy Protocol (VRRP). VRRP specifies an election protocol that dynamically assigns responsibility for a virtual router to one of the VRRP routers on a LAN. The VRRP router controlling the IP address(es) associated with a virtual router is called the Master, and forwards packets sent to these IP addresses. The election process provides dynamic fail over in the forwarding responsibility should the Master become unavailable. This allows any of the virtual router IP addresses on the LAN to be used as the default first hop router by end-hosts. The advantage gained from using VRRP is a higher availability default path without requiring configuration of dynamic routing or router discovery protocols on every end-host. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-vrrp-spec-05.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-vrrp-spec-05.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-vrrp-spec-05.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19980203155401.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-vrrp-spec-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-vrrp-spec-05.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19980203155401.I-D@ietf.org> --OtherAccess-- --NextPart-- From adm Wed Feb 4 09:48:34 1998 Delivery-Date: Wed, 04 Feb 1998 09:53:16 -0500 Return-Path: adm Received: (from adm@localhost) by ns.ietf.org (8.8.7/8.8.7a) id JAA11390 for ietf-123-outbound.10@ietf.org; Wed, 4 Feb 1998 09:47:03 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id JAA10135; Wed, 4 Feb 1998 09:17:21 -0500 (EST) Message-Id: <199802041417.JAA10135@ns.ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce Cc: vrrp@drcoffsite.com From: Internet-Drafts@ns.ietf.org Reply-to: Internet-Drafts@ns.ietf.org Subject: I-D ACTION:draft-ietf-vrrp-spec-05.txt Date: Wed, 04 Feb 1998 09:17:19 -0500 Sender: cclark@cnri.reston.va.us --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Virtual Router Redundancy Protocol Working Group of the IETF. Title : Virtual Router Redundancy Protocol Author(s) : P. Higginson, B. Hinden, S. Knight, A. Lindem, D. Mitzel, M. Shand, D. Whipple, D. Weaver, P. Hunt Filename : draft-ietf-vrrp-spec-05.txt Pages : 30 Date : 03-Feb-98 This memo defines the Virtual Router Redundancy Protocol (VRRP). VRRP specifies an election protocol that dynamically assigns responsibility for a virtual router to one of the VRRP routers on a LAN. The VRRP router controlling the IP address(es) associated with a virtual router is called the Master, and forwards packets sent to these IP addresses. The election process provides dynamic fail over in the forwarding responsibility should the Master become unavailable. This allows any of the virtual router IP addresses on the LAN to be used as the default first hop router by end-hosts. The advantage gained from using VRRP is a higher availability default path without requiring configuration of dynamic routing or router discovery protocols on every end-host. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-vrrp-spec-05.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-vrrp-spec-05.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-vrrp-spec-05.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19980203155401.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-vrrp-spec-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-vrrp-spec-05.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19980203155401.I-D@ietf.org> --OtherAccess-- --NextPart-- From VRRP-owner@drcoffsite.com Wed Feb 4 19:47:18 1998 Delivery-Date: Wed, 04 Feb 1998 19:47:19 -0500 Return-Path: VRRP-owner@drcoffsite.com Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ietf.org (8.8.7/8.8.7a) with ESMTP id TAA25207 for ; Wed, 4 Feb 1998 19:47:18 -0500 (EST) Received: from drcoffsite.com (gw.drcoffsite.com [209.150.7.1]) by cnri.reston.va.us (8.8.5/8.8.7a) with SMTP id TAA00340 for ; Wed, 4 Feb 1998 19:49:59 -0500 (EST) Received: from mailhost.Ipsilon.COM [205.226.5.12] by drcoffsite.com (SMTPD32-4.03) id AAE78A013E; Wed, 04 Feb 1998 19:42:15 EST Received: from spruce.ipsilon.com (spruce.Ipsilon.COM [205.226.1.63]) by mailhost.Ipsilon.COM (8.6.11/8.6.10) with SMTP id QAA03935; Wed, 4 Feb 1998 16:40:47 -0800 Message-Id: <3.0.3.32.19980204164353.008b69b0@mailhost.ipsilon.com> X-Sender: hinden@mailhost.ipsilon.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Wed, 04 Feb 1998 16:43:53 -0800 To: vrrp@drcoffsite.com From: Bob Hinden Subject: [41st IETF-LOS ANGELES: VRRP] Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Precedence: bulk Sender: VRRP-owner@drcoffsite.com FYI >Date: Wed, 04 Feb 1998 17:31:51 -0500 >To: Bob Hinden >From: Marcia Beaulieu >Subject: 41st IETF-LOS ANGELES: VRRP >Cc: jhalpern@newbridge.com > >This is to confirm one session for VRRP as follows: > > Wednesday, April 1 at 1300-1500 (opposite dhc, mboned) > >Please submit an agenda (to agenda@ietf.org) for this meeting as >soon as possible. > >Thanks, > >Marcia > >********************************************************************** >Marcia Beaulieu >Meeting Coordinator >Voice: 703-620-8990 ext. 210 >Fax: 703-758-5913 > > > From VRRP-owner@drcoffsite.com Wed Feb 4 20:27:15 1998 Delivery-Date: Wed, 04 Feb 1998 20:27:16 -0500 Return-Path: VRRP-owner@drcoffsite.com Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ietf.org (8.8.7/8.8.7a) with ESMTP id UAA25572 for ; Wed, 4 Feb 1998 20:27:15 -0500 (EST) Received: from drcoffsite.com (gw.drcoffsite.com [209.150.7.1]) by cnri.reston.va.us (8.8.5/8.8.7a) with SMTP id UAA00461 for ; Wed, 4 Feb 1998 20:29:56 -0500 (EST) Received: from mailhost.Ipsilon.COM [205.226.5.12] by drcoffsite.com (SMTPD32-4.03) id A4824A014C; Wed, 04 Feb 1998 20:23:14 EST Received: from spruce.ipsilon.com (spruce.Ipsilon.COM [205.226.1.63]) by mailhost.Ipsilon.COM (8.6.11/8.6.10) with SMTP id RAA05404; Wed, 4 Feb 1998 17:16:17 -0800 Message-Id: <3.0.3.32.19980204171923.0088f420@mailhost.ipsilon.com> X-Sender: hinden@mailhost.ipsilon.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Wed, 04 Feb 1998 17:19:23 -0800 To: Joel Halpern From: Bob Hinden Subject: Request to Advance "Virtual Router Redundancy Protocol" Cc: scoya@ns.ietf.org, vrrp@drcoffsite.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Precedence: bulk Sender: VRRP-owner@drcoffsite.com Joel, The chair of the VRRP working group, on behalf of the working group, requests that the following document be published as a Proposed Standard: Title : Virtual Router Redundancy Protocol Author(s) : P. Higginson, B. Hinden, S. Knight, A. Lindem, D. Mitzel, M. Shand, D. Whipple, D. Weaver, P. Hunt Filename : draft-ietf-vrrp-spec-05.txt Pages : 30 Date : 03-Feb-98 This document is a product of the VRRP working group. The protocol has been reviewed by the VRRP working group and the group approved it's submission for proposed standard at the Washington, DC IETF. An excerpt from the minutes is attached. This draft includes the last required IANA assignment. Bob Hinden VRRP w.g. chair >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. From VRRP-owner@drcoffsite.com Wed Feb 18 01:37:41 1998 Delivery-Date: Wed, 18 Feb 1998 01:37:41 -0500 Return-Path: VRRP-owner@drcoffsite.com Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id BAA24154 for ; Wed, 18 Feb 1998 01:37:40 -0500 (EST) Received: from drcoffsite.com (dns1.drcoffsite.com [209.150.7.10]) by cnri.reston.va.us (8.8.5/8.8.7a) with SMTP id BAA11158 for ; Wed, 18 Feb 1998 01:40:15 -0500 (EST) Received: from dfw-ix5.ix.netcom.com [206.214.98.5] by drcoffsite.com with ESMTP (SMTPD32-4.03) id AF2D10C03FC; Wed, 18 Feb 1998 01:26:53 EST Received: (from smap@localhost) by dfw-ix5.ix.netcom.com (8.8.4/8.8.4) id AAA25843 for ; Wed, 18 Feb 1998 00:25:16 -0600 (CST) Date: Wed, 18 Feb 1998 00:25:16 -0600 (CST) From: info@cigi.com Message-Id: <199802180625.AAA25843@dfw-ix5.ix.netcom.com> Received: from dd44-159.dub.compuserve.com(199.174.176.159) by dfw-ix5.ix.netcom.com via smap (V1.3) id rma021356; Wed Feb 18 00:24:47 1998 To: vrrp@drcoffsite.com Subject: Shopping Cart - Free Demo Precedence: bulk Sender: VRRP-owner@drcoffsite.com Hello, Thought you may be interested in installing a shopping cart to help better service your customers. If you are interested in seeing how this works you can go to my demo store at: http://205.147.208.119/cashcart/index.html This cart is packed with every possible feature you could ever want. It even comes with a built in search engine. If you would like to find out more about the carts features, you can go to: http://205.147.208.119/cashcart/features.html It won't cost you anything but some time and your commitment to get started. We do not ask for any payments up front, all we ask is that you meet the following requirements: 1) Your pages must be hosted on a UNIX type server. 2) You are serious about purchasing a Shopping Cart to enhance your website. Thats it. If you meet the above requirements, and are ready to add a Shopping Cart to your website, contact us today so we can get started on your working demo. This demo will be created from your own online catalog and will be used as your templates. When you are satisfied with the performance of your working demo and are ready to transfer it over to your server, that is when we ask for payment. PRICES Shopping Cart Program and Manual. $250.00 Shopping Cart Program, Manual, Installation and Tech Support. $425.00 Once we receive payment we will install the Shopping Cart on your server, or provide you with detailed instructions on how to do it yourself, the choice is yours. You will also receive your templates and instructions on how to use them. If you get stuck along the way, we offer tech support via phone or e-mail, for as long as you need it. If you are interested in taking your website to the "next level", or if you have any questions, please, contact me at info@cigi.com Thanks, Eric From VRRP-owner@drcoffsite.com Mon Feb 23 19:24:58 1998 Delivery-Date: Mon, 23 Feb 1998 19:24:58 -0500 Return-Path: VRRP-owner@drcoffsite.com Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id TAA00780 for ; Mon, 23 Feb 1998 19:24:47 -0500 (EST) Received: from drcoffsite.com (gw.drcoffsite.com [209.150.7.1]) by cnri.reston.va.us (8.8.5/8.8.7a) with SMTP id TAA05599 for ; Mon, 23 Feb 1998 19:27:20 -0500 (EST) Received: from janus.3com.com [209.0.73.82] by drcoffsite.com with ESMTP (SMTPD32-4.03) id A11C4DB1011A; Mon, 23 Feb 1998 19:15:24 EST Received: from new-york.3com.com (new-york.3com.com [129.213.157.12]) by janus.3com.com (8.8.2/8.8.5) with ESMTP id QAA00004 for ; Mon, 23 Feb 1998 16:13:59 -0800 (PST) Received: from chicago.nsd.3com.com (chicago.nsd.3com.com [129.213.157.11]) by new-york.3com.com (8.8.2/8.8.5) with ESMTP id PAA23680 for ; Mon, 23 Feb 1998 15:54:30 -0800 (PST) Received: from fubar.nsd.3com.com (fubar.nsd.3com.com [129.213.16.41]) by chicago.nsd.3com.com (8.8.2/8.8.5) with ESMTP id QAA08630; Mon, 23 Feb 1998 16:08:11 -0800 (PST) From: Brian Jewell Received: (from bjewell@localhost) by fubar.nsd.3com.com (8.8.2/8.8.5) id QAA26944; Mon, 23 Feb 1998 16:13:57 -0800 (PST) Date: Mon, 23 Feb 1998 16:13:57 -0800 (PST) Message-Id: <199802240013.QAA26944@fubar.nsd.3com.com> To: vrrp@drcoffsite.com Subject: Suggestion for VRRP Spec. Cc: bjewell@ewd.3Com.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-MD5: etE7Fa5ExrUki6ODvAAWug== Precedence: bulk Sender: VRRP-owner@drcoffsite.com Everyone, In the interest of clarification, I would like to propose one more (minor) addition to the VRRP Specification: In section 1.2 (entitled "Definitions"), a definition for "Associated Address(es)" would be useful. This term has been implicitly used in the VRRP Spec and is needed to further clarify the naming of tables ("vrrpAssoIpAddrTable") in the VRRP MIB. The definition could read something like this: Associated IP Address An IP address that is being back-up by a virtual router. Primarily, a given virtual router would have only one associated IP address, except in the case where multiple IP addresses have been assigned to a single interface. Again, the purpose of this addition would be to provide more consistency between the concept of "a backup-up IP address", as defined in the VRRP Spec and the terminology I have chosen to use in the VRRP MIB. It further ensures the use of a "common language" when speaking or writing about VRRP. Any thoughts on this subject?? Thanks. -Brian Jewell -3Com, Inc. -bjewell@3com.com From adm Fri Feb 27 11:08:56 1998 Delivery-Date: Fri, 27 Feb 1998 11:22:45 -0500 Return-Path: adm Received: (from adm@localhost) by ns.ietf.org (8.8.7/8.8.7a) id LAA11721 for ietf-123-outbound.10@ietf.org; Fri, 27 Feb 1998 11:07:02 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id LAA11670; Fri, 27 Feb 1998 11:06:16 -0500 (EST) Message-Id: <199802271606.LAA11670@ns.ietf.org> To: IETF-Announce: ; Cc: vrrp@drcoffsite.com From: The IESG SUBJECT: Last Call: Virtual Router Redundancy Protocol to Proposed Standard Reply-to: iesg@ns.ietf.org Date: Fri, 27 Feb 1998 11:06:16 -0500 Sender: scoya@cnri.reston.va.us The IESG has received a request from the Virtual Router Redundancy Protocol Working Group to consider Virtual Router Redundancy Protocol as a Proposed Standard. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by March 13, 1998. Files can be obtained via ftp://ftp.ietf.org/internet-drafts/draft-ietf-vrrp-spec-05.txt From VRRP-owner@drcoffsite.com Fri Feb 27 13:24:43 1998 Delivery-Date: Fri, 27 Feb 1998 13:24:44 -0500 Return-Path: VRRP-owner@drcoffsite.com Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id NAA15746 for ; Fri, 27 Feb 1998 13:24:43 -0500 (EST) Received: from drcoffsite.com (gw.drcoffsite.com [209.150.7.1]) by cnri.reston.va.us (8.8.5/8.8.7a) with SMTP id NAA22346 for ; Fri, 27 Feb 1998 13:27:18 -0500 (EST) Received: from kahn.drc.com [198.22.14.98] by drcoffsite.com (SMTPD32-4.03) id A347F76E011C; Fri, 27 Feb 1998 13:17:43 EST Received: from ns.ietf.org [132.151.1.19] by kahn.drc.com with ESMTP (SMTPD32-4.03) id A4C994CB0152; Fri, 27 Feb 1998 11:07:37 EST Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id LAA11670; Fri, 27 Feb 1998 11:06:16 -0500 (EST) Message-Id: <199802271606.LAA11670@ns.ietf.org> To: IETF-Announce: ; Cc: vrrp@drcoffsite.com From: The IESG SUBJECT: Last Call: Virtual Router Redundancy Protocol to Proposed Standard Reply-to: iesg@ns.ietf.org Date: Fri, 27 Feb 1998 11:06:16 -0500 X-Sender: scoya@cnri.reston.va.us Precedence: bulk Sender: VRRP-owner@drcoffsite.com The IESG has received a request from the Virtual Router Redundancy Protocol Working Group to consider Virtual Router Redundancy Protocol as a Proposed Standard. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by March 13, 1998. Files can be obtained via ftp://ftp.ietf.org/internet-drafts/draft-ietf-vrrp-spec-05.txt From VRRP-owner@drcoffsite.com Fri Mar 6 14:58:21 1998 Delivery-Date: Fri, 06 Mar 1998 14:58:22 -0500 Return-Path: VRRP-owner@drcoffsite.com Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id OAA21067 for ; Fri, 6 Mar 1998 14:58:21 -0500 (EST) Received: from drcoffsite.com (gw.drcoffsite.com [209.150.7.1]) by cnri.reston.va.us (8.8.5/8.8.7a) with SMTP id PAA22964 for ; Fri, 6 Mar 1998 15:00:53 -0500 (EST) Received: from ns.ietf.org [132.151.1.19] by drcoffsite.com with ESMTP (SMTPD32-4.03) id A281BC8E0360; Fri, 06 Mar 1998 14:46:09 EST Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id OAA20372; Fri, 6 Mar 1998 14:44:23 -0500 (EST) Message-Id: <199803061944.OAA20372@ns.ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: vrrp@drcoffsite.com From: Internet-Drafts@ns.ietf.org Reply-to: Internet-Drafts@ns.ietf.org Subject: I-D ACTION:draft-ietf-vrrp-mib-01.txt Date: Fri, 06 Mar 1998 14:44:23 -0500 X-Sender: cclark@cnri.reston.va.us Precedence: bulk Sender: VRRP-owner@drcoffsite.com --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Virtual Router Redundancy Protocol Working Group of the IETF. Title : Definitions of Managed Objects for the Virtual Router Redundancy Protocol using SNMPv2 Author(s) : B. Jewell, D. Chuang Filename : draft-ietf-vrrp-mib-01.txt Pages : 29 Date : 05-Mar-98 This specification defines an extension to the Management Information Base (MIB) for use with SNMP-based network management. In particular, it defines objects for configuring, monitoring, and controlling routers that employ the Virtual Router Redundancy Protocol (VRRP) [1]. This memo specifies a MIB module in a manner that is compliant with both the SNMPv2 SMI [6], and semantically identical to the SNMPv1 definitions [2]. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-vrrp-mib-01.txt". A URL for the Internet-Draft is: ftp://ftp.ietf.org/internet-drafts/draft-ietf-vrrp-mib-01.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-vrrp-mib-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <19980305140817.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-vrrp-mib-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-vrrp-mib-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19980305140817.I-D@ietf.org> --OtherAccess-- --NextPart-- From adm Fri Mar 6 19:49:07 1998 Delivery-Date: Fri, 06 Mar 1998 19:50:23 -0500 Return-Path: adm Received: (from adm@localhost) by ns.ietf.org (8.8.7/8.8.7a) id TAA09099 for ietf-123-outbound.10@ietf.org; Fri, 6 Mar 1998 19:45:03 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id OAA20372; Fri, 6 Mar 1998 14:44:23 -0500 (EST) Message-Id: <199803061944.OAA20372@ns.ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: vrrp@drcoffsite.com From: Internet-Drafts@ns.ietf.org Reply-to: Internet-Drafts@ns.ietf.org Subject: I-D ACTION:draft-ietf-vrrp-mib-01.txt Date: Fri, 06 Mar 1998 14:44:23 -0500 Sender: cclark@cnri.reston.va.us --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Virtual Router Redundancy Protocol Working Group of the IETF. Title : Definitions of Managed Objects for the Virtual Router Redundancy Protocol using SNMPv2 Author(s) : B. Jewell, D. Chuang Filename : draft-ietf-vrrp-mib-01.txt Pages : 29 Date : 05-Mar-98 This specification defines an extension to the Management Information Base (MIB) for use with SNMP-based network management. In particular, it defines objects for configuring, monitoring, and controlling routers that employ the Virtual Router Redundancy Protocol (VRRP) [1]. This memo specifies a MIB module in a manner that is compliant with both the SNMPv2 SMI [6], and semantically identical to the SNMPv1 definitions [2]. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-vrrp-mib-01.txt". A URL for the Internet-Draft is: ftp://ftp.ietf.org/internet-drafts/draft-ietf-vrrp-mib-01.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-vrrp-mib-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <19980305140817.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-vrrp-mib-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-vrrp-mib-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19980305140817.I-D@ietf.org> --OtherAccess-- --NextPart-- From VRRP-owner@drcoffsite.com Tue Mar 10 12:11:54 1998 Delivery-Date: Tue, 10 Mar 1998 12:11:55 -0500 Return-Path: VRRP-owner@drcoffsite.com Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id MAA27413 for ; Tue, 10 Mar 1998 12:11:41 -0500 (EST) Received: from drcoffsite.com (gw.drcoffsite.com [209.150.7.1]) by cnri.reston.va.us (8.8.5/8.8.7a) with SMTP id MAA08005 for ; Tue, 10 Mar 1998 12:14:11 -0500 (EST) Received: from mail13.digital.com [192.208.46.30] by drcoffsite.com with ESMTP (SMTPD32-4.03) id A0183027025A; Tue, 10 Mar 1998 11:53:44 EST Received: from muggsy.lkg.dec.com (muggsy.lkg.dec.com [16.20.32.219]) by mail13.digital.com (8.8.8/8.8.8/WV1.0c) with SMTP id LAA06350; Tue, 10 Mar 1998 11:51:42 -0500 (EST) Received: from cei1.lkg.dec.com by muggsy.lkg.dec.com (5.65/DEC-Ultrix/4.3) with SMTP id AA15670; Tue, 10 Mar 1998 11:51:40 -0500 Received: from cei1.lkg.dec.com by cei1.lkg.dec.com; (5.65v3.2/1.1.8.2/07Jan96-0140PM) id AA08183; Tue, 10 Mar 1998 11:51:36 -0500 X-Sender: cei@lkg.dec.com Message-Id: <35056F97.FF6@cei1.lkg.dec.com> Date: Tue, 10 Mar 1998 11:51:35 -0500 From: Carol Iturralde X-Mailer: Mozilla 3.0Gold (X11; I; OSF1 V3.2 alpha) Mime-Version: 1.0 To: bjewell@3com.com, david_chuang@3com.com Cc: cei@cei1.lkg.dec.com, vrrp@drcoffsite.com Subject: problems with the VRRP mib? Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Precedence: bulk Sender: VRRP-owner@drcoffsite.com Hi. I'm implemeting VRRP in our bridge-router codebase, and have seen some issues with the VRRP mib. I was hoping you could tell me whether these are really issues, or if I have simply misunderstood something. They are: 1 - vrrpOperControl ... DESCRIPTION "This object will enable/disable the virtual router function. Setting the value to 'enabled', will transition the state of the router from 'initialize to 'backup'; Setting the value to 'disabled', will tranisition the router from 'master' or 'backup' to 'initialize'." DEFVAL { enabled } I have two problems with the above: a) a VRRP router may transition from initialize directly to master or backup. Enabling a vrrp router will cause it to transition to EITHER backup or master. I think you have forgotten about one of these state transitions, no? b) When enabled, a VRRP router may not immediately transtion out of 'initialize' (for example, if the interface is not yet up, it may wait for the interface to come up first). I am concerned that a newtork manager, reading the above description, may expect the state transition to be immediate (it will not). Is it worth adding a word about this? 2 - vrrpStatsBecomeMaster OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of times that this virtual router's state has transitioned from BACKUP to MASTER." ::= { vrrpRouterStatsEntry 1 } The problem here is the same -- a VRRP router may become master by transition from BACKUP to MASTER, or from INITIALIZE to MASTER. Hence, I think the above should say "The total number of times that this virtual router's state has transitioned to MASTER.". No? From VRRP-owner@drcoffsite.com Thu Mar 12 22:19:03 1998 Delivery-Date: Thu, 12 Mar 1998 22:19:04 -0500 Return-Path: VRRP-owner@drcoffsite.com Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id WAA06335 for ; Thu, 12 Mar 1998 22:18:58 -0500 (EST) Received: from drcoffsite.com (gw.drcoffsite.com [209.150.7.1]) by cnri.reston.va.us (8.8.5/8.8.7a) with SMTP id WAA21666 for ; Thu, 12 Mar 1998 22:21:17 -0500 (EST) Received: from janus.3com.com [209.0.73.82] by drcoffsite.com with ESMTP (SMTPD32-4.03) id A25653D0248; Thu, 12 Mar 1998 22:04:54 EST Received: from new-york.3com.com (new-york.3com.com [129.213.157.12]) by janus.3com.com (8.8.8/8.8.8) with ESMTP id TAA10214; Thu, 12 Mar 1998 19:03:21 -0800 (PST) Received: from chicago.nsd.3com.com (chicago.nsd.3com.com [129.213.157.11]) by new-york.3com.com (8.8.8/8.8.8) with ESMTP id SAA22842; Thu, 12 Mar 1998 18:41:09 -0800 (PST) Received: from towada.nsd.3com.com (towada.nsd.3com.com [129.213.48.46]) by chicago.nsd.3com.com (8.8.8/8.8.8) with ESMTP id SAA06769; Thu, 12 Mar 1998 18:54:18 -0800 (PST) From: David Tsao-Pin Chuang Received: (from dtc@localhost) by towada.nsd.3com.com (8.8.2/8.8.5) id TAA01791; Thu, 12 Mar 1998 19:03:11 -0800 (PST) Message-Id: <199803130303.TAA01791@towada.nsd.3com.com> Subject: Re: problems with the VRRP mib? To: cei@lkg.dec.com (Carol Iturralde) Date: Thu, 12 Mar 1998 19:03:10 -0800 (PST) Cc: bjewell@3com.com, david_chuang@3com.com, cei@cei1.lkg.dec.com, vrrp@drcoffsite.com In-Reply-To: <35056F97.FF6@cei1.lkg.dec.com> from "Carol Iturralde" at Mar 10, 98 11:51:35 am X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Precedence: bulk Sender: VRRP-owner@drcoffsite.com Carol, In version 2, a VRRP router can transit from initialize state directly to MASTER. The related two MIBs' description need to be corrected. When a VRRP router is enabled, the state may not become BACKUP or MASTER. It may stay in initialize and waiting for interface/IP to come up. So, you are also correct on this. Thanks for the information. David > > Hi. I'm implemeting VRRP in our bridge-router codebase, and > have seen some issues with the VRRP mib. I was hoping you > could tell me whether these are really issues, or if I have > simply misunderstood something. They are: > > 1 - vrrpOperControl ... > DESCRIPTION > "This object will enable/disable the virtual router > function. Setting the value to 'enabled', will transition > the state of the router from 'initialize to 'backup'; > Setting the value to 'disabled', will tranisition the > router from 'master' or 'backup' to 'initialize'." > DEFVAL { enabled } > > I have two problems with the above: > > a) a VRRP router may transition from initialize directly > to master or backup. Enabling a vrrp router will cause > it to transition to EITHER backup or master. I think > you have forgotten about one of these state transitions, > no? > > b) When enabled, a VRRP router may not immediately transtion > out of 'initialize' (for example, if the interface is > not yet up, it may wait for the interface to come up first). > I am concerned that a newtork manager, reading the above > description, may expect the state transition to be immediate > (it will not). Is it worth adding a word about this? > > 2 - vrrpStatsBecomeMaster OBJECT-TYPE > SYNTAX Counter32 > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "The total number of times that this virtual router's state > has transitioned from BACKUP to MASTER." > ::= { vrrpRouterStatsEntry 1 } > > > The problem here is the same -- a VRRP router may become > master by transition from BACKUP to MASTER, or from > INITIALIZE to MASTER. Hence, I think the above should say > "The total number of times that this virtual router's state > has transitioned to MASTER.". No? > From VRRP-owner@drcoffsite.com Fri Mar 13 01:02:11 1998 Delivery-Date: Fri, 13 Mar 1998 01:02:12 -0500 Return-Path: VRRP-owner@drcoffsite.com Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id BAA15255 for ; Fri, 13 Mar 1998 01:02:10 -0500 (EST) Received: from drcoffsite.com (gw.drcoffsite.com [209.150.7.1]) by cnri.reston.va.us (8.8.5/8.8.7a) with SMTP id BAA22000 for ; Fri, 13 Mar 1998 01:04:41 -0500 (EST) Received: from mailhost.Ipsilon.COM [205.226.5.12] by drcoffsite.com (SMTPD32-4.03) id A92EBD94021C; Fri, 13 Mar 1998 00:50:38 EST Received: from spruce.ipsilon.com ([205.226.22.78]) by mailhost.Ipsilon.COM (8.6.11/8.6.10) with SMTP id VAA06169; Thu, 12 Mar 1998 21:49:06 -0800 Message-Id: <3.0.3.32.19980312214802.009b8100@mailhost.ipsilon.com> X-Sender: hinden@mailhost.ipsilon.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Thu, 12 Mar 1998 21:48:02 -0800 To: vrrp@drcoffsite.com From: Bob Hinden Subject: Request for Agenda Items Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Precedence: bulk Sender: VRRP-owner@drcoffsite.com The VRRP working group will meet for one sessions at the Los Angeles IETF. The session is: Wednesday, April 1 at 1300-1500 (opposite ipp, schema, dhc, mboned, pint) Please send me proposed agenda items including topic description and length of time required. Thanks, Bob Hinden VRRP chair From VRRP-owner@drcoffsite.com Tue Mar 17 10:38:11 1998 Delivery-Date: Tue, 17 Mar 1998 10:38:12 -0500 Return-Path: VRRP-owner@drcoffsite.com Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id KAA03358 for ; Tue, 17 Mar 1998 10:38:11 -0500 (EST) Received: from drcoffsite.com (gw.drcoffsite.com [209.150.7.1]) by cnri.reston.va.us (8.8.5/8.8.7a) with SMTP id KAA08730 for ; Tue, 17 Mar 1998 10:40:42 -0500 (EST) Received: from ns.ietf.org [132.151.1.19] by drcoffsite.com with ESMTP (SMTPD32-4.03) id A41DE460240; Tue, 17 Mar 1998 10:17:49 EST Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id KAA02584; Tue, 17 Mar 1998 10:16:17 -0500 (EST) Message-Id: <199803171516.KAA02584@ns.ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: vrrp@drcoffsite.com From: Internet-Drafts@ns.ietf.org Reply-to: Internet-Drafts@ns.ietf.org Subject: I-D ACTION:draft-ietf-vrrp-spec-06.txt Date: Tue, 17 Mar 1998 10:16:16 -0500 X-Sender: cclark@cnri.reston.va.us Precedence: bulk Sender: VRRP-owner@drcoffsite.com --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Virtual Router Redundancy Protocol Working Group of the IETF. Title : Virtual Router Redundancy Protocol Author(s) : P. Higginson, B. Hinden, S. Knight, A. Lindem, D. Mitzel, M. Shand, D. Whipple, D. Weaver, P. Hunt Filename : draft-ietf-vrrp-spec-06.txt Pages : 30 Date : 16-Mar-98 This memo defines the Virtual Router Redundancy Protocol (VRRP). VRRP specifies an election protocol that dynamically assigns responsibility for a virtual router to one of the VRRP routers on a LAN. The VRRP router controlling the IP address(es) associated with a virtual router is called the Master, and forwards packets sent to these IP addresses. The election process provides dynamic fail over in the forwarding responsibility should the Master become unavailable. This allows any of the virtual router IP addresses on the LAN to be used as the default first hop router by end-hosts. The advantage gained from using VRRP is a higher availability default path without requiring configuration of dynamic routing or router discovery protocols on every end-host. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-vrrp-spec-06.txt". A URL for the Internet-Draft is: ftp://ftp.ietf.org/internet-drafts/draft-ietf-vrrp-spec-06.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-vrrp-spec-06.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <19980316160026.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-vrrp-spec-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-vrrp-spec-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19980316160026.I-D@ietf.org> --OtherAccess-- --NextPart-- From adm Tue Mar 17 13:56:37 1998 Delivery-Date: Tue, 17 Mar 1998 14:01:55 -0500 Return-Path: adm Received: (from adm@localhost) by ns.ietf.org (8.8.7/8.8.7a) id NAA13396 for ietf-123-outbound.10@ietf.org; Tue, 17 Mar 1998 13:55:02 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id KAA02584; Tue, 17 Mar 1998 10:16:17 -0500 (EST) Message-Id: <199803171516.KAA02584@ns.ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: vrrp@drcoffsite.com From: Internet-Drafts@ns.ietf.org Reply-to: Internet-Drafts@ns.ietf.org Subject: I-D ACTION:draft-ietf-vrrp-spec-06.txt Date: Tue, 17 Mar 1998 10:16:16 -0500 Sender: cclark@cnri.reston.va.us --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Virtual Router Redundancy Protocol Working Group of the IETF. Title : Virtual Router Redundancy Protocol Author(s) : P. Higginson, B. Hinden, S. Knight, A. Lindem, D. Mitzel, M. Shand, D. Whipple, D. Weaver, P. Hunt Filename : draft-ietf-vrrp-spec-06.txt Pages : 30 Date : 16-Mar-98 This memo defines the Virtual Router Redundancy Protocol (VRRP). VRRP specifies an election protocol that dynamically assigns responsibility for a virtual router to one of the VRRP routers on a LAN. The VRRP router controlling the IP address(es) associated with a virtual router is called the Master, and forwards packets sent to these IP addresses. The election process provides dynamic fail over in the forwarding responsibility should the Master become unavailable. This allows any of the virtual router IP addresses on the LAN to be used as the default first hop router by end-hosts. The advantage gained from using VRRP is a higher availability default path without requiring configuration of dynamic routing or router discovery protocols on every end-host. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-vrrp-spec-06.txt". A URL for the Internet-Draft is: ftp://ftp.ietf.org/internet-drafts/draft-ietf-vrrp-spec-06.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-vrrp-spec-06.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <19980316160026.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-vrrp-spec-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-vrrp-spec-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19980316160026.I-D@ietf.org> --OtherAccess-- --NextPart-- From VRRP-owner@drcoffsite.com Wed Mar 18 07:07:01 1998 Delivery-Date: Wed, 18 Mar 1998 07:07:02 -0500 Return-Path: VRRP-owner@drcoffsite.com Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id HAA22588 for ; Wed, 18 Mar 1998 07:07:00 -0500 (EST) Received: from drcoffsite.com (gw.drcoffsite.com [209.150.7.1]) by cnri.reston.va.us (8.8.5/8.8.7a) with SMTP id HAA12736 for ; Wed, 18 Mar 1998 07:09:30 -0500 (EST) Received: from ns.ietf.org [132.151.1.19] by drcoffsite.com with ESMTP (SMTPD32-4.03) id A7543E6021A; Wed, 18 Mar 1998 07:00:20 EST Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id GAA22370; Wed, 18 Mar 1998 06:58:48 -0500 (EST) Message-Id: <199803181158.GAA22370@ns.ietf.org> To: IETF-Announce: ; Cc: RFC Editor Cc: Internet Architecture Board Cc: vrrp@drcoffsite.com From: The IESG Subject: Protocol Action: Virtual Router Redundancy Protocol to Proposed Standard Date: Wed, 18 Mar 1998 06:58:47 -0500 X-Sender: scoya@cnri.reston.va.us Precedence: bulk Sender: VRRP-owner@drcoffsite.com The IESG has approved the Internet-Draft 'Virtual Router Redundancy Protocol' as a Proposed Standard. This document is the product of the Virtual Router Redundancy Protocol Working Group. The IESG contact persons is Joel Halpern. Technical Summary This protocol provides a mechanism for hosts to find and use a default router without any of Router Discovery, DHCP, or per site configuration. This default router mechanism allows for redundancy and load sharing. It also works properly with ICMP redirects for those sites where that technique is useful. Working Group Summary The working group strongly supported advancement of this protocol. The only significant dissent was support for certain existing deployed protocols. While this dissent was clear and present, the rough consensus of the working group was in favor of VRRP. Protocol Quality The protocol has been reivewed for the IESG by Joel M. Halpern, the Routing Area Director. It is a sound, practical solution to the problem. From adm Wed Mar 18 07:07:00 1998 Delivery-Date: Wed, 18 Mar 1998 07:13:03 -0500 Return-Path: adm Received: (from adm@localhost) by ns.ietf.org (8.8.7/8.8.7a) id HAA22502 for ietf-123-outbound.10@ietf.org; Wed, 18 Mar 1998 07:05:03 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id GAA22370; Wed, 18 Mar 1998 06:58:48 -0500 (EST) Message-Id: <199803181158.GAA22370@ns.ietf.org> To: IETF-Announce: ; Cc: RFC Editor Cc: Internet Architecture Board Cc: vrrp@drcoffsite.com From: The IESG Subject: Protocol Action: Virtual Router Redundancy Protocol to Proposed Standard Date: Wed, 18 Mar 1998 06:58:47 -0500 Sender: scoya@cnri.reston.va.us The IESG has approved the Internet-Draft 'Virtual Router Redundancy Protocol' as a Proposed Standard. This document is the product of the Virtual Router Redundancy Protocol Working Group. The IESG contact persons is Joel Halpern. Technical Summary This protocol provides a mechanism for hosts to find and use a default router without any of Router Discovery, DHCP, or per site configuration. This default router mechanism allows for redundancy and load sharing. It also works properly with ICMP redirects for those sites where that technique is useful. Working Group Summary The working group strongly supported advancement of this protocol. The only significant dissent was support for certain existing deployed protocols. While this dissent was clear and present, the rough consensus of the working group was in favor of VRRP. Protocol Quality The protocol has been reivewed for the IESG by Joel M. Halpern, the Routing Area Director. It is a sound, practical solution to the problem. From VRRP-owner@drcoffsite.com Wed Mar 25 20:18:30 1998 Delivery-Date: Wed, 25 Mar 1998 20:18:30 -0500 Return-Path: VRRP-owner@drcoffsite.com Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id UAA13974 for ; Wed, 25 Mar 1998 20:18:29 -0500 (EST) Received: from drcoffsite.com (gw.drcoffsite.com [209.150.7.1]) by cnri.reston.va.us (8.8.5/8.8.7a) with SMTP id UAA13820 for ; Wed, 25 Mar 1998 20:20:54 -0500 (EST) Received: from fwns2.raleigh.ibm.com [204.146.167.236] by drcoffsite.com with ESMTP (SMTPD32-4.03) id A8EB881C017A; Wed, 25 Mar 1998 20:01:31 +03d00 Received: from rtpmail02.raleigh.ibm.com (rtpmail02.raleigh.ibm.com [9.37.172.48]) by fwns2.raleigh.ibm.com (AIX4.2/UCB 8.7/8.7RTP-FW1.1) with ESMTP id TAA52122 for ; Wed, 25 Mar 1998 19:59:23 -0500 (EST) Received: from aceman.raleigh.ibm.com (aceman.raleigh.ibm.com [9.37.177.119]) by rtpmail02.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id TAA40594 for ; Wed, 25 Mar 1998 19:59:27 -0500 Received: from loopback by aceman.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA16478; Wed, 25 Mar 1998 19:59:57 -0500 X-Sender: acee@raleigh.ibm.com Message-Id: <3519A88C.87B46DA1@raleigh.ibm.com> Date: Wed, 25 Mar 1998 19:59:56 -0500 From: Acee Lindem Organization: IBM Networking Divison X-Mailer: Mozilla 4.04 [en] (X11; I; AIX 4.1) Mime-Version: 1.0 To: IETF VRRP List Subject: Cisco's Intellectual Property Claims from http://www.ietf.org/ipr.html Content-Type: multipart/mixed; boundary="------------7185B92370288D6D636DC0F6" Precedence: bulk Sender: VRRP-owner@drcoffsite.com This is a multi-part message in MIME format. --------------7185B92370288D6D636DC0F6 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit I don't think anyone posted this to the list. -- Acee --------------7185B92370288D6D636DC0F6 Content-Type: text/plain; charset=us-ascii; name="VRRP-CISCO" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="VRRP-CISCO" Late in 1997, Cisco wrote: >>With reference to the recently published Internet draft: Title : Virtual Router Redundancy Protocol Author(s) : S. Knight, D. Weaver, D. Whipple Filename : draft-whipple-vrrp-00.txt Pages : 14 Date : 11/26/1996 >>This message is to inform you that Cisco believes that this >>proposed protocol may infringe Cisco's patent #5,473,599, >>Standby Router Protocol. The original document has gone through a number of revisions and name changes. When submitted by the vrrp WG for publication, a query was sent to Cisco. The following message was received on March 11: We have done the evaluation and our response is the following: Cisco believes that implementation of draft-ietf-vrrp-spec-05.txt will require a license to Cisco's patent #5,473,599. If this protocol is approved as an IETF standard, licenses will be available to any party on reasonable, nondiscriminatory terms for implentation of the protocol. On March 20, 1998, the definitive statement from Cisco Systems was received: From: Martin McNealis The following statement is in response to recent requests for a clarification on Cisco Systems' position regarding both its Hot Standby Router Protocol (HSRP) and the Virtual Router Redundancy Protocol (VRRP) proposal:- In Cisco's assessment, the VRRP proposal does not represent any significantly different functionality from that available with HSRP and also implementation of 'draft-ietf-vrrp-spec-06.txt' would likely infringe on Cisco's patent #5,473,599. When Cisco originally learned of the VRRP proposal, the Hot Standby Router Protocol was then promptly offered for standardization with the understanding that, if approved, licenses for HSRP would be made available on reasonable, nondiscriminatory terms for implementation of the protocol. This offer stands for the adoption and implementation of HSRP. However, now that the 'draft-li-hsrp-01.txt' submission is approaching expiration and the Working Group is continuing with the VRRP proposal, Cisco Systems reserves the right to protect its intellectual property. Furthermore, Cisco takes the position that standardizing on another proposal that so closely mirrors an existing, well established, extensively deployed protocol is out of step with the principles and practices embodied in the IETF and would thus represent cause for concern within the industry. Martin McNealis IP Product Line Manager --------------7185B92370288D6D636DC0F6-- From VRRP-owner@drcoffsite.com Thu Apr 2 20:39:23 1998 Delivery-Date: Thu, 02 Apr 1998 20:39:23 -0500 Return-Path: VRRP-owner@drcoffsite.com Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.5/8.8.7a) with ESMTP id UAA15461 for ; Thu, 2 Apr 1998 20:39:22 -0500 (EST) Received: from drcoffsite.com (gw.drcoffsite.com [209.150.7.1]) by cnri.reston.va.us (8.8.5/8.8.7a) with SMTP id UAA00177 for ; Thu, 2 Apr 1998 20:41:43 -0500 (EST) Received: from mail11.digital.com [192.208.46.10] by drcoffsite.com with ESMTP (SMTPD32-4.03) id A97B26930212; Thu, 02 Apr 1998 20:20:59 +03d00 Received: from ucxaxp.ucx.lkg.dec.com (ucxaxp.ucx.lkg.dec.com [16.20.208.53]) by mail11.digital.com (8.8.8/8.8.8/WV1.0c) with SMTP id UAA08622 for ; Thu, 2 Apr 1998 20:19:22 -0500 (EST) Received: by ucxaxp.ucx.lkg.dec.com (UCX V4.2-21A, OpenVMS V7.1 Alpha); Thu, 2 Apr 1998 20:19:21 -0500 From: "M. T. Hollinger" To: Subject: Comments on VRRP-spec-06 Draft Date: Thu, 2 Apr 1998 20:16:41 -0500 Message-ID: <01bd5e9e$28883220$LocalHost@BigBrain.ucx.lkg.dec.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.71.1712.3 X-MimeOle: Produced By Microsoft MimeOLE V4.71.1712.3 Precedence: bulk Sender: VRRP-owner@drcoffsite.com Prodded by the discussion at the WG session yesterday, I took another look at the VRRP spec. This document has come a long way since I last read it, but I believe there is still room for refinement. Various technical comments follow. >5.2.3 TTL > > The TTL MUST be set to 255. A VRRP router receiving a packet with > the TTL not equal to 255 MUST discard the packet. Although I've heard some of the arguments for the choice of 255, I am unconvinced. When all the routers on the LAN are behaving properly, they won't forward the packet regardless of IP TTL. So why not set the field to something more representative of expected behavior, such as 1? That would be a lot less scary for the poor guy trying to troubleshoot the network, looking at packet traces and knowing very little about VRRP. >5.3.4 Priority >... > VRRP routers backing up a virtual router MUST use priority values > between 1-254 (decimal). The default priority value for VRRP routers > backing up a virtual router is 100 (decimal). It might be nice to emphsize right up front that when there are multiple backup routers, their priorities should be widely distributed. For example, if you set the priority to100 on backup router B1 and 99 on B2, then both routers would try to take over about 3.61 seconds after the master sent its last advertisement. By setting B1's priority to 150 and B2's to 50, you would more likely avoid a brief period when B1 and B2 each consider themselves the master. B1 would send out an advertisement 3.41 seconds. B2 would have time to notice this before its timer expired, at 3.81 seconds, and not try to become the new master. Clearly, the authors of the draft already know this, but the readers of it may not. One added sentence would help, something like: For faster convergence after a transition, backup routers should be assigned priority values which are widely distributed. > 7.1 Receiving VRRP Packets Although I realize an implementation would not have to perform its checks in the same order specified in the draft, I would still like to see them specified in a reasonable order. Specifically, it would make sense to check for a valid VRID before bothering to compute the checksum or perform authentication. If there are other virtual routers on the LAN, there will be a lot of packets coming in with VRID's you don't care about. The faster you can discard those uninteresting packets, the better. > - MUST perform authentication specified by Auth Type I'd break this bullet item into two: - MUST verify that Auth Type contains the expected value - MUST perform authentication as expected for this VRID In other words, if I'm configured to expect an Authentication Header, but a packet comes in specifying an Auth Type of 0, it's a bogus advertisement and should be discarded. > - MUST verify that the Adver Interval in the packet is the same as > the locally configured for this virtual router > > If the above check fails, the receiver MUST discard the packet, > SHOULD log the event and MAY indicate via network management that a > misconfiguration was detected. I quite object to this one. Suppose some network administrator decides to change his advertisement interval from 1 second to 2. But maybe he misses one router, or maybe it was down for maintenance at the time of the change, or maybe he's trying to be clever by setting a different value on the backup router from what the master uses. In any case, a misconfiguration exists, but logging that fact really isn't enough. The way the draft reads now, the backup router will discard the master's advertisements due to the mismatch and start sending out advertisements of its own. These will confuse the bridges, with their spanning tree algorithm, and create instability on the LAN. If the backup is on the same LAN segment as the master, then it will start forwarding a second copy of each and every outbound packet sent to the VR. This will continue indefinitely, perhaps for days or weeks, until the network administrator notices the log and corrects the misconfiguration. A better way to handle this error would be for the backup routers to just stay in Backup state. Or maybe they could update their advertisement interval (if the one in the packet is in a reasonable range), log the event, and continue. I'm not sure what the right behavior is, but discarding the packet and allowing two masters at once isn't the answer. A similar argument could be made for other cases in which the authentication checks out but the rest of the packet is flawed. A backup router should just back off, log the problem, and let the differently-configured master continue its work. >7.2 Transmitting VRRP Packets >... > - Set the source MAC address to Virtual Router MAC Address I really think this, and other uses of the VR MAC address, should be an optional part of the protocol. With most existing host implementations out there, sending unsolicited ARP messages to update the MAC address after router failover will work just fine. Particularly with unusual LAN topologies (including FDDI and Token Ring), use of the VR MAC address is problematic. If it creates problems and is unnecessary, why make the use of that MAC address a required part of VRRP? >8.1 ICMP Redirects > The IP source address of an ICMP redirect should be the address the > end host used when making its next hop routing decision. That's easier said than done, and may not always be possible. If a particular virtual router serves multiple addresses, and two or more of the addresses are in the same subnet, then there is no way to tell which one the host used. Of course, this problem is not unique to VRRP routers; any router would have the same limitation. > When a VRRP router restarts or boots, it SHOULD not send any ARP > messages with its physical MAC address for the IP address it owns, it > should only send ARP messages that include Virtual MAC addresses. > This may entail: > > - When configuring an interface, VRRP routers should broadcast a > gratuitous ARP request containing the virtual router MAC address > for each IP address on that interface. I wouldn't send any ARP requests at boot or interface configuration time. If we're to become the Master, the ARP messages will be sent upon VRRP startup anyway -- no need to send them twice. And if we're the backup, with the master already up and running elsewhere on the LAN, then sending ARP messages using the VR MAC address will just confuse the bridges into thinking that station is now on our local segment (when in fact it hasn't moved). >8.3 Proxy ARP > > If Proxy ARP is to be used on a VRRP router, then the VRRP router > must advertise the Virtual Router MAC address in the Proxy ARP > message. Doing otherwise could cause hosts to learn the real MAC > address of the VRRP router. Well, that would depend on the reason for doing proxy ARP. If the router is doing proxy ARP for the entire Internet, as a way to avoid configuring a particular default gateway on the hosts, then sure, use the VR MAC address. But if the router is doing proxy ARP for some host to which it alone is able to reach (by serial line, radio link, infrared, ...), as a way to avoid allocating a subnet, then the router should use its own MAC address in the proxy ARP response. Mark "MyTH" From VRRP-owner@drcoffsite.com Fri Apr 3 02:55:49 1998 Delivery-Date: Fri, 03 Apr 1998 02:55:49 -0500 Return-Path: VRRP-owner@drcoffsite.com Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.5/8.8.7a) with ESMTP id CAA27112 for ; Fri, 3 Apr 1998 02:55:48 -0500 (EST) Received: from drcoffsite.com (gw.drcoffsite.com [209.150.7.1]) by cnri.reston.va.us (8.8.5/8.8.7a) with SMTP id CAA12656 for ; Fri, 3 Apr 1998 02:58:18 -0500 (EST) Received: from mail12.digital.com [192.208.46.20] by drcoffsite.com with ESMTP (SMTPD32-4.03) id A02895C3009A; Fri, 03 Apr 1998 02:30:48 +03d00 Received: from reohub2.reo.dec.com (reohub2.reo.dec.com [16.37.21.19]) by mail12.digital.com (8.8.8/8.8.8/WV1.0c) with ESMTP id CAA13356 for ; Fri, 3 Apr 1998 02:29:07 -0500 (EST) Received: by reohub2.reo.dec.com with Internet Mail Service (5.0.1458.49) id <2FAK85V2>; Fri, 3 Apr 1998 08:30:24 +0100 Message-ID: <250F9C8DEB9ED011A14D08002BE4F64C0100C657@WADE> From: Mike Shand To: "'vrrp@drcoffsite.com'" Cc: "'myth@ucx.lkg.dec.com'" Subject: RE: Comments on VRRP-spec-06 Draft Date: Fri, 3 Apr 1998 08:26:34 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1458.49) Content-Type: text/plain Precedence: bulk Sender: VRRP-owner@drcoffsite.com Just a quick comment on this one >>8.1 ICMP Redirects >> The IP source address of an ICMP redirect should be the address the >> end host used when making its next hop routing decision. >That's easier said than done, True! >and may not always be possible. If a Not true >particular virtual router serves multiple addresses, and two or more of >the addresses are in the same subnet, then there is no way to tell which >one the host used. Of course, this problem is not unique to VRRP routers; >any router would have the same limitation. The case you describe, although it would result in it being impossible to determine the correct address, would be very unusual.. There are two fields you can use to determine the correct return address. 1. The source IP address of the original packet 2. The destination MAC address of the original packet. The former is what a normal router would use. So if it has multiple subnets on an interface, it would choose a return IP address on its interface which is in the same subnet as the source IP address. In the case of a Virtual router, the choice of subnet is made by the same mechanism, but the choice of address within that subnet is made by considering the destination MAC address. The combination of the two mechanisms will always give the correct result except in the unusual case of a single (virtual) router having multiple IP addresses on the interface within the SAME subnet. Mike I'll look at the rest in more detail later. From VRRP-owner@drcoffsite.com Fri Apr 3 10:14:50 1998 Delivery-Date: Fri, 03 Apr 1998 10:14:50 -0500 Return-Path: VRRP-owner@drcoffsite.com Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.5/8.8.7a) with ESMTP id KAA00543 for ; Fri, 3 Apr 1998 10:14:47 -0500 (EST) Received: from drcoffsite.com (gw.drcoffsite.com [209.150.7.1]) by cnri.reston.va.us (8.8.5/8.8.7a) with SMTP id KAA20078 for ; Fri, 3 Apr 1998 10:17:17 -0500 (EST) Received: from mail13.digital.com [192.208.46.30] by drcoffsite.com with ESMTP (SMTPD32-4.03) id A7309F1E005C; Fri, 03 Apr 1998 09:50:24 +03d00 Received: from muggsy.lkg.dec.com (muggsy.lkg.dec.com [16.20.32.219]) by mail13.digital.com (8.8.8/8.8.8/WV1.0c) with SMTP id JAA05247 for ; Fri, 3 Apr 1998 09:48:43 -0500 (EST) Received: from cei1.lkg.dec.com by muggsy.lkg.dec.com (5.65/DEC-Ultrix/4.3) with SMTP id AA11036; Fri, 3 Apr 1998 09:48:42 -0500 Received: from cei1.lkg.dec.com by cei1.lkg.dec.com; (5.65v3.2/1.1.8.2/07Jan96-0140PM) id AA10084; Fri, 3 Apr 1998 09:49:58 -0500 X-Sender: cei@lkg.dec.com Message-Id: <3524F715.3F54@cei1.lkg.dec.com> Date: Fri, 03 Apr 1998 09:49:57 -0500 From: Carol Iturralde X-Mailer: Mozilla 3.0Gold (X11; I; OSF1 V3.2 alpha) Mime-Version: 1.0 To: vrrp@drcoffsite.com Cc: cei@cei1.lkg.dec.com, Tony Hart Subject: comments on VRRP-spec-06 Draft Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Precedence: bulk Sender: VRRP-owner@drcoffsite.com I agree with many of the points made by Mark Hollinger. I'd like to add my own reasons for supporting his suggestions, and also suggest a few additional changes: - Priorities of backup routers should be 'spread out' -------------------------------------------------- (e.g., not 50, 51, 52). In my case, the granularity of the timers in some of our routers is 60 times per second (and not the 256 times per second required for skew times like these to really work). For this reason, backup routers whose priorities differ by small values (1,2,3.) will behave as if the priorities were equal. I expect that I am not alone, and that there will be many routers whose timer granularity is less than 256/sec. For this reason, I recommend adding a sentence to the spec. suggesting that 'spreading out' the backup priorities may be helpful for boxes whose timers have this characteristic. I plan to include such a recommendation (with specific values) in our user documentation. - Using same VRID on different interfaces --------------------------------------- The spec. says that a virtual router is uniquely identified by (VRID, Interface). This allows customers to re-use the SAME ID on a DIFFERENT INTERFACE. It should be noted that doing this could produce a DUPLICATE MAC on your network, which could confuse VLAN-capable bridges. Let me explain. Some bridges implement VLANs in such a way that a single physical bridge acts as if it were, for example, two logical bridges (say odd ports are one bridge, and even ports another). Many vendors have made this work EXCEPT for the case where the SAME MAC address is seen on both VLANs (seen on an odd port, and then see on an even port). Rather than learning the MAC address twice (once on the odd port, again on the even port), some bridges trash -- they learn it on the odd port, then move it to the even port, then back again, as they see packets with source addresses == this MAC. This can be a very big problem. Up to now, I have only seen it happen when: - DECnet routers are connected to each VLAN (because DECnet routers use the same MAC address each interface), - ATM ELANs are connected to each VLAN (because some switches use the same MAC address on all ELANs) - multi-homed Sun workstations sometimes use the same MAC address on interfaces Notice that we have added VRRP-routers to the above list, as a source of DUPLICATE MACs which may cause great trouble with your VLAN bridges. I strongly suggest that we make a note of this in the spec. It can be easily avoided by simply using unique VRIDs on all LANs interconnected by VLAN-capable routers which suffer from this duplicate MAC problem. - Need for a Subnet Mask ---------------------- Configuring backup routers with the Virtual IP Addresses may not be good enough -- we may want to include a subnet mask. The reason is as follows: Assume that a backup router has become Master. Assume that this router receives a packet to the Virtual MAC, for which it must send an ICMP redirect to the originating host. The router needs to select a source IP address for the ICMP packet. If the router has several Virtual IP Addresses, it would typically choose the one which is in the same subnet as the sending host. It cannot do this if (1) it does not have the subnet mask, and (2)one of the IP addresses is a subnet of the other (unlikely, I grant you). Rather than making this complicated, I suggest we add the subnet mask to the mib, and to the configurable parameters (coupled with the Virtual IP Addresses). Users are accustomed to entering IP addresses and associated subnet masks -- why not add it? - TTL should be 1, not 255 ------------------------ A value of 255 just plain looks wrong... and confusing. From VRRP-owner@drcoffsite.com Fri Apr 3 17:20:41 1998 Delivery-Date: Fri, 03 Apr 1998 17:20:41 -0500 Return-Path: VRRP-owner@drcoffsite.com Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.5/8.8.7a) with ESMTP id RAA04426 for ; Fri, 3 Apr 1998 17:20:40 -0500 (EST) Received: from drcoffsite.com (gw.drcoffsite.com [209.150.7.1]) by cnri.reston.va.us (8.8.5/8.8.7a) with SMTP id RAA21707 for ; Fri, 3 Apr 1998 17:23:09 -0500 (EST) Received: from relay4.UU.NET [192.48.96.14] by drcoffsite.com with ESMTP (SMTPD32-4.03) id AF5E35E60184; Fri, 03 Apr 1998 17:14:54 +03d00 Received: from xedia.com by relay4.UU.NET with SMTP (peer crosschecked as: madway.xedia.com [198.202.232.199]) id QQejoi25800; Fri, 3 Apr 1998 17:13:23 -0500 (EST) Received: from grenada. by xedia.com (4.1/SMI-4.1) id AA00645; Fri, 3 Apr 98 17:09:29 EST Received: from grenada (localhost) by grenada. (5.x/SMI-SVR4) id AA25179; Fri, 3 Apr 1998 17:11:51 -0500 X-Sender: sbarvick@grenada.xedia.com Message-Id: <35255EA6.7E6C@xedia.com> Date: Fri, 03 Apr 1998 17:11:50 -0500 From: Scott Barvick X-Mailer: Mozilla 3.01Gold (X11; I; SunOS 5.4 sun4m) Mime-Version: 1.0 To: vrrp@drcoffsite.com Subject: Re: Comments + authentication issue References: <01bd5e9e$28883220$LocalHost@BigBrain.ucx.lkg.dec.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Precedence: bulk Sender: VRRP-owner@drcoffsite.com I said I would post something on the authentication so I'll do it along with my comments on the following issues: M. T. Hollinger wrote: ... > > >5.2.3 TTL > > > > The TTL MUST be set to 255. A VRRP router receiving a packet with > > the TTL not equal to 255 MUST discard the packet. > > Although I've heard some of the arguments for the choice of 255, I am > unconvinced. When all the routers on the LAN are behaving properly, they > won't forward the packet regardless of IP TTL. So why not set the field > to something more representative of expected behavior, such as 1? That > would be a lot less scary for the poor guy trying to troubleshoot the > network, looking at packet traces and knowing very little about VRRP. Agree. > > >5.3.4 Priority > >... > > VRRP routers backing up a virtual router MUST use priority values > > between 1-254 (decimal). The default priority value for VRRP routers > > backing up a virtual router is 100 (decimal). > > It might be nice to emphsize right up front that when there are multiple > backup routers, their priorities should be widely distributed. For > example, if you set the priority to100 on backup router B1 and 99 on B2, > then both routers would try to take over about 3.61 seconds after the > master sent its last advertisement. By setting B1's priority to 150 and > B2's to 50, you would more likely avoid a brief period when B1 and B2 each > consider themselves the master. B1 would send out an advertisement 3.41 > seconds. B2 would have time to notice this before its timer expired, at > 3.81 seconds, and not try to become the new master. > > Clearly, the authors of the draft already know this, but the readers of it > may not. One added sentence would help, something like: For faster > convergence after a transition, backup routers should be assigned priority > values which are widely distributed. Agree with the need for at least a statement about distributing the values, but aren't we really saying that this part of the operation is overengineered? We need some algorithm to pick a timer value, but I expect that few implementers will be strict about the timer value if it doesn't fit with timer services already implemented. It is good to try to minimize changing masters by giving higher priority backups a bit of an edge in time, but if we don't expect people to really implement it that way, we may just want to define Skew_Time as something like (Sec 6.1.2): "Time to skew Master_Down_Timer in seconds. The specific calculation is an implementation-specific function of virtual router priority that produces a value between 0 and 1 second with the property that higher priorities result in Skew_Times less than or equal to those of lower priorities." Of course, this may result in different vendor implementations causing different resulting Skew_Times, but that is why we actually do the real priority processing on received advertisements. > > > 7.1 Receiving VRRP Packets > ... > > > > If the above check fails, the receiver MUST discard the packet, > > SHOULD log the event and MAY indicate via network management that a > > misconfiguration was detected. > ... > A better way to handle this error would be for the backup routers to just > stay in Backup state. Or maybe they could update their advertisement > interval (if the one in the packet is in a reasonable range), log the > event, and continue. I'm not sure what the right behavior is, but > discarding the packet and allowing two masters at once isn't the answer. > > A similar argument could be made for other cases in which the > authentication checks out but the rest of the packet is flawed. A backup > router should just back off, log the problem, and let the > differently-configured master continue its work. I agree strongly with this one. It is far too easy to end up with two masters. Authentication: I suggest removing the text in the draft (Sections 5.3.6 and 5.3.6.3) and MIB (vrrpOperHMACMD5Key) concerning MD5 authentication. Even though OSPF allows this, I find it unlikely that anyone would bother putting the keys in each VRRP router configuration. Additionally, Section 5.3.10 of the protocol draft effectively defers support for this capability. I think that very soon we will have IPSec transport SA security of all router to router communications (OSPF, VRRP, BGP, etc) and to put the capability in each protocol is not the right way to go. This leaves the simple text password as a useful, but hardly secure, sanity check. I don't have any problems leaving that in as is. -- Scott Barvick sbarvick@xedia.com (978) 952-6000 x162 From VRRP-owner@drcoffsite.com Sun Apr 5 21:08:30 1998 Delivery-Date: Sun, 05 Apr 1998 21:08:31 -0400 Return-Path: VRRP-owner@drcoffsite.com Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.5/8.8.7a) with ESMTP id VAA11229 for ; Sun, 5 Apr 1998 21:08:29 -0400 (EDT) Received: from drcoffsite.com (gw.drcoffsite.com [209.150.7.1]) by cnri.reston.va.us (8.8.5/8.8.7a) with SMTP id VAA00014 for ; Sun, 5 Apr 1998 21:10:57 -0400 (EDT) Received: from midnight.midnight.com [137.103.210.2] by drcoffsite.com (SMTPD32-4.03) id A8CD3850378; Sun, 05 Apr 1998 20:58:53 +03d00 Received: from rasarit.midnight.com by midnight.midnight.com (4.1/SMI-4.1) id AA05973; Sun, 5 Apr 98 20:54:10 EDT Received: (from cristina@localhost) by rasarit.midnight.com (8.8.5/8.8.5) id UAA18554; Sun, 5 Apr 1998 20:59:53 -0400 Date: Sun, 5 Apr 1998 20:59:53 -0400 Message-Id: <199804060059.UAA18554@rasarit.midnight.com> From: Cristina Radulescu-Banu To: vrrp@drcoffsite.com Subject: questions about the vrrp draft Reply-To: cristina@midnight.com (Cristina Radelescu-Banu 617/890-1001) Precedence: bulk Sender: VRRP-owner@drcoffsite.com I'm sorry I didn't ask these questions at the meeting, but I needed to catch my flight while the patent discussion was still going on: 1. The reason for the existence of this draft is to eliminate the overload of using routing (snooping) a dynamic routing protocol (like ICMP router discovery, OSPF) in end-hosts. However, VRRP *is* such a dynamic-discovery protocol, to which you add the statically configured route to get to the Virtual Router(s) which the end-host wants to use. Again, if it's only 1 Virtual Router the end-host knows about, you get back to the problem of having 1 default gateway in the statically configured route scenario. So I don't see (yet) the point of this protocol to be used, instead of ICMP router discovery, for example. 2. At page 12, Section "Priority" in the phrase "The priority field specifies the sending VRRP router's priority" I don't know what's the significance of the word "sending" is, since we speak only about senders here (I think you don't need this word here, it's redundant). 3. What is the primary IP addr of the iface? (src addr for the IP pkt) (is the primary interface chosen by the administrator?) 4. Is the Startup Event *always* associated with the router first coming up in the network? Or are there other instances which trigger the Starup Event (changes in its own Priority, etc)? -- ............................................................................... Cristina Radulescu-Banu : Midnight Networks 200 Fifth Avenue Waltham MA 02154 cristina@midnight.com : Vox 781/890-1001 Fax 0028 The Best in Network Software A conclusion is the place where you got tired of thinking. From VRRP-owner@drcoffsite.com Sun Apr 5 22:45:38 1998 Delivery-Date: Sun, 05 Apr 1998 22:45:38 -0400 Return-Path: VRRP-owner@drcoffsite.com Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.5/8.8.7a) with ESMTP id WAA12762 for ; Sun, 5 Apr 1998 22:45:38 -0400 (EDT) Received: from drcoffsite.com (gw.drcoffsite.com [209.150.7.1]) by cnri.reston.va.us (8.8.5/8.8.7a) with SMTP id WAA17406 for ; Sun, 5 Apr 1998 22:48:02 -0400 (EDT) Received: from fwns1.raleigh.ibm.com [204.146.167.235] by drcoffsite.com with ESMTP (SMTPD32-4.03) id AFE6291C0084; Sun, 05 Apr 1998 22:37:26 +03d00 Received: from rtpmail03.raleigh.ibm.com (rtpmail03.raleigh.ibm.com [9.37.172.47]) by fwns1.raleigh.ibm.com (AIX4.2/UCB 8.7/8.7RTP-FW1.1) with ESMTP id WAA31498; Sun, 5 Apr 1998 22:35:43 -0400 (EDT) Received: from aceman.raleigh.ibm.com (aceman.raleigh.ibm.com [9.37.177.119]) by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id WAA31320; Sun, 5 Apr 1998 22:35:44 -0400 Received: from localhost by aceman.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA14142; Sun, 5 Apr 1998 22:35:44 -0400 Date: Sun, 5 Apr 1998 22:35:43 -0400 (EDT) From: Acee Lindem To: Cristina Radulescu-Banu Cc: vrrp@drcoffsite.com Subject: Re: questions about the vrrp draft In-Reply-To: <199804060059.UAA18554@rasarit.midnight.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Precedence: bulk Sender: VRRP-owner@drcoffsite.com On Sun, 5 Apr 1998, Cristina Radulescu-Banu wrote: > > I'm sorry I didn't ask these questions at the meeting, but I > needed to catch my flight while the patent discussion was still going on: I wasn't able to attend but I think I can answer your questions. > > > 1. The reason for the existence of this draft is to eliminate the > overload of using routing (snooping) a dynamic routing protocol (like > ICMP router discovery, OSPF) in end-hosts. However, VRRP *is* such a > dynamic-discovery protocol, to which you add the statically configured > route to get to the Virtual Router(s) which the end-host wants to use. > Again, if it's only 1 Virtual Router the end-host knows about, you get > back to the problem of having 1 default gateway in the statically > configured route scenario. So I don't see (yet) the point of this > protocol to be used, instead of ICMP router discovery, for example. The whole point of the protocol is to provide a backup mechanism which is completely transparent to the hosts. With ICMP router discovery, the hosts must take an active role. > > > 2. At page 12, Section "Priority" in the phrase > "The priority field specifies the sending VRRP router's priority" > I don't know what's the significance of the word "sending" is, since > we speak only about senders here (I think you don't need this word > here, it's redundant). Ok - seems like a nit. > > 3. What is the primary IP addr of the iface? (src addr for the IP pkt) > (is the primary interface chosen by the administrator?) VRRP advertisements are multicast and can contain multiple addresses. Hence, a single instance of a Virtual Router can service mulitple IP subnets on the same physical network. The primary address is the only configured IP address or an implementation-dependent choice of one of the configured IP addresses (e.g,, the first configured). > > > 4. Is the Startup Event *always* associated with the router first > coming up in the network? Or are there other instances which > trigger the Starup Event (changes in its own Priority, etc)? Dynamic configuration of VRRP for the interface could start VRRP without a network-up event. Also, if you look at the MIB draft I believe there are write-capable variables which will effect VRRP's status. > > > -- > > > ............................................................................... > Cristina Radulescu-Banu : Midnight Networks 200 Fifth Avenue Waltham MA 02154 > cristina@midnight.com : Vox 781/890-1001 Fax 0028 The Best in Network Software > > A conclusion is the place where you got tired of thinking. > > > > > > From VRRP-owner@drcoffsite.com Tue Apr 7 09:32:55 1998 Delivery-Date: Tue, 07 Apr 1998 09:32:56 -0400 Return-Path: VRRP-owner@drcoffsite.com Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.5/8.8.7a) with ESMTP id JAA27393 for ; Tue, 7 Apr 1998 09:32:52 -0400 (EDT) Received: from drcoffsite.com (gw.drcoffsite.com [209.150.7.1]) by cnri.reston.va.us (8.8.5/8.8.7a) with SMTP id JAA03119 for ; Tue, 7 Apr 1998 09:35:18 -0400 (EDT) Received: from mail11.digital.com [192.208.46.10] by drcoffsite.com with ESMTP (SMTPD32-4.03) id A8B386AB0212; Tue, 07 Apr 1998 09:22:59 +03d00 Received: from muggsy.lkg.dec.com (muggsy.lkg.dec.com [16.20.32.219]) by mail11.digital.com (8.8.8/8.8.8/WV1.0d) with SMTP id JAA18728 for ; Tue, 7 Apr 1998 09:21:28 -0400 (EDT) Received: from cei1.lkg.dec.com by muggsy.lkg.dec.com (5.65/DEC-Ultrix/4.3) with SMTP id AA02362; Tue, 7 Apr 1998 09:21:26 -0400 Received: from cei1.lkg.dec.com by cei1.lkg.dec.com; (5.65v3.2/1.1.8.2/07Jan96-0140PM) id AA11966; Tue, 7 Apr 1998 09:22:55 -0400 X-Sender: cei@lkg.dec.com Message-Id: <352A28AE.7A79@cei1.lkg.dec.com> Date: Tue, 07 Apr 1998 09:22:54 -0400 From: Carol Iturralde X-Mailer: Mozilla 3.0Gold (X11; I; OSF1 V3.2 alpha) Mime-Version: 1.0 To: vrrp@drcoffsite.com Cc: Tony Hart , cei@cei1.lkg.dec.com Subject: 2 questions on the VRRP spec. Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Precedence: bulk Sender: VRRP-owner@drcoffsite.com I understand that Advertisements must be send using 00-00-5E-00-01-{VRID} as the source MAC address. My questions are: - when sending an ARP reply (when the request was for a IP address of a virtual router), must this reply be sent using 00-00-5E-00-01-{VRID} as the source MAC address? (I understand that this MAC address must be present in the ARP packet, but I am asking about the datalink header' source MAC address). I don't recall seeing this spelled out in the spec. - when a vrrp-router forwards a data packet which it received (with MAC DA == 00-00-5E-00-01-{VRID1}), and the outgoing interface it uses to forward the packet is also one on which it is acting as a virtual router, is it required to use 00-00-5E-00-01-{VRID2} as the source MAC address of the outbound packet? Again, I don't recall seeing this spelled out in the spec. The reason these questions are important is that it is fairly easy to implement the insertion of the special MAC address in ARP code, and also when sending Advertisements. The other two cases (above) are more complicated, and I don't want to do them if they are not required. Please advise. From VRRP-owner@drcoffsite.com Tue Apr 7 09:52:56 1998 Delivery-Date: Tue, 07 Apr 1998 09:52:59 -0400 Return-Path: VRRP-owner@drcoffsite.com Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.5/8.8.7a) with ESMTP id JAA27817 for ; Tue, 7 Apr 1998 09:52:54 -0400 (EDT) Received: from drcoffsite.com (gw.drcoffsite.com [209.150.7.1]) by cnri.reston.va.us (8.8.5/8.8.7a) with SMTP id JAA03204 for ; Tue, 7 Apr 1998 09:55:20 -0400 (EDT) Received: from mail13.digital.com [192.208.46.30] by drcoffsite.com with ESMTP (SMTPD32-4.03) id AE0393520212; Tue, 07 Apr 1998 09:45:39 +03d00 Received: from shand.reo.dec.com (shand.reo.dec.com [16.36.16.22]) by mail13.digital.com (8.8.8/8.8.8/WV1.0d) with SMTP id JAA20834 for ; Tue, 7 Apr 1998 09:44:01 -0400 (EDT) Received: from osicwg.reo.dec.com by shand.reo.dec.com (5.65/MS-010395) id AA06661; Tue, 7 Apr 1998 14:43:51 +0100 Received: by localhost with Microsoft MAPI; Tue, 7 Apr 1998 14:43:15 +0100 Message-Id: <250F9C8DEB9ED011A14D08002BE4F64C0100C669@wade.reo.dec.com> From: Mike Shand Reply-To: "shand@mail.dec.com" To: "'Carol Iturralde'" , "vrrp@drcoffsite.com" Cc: Tony Hart , "cei@cei1.lkg.dec.com" Subject: RE: 2 questions on the VRRP spec. Date: Tue, 7 Apr 1998 14:41:24 +0100 Organization: Digital Equipment Co X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4211 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Precedence: bulk Sender: VRRP-owner@drcoffsite.com On Tuesday, April 07, 1998 2:23 PM, Carol Iturralde [SMTP:cei@lkg.dec.com] wrote: > I understand that Advertisements must be send using > 00-00-5E-00-01-{VRID} as the source MAC address. > > My questions are: > > - when sending an ARP reply (when the request was for a > IP address of a virtual router), must this reply be sent > using 00-00-5E-00-01-{VRID} as the source MAC address? > (I understand that this MAC address must be present in > the ARP packet, but I am asking about the datalink header' > source MAC address). No. There's no requirement to do so. Of course it wouldn't hurt. There is a requirement to use the ****{VRID} MAC address in at least the VRRP messages themselves in order to cause learning bridges to correctly learn the location, especially when they move. Using this MAC address for other packets would only help speed up this process, but note that it could be disaterous to use the WRONG ****{VRID} MAC address > > I don't recall seeing this spelled out in the spec. > > - when a vrrp-router forwards a data packet which it received > (with MAC DA == 00-00-5E-00-01-{VRID1}), and the outgoing > interface it uses to forward the packet is also one on > which it is acting as a virtual router, is it required > to use 00-00-5E-00-01-{VRID2} as the source MAC address > of the outbound packet? No. > > Again, I don't recall seeing this spelled out in the spec. > > The reason these questions are important is that it is fairly > easy to implement the insertion of the special MAC address > in ARP code, and also when sending Advertisements. The other > two cases (above) are more complicated, and I don't want > to do them if they are not required. > > Please advise. From VRRP-owner@drcoffsite.com Thu Apr 9 11:37:22 1998 Delivery-Date: Thu, 09 Apr 1998 11:37:22 -0400 Return-Path: VRRP-owner@drcoffsite.com Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.5/8.8.7a) with ESMTP id LAA15712 for ; Thu, 9 Apr 1998 11:37:20 -0400 (EDT) Received: from drcoffsite.com (gw.drcoffsite.com [209.150.7.1]) by cnri.reston.va.us (8.8.5/8.8.7a) with SMTP id LAA12111 for ; Thu, 9 Apr 1998 11:39:47 -0400 (EDT) Received: from kahn.drc.com [198.22.14.98] by drcoffsite.com (SMTPD32-4.03) id AAA41CAD02D0; Thu, 09 Apr 1998 08:10:12 +03d00 Received: from wwwnni.us.newbridge.com [204.177.219.11] by kahn.drc.com with ESMTP (SMTPD32-4.03) id A99E14E0540; Thu, 09 Apr 1998 08:05:50 EST Received: from herndon-gw1.us.newbridge.com (herndon-gw1 [204.177.219.66]) by wwwnni.us.newbridge.com (8.8.5/8.6.12) with SMTP id IAA04831 for ; Thu, 9 Apr 1998 08:08:15 -0400 (EDT) Received: from hernmaster.us.newbridge.com ([138.120.108.6]) by herndon-gw1.us.newbridge.com via smtpd (for wwwnni.us.newbridge.com [204.177.219.11]) with SMTP; 9 Apr 1998 12:01:23 UT Received: (from smap@localhost) by us.newbridge.com. (8.8.6/8.8.6) id IAA15735 for ; Thu, 9 Apr 1998 08:01:10 -0400 (EDT) Received: from ubgateway.ub.com(128.203.51.47) by hernmaster.us.newbridge.com via smap (V1.3) id sma015709; Thu Apr 9 08:00:37 1998 Received: by notes.ub.com(Lotus SMTP MTA v1.1 (385.6 5-6-1997)) id 882565E1.00420814 ; Thu, 9 Apr 1998 05:01:14 -0700 X-Lotus-FromDomain: UB From: dpickett@newbridge.com To: vrrp-request@drcoffsite.com Message-ID: <852565E1.0041FE09.00@notes.ub.com> Date: Thu, 9 Apr 1998 08:01:32 -0400 Subject: Remove name Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Precedence: bulk Sender: VRRP-owner@drcoffsite.com My mail address has changed since starting my subscription. Please remove david_pickett@ub.com from the list. dp From VRRP-owner@drcoffsite.com Fri Apr 10 14:25:41 1998 Delivery-Date: Fri, 10 Apr 1998 14:25:42 -0400 Return-Path: VRRP-owner@drcoffsite.com Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.5/8.8.7a) with ESMTP id OAA20957 for ; Fri, 10 Apr 1998 14:25:37 -0400 (EDT) Received: from drcoffsite.com (gw.drcoffsite.com [209.150.7.1]) by cnri.reston.va.us (8.8.5/8.8.7a) with SMTP id OAA18553 for ; Fri, 10 Apr 1998 14:28:02 -0400 (EDT) Received: from mail11.digital.com [192.208.46.10] by drcoffsite.com with ESMTP (SMTPD32-4.04) id A2186A5D03D0; Fri, 10 Apr 1998 14:16:56 +03d00 Received: from muggsy.lkg.dec.com (muggsy.lkg.dec.com [16.20.32.219]) by mail11.digital.com (8.8.8/8.8.8/WV1.0d) with SMTP id OAA18567 for ; Fri, 10 Apr 1998 14:15:29 -0400 (EDT) Received: from cei1.lkg.dec.com by muggsy.lkg.dec.com (5.65/DEC-Ultrix/4.3) with SMTP id AA26007; Fri, 10 Apr 1998 14:15:27 -0400 Received: from cei1.lkg.dec.com by cei1.lkg.dec.com; (5.65v3.2/1.1.8.2/07Jan96-0140PM) id AA14927; Fri, 10 Apr 1998 14:17:32 -0400 X-Sender: cei@lkg.dec.com Message-Id: <352E623B.FF6@cei1.lkg.dec.com> Date: Fri, 10 Apr 1998 14:17:31 -0400 From: Carol Iturralde X-Mailer: Mozilla 3.0Gold (X11; I; OSF1 V3.2 alpha) Mime-Version: 1.0 To: vrrp@drcoffsite.com Cc: shand@shand.reo.dec.com, cei@cei1.lkg.dec.com, Tony Hart Subject: VRRP and DECnet Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Precedence: bulk Sender: VRRP-owner@drcoffsite.com Bringing DECnet up on an interface (e.g., Ethernet or FDDI) causes the MAC address to be modified. DECnet sets it to a desired value -- and it must use this value. It occurs to me that this means that VRRP and DECnet cannot be running on the same interface (unless the interface is smart enough to use one MAC address for DECnet packets, and a different one for IP packets, which most aren't). Should the VRRP spec. say something about how it may not be implementable to run DECnet and VRRP on the same interface? From VRRP-owner@drcoffsite.com Fri Apr 10 14:51:27 1998 Delivery-Date: Fri, 10 Apr 1998 14:51:28 -0400 Return-Path: VRRP-owner@drcoffsite.com Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.5/8.8.7a) with ESMTP id OAA21332 for ; Fri, 10 Apr 1998 14:51:26 -0400 (EDT) Received: from drcoffsite.com (gw.drcoffsite.com [209.150.7.1]) by cnri.reston.va.us (8.8.5/8.8.7a) with SMTP id OAA27275 for ; Fri, 10 Apr 1998 14:53:52 -0400 (EDT) Received: from mailhost.iprg.nokia.com [205.226.5.12] by drcoffsite.com (SMTPD32-4.04) id A6D9699A039E; Fri, 10 Apr 1998 14:37:13 +03d00 Received: from pfinger.iprg.nokia.com (pfinger.iprg.nokia.com [205.226.1.149]) by mailhost.iprg.nokia.com (8.6.11/8.6.10) with ESMTP id LAA06232; Fri, 10 Apr 1998 11:35:44 -0700 Received: from localhost.iprg.nokia.com (localhost.iprg.nokia.com [127.0.0.1]) by pfinger.iprg.nokia.com (8.6.12/8.6.12) with SMTP id LAA27144; Fri, 10 Apr 1998 11:35:43 -0700 Message-Id: <199804101835.LAA27144@pfinger.iprg.nokia.com> X-Authentication-Warning: pfinger.iprg.nokia.com: Host localhost.iprg.nokia.com didn't use HELO protocol X-Mailer: exmh version 2.0beta 12/23/96 To: Carol Iturralde cc: hunt@iprg.nokia.com, vrrp@drcoffsite.com Subject: Re: VRRP and DECnet In-reply-to: Your message of "Fri, 10 Apr 1998 14:17:31 EDT." <352E623B.FF6@cei1.lkg.dec.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 10 Apr 1998 11:35:42 -0700 From: Peter Hunt Precedence: bulk Sender: VRRP-owner@drcoffsite.com > Bringing DECnet up on an interface (e.g., Ethernet or FDDI) > causes the MAC address to be modified. DECnet sets it to > a desired value -- and it must use this value. Is this a problem with sending or receiving packets? That is, must DECnet packets be use the DECnet MAC as their source MAC? Or do you see this as a problem in receiving packets (ie. the ethernet device can't filter on both the DECnet MAC and the VRRP MAC at the same time)? Regards, Peter. From VRRP-owner@drcoffsite.com Fri Apr 10 14:52:01 1998 Delivery-Date: Fri, 10 Apr 1998 14:52:01 -0400 Return-Path: VRRP-owner@drcoffsite.com Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.5/8.8.7a) with ESMTP id OAA21348 for ; Fri, 10 Apr 1998 14:52:00 -0400 (EDT) Received: from drcoffsite.com (gw.drcoffsite.com [209.150.7.1]) by cnri.reston.va.us (8.8.5/8.8.7a) with SMTP id OAA27479 for ; Fri, 10 Apr 1998 14:54:26 -0400 (EDT) Received: from mailhost.iprg.nokia.com [205.226.5.12] by drcoffsite.com (SMTPD32-4.04) id A9D831A3023A; Fri, 10 Apr 1998 14:50:00 +03d00 Received: from spruce.iprg.nokia.com ([205.226.22.76]) by mailhost.iprg.nokia.com (8.6.11/8.6.10) with SMTP id LAA06549; Fri, 10 Apr 1998 11:47:15 -0700 Message-Id: <3.0.5.32.19980410114611.00acf100@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Fri, 10 Apr 1998 11:46:11 -0700 To: Carol Iturralde From: Bob Hinden Subject: Re: VRRP and DECnet Cc: vrrp@drcoffsite.com, shand@shand.reo.dec.com, cei@cei1.lkg.dec.com, Tony Hart In-Reply-To: <352E623B.FF6@cei1.lkg.dec.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Precedence: bulk Sender: VRRP-owner@drcoffsite.com Carol, >Should the VRRP spec. say something about how it may not >be implementable to run DECnet and VRRP on the same >interface? Probably not. Same issue come up with running Decnet and IP (independent of VRRP), IPX, CLNP, etc. on the same interface. It would too hard to have every IP related specification have to specify the complications of running it with every other non-IP protocol. Also, I would think that if one can run Decnet and IP on the same interface, then this shouldn't be too much of a problem. Bob From VRRP-owner@drcoffsite.com Fri Apr 10 15:49:05 1998 Delivery-Date: Fri, 10 Apr 1998 15:49:06 -0400 Return-Path: VRRP-owner@drcoffsite.com Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.5/8.8.7a) with ESMTP id PAA22437 for ; Fri, 10 Apr 1998 15:49:04 -0400 (EDT) Received: from drcoffsite.com (gw.drcoffsite.com [209.150.7.1]) by cnri.reston.va.us (8.8.5/8.8.7a) with SMTP id PAA16558 for ; Fri, 10 Apr 1998 15:51:32 -0400 (EDT) Received: from mpdr0.detroit.mi.ameritech.net [206.141.239.206] by drcoffsite.com with ESMTP (SMTPD32-4.04) id A57D5222023A; Fri, 10 Apr 1998 15:39:41 +03d00 Received: from ameritech.net ([206.141.226.115]) by mpdr0.detroit.mi.ameritech.net (InterMail v03.02.01 118 111) with ESMTP id <19980410203727.CGOL7034@ameritech.net>; Fri, 10 Apr 1998 15:37:27 -0500 Message-ID: <352E74C1.F49B3D47@ameritech.net> Date: Fri, 10 Apr 1998 15:36:33 -0400 From: Rob Montgomery Reply-To: robm@null.net X-Mailer: Mozilla 4.03 [en] (Win95; U) MIME-Version: 1.0 To: Bob Hinden CC: Carol Iturralde , vrrp@drcoffsite.com, shand@shand.reo.dec.com, cei@cei1.lkg.dec.com, Tony Hart Subject: Re: VRRP and DECnet References: <3.0.5.32.19980410114611.00acf100@mailhost.iprg.nokia.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Precedence: bulk Sender: VRRP-owner@drcoffsite.com Not to beat a dead horse, but shouldn't this be a warning about what happens when layer 3 protocols start messing around with the MAC address. (hint, hint, hint.) :-) -Rob Bob Hinden wrote: > > Carol, > > >Should the VRRP spec. say something about how it may not > >be implementable to run DECnet and VRRP on the same > >interface? > > Probably not. Same issue come up with running Decnet and IP (independent > of VRRP), IPX, CLNP, etc. on the same interface. It would too hard to have > every IP related specification have to specify the complications of running > it with every other non-IP protocol. > > Also, I would think that if one can run Decnet and IP on the same > interface, then this shouldn't be too much of a problem. > > Bob From VRRP-owner@drcoffsite.com Sat Apr 11 06:57:31 1998 Delivery-Date: Sat, 11 Apr 1998 06:57:32 -0400 Return-Path: VRRP-owner@drcoffsite.com Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.5/8.8.7a) with ESMTP id GAA11892 for ; Sat, 11 Apr 1998 06:57:31 -0400 (EDT) Received: from drcoffsite.com (gw.drcoffsite.com [209.150.7.1]) by cnri.reston.va.us (8.8.5/8.8.7a) with SMTP id GAA13157 for ; Sat, 11 Apr 1998 06:59:54 -0400 (EDT) Received: from mr.tuwien.ac.at [128.130.2.10] by drcoffsite.com with ESMTP (SMTPD32-4.04) id AAB53686038C; Sat, 11 Apr 1998 06:49:25 +03d00 Received: from logo (actually logo.ikn.tuwien.ac.at) by mr.tuwien.ac.at with SMTP (PP); Sat, 11 Apr 1998 12:47:53 +0200 Message-Id: <3.0.3.32.19980411124050.009f27c0@mail.zserv.tuwien.ac.at> X-Sender: vanas@mail.zserv.tuwien.ac.at X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Sat, 11 Apr 1998 12:40:50 +0200 To: vrrp@drcoffsite.com From: "Harmen R. van As" Subject: 8th IFIP Conference on High Performance Networking (HPN'98) Mime-Version: 1.0 Content-Type: text/enriched; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Precedence: bulk Sender: VRRP-owner@drcoffsite.com Dear member of the Virtual Router Redundancy Protocol community We still are looking for some papers for the HPN'98 Conference in Vienna. Would there be any change that you or somebody else would be able to submit a contribution within the next two weeks? Please notify coming submission With best regards Harmen R. van As
CALL FOR TUTORIALS CALL FOR PAPERS DEADLINE EXTENDED BUT NOTIFY COMING SUBMISSION ----------------------------------------------------------- 8th IFIP Conference on High Performance Networking (HPN'98) The Millennium Push of Internet =20 Vienna University of Technology, Vienna, Austria September 21-25, 1998 ------------------------------------------------------------ http://www.ikn.tuwien.ac.at/IKN/events/hpn-cfp.html March 15, 1998: Tutorial proposal March 15, 1998: Paper submission April 15, 1998: Notification May 15, 1998: Camera-ready paper =20 Conference book published by Chapman & Hall
Paper submission: preferably postscript file attached to email=20 otherwise 5 copies of paper by postal mail Topics of interest:=20 - Trends of Internet/Intranet Technologies=20 - Next Generation Internet, Evolutionary approaches=20 - Fast Internet (ADSL, HDSL, VHDSL, PONs)=20 - Cable Network, Wireless and Satellite Access=20 - Next Generation Routers, Tag Switching=20 - Bypass Tunneling (SDH, Photonics) =20 - Network/System Architecture and Design=20 - Cache Server Allocation and Interconnection=20 - Network Availability, Automatic Reconfiguration=20 - Coporate Networks, Global Networking =20 - Security in Internet, Network/System Security=20 - Network Management using Internet=20 - WWW and Java Network Service Management=20 - Distributed Systems Management in Internet=20 - Interworking with ATM, ISDN, and LANs=20 - System Interoperability =20 - Internet Mobility Support, Mobility Management=20 - Mobile-IP, Mobile-IPv6=20 - Mobile Agents, Intelligent/Smart Agents=20 - Flow Control, Traffic Monitoring and Control=20 - Adressing and Routing =20 - Advanced Internet Protocols (RTP, RSVP)=20 - Multicast Protocols=20 - Protocol Design, Combined ATM and IP=20 - Secure Protocols (S-HTTP, SSL, SET)=20 - Internet Tunneling =20 - Quality of Service, Service Level Guarantees=20 - Resource Management=20 - Real-Time Services over Internet=20 - IP Telephony, Voice over Internet=20 - Teleconferencing, Broadband Internet=20 - Integrated Services Internet=20 - Internet in Multimedia Environments=20 - Heterogenous Distributed Environments =20 - Internet Groupware and Cooperative Work=20 - Information Management over Internet=20 - Electronic Commerce, Online-Marketing=20 - Internet Payment Systems, Webcasting=20 - WWW Servers, Tele-Service-Systems=20 - Internet Servers (Data-Base, Cache, Archive)=20 - High-Performance Tele-Activities=20 - Social Impacts, Opportunities and Threats=20 INTERNATIONAL PROGRAM COMMITTEE:=20 General Chair:=20 Harmen R. van As, Vienna University of Technology, Austria=20 Ian Akyildiz, Georgia Tech, USA=20 Torsten Braun, Univ. of Berne, CH=20 Augusto Casaca, INESC, Portugal=20 Andre Danthine, Univ. Liege, Belgium=20 Michel Diaz, Univ. Toulouse, France=20 Christophe Diot, INRIA, France=20 Otto Duarte, Univ. Fed. Rio de Janeiro, Brazil=20 J=F6rg Ebersp=E4cher, Techn. Univ. Munich, Germany=20 Serge Fdida, Univ. Paris VI, France=20 Zygmunt Haas, Cornell University, USA=20 Marjory Johnson, NASA-RIACS, USA=20 Paul K=FChn, Univ. Stuttgart, Germany=20 Ralf Lehnert, Dresden Univ. of Technology, Germany=20 Helmut Leopold, Alcatel, Austria=20 Kurt Maly, Old Dominion Univ., USA=20 Olli Martikainen, Helsinki Univ. of Technology, Finland=20 Georg Mittenecker, Vienna Univ. of Technology, Austria=20 Hussein Mouftah, Queens Univ., Canada=20 Ignas Niemegeers, Univ. of Twente, The Netherlands=20 Guru Parulkar, Washington U. St. Louis, USA=20 Stephen Pink, SICS, Sweden=20 Radu Popescu-Zeletin, GMD Fokus, Germany=20 Ramon Puigjanier, Univ. Illes Balears, Spain=20 Guy Pujolle, Univ. Versailles, France=20 Doug Shepherd, Univ. Lancaster, UK=20 Thomas Sommer, Vienna Univ. of Technology, Austria=20 Otto Spaniol, Univ. Aachen, Germany=20 Ralf Steinmetz, Techn. Univ. Darmstadt, Germany=20 Ahmed Tantawi, IBM Res., Yorktown Heights, USA=20 Fouad Tobagi, Stanford Univ., USA=20 Samir Tohm=E9, ENST, France=20 Giorgio Ventre, Univ. Napoli, Italy=20 Martina Zitterbart, Univ. Braunschweig, Germany=20 ---------------------------------------------------------------------------- Prof.Dr. Harmen R. van As Institute of Communication Networks Vienna University of Technology Tel +43-1-58801-5246 Gusshausstrasse 25/388 Fax +43-1-5870583 A-1040 Vienna, Austria email: Harmen.R.van-As@tuwien.ac.at http://www.ikn.tuwien.ac.at=20 ---------------------------------------------------------------------------- From VRRP-owner@drcoffsite.com Mon Apr 13 08:59:38 1998 Delivery-Date: Mon, 13 Apr 1998 08:59:39 -0400 Return-Path: VRRP-owner@drcoffsite.com Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.5/8.8.7a) with ESMTP id IAA26345 for ; Mon, 13 Apr 1998 08:59:36 -0400 (EDT) Received: from drcoffsite.com (gw.drcoffsite.com [209.150.7.1]) by cnri.reston.va.us (8.8.5/8.8.7a) with SMTP id JAA02299 for ; Mon, 13 Apr 1998 09:02:03 -0400 (EDT) Received: from mail12.digital.com [192.208.46.20] by drcoffsite.com with ESMTP (SMTPD32-4.04) id AA15DDB0264; Mon, 13 Apr 1998 08:50:29 +03d00 Received: from muggsy.lkg.dec.com (muggsy.lkg.dec.com [16.20.32.219]) by mail12.digital.com (8.8.8/8.8.8/WV1.0d) with SMTP id IAA17163; Mon, 13 Apr 1998 08:49:03 -0400 (EDT) Received: from cei1.lkg.dec.com by muggsy.lkg.dec.com (5.65/DEC-Ultrix/4.3) with SMTP id AA11550; Mon, 13 Apr 1998 08:49:01 -0400 Received: from cei1.lkg.dec.com by cei1.lkg.dec.com; (5.65v3.2/1.1.8.2/07Jan96-0140PM) id AA16209; Mon, 13 Apr 1998 08:51:04 -0400 X-Sender: cei@lkg.dec.com Message-Id: <35320A38.ABD@cei1.lkg.dec.com> Date: Mon, 13 Apr 1998 08:51:04 -0400 From: Carol Iturralde X-Mailer: Mozilla 3.0Gold (X11; I; OSF1 V3.2 alpha) Mime-Version: 1.0 To: Peter Hunt Cc: vrrp@drcoffsite.com Subject: Re: VRRP and DECnet References: <199804101835.LAA27144@pfinger.iprg.nokia.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Precedence: bulk Sender: VRRP-owner@drcoffsite.com Peter: You are correct -- this is not the problem I thought it was. The vrrp-router could receive both the DECnet MAC address and the VRRP MAC address at the same time (or at least in my implementation it can). Thanks for the response. I withdraw the issue -- it is not really an issue. Carol Peter Hunt wrote: > > > Bringing DECnet up on an interface (e.g., Ethernet or FDDI) > > causes the MAC address to be modified. DECnet sets it to > > a desired value -- and it must use this value. > > Is this a problem with sending or receiving packets? That is, must DECnet > packets be use the DECnet MAC as their source MAC? Or do you see this as > a problem in receiving packets (ie. the ethernet device can't filter on > both the DECnet MAC and the VRRP MAC at the same time)? > > Regards, > > Peter. From VRRP-owner@drcoffsite.com Mon Apr 13 11:18:35 1998 Delivery-Date: Mon, 13 Apr 1998 11:18:35 -0400 Return-Path: VRRP-owner@drcoffsite.com Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.5/8.8.7a) with ESMTP id LAA28034 for ; Mon, 13 Apr 1998 11:18:34 -0400 (EDT) Received: from drcoffsite.com (gw.drcoffsite.com [209.150.7.1]) by cnri.reston.va.us (8.8.5/8.8.7a) with SMTP id LAA03064 for ; Mon, 13 Apr 1998 11:20:59 -0400 (EDT) Received: from mailhost.iprg.nokia.com [205.226.5.12] by drcoffsite.com (SMTPD32-4.04) id ABA33B240154; Mon, 13 Apr 1998 11:13:39 +03d00 Received: from crowdhouse.iprg.nokia.com (maxdialin0.iprg.nokia.com [205.226.20.230]) by mailhost.iprg.nokia.com (8.6.11/8.6.10) with SMTP id IAA26685; Mon, 13 Apr 1998 08:10:53 -0700 Message-ID: <35322B66.2834@iprg.nokia.com> Date: Mon, 13 Apr 1998 08:12:38 -0700 From: Peter Hunt Reply-To: hunt@iprg.nokia.com Organization: Nokia Communications X-Mailer: Mozilla 3.01 (Win95; I) MIME-Version: 1.0 To: Carol Iturralde CC: hunt@iprg.nokia.com, vrrp@drcoffsite.com Subject: Re: VRRP and DECnet References: <199804101835.LAA27144@pfinger.iprg.nokia.com> <35320A38.ABD@cei1.lkg.dec.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Precedence: bulk Sender: VRRP-owner@drcoffsite.com Carol, > The vrrp-router could receive both the DECnet MAC address > and the VRRP MAC address at the same time (or at least in > my implementation it can). It may be device dependent; some ethernet devices allow additional unicast MAC address filters to be configured, so the physical, DECnet and VRRP MAC addresses can all coexist. DEC tulip devices allow this, for example. Some devices may not support this, but you can always work around it by putting the device in promiscuous mode and filtering in software. Not ideal, I'll grant you. :) But I agree that the issue doesn't merit updating the draft. Regards, -- | Peter Hunt | Phone: +1 408 990 2093 | Nokia Communications - IP Routing | Fax: +1 408 743 5677 | 232 Java Drive, Sunnyvale CA 94089-1318 | Email: hunt@iprg.nokia.com From VRRP-owner@drcoffsite.com Tue Apr 14 11:09:00 1998 Delivery-Date: Tue, 14 Apr 1998 11:09:00 -0400 Return-Path: VRRP-owner@drcoffsite.com Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.5/8.8.7a) with ESMTP id LAA25429 for ; Tue, 14 Apr 1998 11:08:59 -0400 (EDT) Received: from drcoffsite.com (gw.drcoffsite.com [209.150.7.1]) by cnri.reston.va.us (8.8.5/8.8.7a) with SMTP id LAA07615 for ; Tue, 14 Apr 1998 11:11:28 -0400 (EDT) Received: from relay5.UU.NET [192.48.96.15] by drcoffsite.com with ESMTP (SMTPD32-4.04) id A87161D9028C; Tue, 14 Apr 1998 10:53:37 +03d00 Received: from xedia.com by relay5.UU.NET with SMTP (peer crosschecked as: madway.xedia.com [198.202.232.199]) id QQelbv16072; Tue, 14 Apr 1998 10:52:08 -0400 (EDT) Received: from grenada.xedia.com by xedia.com (4.1/SMI-4.1) id AA08660; Tue, 14 Apr 98 10:53:25 EDT Received: from grenada (localhost) by grenada.xedia.com (5.x/SMI-SVR4) id AA02138; Tue, 14 Apr 1998 10:52:04 -0400 X-Sender: sbarvick@grenada.xedia.com Message-Id: <35337813.3F94@xedia.com> Date: Tue, 14 Apr 1998 10:52:03 -0400 From: Scott Barvick X-Mailer: Mozilla 3.01Gold (X11; I; SunOS 5.4 sun4m) Mime-Version: 1.0 To: vrrp@drcoffsite.com Subject: vrrpOperProtocol attribute Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Precedence: bulk Sender: VRRP-owner@drcoffsite.com >From the DECnet VRRP discussion and other ideas about the use of VRRP, it seems that we might need a vrrpOperProtocol attribute to distinguish among various protocols which might be backed up through VRRP. How about: vrrpOperProtocol OBJECT-TYPE SYNTAX INTEGER { ip (1), bridge (2), DECnet (3), other (4) } MAX-ACCESS read-create STATUS current DESCRIPTION "The particular protocol being controlled by this Virtual Router." DEFVAL { ip } ::= {vrrpOperEntry X} -- Scott Barvick sbarvick@xedia.com (978) 952-6000 x162 From VRRP-owner@drcoffsite.com Tue Apr 14 13:21:26 1998 Delivery-Date: Tue, 14 Apr 1998 13:21:26 -0400 Return-Path: VRRP-owner@drcoffsite.com Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.5/8.8.7a) with ESMTP id NAA00590 for ; Tue, 14 Apr 1998 13:21:26 -0400 (EDT) Received: from drcoffsite.com (gw.drcoffsite.com [209.150.7.1]) by cnri.reston.va.us (8.8.5/8.8.7a) with SMTP id NAA08317 for ; Tue, 14 Apr 1998 13:23:53 -0400 (EDT) Received: from fwns1.raleigh.ibm.com [204.146.167.235] by drcoffsite.com with ESMTP (SMTPD32-4.04) id A709394D0256; Tue, 14 Apr 1998 13:04:09 +03d00 Received: from rtpmail02.raleigh.ibm.com (rtpmail02.raleigh.ibm.com [9.37.172.48]) by fwns1.raleigh.ibm.com (AIX4.2/UCB 8.7/8.7RTP-FW1.1) with ESMTP id NAA42288; Tue, 14 Apr 1998 13:02:39 -0400 (EDT) Received: from aceman.raleigh.ibm.com (aceman.raleigh.ibm.com [9.37.177.119]) by rtpmail02.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id NAA32752; Tue, 14 Apr 1998 13:02:40 -0400 Received: from loopback by aceman.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA21452; Tue, 14 Apr 1998 13:02:41 -0400 X-Sender: acee@raleigh.ibm.com Message-Id: <353396B0.4115E3A8@raleigh.ibm.com> Date: Tue, 14 Apr 1998 13:02:40 -0400 From: Acee Lindem Organization: IBM Networking Divison X-Mailer: Mozilla 4.04 [en] (X11; I; AIX 4.1) Mime-Version: 1.0 To: Scott Barvick Cc: vrrp@drcoffsite.com Subject: Re: vrrpOperProtocol attribute References: <35337813.3F94@xedia.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Precedence: bulk Sender: VRRP-owner@drcoffsite.com Scott Barvick wrote: > > >From the DECnet VRRP discussion and other ideas about the use of VRRP, > it seems that we might need a vrrpOperProtocol attribute to distinguish > among various protocols which might be backed up through VRRP. > > How about: > > vrrpOperProtocol OBJECT-TYPE > SYNTAX INTEGER { > ip (1), > bridge (2), There are already host-transparent mechanisms for multiple bridge paths to back one another up. > DECnet (3), > other (4) > } > MAX-ACCESS read-create > STATUS current > DESCRIPTION > "The particular protocol being controlled by this Virtual > Router." > DEFVAL { ip } > ::= {vrrpOperEntry X} > > -- I think this is going overboard since to do it consistently you'd need to associate addresses from the non-IP protocols to a VRID. This wouldn't preclude a vendor from using VRRP "router-awareness" to provide backup of other protocols - it just keeps it out of the base specificaition. -- Acee From VRRP-owner@drcoffsite.com Tue Apr 14 13:48:58 1998 Delivery-Date: Tue, 14 Apr 1998 13:48:58 -0400 Return-Path: VRRP-owner@drcoffsite.com Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.5/8.8.7a) with ESMTP id NAA01702 for ; Tue, 14 Apr 1998 13:48:58 -0400 (EDT) Received: from drcoffsite.com (gw.drcoffsite.com [209.150.7.1]) by cnri.reston.va.us (8.8.5/8.8.7a) with SMTP id NAA08450 for ; Tue, 14 Apr 1998 13:51:26 -0400 (EDT) Received: from relay1.UU.NET [192.48.96.5] by drcoffsite.com with ESMTP (SMTPD32-4.04) id AC6279110256; Tue, 14 Apr 1998 13:26:58 +03d00 Received: from xedia.com by relay1.UU.NET with SMTP (peer crosschecked as: madway.xedia.com [198.202.232.199]) id QQelcf15606; Tue, 14 Apr 1998 13:25:32 -0400 (EDT) Received: from grenada.xedia.com by xedia.com (4.1/SMI-4.1) id AA10361; Tue, 14 Apr 98 13:26:50 EDT Received: from grenada (localhost) by grenada.xedia.com (5.x/SMI-SVR4) id AA05549; Tue, 14 Apr 1998 13:25:29 -0400 X-Sender: sbarvick@grenada.xedia.com Message-Id: <35339C09.18BB@xedia.com> Date: Tue, 14 Apr 1998 13:25:29 -0400 From: Scott Barvick X-Mailer: Mozilla 3.01Gold (X11; I; SunOS 5.4 sun4m) Mime-Version: 1.0 To: vrrp@drcoffsite.com Subject: Re: vrrpOperProtocol attribute Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Precedence: bulk Sender: VRRP-owner@drcoffsite.com Acee Lindem wrote: > > Scott Barvick wrote: > > > > >From the DECnet VRRP discussion and other ideas about the use of VRRP, > > it seems that we might need a vrrpOperProtocol attribute to distinguish > > among various protocols which might be backed up through VRRP. > > > > How about: > > > > vrrpOperProtocol OBJECT-TYPE > > SYNTAX INTEGER { > > ip (1), > > bridge (2), > > There are already host-transparent mechanisms for multiple bridge paths > to back one another up. > > > DECnet (3), > > other (4) > > } > > MAX-ACCESS read-create > > STATUS current > > DESCRIPTION > > "The particular protocol being controlled by this Virtual > > Router." > > DEFVAL { ip } > > ::= {vrrpOperEntry X} > > > > -- > > I think this is going overboard since to do it consistently you'd need > to associate addresses from the non-IP protocols to a VRID. This > wouldn't preclude a vendor from using VRRP "router-awareness" to > provide backup of other protocols - it just keeps it out of the > base specificaition. We certainly would want to not specify anything beyond IP in the base spec, and I'm sure we would never actually go any further in the IETF on support for other protocols. However, people will use the "router-awareness" for other things and it would be nice to have a way to note this in the standard MIB so that those who are looking at the operation of VRRP will not be confused by a VR in the MIB that isn't doing quite what it would be doing if it were managing IP. -- Scott Barvick sbarvick@xedia.com (978) 952-6000 x162 From VRRP-owner@drcoffsite.com Wed Apr 15 11:57:23 1998 Delivery-Date: Wed, 15 Apr 1998 11:57:28 -0400 Return-Path: VRRP-owner@drcoffsite.com Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.5/8.8.7a) with ESMTP id LAA03321 for ; Wed, 15 Apr 1998 11:57:23 -0400 (EDT) Received: from drcoffsite.com (gw.drcoffsite.com [209.150.7.1]) by cnri.reston.va.us (8.8.5/8.8.7a) with SMTP id LAA12314 for ; Wed, 15 Apr 1998 11:59:48 -0400 (EDT) Received: from seattle.3com.com [129.213.128.97] by drcoffsite.com with ESMTP (SMTPD32-4.04) id A4F69DD0222; Wed, 15 Apr 1998 11:40:38 +03d00 Received: from new-york.3com.com (new-york.3com.com [129.213.157.12]) by seattle.3com.com (8.8.8/8.8.8) with ESMTP id IAA26268 for ; Wed, 15 Apr 1998 08:39:09 -0700 (PDT) Received: from chicago.nsd.3com.com (chicago.nsd.3com.com [129.213.157.11]) by new-york.3com.com (8.8.8/8.8.8) with ESMTP id IAA18458 for ; Wed, 15 Apr 1998 08:39:08 -0700 (PDT) Received: from fubar.nsd.3com.com (fubar.nsd.3com.com [129.213.16.41]) by chicago.nsd.3com.com (8.8.8/8.8.8) with ESMTP id IAA07928; Wed, 15 Apr 1998 08:39:07 -0700 (PDT) From: Brian Jewell Received: (from bjewell@localhost) by fubar.nsd.3com.com (8.8.2/8.8.5) id IAA04838; Wed, 15 Apr 1998 08:39:05 -0700 (PDT) Date: Wed, 15 Apr 1998 08:39:05 -0700 (PDT) Message-Id: <199804151539.IAA04838@fubar.nsd.3com.com> Subject: Re: vrrpOperProtocol attribute To: vrrp@drcoffsite.com Cc: bjewell@ewd.3Com.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-MD5: OdSRdTHOYQcpPn+BR/ODMA== Precedence: bulk Sender: VRRP-owner@drcoffsite.com Response is at the bottom. > > > Acee Lindem wrote: > > > > Scott Barvick wrote: > > > > > > >From the DECnet VRRP discussion and other ideas about the use of VRRP, > > > it seems that we might need a vrrpOperProtocol attribute to distinguish > > > among various protocols which might be backed up through VRRP. > > > > > > How about: > > > > > > vrrpOperProtocol OBJECT-TYPE > > > SYNTAX INTEGER { > > > ip (1), > > > bridge (2), > > > > There are already host-transparent mechanisms for multiple bridge paths > > to back one another up. > > > > > DECnet (3), > > > other (4) > > > } > > > MAX-ACCESS read-create > > > STATUS current > > > DESCRIPTION > > > "The particular protocol being controlled by this Virtual > > > Router." > > > DEFVAL { ip } > > > ::= {vrrpOperEntry X} > > > > > > -- > > > > I think this is going overboard since to do it consistently you'd need > > to associate addresses from the non-IP protocols to a VRID. This > > wouldn't preclude a vendor from using VRRP "router-awareness" to > > provide backup of other protocols - it just keeps it out of the > > base specificaition. > > > We certainly would want to not specify anything beyond IP in > the base spec, and I'm sure we would never actually go any further > in the IETF on support for other protocols. > > However, people will use the "router-awareness" for other things > and it would be nice to have a way to note this in the standard MIB > so that those who are looking at the operation of VRRP will not be > confused by a VR in the MIB that isn't doing quite what it would be > doing if it were managing IP. > > -- > Scott Barvick > sbarvick@xedia.com > (978) 952-6000 x162 > Response: I don't see any problem here about including such an object in the vrrpOperTable. >From the emails that have been exchanged, I have gleaned one possible concern: With a protocol such as Decnet, which apparently assigns it own MAC address, the choice of VRID's would be limited. Thus, screwing up the vrrpOperTable VRID index?? Let me know if I am interpreting this correctly and if it is a valid concern. Otherwise I will include this object in the next MIB revision. Thanks. -Brian From VRRP-owner@drcoffsite.com Thu Apr 16 17:01:19 1998 Delivery-Date: Thu, 16 Apr 1998 17:01:21 -0400 Return-Path: VRRP-owner@drcoffsite.com Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.5/8.8.7a) with ESMTP id RAA08633 for ; Thu, 16 Apr 1998 17:01:15 -0400 (EDT) Received: from drcoffsite.com (gw.drcoffsite.com [209.150.7.1]) by cnri.reston.va.us (8.8.5/8.8.7a) with SMTP id RAA18262 for ; Thu, 16 Apr 1998 17:03:28 -0400 (EDT) Received: from fwns1.raleigh.ibm.com [204.146.167.235] by drcoffsite.com with ESMTP (SMTPD32-4.04) id A004109D0220; Thu, 16 Apr 1998 16:54:28 +03d00 Received: from rtpmail03.raleigh.ibm.com ([9.37.172.47]) by fwns1.raleigh.ibm.com (AIX4.2/UCB 8.7/8.7RTP-FW1.1) with ESMTP id TAA218692; Wed, 15 Apr 1998 19:20:47 -0400 (EDT) Received: from aceman.raleigh.ibm.com (aceman.raleigh.ibm.com [9.37.177.119]) by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id TAA27860; Wed, 15 Apr 1998 19:20:13 -0400 Received: from loopback by aceman.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA18878; Wed, 15 Apr 1998 19:20:12 -0400 X-Sender: acee@raleigh.ibm.com Message-Id: <353540AB.E7D9FF11@raleigh.ibm.com> Date: Wed, 15 Apr 1998 19:20:11 -0400 From: Acee Lindem Organization: IBM Networking Divison X-Mailer: Mozilla 4.04 [en] (X11; I; AIX 4.1) Mime-Version: 1.0 To: "shand@mail.dec.com" Cc: "'Carol Iturralde'" , "vrrp@drcoffsite.com" , Tony Hart , "cei@cei1.lkg.dec.com" Subject: Re: 2 questions on the VRRP spec. References: <250F9C8DEB9ED011A14D08002BE4F64C0100C669@wade.reo.dec.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Precedence: bulk Sender: VRRP-owner@drcoffsite.com Mike Shand wrote: > > On Tuesday, April 07, 1998 2:23 PM, Carol Iturralde [SMTP:cei@lkg.dec.com] > wrote: > > I understand that Advertisements must be send using > > 00-00-5E-00-01-{VRID} as the source MAC address. > > > > My questions are: > > > > - when sending an ARP reply (when the request was for a > > IP address of a virtual router), must this reply be sent > > using 00-00-5E-00-01-{VRID} as the source MAC address? > > (I understand that this MAC address must be present in > > the ARP packet, but I am asking about the datalink header' > > source MAC address). > With source route bridging, it is preferable to use the virtual MAC address as the MAC source address in the ARP reply. The reason for this is that some token ring device driver implementations keep a cache of MAC address to RIF mappings independent of the ARP cache. Hence, if the host never receives a unicast packet with the virtual MAC address as the source MAC, it will never be able to resolve the RIF for the virtual MAC address. For host implementations that keep the RIF in the ARP entry (e.g., IBM AIX), this is not a problem. Note that the RIF (Route Information Field) is a variable length field in the MAC header of source route bridged packets which contains the complete source-route bridge path to the destination MAC. It consists of a 2 byte routing control header and 1-8 ring number/bridge number tuples. A way to get around this is to use the functional address virtual MAC mapping for source route bridged LANs (i.e., token ring). A disadvantage of this is that packets addressed to the token ring functional address traverse all the LAN segments. -- Acee From VRRP-owner@drcoffsite.com Thu Apr 16 17:28:00 1998 Delivery-Date: Thu, 16 Apr 1998 17:28:00 -0400 Return-Path: VRRP-owner@drcoffsite.com Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.5/8.8.7a) with ESMTP id RAA09830 for ; Thu, 16 Apr 1998 17:27:59 -0400 (EDT) Received: from drcoffsite.com (gw.drcoffsite.com [209.150.7.1]) by cnri.reston.va.us (8.8.5/8.8.7a) with SMTP id RAA18452 for ; Thu, 16 Apr 1998 17:30:27 -0400 (EDT) Received: from fwns2.raleigh.ibm.com [204.146.167.236] by drcoffsite.com with ESMTP (SMTPD32-4.04) id A78D8300228; Thu, 16 Apr 1998 17:26:37 +03d00 Received: from rtpmail03.raleigh.ibm.com (rtpmail03.raleigh.ibm.com [9.37.172.47]) by fwns2.raleigh.ibm.com (AIX4.2/UCB 8.7/8.7RTP-FW1.1) with ESMTP id RAA41522; Thu, 16 Apr 1998 17:25:01 -0400 (EDT) Received: from aceman.raleigh.ibm.com (aceman.raleigh.ibm.com [9.37.177.119]) by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id RAA31636; Thu, 16 Apr 1998 17:25:03 -0400 Received: from loopback by aceman.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA24016; Thu, 16 Apr 1998 17:25:01 -0400 X-Sender: acee@raleigh.ibm.com Message-Id: <3536772D.C63FA05@raleigh.ibm.com> Date: Thu, 16 Apr 1998 17:25:01 -0400 From: Acee Lindem Organization: IBM Networking Divison X-Mailer: Mozilla 4.04 [en] (X11; I; AIX 4.1) Mime-Version: 1.0 To: Brian Jewell Cc: vrrp@drcoffsite.com, bjewell@ewd.3Com.com Subject: Re: vrrpOperProtocol attribute References: <199804151539.IAA04838@fubar.nsd.3com.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Precedence: bulk Sender: VRRP-owner@drcoffsite.com Brian Jewell wrote: > Response: > > I don't see any problem here about including such an object in the > vrrpOperTable. > > >From the emails that have been exchanged, I have gleaned one possible concern: > With a protocol such as Decnet, which apparently assigns it own MAC address, > the choice of VRID's would be limited. Thus, screwing up the vrrpOperTable VRID > index?? Maybe I'm confused. However, my take is that the only way you can use VRRP for DECnet (on any other non-IP protocol) is to have the VRRP state transitions internally signal these protocols to forward or cease-forwarding for a given non-IP protocol address. Hence, the fact that DECnet changes the hardware MAC address is an othogonal issue (you'd simply have to have hardware or promiscuous filtering to receive packets addressed to both the VRID virtual addresses and the DECnet MAC addresses). Given that the above is correct, my point was that since this shouldn't be in the MIB since it must be done outside the scope of VRRP (VRRP doesn't maintain state for non-IP protocols nor does it addvertise non-IP protocol addresses). Thanks, -- Acee From VRRP-owner@drcoffsite.com Fri Apr 17 08:56:07 1998 Delivery-Date: Fri, 17 Apr 1998 08:56:08 -0400 Return-Path: VRRP-owner@drcoffsite.com Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.5/8.8.7a) with ESMTP id IAA29952 for ; Fri, 17 Apr 1998 08:56:06 -0400 (EDT) Received: from drcoffsite.com (gw.drcoffsite.com [209.150.7.1]) by cnri.reston.va.us (8.8.5/8.8.7a) with SMTP id IAA20503 for ; Fri, 17 Apr 1998 08:58:32 -0400 (EDT) Received: from relay2.UU.NET [192.48.96.7] by drcoffsite.com with ESMTP (SMTPD32-4.04) id AF2B3860370; Fri, 17 Apr 1998 08:46:35 +03d00 Received: from xedia.com by relay2.UU.NET with SMTP (peer crosschecked as: madway.xedia.com [198.202.232.199]) id QQelmp06819; Fri, 17 Apr 1998 08:45:01 -0400 (EDT) Received: from grenada.xedia.com by xedia.com (4.1/SMI-4.1) id AA05953; Fri, 17 Apr 98 08:46:16 EDT Received: from grenada (localhost) by grenada.xedia.com (5.x/SMI-SVR4) id AA24255; Fri, 17 Apr 1998 08:44:58 -0400 X-Sender: sbarvick@grenada.xedia.com Message-Id: <35374EC9.6DBA@xedia.com> Date: Fri, 17 Apr 1998 08:44:57 -0400 From: Scott Barvick X-Mailer: Mozilla 3.01Gold (X11; I; SunOS 5.4 sun4m) Mime-Version: 1.0 To: vrrp@drcoffsite.com Subject: Re: vrrpOperProtocol attribute References: <199804151539.IAA04838@fubar.nsd.3com.com> <3536772D.C63FA05@raleigh.ibm.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Precedence: bulk Sender: VRRP-owner@drcoffsite.com Acee Lindem wrote: ... > > Maybe I'm confused. However, my take is that the only way you can use VRRP for > DECnet (on any other non-IP protocol) is to have the VRRP state transitions internally > signal these protocols to forward or cease-forwarding for a given non-IP protocol > address. Hence, the fact that DECnet changes the hardware MAC address is an othogonal > issue (you'd simply have to have hardware or promiscuous filtering to receive packets > addressed to both the VRID virtual addresses and the DECnet MAC addresses). > > Given that the above is correct, my point was that since this shouldn't > be in the MIB since it must be done outside the scope of VRRP (VRRP doesn't > maintain state for non-IP protocols nor does it addvertise non-IP protocol > addresses). I agree with the assessment that it would take modifications to some portion of the VRRP state machine to have it control other protocols. To me the state machine implementation is the smallest part of building an application such as VRRP. The configuration, infrastructure, other system hooks tend to take more time than coding up the final state table and resulting actions. Therefore, the question for us is "do we want VRRP to be extensible?" My view is that VRRP can be a general mechanism for "router aliveness", and there will be a desire to have a redundancy mechanism for different applications. Some of these may be non-IETF (DECnet, IPX, bridge), and if they were the only cases, there might be a philosophical issue concerning using an IETF IP MIB to indicate that the IETF IP protocol was being used with non-IETF non-IP protocols. I'd still put it in because it will make the IETF MIB more accurate when monitoring VRRP when it is used for other purposes. However, it is possible that this fairly generic mechanism could be used for IP based operations beyond simple address redundancy. One is NAT backup/redundancy. There may be work undertaken in the NAT working group to do something across routers. Given that NAT doesn't have any protocol mechanisms of its own, I can see that VRRP might be the interrouter communication mechanism of choice. The vrrpOperProtocol = NAT could signal a pool (an possibly even a WAN link) to be activated when a backup router transitions to the master state. The state machines might be somewhat or even very different. Is that still VRRP, I think it can be if that's how we end up defining - or specifically not defining- operations based on different vrrpOperProtocol values. An I still vote for defined values for current non-IP protocols including DECnet, IPX, and bridge. At the very least, a "VENDOR-SPECIFIC" range could be used. Scott -- Scott Barvick sbarvick@xedia.com (978) 952-6000 x162 From VRRP-owner@drcoffsite.com Fri Apr 17 13:18:46 1998 Delivery-Date: Fri, 17 Apr 1998 13:18:47 -0400 Return-Path: VRRP-owner@drcoffsite.com Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.5/8.8.7a) with ESMTP id NAA06098 for ; Fri, 17 Apr 1998 13:18:46 -0400 (EDT) Received: from drcoffsite.com (gw.drcoffsite.com [209.150.7.1]) by cnri.reston.va.us (8.8.5/8.8.7a) with SMTP id NAA21696 for ; Fri, 17 Apr 1998 13:21:11 -0400 (EDT) Received: from joshua.drcoffsite.com [209.150.7.12] by drcoffsite.com (SMTPD32-4.04) id ACFE2FF40220; Fri, 17 Apr 1998 13:10:22 +03d00 Received: from fwns2.raleigh.ibm.com [204.146.167.236] by joshua.drcoffsite.com with ESMTP (SMTPD32-4.04) id ADC65A9014A; Fri, 17 Apr 1998 13:13:42 EST Received: from rtpmail01.raleigh.ibm.com (rtpmail01.raleigh.ibm.com [9.37.172.24]) by fwns2.raleigh.ibm.com (AIX4.2/UCB 8.7/8.7RTP-FW1.1) with ESMTP id NAA45696; Fri, 17 Apr 1998 13:03:37 -0400 (EDT) Received: from aceman.raleigh.ibm.com (aceman.raleigh.ibm.com [9.37.177.119]) by rtpmail01.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id NAA25938; Fri, 17 Apr 1998 13:03:38 -0400 Received: from loopback by aceman.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA23264; Fri, 17 Apr 1998 13:03:40 -0400 X-Sender: acee@raleigh.ibm.com Message-Id: <35378B67.F10AAFB2@raleigh.ibm.com> Date: Fri, 17 Apr 1998 13:03:35 -0400 From: Acee Lindem Organization: IBM Networking Divison X-Mailer: Mozilla 4.04 [en] (X11; I; AIX 4.1) Mime-Version: 1.0 To: Scott Barvick Cc: vrrp@drcoffsite.com Subject: Re: vrrpOperProtocol attribute References: <199804151539.IAA04838@fubar.nsd.3com.com> <3536772D.C63FA05@raleigh.ibm.com> <35374EC9.6DBA@xedia.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Precedence: bulk Sender: VRRP-owner@drcoffsite.com Scott Barvick wrote: > > Acee Lindem wrote: > ... > > > > Maybe I'm confused. However, my take is that the only way you can use VRRP for > > DECnet (on any other non-IP protocol) is to have the VRRP state transitions internally > > signal these protocols to forward or cease-forwarding for a given non-IP protocol > > address. Hence, the fact that DECnet changes the hardware MAC address is an othogonal > > issue (you'd simply have to have hardware or promiscuous filtering to receive packets > > addressed to both the VRID virtual addresses and the DECnet MAC addresses). > > > > Given that the above is correct, my point was that since this shouldn't > > be in the MIB since it must be done outside the scope of VRRP (VRRP doesn't > > maintain state for non-IP protocols nor does it addvertise non-IP protocol > > addresses). > > I agree with the assessment that it would take modifications to some > portion of the VRRP state machine to have it control other protocols. > To me the state machine implementation is the smallest part of building > an application such as VRRP. The configuration, infrastructure, other > system hooks tend to take more time than coding up the final state table > and resulting actions. > > Therefore, the question for us is "do we want VRRP to be extensible?" > My view is that VRRP can be a general mechanism for "router aliveness", > and there will be a desire to have a redundancy mechanism for different > applications. Some of these may be non-IETF (DECnet, IPX, bridge), and > if they were the only cases, there might be a philosophical issue > concerning using an IETF IP MIB to indicate that the IETF IP protocol > was being used with non-IETF non-IP protocols. I'd still put it in > because it will make the IETF MIB more accurate when monitoring VRRP > when it is used for other purposes. However, it is possible that this > fairly generic mechanism could be used for IP based operations beyond > simple address redundancy. > > One is NAT backup/redundancy. There may be work undertaken in the NAT > working group to do something across routers. Given that NAT doesn't > have any protocol mechanisms of its own, I can see that VRRP might be > the interrouter communication mechanism of choice. The vrrpOperProtocol > = NAT could signal a pool (an possibly even a WAN link) to be activated > when a backup router transitions to the master state. > > The state machines might be somewhat or even very different. Is that > still VRRP, I think it can be if that's how we end up defining - or > specifically not defining- operations based on different > vrrpOperProtocol values. I don't disagree that VRRP awareness could be used for other applications. I just don't think adding this one MIB varibable does much for you. To do it right, a separate draft would be required for the interaction with each protocol. I might envision one way this would work with a non-IP protocol and you might envision another. However, if I'm in the minority here and it is added I think it should be part of the index for the vrrpOperTable to allow a single VRID to control multiple applications. > > An I still vote for defined values for current non-IP protocols > including DECnet, IPX, and bridge. If this MIB value is added, why is "bridge" required? TB, SRB, and SRT all have host-transparent mechanisms to provide redundant paths. > At the very least, a > "VENDOR-SPECIFIC" range could be used. -- Acee From VRRP-owner@drcoffsite.com Fri Apr 17 14:55:23 1998 Delivery-Date: Fri, 17 Apr 1998 14:55:23 -0400 Return-Path: VRRP-owner@drcoffsite.com Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.5/8.8.7a) with ESMTP id OAA08282 for ; Fri, 17 Apr 1998 14:55:22 -0400 (EDT) Received: from drcoffsite.com (gw.drcoffsite.com [209.150.7.1]) by cnri.reston.va.us (8.8.5/8.8.7a) with SMTP id OAA22183 for ; Fri, 17 Apr 1998 14:57:49 -0400 (EDT) Received: from relay2.UU.NET [192.48.96.7] by drcoffsite.com with ESMTP (SMTPD32-4.04) id A24D4AC20220; Fri, 17 Apr 1998 14:41:17 +03d00 Received: from xedia.com by relay2.UU.NET with SMTP (peer crosschecked as: madway.xedia.com [198.202.232.199]) id QQelnm20622; Fri, 17 Apr 1998 14:39:46 -0400 (EDT) Received: from grenada.xedia.com by xedia.com (4.1/SMI-4.1) id AA09787; Fri, 17 Apr 98 14:41:01 EDT Received: from grenada (localhost) by grenada.xedia.com (5.x/SMI-SVR4) id AA24469; Fri, 17 Apr 1998 14:39:43 -0400 X-Sender: sbarvick@grenada.xedia.com Message-Id: <3537A1EF.6384@xedia.com> Date: Fri, 17 Apr 1998 14:39:43 -0400 From: Scott Barvick X-Mailer: Mozilla 3.01Gold (X11; I; SunOS 5.4 sun4m) Mime-Version: 1.0 To: vrrp@drcoffsite.com Subject: Re: vrrpOperProtocol attribute References: <199804151539.IAA04838@fubar.nsd.3com.com> <3536772D.C63FA05@raleigh.ibm.com> <35374EC9.6DBA@xedia.com> <35378B67.F10AAFB2@raleigh.ibm.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Precedence: bulk Sender: VRRP-owner@drcoffsite.com Acee Lindem wrote: > >[...] > > I don't disagree that VRRP awareness could be used for other applications. > I just don't think adding this one MIB varibable does much for you. To > do it right, a separate draft would be required for the interaction with > each protocol. I might envision one way this would work with a non-IP > protocol and you might envision another. > > However, if I'm in the minority here and it is added I think it should be > part of the index for the vrrpOperTable to allow a single VRID to control > multiple applications. I'm agree that each new application would need a separate draft or something outside the base VRRP spec. What the value buys you now is that base VRRP MIB doesn't change when we decide to support redundant NATs through VRRP, and the way this is indicated fits nicely with how DEC has represented its (proprietary?) DECnet support on a VR (my assumption of course). I agree that the protocol *should* be part of the index, but with 255 VRs per LAN, I'd vote for less complexity by not having it as part of the index with the requirement that you don't reuse VRs for different protocols on the same LAN. If we feel that we can't do this, I'd say forget the whole thing because I wouldn't want to burden the majority of VRRP usage and implementation with another index parameter. > > > > > An I still vote for defined values for current non-IP protocols > > including DECnet, IPX, and bridge. > > If this MIB value is added, why is "bridge" required? TB, SRB, and SRT > all have host-transparent mechanisms to provide redundant paths. I included it for completeness. I can see implementions that have VRRP but no Spanning Tree quickly modifying the VRRP state machines to support bridging. This would obviously be proprietary, but I've seen worse done out there:) -- Scott Barvick sbarvick@xedia.com (978) 952-6000 x162 From VRRP-owner@drcoffsite.com Fri Apr 17 16:47:32 1998 Delivery-Date: Fri, 17 Apr 1998 16:47:33 -0400 Return-Path: VRRP-owner@drcoffsite.com Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.5/8.8.7a) with ESMTP id QAA10686 for ; Fri, 17 Apr 1998 16:47:32 -0400 (EDT) Received: from drcoffsite.com (gw.drcoffsite.com [209.150.7.1]) by cnri.reston.va.us (8.8.5/8.8.7a) with SMTP id QAA22855 for ; Fri, 17 Apr 1998 16:50:00 -0400 (EDT) Received: from seattle.3com.com [129.213.128.97] by drcoffsite.com with ESMTP (SMTPD32-4.04) id AEDFAD3C020A; Fri, 17 Apr 1998 16:43:11 +03d00 Received: from new-york.3com.com (new-york.3com.com [129.213.157.12]) by seattle.3com.com (8.8.8/8.8.8) with ESMTP id NAA07130 for ; Fri, 17 Apr 1998 13:40:55 -0700 (PDT) Received: from chicago.nsd.3com.com (chicago.nsd.3com.com [129.213.157.11]) by new-york.3com.com (8.8.8/8.8.8) with ESMTP id NAA06517 for ; Fri, 17 Apr 1998 13:40:55 -0700 (PDT) Received: from fubar.nsd.3com.com (fubar.nsd.3com.com [129.213.16.41]) by chicago.nsd.3com.com (8.8.8/8.8.8) with ESMTP id NAA03952; Fri, 17 Apr 1998 13:40:54 -0700 (PDT) From: Brian Jewell Received: (from bjewell@localhost) by fubar.nsd.3com.com (8.8.2/8.8.5) id NAA06689; Fri, 17 Apr 1998 13:40:51 -0700 (PDT) Date: Fri, 17 Apr 1998 13:40:51 -0700 (PDT) Message-Id: <199804172040.NAA06689@fubar.nsd.3com.com> Subject: Re: vrrpOperProtocol attribute To: vrrp@drcoffsite.com Cc: bjewell@ewd.3Com.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-MD5: aYt3A/O6vpJASh42KjJyew== Precedence: bulk Sender: VRRP-owner@drcoffsite.com >> >>[...] >> >> I don't disagree that VRRP awareness could be used for other applications. >> I just don't think adding this one MIB varibable does much for you. To >> do it right, a separate draft would be required for the interaction with >> each protocol. I might envision one way this would work with a non-IP >> protocol and you might envision another. >> >> However, if I'm in the minority here and it is added I think it should be >> part of the index for the vrrpOperTable to allow a single VRID to control >> multiple applications. >I'm agree that each new application would need a separate draft or >something outside the base VRRP spec. What the value buys you now is >that base VRRP MIB doesn't change when we decide to support redundant >NATs through VRRP, and the way this is indicated fits nicely with how >DEC has represented its (proprietary?) DECnet support on a VR (my >assumption of course). >I agree that the protocol *should* be part of the index, but with 255 >VRs per LAN, I'd vote for less complexity by not having it as part of >the index with the requirement that you don't reuse VRs for different >protocols on the same LAN. If we feel that we can't do this, I'd say >forget the whole thing because I wouldn't want to burden the majority of >VRRP usage and implementation with another index parameter. I would agree with Scott's comments as shown above. Originally (as first proposed), this object was relatively transparent with respect to the VRRP MIB. Which was o.k., because (as has been pointed out), the implications of a "vrrpOperProtocol" object go beyond the scope of the VRRP draft. If this object becomes an index into the vrrpOperTable, it takes on a whole new significance which, in my mind, is difficult to justify for an area that has not been addressed in the VRRP Spec. This would mean that every net management application that wishes to obtain information from the VRRP MIB suddenly has to be aware of a new attribute about a virtual router. If and when VRRP is expanded to incorporate other protocols, my guess is that the MIB will be substantially different as to require a new MIB RFC. Thanks. -Brian Jewell -3Com, Inc. ------------- End Forwarded Message ------------- From VRRP-owner@drcoffsite.com Fri Apr 24 12:23:53 1998 Delivery-Date: Fri, 24 Apr 1998 12:23:54 -0400 Return-Path: VRRP-owner@drcoffsite.com Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.5/8.8.7a) with ESMTP id MAA17556 for ; Fri, 24 Apr 1998 12:23:52 -0400 (EDT) Received: from drcoffsite.com ([209.150.7.1]) by cnri.reston.va.us (8.8.5/8.8.7a) with SMTP id MAA22428 for ; Fri, 24 Apr 1998 12:26:14 -0400 (EDT) Received: from mailhost.iprg.nokia.com [205.226.5.12] by drcoffsite.com with ESMTP (SMTPD32-4.04) id A9F315EF0226; Fri, 24 Apr 1998 12:12:35 +03d00 Received: from spruce.iprg.nokia.com (spruce.iprg.nokia.com [205.226.1.63]) by mailhost.iprg.nokia.com (8.8.7/8.6.10) with SMTP id JAA17437; Fri, 24 Apr 1998 09:10:35 -0700 (PDT) Message-Id: <3.0.5.32.19980424090935.009b38e0@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Fri, 24 Apr 1998 09:09:35 -0700 To: minutes@ns.ietf.org From: Bob Hinden Subject: VRRP W.G. Minutes / Los Angeles IETF Cc: vrrp@drcoffsite.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Precedence: bulk Sender: VRRP-owner@drcoffsite.com IETF VRRP Working Group Meeting April 1, 1998 Los Angeles IETF -------------------------------- Robert Hinden / Nokia, Chair Minutes taken by Joe Eykholt / Nokia Agenda: Agenda Bashing Status Intellectual Property Issues Review of VRRP MIB Draft VRRP for IPv6 Status IESG advanced VRRP to Proposed Standard on 18 Mar 1998, based on Draft 6. Intellectual Property Issues: Two patents that may have impact on VRRP are: cisco: Standby Routing Protocol, 5,473,599, December 5, 1995. IBM: Cluster patent, 5,371,852. Patent info available via http://womplex.ibm.com/patent Martin McNealus (sp?) from cisco said a few words about the cisco patent. cisco claims VRRP infringes on the HSRP patent. Since HSRP was submitted to the working group, to standardize VRRP instead of HSRP would be an attempt to compromise patent rights. [Note: Patents are public and there is no issue with standards documents infringing on patents. Infringement occurs when patented idea are included in shipping products] Q. Would cisco license the patent to implementors of HSRP and/or VRRP? A. HSRP yes, VRRP no. Comments from others: The IBM patent may have precedence. Both patents may apply separately. cisco contacts for patent issues are Martin McNealus (sp?), Robert Barr (sp?) and Steve Gordon (sp?). VRRP MIB - Brian Jewel, 3COM Feedback from the December IETF and e-mail list has been incorporated into the Rev 01 draft. Fred Baker is assisting the MIB doc as the IETF official MIB representative. Additional feedback has been incorporated into the Rev 02 draft. Q. Some fields are per-interface (not per-interface AND per VRID), for example the authentication method and key, but are described by the MIB as per-interface and per VRID. This could result in a conflict in settings. How should this be resolved? Discussion: Q. Are there any other fields similar to this in other MIBS. A. There's a similar object in RFC 2275 (SNMP V3 security). Q. Do these have to be in the MIB or not? Q. Make it read-only instead of read-create? Comment: Another MIB can be obtained. Comment: OK to put this in by ifindex/VRid. It was requested that specific suggestions be posted to the list. Q. Why would the major key be the ifindex and the minor key be the VRID instead of the other way around? A. The VRID has to be unique on a link, but it's possible to have the same VRID on different interfaces. Q. What was the reason for not indexing by IP address for the vrrpAssoIpAddrEntry table. [indexed by { ifIndex, vrrpOperVrId, vrrpAssoIpAddrIndex }]. Danny Mitzel, Nokia, agreed with using the IP address - "it makes row creation clearer" Brian said this is addressed in other MIBs (RFC 1903) and is a common problem in other MIBs. He'll consider and may post something to the mailing list. Comment: in this case IPaddress will make the row unique. The group was asked if there were any objections to making this change. There were none. Brian said the 02 revision should be done in a month or so. Will incorporate any input received. IPv6 changes for VRRP. Suggestion: Test with two IPv6 routers, cranking down the router advertisement frequency to see if a solution is needed. Hosts should switch when one router dies. If times are too long, we could change IPv6 or do something with VRRP for IPv6. It'd be nice not to need VRRP for IPv6. ----------------------------------------------------------------- From VRRP-owner@drcoffsite.com Wed Apr 29 11:45:55 1998 Delivery-Date: Wed, 29 Apr 1998 11:45:55 -0400 Return-Path: VRRP-owner@drcoffsite.com Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id LAA18022 for ; Wed, 29 Apr 1998 11:45:54 -0400 (EDT) Received: from drcoffsite.com (gw.drcoffsite.com [209.150.7.1]) by cnri.reston.va.us (8.8.5/8.8.7a) with SMTP id LAA12597 for ; Wed, 29 Apr 1998 11:48:19 -0400 (EDT) Message-Id: <199804291548.LAA12597@cnri.reston.va.us> Received: from joshua.drcoffsite.com [209.150.7.12] by drcoffsite.com (SMTPD32-4.04) id A73722FA03E0; Wed, 29 Apr 1998 11:28:55 +03d00 Received: from server.ethan1223.cml2.com [209.160.21.245] by joshua.drcoffsite.com (SMTPD32-4.04) id A2423100C2; Wed, 29 Apr 1998 08:51:14 EST Date: Wed, 29 Apr 1998 04:54:14 From: To: Subject: Get 400 Search Engines, $5.75(1) Precedence: bulk Sender: VRRP-owner@drcoffsite.com *** $5.75 *** Limited Time Special Offer For Only $5.75 We Will Submit Your Web Site To 400 Of The Net's Hottest Search Engines & Directories...(1) * Over 90% of Internet Users Use Search Engines To Find Products & Services. If You're Not In Them, They Can't Find You. * Immediately Increase Your Sites Exposure * Get Noticed By Your Prospects http://www.tiffiny.com/sitesubmissions Note: (1) Visit our web site for details. Minimum term requirement, prepaid. ====================================== We honor any name removal requests. Please resond to; TO: webmaster@tiffiny.com SUB: remove ====================================== From VRRP-owner@drcoffsite.com Fri May 1 15:01:09 1998 Delivery-Date: Fri, 01 May 1998 15:01:09 -0400 Return-Path: VRRP-owner@drcoffsite.com Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id PAA09276 for ; Fri, 1 May 1998 15:01:00 -0400 (EDT) Received: from drcoffsite.com (gw.drcoffsite.com [209.150.7.1]) by cnri.reston.va.us (8.8.5/8.8.7a) with SMTP id PAA22142 for ; Fri, 1 May 1998 15:03:26 -0400 (EDT) Received: from mailhost.iprg.nokia.com [205.226.5.12] by drcoffsite.com with ESMTP (SMTPD32-4.04) id A7EC6BB40070; Fri, 01 May 1998 14:43:56 +03d00 Received: from spruce.iprg.nokia.com (Ihinden-3.iprg.nokia.com [205.226.22.76]) by mailhost.iprg.nokia.com (8.8.7/8.6.10) with SMTP id LAA17259 for ; Fri, 1 May 1998 11:42:25 -0700 (PDT) Message-Id: <3.0.5.32.19980501114045.00981b10@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Fri, 01 May 1998 11:40:45 -0700 To: vrrp@drcoffsite.com From: RFC Editor (by way of Bob Hinden ) Subject: RFC 2338 on VRRP Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Precedence: bulk Sender: VRRP-owner@drcoffsite.com A new Request for Comments is now available in online RFC libraries. RFC 2338: Title: Virtual Router Redundancy Protocol Author(s): S. Knight, D. Weaver, D. Whipple, R. Hinden, D. Mitzel, P. Hunt, P. Higginson, M. Shand, A. Lindem Status: Proposed Standard Date: April 1998 Mailbox: Steven.Knight@ascend.com, Doug.Weaver@ascend.com, dwhipple@microsoft.com, hinden@iprg.nokia.com, mitzel@iprg.nokia.com, hunt@iprg.nokia.com, higginson@mail.dec.com, shand@mail.dec.com, acee@raleigh.ibm.com Pages: 27 Characters: 59871 Updates/Obsoletes: None URL: ftp://ftp.isi.edu/in-notes/rfc2338.txt This memo defines the Virtual Router Redundancy Protocol (VRRP). VRRP specifies an election protocol that dynamically assigns responsibility for a virtual router to one of the VRRP routers on a LAN. The VRRP router controlling the IP address(es) associated with a virtual router is called the Master, and forwards packets sent to these IP addresses. The election process provides dynamic fail over in the forwarding responsibility should the Master become unavailable. This allows any of the virtual router IP addresses on the LAN to be used as the default first hop router by end-hosts. The advantage gained from using VRRP is a higher availability default path without requiring configuration of dynamic routing or router discovery protocols on every end-host. This document is a product of the Virtual Router Redundancy Protocol Working Group of the IETF. This is now a Proposed Standard Protocol. This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@ISI.EDU. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@ISI.EDU with the message body help: ways_to_get_rfcs. For example: To: rfc-info@ISI.EDU Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@ISI.EDU. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to RFC-EDITOR@ISI.EDU. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Alegre Ramos USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. Content-Type: text/plain Content-ID: <980501083814.RFC@ISI.EDU> RETRIEVE: rfc DOC-ID: rfc2338 From VRRP-owner@drcoffsite.com Sun May 3 21:39:35 1998 Delivery-Date: Sun, 03 May 1998 21:39:36 -0400 Return-Path: VRRP-owner@drcoffsite.com Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id VAA09678 for ; Sun, 3 May 1998 21:39:30 -0400 (EDT) Received: from drcoffsite.com (gw.drcoffsite.com [209.150.7.1]) by cnri.reston.va.us (8.8.5/8.8.7a) with SMTP id VAA01386 for ; Sun, 3 May 1998 21:41:52 -0400 (EDT) Received: from mpdr0.detroit.mi.ameritech.net [206.141.239.206] by drcoffsite.com with ESMTP (SMTPD32-4.04) id AA273C0503E0; Sun, 03 May 1998 21:30:15 +03d00 Received: from ameritech.net ([206.141.224.103]) by mpdr0.detroit.mi.ameritech.net (InterMail v03.02.01 118 111) with ESMTP id <19980504022746.FNDR14564@ameritech.net> for ; Sun, 3 May 1998 21:27:46 -0500 Message-ID: <354D1959.AC4D404E@ameritech.net> Date: Sun, 03 May 1998 21:26:49 -0400 From: Rob Montgomery Reply-To: robm@null.net X-Mailer: Mozilla 4.03 [en] (Win95; U) MIME-Version: 1.0 To: VRRP Mailing List Subject: VRRP support on Multi-access LAN's. Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Precedence: bulk Sender: VRRP-owner@drcoffsite.com Hi, At the risk of beating a dead horse, are there any plans, or is there any desire, to expand support for VRRP to all multi-access LAN technologies? In the VRRP document, the issues surrounding Token Ring are well documented, and there are also issues in ATM deployment (LANE environments). -Rob From VRRP-owner@drcoffsite.com Fri May 22 02:05:08 1998 Delivery-Date: Fri, 22 May 1998 02:05:08 -0400 Return-Path: VRRP-owner@drcoffsite.com Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id CAA00269 for ; Fri, 22 May 1998 02:05:06 -0400 (EDT) Received: from drcoffsite.com (gw.drcoffsite.com [209.150.7.1]) by cnri.reston.va.us (8.8.5/8.8.7a) with SMTP id CAA19707 for ; Fri, 22 May 1998 02:07:21 -0400 (EDT) Received: from fsnt.future.futsoft.com [38.242.192.5] by drcoffsite.com with ESMTP (SMTPD32-4.04) id A25949970228; Fri, 22 May 1998 01:51:21 +03d00 Received: from kailash.future.futsoft.com (unverified [38.242.192.4]) by fsnt.future.futsoft.com (Integralis SMTPRS 2.04) with ESMTP id ; Fri, 22 May 1998 11:14:28 +0530 Received: from msgate.future.futsoft.com (msgate.future.futsoft.com [10.0.8.4]) by kailash.future.futsoft.com (8.7.1/8.7.1) with SMTP id LAA18018 for ; Fri, 22 May 1998 11:04:29 +0530 Received: by msgate.future.futsoft.com with Microsoft Mail id <3565C173@msgate.future.futsoft.com>; Fri, 22 May 98 11:18:27 PDT From: basila To: "'vrrp'" Subject: Doubt Date: Fri, 22 May 98 11:18:00 PDT Message-Id: <3565C173@msgate.future.futsoft.com> Encoding: 95 TEXT X-Mailer: Microsoft Mail V3.0 Precedence: bulk Sender: VRRP-owner@drcoffsite.com Hi, I have the following doubt regarding the VRRP operation: Consider the following topology: +-----+ | | (IP C) | H3 | | | +--+--+ | | Network C -----------------+------------------ | | +--+--+ | | | VR3 | | | +-----+ -- / \ /---- ----\ | IP | \____ ____/ \ / -- +--+--+ +--+--+ | | | | | VR1 | | VR2 | | | | | +--+--+ +--+--+ | | | | ----+--+--------------------+--+---- Network A | | Network B | | +--+--+ +--+--+ | | | | (IP A) | H1 | | H2 | (IP B) | | | | +-----+ +-----+ Assumptions: VR1, VR2 and VR3 are Virtual routers connected by IP network. VR2 is backing up VR1. H1, H2 and H3 are hosts connected through VRRP routers Problem Description: Let's consider a scenario where there is a active FTP session between H1 and H3 through Virtual routers VR1 <-> VR3. When virtual router VR1 is down, its forwarding responsibility should be taken over by VR2. So the FTP session between H1 and H3 should be through VR2<->VR3. But the information about forwarding responsibility changeover between VR1 and VR2 is not available VR3. Since this information is not available with VR3, it will route the packets to VR1 where the packets will get dropped, as it is in backup state now. To avoid this situation, the information about the forwarding responsibility changeover between VR1 and VR2 should be made available to VR3. Doubt: In this case, do the VRRP need to have control over the routing protocol so that the routing updates are appropriately sent when there is a transition within VRRP? In the abovementioned scenario, VR1 should send routing update specifying Network A is unreachable through VR1 when it transits to backup. Similarly VR2 should send a routing update specifying its reachability to Network A when it transits to master. I would appreciate if someone in the mailing list could help me in clarifying this doubt. Regards Basil /*-----------------------------------------------------------*/ R. Anton Basil Future Software Private Limited. 480-481, Anna Salai, Nandanam, Chennai - 600 035, INDIA. Tel : +91-44-4330550 Fax : +91-44-4344157, 4834551, 4834661 email : basila@future.futsoft.com /*-----------------------------------------------------------*/ From VRRP-owner@drcoffsite.com Fri May 22 10:17:38 1998 Delivery-Date: Fri, 22 May 1998 10:17:39 -0400 Return-Path: VRRP-owner@drcoffsite.com Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id KAA03781 for ; Fri, 22 May 1998 10:17:38 -0400 (EDT) Received: from drcoffsite.com (gw.drcoffsite.com [209.150.7.1]) by cnri.reston.va.us (8.8.5/8.8.7a) with SMTP id KAA20482 for ; Fri, 22 May 1998 10:20:01 -0400 (EDT) Received: from fwns2.raleigh.ibm.com [204.146.167.236] by drcoffsite.com with ESMTP (SMTPD32-4.04) id A80B1DA018E; Fri, 22 May 1998 10:13:31 +03d00 Received: from rtpmail01.raleigh.ibm.com (rtpmail01.raleigh.ibm.com [9.37.172.24]) by fwns2.raleigh.ibm.com (AIX4.2/UCB 8.7/8.7RTP-FW1.1) with ESMTP id KAA08380; Fri, 22 May 1998 10:11:29 -0400 (EDT) Received: from aceman.raleigh.ibm.com (aceman.raleigh.ibm.com [9.37.177.119]) by rtpmail01.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id KAA23980; Fri, 22 May 1998 10:11:32 -0400 Received: from loopback by aceman.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA21806; Fri, 22 May 1998 10:11:32 -0400 X-Sender: acee@raleigh.ibm.com Message-Id: <35658793.B0B31751@raleigh.ibm.com> Date: Fri, 22 May 1998 10:11:31 -0400 From: Acee Lindem Organization: IBM Networking Divison X-Mailer: Mozilla 4.04 [en] (X11; I; AIX 4.1) Mime-Version: 1.0 To: basila Cc: "'vrrp'" Subject: Re: Doubt References: <3565C173@msgate.future.futsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Precedence: bulk Sender: VRRP-owner@drcoffsite.com basila wrote: Pruned o o > > > Problem Description: > Let's consider a scenario where there is a active FTP session > between H1 and H3 through Virtual routers VR1 <-> VR3. When > virtual router VR1 is down, its forwarding responsibility > should be taken over by VR2. So the FTP session between H1 and > H3 should be through VR2<->VR3. > > But the information about forwarding responsibility changeover > between VR1 and VR2 is not available VR3. Since this information > is not available with VR3, it will route the packets to VR1 > where the packets will get dropped, as it is in backup state now. > To avoid this situation, the information about the forwarding > responsibility changeover between VR1 and VR2 should be made > available to VR3. Anton, VRRP's primary goal is to provide transparent default gateway backup for hosts. It is not meant to be routing protocol - use RIP or OSPF between routers VR1, VR2, VR3. Let's take this a step further - if the VR1 connection to VR3 goes down but it is still active on the LAN with the H1, you will need to run an IGP (e.g., RIP or OSPF) on the LAN with VRRP so that VR1 has the correct routes and can send redirects to hosts using it as a default gateway. -- Acee From VRRP-owner@drcoffsite.com Fri May 22 12:49:49 1998 Delivery-Date: Fri, 22 May 1998 12:49:49 -0400 Return-Path: VRRP-owner@drcoffsite.com Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id MAA06529 for ; Fri, 22 May 1998 12:49:48 -0400 (EDT) Received: from drcoffsite.com (gw.drcoffsite.com [209.150.7.1]) by cnri.reston.va.us (8.8.5/8.8.7a) with SMTP id MAA21529 for ; Fri, 22 May 1998 12:52:10 -0400 (EDT) Received: from alink.net [207.135.127.68] by drcoffsite.com with ESMTP (SMTPD32-4.04) id AC316DA0184; Fri, 22 May 1998 12:47:45 +03d00 Received: from yagosys.com (mail.yagosys.com [207.135.89.130]) by alink.net (8.8.8/8.8.8) with SMTP id JAA03488 for ; Fri, 22 May 1998 09:46:16 -0700 (PDT) Received: from macondo.yagosys.com by yagosys.com (SMI-8.6/SMI-SVR4) id JAA02561; Fri, 22 May 1998 09:46:09 -0700 Received: from macondo by macondo.yagosys.com (SMI-8.6/SMI-SVR4) id JAA02830; Fri, 22 May 1998 09:46:15 -0700 X-Sender: jsanchez@yagosys.com Message-ID: <3565ABD7.604B@yagosys.com> Date: Fri, 22 May 1998 09:46:15 -0700 From: "Juan D. Sánchez" X-Mailer: Mozilla 3.01Gold (X11; U; SunOS 5.5.1 sun4u) MIME-Version: 1.0 To: vrrp@drcoffsite.com Subject: vrrp questions Content-Type: text/plain; charset=us-ascii; name="vrrp.txt" Content-Disposition: inline; filename="vrrp.txt" Content-Transfer-Encoding: 7bit Precedence: bulk Sender: VRRP-owner@drcoffsite.com Hello, I just joined the VRRP mailing list and have a couple of questions. - Is there a VRRP FAQ document and/or a mail archive ? - I received a copy of the April/LA working group minutes and was wondering if there's any new information regarding the cisco and IBM patents issue. Have any other vendors also decided to continue with their VRRP development effort ? Thanks in advance for your replies. Juan D. Sanchez YAGO Systems From VRRP-owner@drcoffsite.com Fri May 22 17:15:06 1998 Delivery-Date: Fri, 22 May 1998 17:15:07 -0400 Return-Path: VRRP-owner@drcoffsite.com Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id RAA09823 for ; Fri, 22 May 1998 17:15:02 -0400 (EDT) Received: from drcoffsite.com (gw.drcoffsite.com [209.150.7.1]) by cnri.reston.va.us (8.8.5/8.8.7a) with SMTP id RAA22597 for ; Fri, 22 May 1998 17:17:26 -0400 (EDT) Received: from fwns2.raleigh.ibm.com [204.146.167.236] by drcoffsite.com with ESMTP (SMTPD32-4.04) id AA72181E0186; Fri, 22 May 1998 17:13:22 +03d00 Received: from rtpmail01.raleigh.ibm.com (rtpmail01.raleigh.ibm.com [9.37.172.24]) by fwns2.raleigh.ibm.com (AIX4.2/UCB 8.7/8.7RTP-FW1.1) with ESMTP id RAA22368; Fri, 22 May 1998 17:10:35 -0400 (EDT) Received: from aceman.raleigh.ibm.com (aceman.raleigh.ibm.com [9.37.177.119]) by rtpmail01.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id RAA61548; Fri, 22 May 1998 17:10:36 -0400 Received: from loopback by aceman.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA27414; Fri, 22 May 1998 17:10:29 -0400 X-Sender: acee@raleigh.ibm.com Message-Id: <3565E9C4.28698A6C@raleigh.ibm.com> Date: Fri, 22 May 1998 17:10:28 -0400 From: Acee Lindem Organization: IBM Networking Divison X-Mailer: Mozilla 4.04 [en] (X11; I; AIX 4.1) Mime-Version: 1.0 To: "Juan D. Sánchez" Cc: vrrp@drcoffsite.com Subject: Re: vrrp questions References: <3565ABD7.604B@yagosys.com> Content-Type: text/plain; charset=iso-8859-1 Precedence: bulk Sender: VRRP-owner@drcoffsite.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id RAA09823 Juan D. Sánchez wrote: > > Hello, > > I just joined the VRRP mailing list and have a couple of questions. > > - Is there a VRRP FAQ document and/or a mail archive ? > - I received a copy of the April/LA working group minutes and was > wondering if there's any new information regarding the cisco and IBM > patents issue. Have any other vendors also decided to continue with > their VRRP development effort ? We are shipping VRRP on our small and mid-range routers within the next couple months. See http://www.networking.ibm.com/220/220prod.html for more information. I'm sorry but I can't address questions on IBM's patent claim. See http://www.ietf.org/ipr.html for more information. -- Acee From VRRP-owner@drcoffsite.com Sat May 23 00:57:18 1998 Delivery-Date: Sat, 23 May 1998 00:57:18 -0400 Return-Path: VRRP-owner@drcoffsite.com Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id AAA18311 for ; Sat, 23 May 1998 00:57:07 -0400 (EDT) Received: from drcoffsite.com (gw.drcoffsite.com [209.150.7.1]) by cnri.reston.va.us (8.8.5/8.8.7a) with SMTP id AAA23464 for ; Sat, 23 May 1998 00:59:31 -0400 (EDT) Received: from fsnt.future.futsoft.com [38.242.192.5] by drcoffsite.com with ESMTP (SMTPD32-4.04) id A5F2FC0054; Sat, 23 May 1998 00:52:02 +03d00 Received: from kailash.future.futsoft.com (unverified [38.242.192.4]) by fsnt.future.futsoft.com (Integralis SMTPRS 2.04) with ESMTP id ; Sat, 23 May 1998 10:15:17 +0530 Received: from msgate.future.futsoft.com (msgate.future.futsoft.com [10.0.8.4]) by kailash.future.futsoft.com (8.7.1/8.7.1) with SMTP id KAA28287; Sat, 23 May 1998 10:05:57 +0530 Received: by msgate.future.futsoft.com with Microsoft Mail id <3567051F@msgate.future.futsoft.com>; Sat, 23 May 98 10:19:27 PDT From: basila To: Acee Lindem , basila Cc: "'vrrp'" Subject: RE: Doubt Date: Sat, 23 May 98 10:06:00 PDT Message-Id: <3567051F@msgate.future.futsoft.com> Encoding: 125 TEXT X-Mailer: Microsoft Mail V3.0 Precedence: bulk Sender: VRRP-owner@drcoffsite.com Acee, Thanks for the immediate response. As you said, VRRP is for providing transparent gateway for the hosts. But still this is the VRRP operational issue which we have to take care while deploying VRRP routers in the network. Let me put forward my doubt in a better way. In the following topology (same depicted in my previous mail): +-----+ | | (IP C) | H3 | | | +--+--+ | | Network C -----------------+------------------ | | +--+--+ | | | VR3 | | | +-----+ -- / \ /---- ----\ | IP | \____ ____/ \ / -- +--+--+ +--+--+ | | | | | VR1 | | VR2 | | | | | +--+--+ +--+--+ | | | | ----+--+--------------------+--+---- Network A | | Network B | | +--+--+ +--+--+ | | | | (IP A) | H1 | | H2 | (IP B) | | | | +-----+ +-----+ Assumptions: VR1, VR2 and VR3 are Virtual routers connected by IP network. H1, H2 and H3 are hosts connected through Virtual routers VR1 is master for Network A VR2 is backing up VR1 Active FTP session is going on between H1 and H3 through VR1<->VR3 In the abovementioned topology, VR1 becomes backup from master because of coming up of VR2, which has higher priority. Therefore there is a forwarding responsibility for "Network A" from VR1 to VR2 (i.e.. VR1 becoming backup and VR2 becoming master). But this is not known to VR3. VR3 will still sends the data to VR1 which is intended H1 (Network A). VR1 is in backup state now so it will discard the data. To avoid this, there should be some way of informing VR3 that the data intended H1 (Network A) should be sent to VR2. Now coming back to my doubt, how do I inform VR3 about the forwarding responsibility change between VR1 and VR2? In other words, how do I inform VR3 that the data intended for H1 (Network A) should be sent to VR2 instead of VR1? Hope my doubts are somewhat clear now. Looking for your reply. Regards, Basil -----Original Message----- From: Acee Lindem [SMTP:acee@raleigh.ibm.com] Sent: Friday, May 22, 1998 10:12 AM To: basila Cc: 'vrrp' Subject: Re: Doubt basila wrote: Pruned o o > > > Problem Description: > Let's consider a scenario where there is a active FTP session > between H1 and H3 through Virtual routers VR1 <-> VR3. When > virtual router VR1 is down, its forwarding responsibility > should be taken over by VR2. So the FTP session between H1 and > H3 should be through VR2<->VR3. > > But the information about forwarding responsibility changeover > between VR1 and VR2 is not available VR3. Since this information > is not available with VR3, it will route the packets to VR1 > where the packets will get dropped, as it is in backup state now. > To avoid this situation, the information about the forwarding > responsibility changeover between VR1 and VR2 should be made > available to VR3. Anton, VRRP's primary goal is to provide transparent default gateway backup for hosts. It is not meant to be routing protocol - use RIP or OSPF between routers VR1, VR2, VR3. Let's take this a step further - if the VR1 connection to VR3 goes down but it is still active on the LAN with the H1, you will need to run an IGP (e.g., RIP or OSPF) on the LAN with VRRP so that VR1 has the correct routes and can send redirects to hosts using it as a default gateway. -- Acee From VRRP-owner@drcoffsite.com Sun May 24 11:05:58 1998 Delivery-Date: Sun, 24 May 1998 11:06:04 -0400 Return-Path: VRRP-owner@drcoffsite.com Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id LAA05747 for ; Sun, 24 May 1998 11:05:53 -0400 (EDT) Received: from drcoffsite.com (gw.drcoffsite.com [209.150.7.1]) by cnri.reston.va.us (8.8.5/8.8.7a) with SMTP id LAA00528 for ; Sun, 24 May 1998 11:08:16 -0400 (EDT) Received: from warp.lannet.com [194.90.94.231] by drcoffsite.com with ESMTP (SMTPD32-4.04) id A570391D023E; Sun, 24 May 1998 10:57:52 +03d00 Received: from smtplink.lannet.com ([149.49.50.110]) by warp.lannet.com (8.8.8/8.8.8) with SMTP id RAA19016 for ; Sun, 24 May 1998 17:50:55 +0300 (IDT) Received: from Connect2 Message Router by smtplink.lannet.com via Connect2-SMTP 4.00; Sun, 24 May 98 17:56:44 -0500 Message-ID: <504C683501660C00@smtplink.lannet.com> In-Reply-To: <692F683501660C00> Date: Sun, 24 May 98 17:56:40 +0300 From: "Benny rodrig DVP-TA" X-Sender: "Benny rodrig DVP-TA" Organization: LANNET LTD To: basila@future.futsoft.com (basila) Cc: vrrp@drcoffsite.com ("'vrrp'") Subject: RE: Doubt MIME-Version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7BIT X-mailer: Connect2-SMTP 4.00 MHS to SMTP Gateway Precedence: bulk Sender: VRRP-owner@drcoffsite.com Basil, > VR3 will still sends the data to VR1 which is intended H1 (Network A). > VR1 is in backup state now so it will discard the data. No, I don't think it will discard the data. The backup state applies only to traffic received from network A. It does not effect the forwarding of packets from other interfaces to network A. >To avoid this, there should be some way of informing VR3 that the data > intended H1 (Network A) should be sent to VR2. As Acee said, this is the job of the routing protocol. But routing will not necessarily change, VR3 may well continue to route to network A via VR1, while traffic from H1 goes via VR2. Routing does not have to be symetric. Benny From VRRP-owner@drcoffsite.com Thu May 28 00:11:47 1998 Delivery-Date: Thu, 28 May 1998 00:11:47 -0400 Return-Path: VRRP-owner@drcoffsite.com Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id AAA20057 for ; Thu, 28 May 1998 00:11:46 -0400 (EDT) Received: from drcoffsite.com (gw.drcoffsite.com [209.150.7.1]) by cnri.reston.va.us (8.8.5/8.8.7a) with SMTP id AAA14170 for ; Thu, 28 May 1998 00:14:07 -0400 (EDT) Received: from out2.ibm.net [165.87.194.229] by drcoffsite.com with ESMTP (SMTPD32-4.04) id A1D51AC0396; Thu, 28 May 1998 00:02:29 +03d00 Received: from cigi.com (slip129-37-113-30.ny.us.ibm.net [129.37.113.30]) by out2.ibm.net (8.8.5/8.6.9) with SMTP id EAA61318 for ; Thu, 28 May 1998 04:01:03 GMT Date: Thu, 28 May 1998 04:01:03 GMT From: info@cigi.com Message-Id: <199805280401.EAA61318@out2.ibm.net> To: vrrp@drcoffsite.com Subject: Shopping Cart - June Specials! Precedence: bulk Sender: VRRP-owner@drcoffsite.com Hello, Thought you may be interested in installing a shopping cart to help better service your customers. The shopping cart can be easily modified to suit your website. If you are interested in seeing how this works you can go to my demo shops at: http://www.webjunkie.com/tvmatters/index.html AND http://www.webjunkie.com/cashcart/index.html This cart is loaded with many features, it even comes with a built in search engine. If you would like to find out more about the carts features, you can go to: http://www.webjunkie.com/cashcart/features.html It won't cost you anything but some time and your commitment to get started. We do not ask for any payments up front, all we ask is that you meet the following requirements: 1) Your pages must be hosted on a UNIX type server. (Will work on anything but an NT server) 2) You are serious about purchasing a Shopping Cart to enhance your website. Thats it. If you meet the above requirements, and are ready to add a Shopping Cart to your website, contact us today so we can get started on your working demo. This demo will be created from your own online catalog and will be used as your templates. When you are satisfied with the performance of your working demo and are ready to transfer it over to your server, that is when we ask for payment. PRICES Shopping Cart Program, Manual, $175.00 (reg. $250.00)* and Tech Support. Shopping Cart Program, Manual, Installation and Tech Support. $325.00 (reg. $425.00)* * The discounts will only apply to carts purchased before June 31,1998. Prices will revert back to normal after that. Once we receive payment we will install the Shopping Cart on your server, or provide you with detailed instructions on how to do it yourself, the choice is yours. You will also receive your templates and instructions on how to use them. If you get stuck along the way, we offer tech support via phone or e-mail, for as long as you need it. We can setup many other cgi-scripts, such as Bulletin Boards, Live Chat, Search Engines, Auction Scripts, Classifieds, etc. If you are interested in taking your website to the "next level", or if you have any questions, please, contact me at info@cigi.com Thanks, Eric Webjunkie Productions http://www.webjunkie.com From VRRP-owner@drcoffsite.com Thu May 28 12:48:55 1998 Delivery-Date: Thu, 28 May 1998 12:48:55 -0400 Return-Path: VRRP-owner@drcoffsite.com Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id MAA03693 for ; Thu, 28 May 1998 12:48:54 -0400 (EDT) Received: from drcoffsite.com (gw.drcoffsite.com [209.150.7.1]) by cnri.reston.va.us (8.8.5/8.8.7a) with SMTP id MAA16464 for ; Thu, 28 May 1998 12:51:17 -0400 (EDT) Received: from tor.securecomputing.com [199.71.190.98] by drcoffsite.com with ESMTP (SMTPD32-4.04) id A37A89D0212; Thu, 28 May 1998 12:40:26 +03d00 Received: by janus.tor.securecomputing.com id <11650>; Thu, 28 May 1998 12:39:50 -0400 Message-Id: <98May28.123950edt.11650@janus.tor.securecomputing.com> From: "Alex Reidiboim" To: Subject: Are there any VRRP implementations available yet? Date: Thu, 28 May 1998 12:44:55 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.2106.4 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Precedence: bulk Sender: VRRP-owner@drcoffsite.com Hello folks, I was wondering if there was any VRRP implementation source code available yet ? Any help is appreciated, AR. From VRRP-owner@drcoffsite.com Tue Jun 2 19:52:07 1998 Delivery-Date: Tue, 02 Jun 1998 19:52:08 -0400 Return-Path: VRRP-owner@drcoffsite.com Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id TAA01418 for ; Tue, 2 Jun 1998 19:52:06 -0400 (EDT) Received: from drcoffsite.com (gw.drcoffsite.com [209.150.7.1]) by cnri.reston.va.us (8.8.5/8.8.7a) with SMTP id TAA11188 for ; Tue, 2 Jun 1998 19:54:24 -0400 (EDT) Received: from sol.extremenetworks.com [207.94.36.2] by drcoffsite.com with ESMTP (SMTPD32-4.04) id AE589E602D8; Tue, 02 Jun 1998 19:44:24 +03d00 Received: by SOL with Internet Mail Service (5.5.1960.3) id ; Tue, 2 Jun 1998 16:42:58 -0700 Message-ID: <8F76211F5DB3D1119F6F00A0C95A6630397820@SOL> From: Apoorva Bhatt To: "'vrrp@drcoffsite.com'" Subject: Gratuitous ARP Date: Tue, 2 Jun 1998 16:42:53 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) Content-Type: text/plain; charset="iso-8859-1" Precedence: bulk Sender: VRRP-owner@drcoffsite.com Sorry guys if this topic has already been discussed before. I am doing a collective survey and it would be great to know which endhost vendors support Gratuitous ARP and which ones do not. I got a message from Acee Lindem (Thanks to Acee!) that BSD 4.3/4.4 honors Gratuitous ARPs. If Gratuitous ARP is not supported on all platforms, then can somebody convince me why VRRP is a practical and a great implementation and not proprietary ones like Cisco's HSRP, etc. Thanks, Apoorva Bhatt From VRRP-owner@drcoffsite.com Tue Jun 2 20:04:22 1998 Delivery-Date: Tue, 02 Jun 1998 20:04:23 -0400 Return-Path: VRRP-owner@drcoffsite.com Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id UAA01510 for ; Tue, 2 Jun 1998 20:04:22 -0400 (EDT) Received: from drcoffsite.com (gw.drcoffsite.com [209.150.7.1]) by cnri.reston.va.us (8.8.5/8.8.7a) with SMTP id UAA11203 for ; Tue, 2 Jun 1998 20:06:39 -0400 (EDT) Received: from red.juniper.net [208.197.169.254] by drcoffsite.com with ESMTP (SMTPD32-4.04) id A0B4D1802CE; Tue, 02 Jun 1998 19:54:28 +03d00 Received: from chimp.juniper.net (chimp.juniper.net [208.197.169.196]) by red.juniper.net (8.8.5/8.8.5) with ESMTP id QAA17655; Tue, 2 Jun 1998 16:53:01 -0700 (PDT) Received: (from tli@localhost) by chimp.juniper.net (8.7.6/8.7.3) id QAA19398; Tue, 2 Jun 1998 16:52:51 -0700 (PDT) Date: Tue, 2 Jun 1998 16:52:51 -0700 (PDT) Message-Id: <199806022352.QAA19398@chimp.juniper.net> From: Tony Li To: abhatt@extremenetworks.com CC: vrrp@drcoffsite.com In-reply-to: <8F76211F5DB3D1119F6F00A0C95A6630397820@SOL> (message from Apoorva Bhatt on Tue, 2 Jun 1998 16:42:53 -0700) Subject: Re: Gratuitous ARP Precedence: bulk Sender: VRRP-owner@drcoffsite.com | If Gratuitous ARP is not supported on all | platforms, then can somebody convince me why VRRP is a practical and a | great implementation and not proprietary ones like Cisco's HSRP, etc. It's going to be very hard to convince you of something that isn't true. ;-) Tony From VRRP-owner@drcoffsite.com Tue Jun 2 21:00:50 1998 Delivery-Date: Tue, 02 Jun 1998 21:00:50 -0400 Return-Path: VRRP-owner@drcoffsite.com Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id VAA01715 for ; Tue, 2 Jun 1998 21:00:50 -0400 (EDT) Received: from drcoffsite.com (gw.drcoffsite.com [209.150.7.1]) by cnri.reston.va.us (8.8.5/8.8.7a) with SMTP id VAA11292 for ; Tue, 2 Jun 1998 21:03:07 -0400 (EDT) Received: from mail3-b.microsoft.com [131.107.3.123] by drcoffsite.com with ESMTP (SMTPD32-4.04) id AE50D9E0394; Tue, 02 Jun 1998 20:52:32 +03d00 Received: by mail3-b.microsoft.com with Internet Mail Service (5.5.2328.0) id ; Tue, 2 Jun 1998 17:51:07 -0700 Message-ID: <4D0A23B3F74DD111ACCD00805F31D8100666B25D@red-msg-50.dns.microsoft.com> From: David Whipple To: "'Apoorva Bhatt'" , "'vrrp@drcoffsite.com'" Subject: RE: Gratuitous ARP Date: Tue, 2 Jun 1998 17:51:05 -0700 X-Mailer: Internet Mail Service (5.5.2328.0) Precedence: bulk Sender: VRRP-owner@drcoffsite.com Gratutious ARP is supported on Windows NT, not 9X. I am not real sure about which Unix versions support it. Thanks. David Whipple. -----Original Message----- From: Apoorva Bhatt [mailto:abhatt@extremenetworks.com] Sent: Tuesday, June 02, 1998 4:43 PM To: 'vrrp@drcoffsite.com' Subject: Gratuitous ARP Sorry guys if this topic has already been discussed before. I am doing a collective survey and it would be great to know which endhost vendors support Gratuitous ARP and which ones do not. I got a message from Acee Lindem (Thanks to Acee!) that BSD 4.3/4.4 honors Gratuitous ARPs. If Gratuitous ARP is not supported on all platforms, then can somebody convince me why VRRP is a practical and a great implementation and not proprietary ones like Cisco's HSRP, etc. Thanks, Apoorva Bhatt From VRRP-owner@drcoffsite.com Tue Jun 2 21:07:19 1998 Delivery-Date: Tue, 02 Jun 1998 21:07:20 -0400 Return-Path: VRRP-owner@drcoffsite.com Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id VAA01758 for ; Tue, 2 Jun 1998 21:07:19 -0400 (EDT) Received: from drcoffsite.com (gw.drcoffsite.com [209.150.7.1]) by cnri.reston.va.us (8.8.5/8.8.7a) with SMTP id VAA11319 for ; Tue, 2 Jun 1998 21:09:40 -0400 (EDT) Received: from red.juniper.net [208.197.169.254] by drcoffsite.com with ESMTP (SMTPD32-4.04) id AFF731B0388; Tue, 02 Jun 1998 20:59:35 +03d00 Received: from chimp.juniper.net (chimp.juniper.net [208.197.169.196]) by red.juniper.net (8.8.5/8.8.5) with ESMTP id RAA20459; Tue, 2 Jun 1998 17:58:08 -0700 (PDT) Received: (from tli@localhost) by chimp.juniper.net (8.7.6/8.7.3) id RAA19555; Tue, 2 Jun 1998 17:57:57 -0700 (PDT) Date: Tue, 2 Jun 1998 17:57:57 -0700 (PDT) Message-Id: <199806030057.RAA19555@chimp.juniper.net> From: Tony Li To: dwhipple@microsoft.com CC: abhatt@extremenetworks.com, vrrp@drcoffsite.com In-reply-to: <4D0A23B3F74DD111ACCD00805F31D8100666B25D@red-msg-50.dns.microsoft.com> (message from David Whipple on Tue, 2 Jun 1998 17:51:05 -0700) Subject: Re: Gratuitous ARP Precedence: bulk Sender: VRRP-owner@drcoffsite.com | Gratutious ARP is supported on Windows NT, not 9X. I am not real sure about | which Unix versions support it. So how does that help the legacy systems that VRRP/HSRP was trying to fix? Tony From VRRP-owner@drcoffsite.com Tue Jun 2 21:34:54 1998 Delivery-Date: Tue, 02 Jun 1998 21:34:54 -0400 Return-Path: VRRP-owner@drcoffsite.com Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id VAA01836 for ; Tue, 2 Jun 1998 21:34:53 -0400 (EDT) Received: from drcoffsite.com (gw.drcoffsite.com [209.150.7.1]) by cnri.reston.va.us (8.8.5/8.8.7a) with SMTP id VAA11352 for ; Tue, 2 Jun 1998 21:37:10 -0400 (EDT) Received: from inet-imc-05.mail5-b.microsoft.com [131.107.3.121] by drcoffsite.com with ESMTP (SMTPD32-4.04) id A337F7D0394; Tue, 02 Jun 1998 21:13:27 +03d00 Received: by INET-IMC-05 with Internet Mail Service (5.5.2328.0) id ; Tue, 2 Jun 1998 18:12:06 -0700 Message-ID: <4D0A23B3F74DD111ACCD00805F31D8100666B25E@red-msg-50.dns.microsoft.com> From: David Whipple To: "'Tony Li'" Cc: abhatt@extremenetworks.com, vrrp@drcoffsite.com Subject: RE: Gratuitous ARP Date: Tue, 2 Jun 1998 18:12:04 -0700 X-Mailer: Internet Mail Service (5.5.2328.0) Precedence: bulk Sender: VRRP-owner@drcoffsite.com Tony, I think that there are actually quite a few systems which do support Gratuitous ARP which it does fix. Two examples were given (NT, and BSD 4.3/4.4). I am sure that there are many systems which do not support it, but I am not sure that VRRP was designed to fix these legacy systems. Maybe HSRP was... Thanks. David Whipple. -----Original Message----- From: Tony Li [mailto:tli@juniper.net] Sent: Tuesday, June 02, 1998 5:58 PM To: David Whipple Cc: abhatt@extremenetworks.com; vrrp@drcoffsite.com Subject: Re: Gratuitous ARP | Gratutious ARP is supported on Windows NT, not 9X. I am not real sure about | which Unix versions support it. So how does that help the legacy systems that VRRP/HSRP was trying to fix? Tony From VRRP-owner@drcoffsite.com Tue Jun 2 21:42:30 1998 Delivery-Date: Tue, 02 Jun 1998 21:42:30 -0400 Return-Path: VRRP-owner@drcoffsite.com Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id VAA01861 for ; Tue, 2 Jun 1998 21:42:29 -0400 (EDT) Received: from drcoffsite.com (gw.drcoffsite.com [209.150.7.1]) by cnri.reston.va.us (8.8.5/8.8.7a) with SMTP id VAA11368 for ; Tue, 2 Jun 1998 21:44:48 -0400 (EDT) Received: from red.juniper.net [208.197.169.254] by drcoffsite.com with ESMTP (SMTPD32-4.04) id A707115C0394; Tue, 02 Jun 1998 21:29:43 +03d00 Received: from chimp.juniper.net (chimp.juniper.net [208.197.169.196]) by red.juniper.net (8.8.5/8.8.5) with ESMTP id SAA21537; Tue, 2 Jun 1998 18:28:16 -0700 (PDT) Received: (from tli@localhost) by chimp.juniper.net (8.7.6/8.7.3) id SAA19641; Tue, 2 Jun 1998 18:28:05 -0700 (PDT) Date: Tue, 2 Jun 1998 18:28:05 -0700 (PDT) Message-Id: <199806030128.SAA19641@chimp.juniper.net> From: Tony Li To: dwhipple@microsoft.com CC: abhatt@extremenetworks.com, vrrp@drcoffsite.com In-reply-to: <4D0A23B3F74DD111ACCD00805F31D8100666B25E@red-msg-50.dns.microsoft.com> (message from David Whipple on Tue, 2 Jun 1998 18:12:04 -0700) Subject: Re: Gratuitous ARP Precedence: bulk Sender: VRRP-owner@drcoffsite.com David, I was asking about systems that do not support router discovery. New operating systems that do not support router discovery are clearly simply flawed. BSD certainly now supports router discovery. Does Win98? NT? The ENTIRE point of HSRP was to support these legacy systems. Router discovery is a clearly better solution in every respect. I won't claim to understand the technical design goals for VRRP. The non-technical ones are obvious. Tony | I think that there are actually quite a few systems which do support | Gratuitous ARP which it does fix. Two examples were given (NT, and BSD | 4.3/4.4). I am sure that there are many systems which do not support it, | but I am not sure that VRRP was designed to fix these legacy systems. Maybe | HSRP was... | | Thanks. | David Whipple. | | -----Original Message----- | From: Tony Li [mailto:tli@juniper.net] | Sent: Tuesday, June 02, 1998 5:58 PM | To: David Whipple | Cc: abhatt@extremenetworks.com; vrrp@drcoffsite.com | Subject: Re: Gratuitous ARP | | | | | Gratutious ARP is supported on Windows NT, not 9X. I am not real sure | about | | which Unix versions support it. | | So how does that help the legacy systems that VRRP/HSRP was trying to fix? | | Tony | From VRRP-owner@drcoffsite.com Tue Jun 2 21:54:45 1998 Delivery-Date: Tue, 02 Jun 1998 21:54:46 -0400 Return-Path: VRRP-owner@drcoffsite.com Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id VAA01895 for ; Tue, 2 Jun 1998 21:54:45 -0400 (EDT) Received: from drcoffsite.com (gw.drcoffsite.com [209.150.7.1]) by cnri.reston.va.us (8.8.5/8.8.7a) with SMTP id VAA11402 for ; Tue, 2 Jun 1998 21:57:02 -0400 (EDT) Received: from mail13.digital.com [192.208.46.30] by drcoffsite.com with ESMTP (SMTPD32-4.04) id A97F11EB0394; Tue, 02 Jun 1998 21:40:15 +03d00 Received: from ucxaxp.ucx.lkg.dec.com (ucxaxp.ucx.lkg.dec.com [16.20.208.53]) by mail13.digital.com (8.8.8/8.8.8/WV1.0e) with SMTP id VAA20924 for ; Tue, 2 Jun 1998 21:38:48 -0400 (EDT) Received: by ucxaxp.ucx.lkg.dec.com (UCX V4.2-21A, OpenVMS V7.1 Alpha); Tue, 2 Jun 1998 21:38:37 -0400 From: "M. T. Hollinger" To: "David Whipple" , Subject: Re: Gratuitous ARP Date: Tue, 2 Jun 1998 21:35:58 -0400 Message-ID: <01bd8e8f$f58bf6a0$cf501410@BigBrain.ucx.lkg.dec.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.71.1712.3 X-MimeOLE: Produced By Microsoft MimeOLE V4.71.1712.3 Precedence: bulk Sender: VRRP-owner@drcoffsite.com >Gratutious ARP is supported on Windows NT, not 9X. I am not real sure about >which Unix versions support it. Sorry, but I think you are mistaken. It works fine on Windows 95, and all the other legacy systems I have tried. I just did a quick test, using a Windows 95 system and two OpenVMS systems. The OpenVMS systems send out unsolicited ARP broadcasts every time you create a new interface (or add an IP address to an existing interface). I watched the output from "arp -a" in an MS-DOS window on the Windows 95 system as I created interfaces on the two OpenVMS systems, in turn, using the same IP address. The ARP cache on the Windows 95 system was immediately updated as I did this, repeated several times. In fact, the particular software product I work on (UCX) relies on other hosts updating their ARP caches upon receipt of such unsolicited broadcasts in order to support our cluster alias failover feature. Although our product has been on the market 10 years now, and has developed a large installed base, I have heard no complaints about cluster alias not working from any particular vendor's client hosts. For this reason, I have repeatedly opposed the use of a shared MAC address by VRRP. It confuses bridges and hubs, complicates troubleshooting, and makes VRRP harder to implement. I'll say it again, since the topic has arisen: there is no reason to require a shared MAC address. At most, this should be an optional provision in VRRP for those vendors who ill-advisedly wish to implement it. - Mark From VRRP-owner@drcoffsite.com Tue Jun 2 22:16:20 1998 Delivery-Date: Tue, 02 Jun 1998 22:16:22 -0400 Return-Path: VRRP-owner@drcoffsite.com Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id WAA02000 for ; Tue, 2 Jun 1998 22:16:19 -0400 (EDT) Received: from drcoffsite.com (gw.drcoffsite.com [209.150.7.1]) by cnri.reston.va.us (8.8.5/8.8.7a) with SMTP id WAA11428 for ; Tue, 2 Jun 1998 22:18:31 -0400 (EDT) Received: from mail2-b.microsoft.com [131.107.3.124] by drcoffsite.com with ESMTP (SMTPD32-4.04) id AE9E16C80378; Tue, 02 Jun 1998 22:02:06 +03d00 Received: by mail2-b.microsoft.com with Internet Mail Service (5.5.2166.0) id ; Tue, 2 Jun 1998 19:00:43 -0700 Message-ID: <4D0A23B3F74DD111ACCD00805F31D8100666B261@red-msg-50.dns.microsoft.com> From: David Whipple To: "'M. T. Hollinger'" , vrrp@drcoffsite.com Cc: "'tli@juniper.net'" Subject: RE: Gratuitous ARP Date: Tue, 2 Jun 1998 19:00:42 -0700 X-Mailer: Internet Mail Service (5.5.2166.0) Precedence: bulk Sender: VRRP-owner@drcoffsite.com Mark & Tony, I am pretty sure some versions do and some don't support both gratutious ARP, and router discovery. As you know the stack(s) certainly have been enhanced/fixed over time. However, I will get a current list of which versions of 9x/NT (with SP fixes) support both Gratutious ARP, and router discovery. I will forward the information to the group, so everyone has a complete picture. Thanks. David Whipple. -----Original Message----- From: M. T. Hollinger [mailto:myth@ucx.lkg.dec.com] Sent: Tuesday, June 02, 1998 6:36 PM To: David Whipple; vrrp@drcoffsite.com Subject: Re: Gratuitous ARP >Gratutious ARP is supported on Windows NT, not 9X. I am not real sure about >which Unix versions support it. Sorry, but I think you are mistaken. It works fine on Windows 95, and all the other legacy systems I have tried. I just did a quick test, using a Windows 95 system and two OpenVMS systems. The OpenVMS systems send out unsolicited ARP broadcasts every time you create a new interface (or add an IP address to an existing interface). I watched the output from "arp -a" in an MS-DOS window on the Windows 95 system as I created interfaces on the two OpenVMS systems, in turn, using the same IP address. The ARP cache on the Windows 95 system was immediately updated as I did this, repeated several times. In fact, the particular software product I work on (UCX) relies on other hosts updating their ARP caches upon receipt of such unsolicited broadcasts in order to support our cluster alias failover feature. Although our product has been on the market 10 years now, and has developed a large installed base, I have heard no complaints about cluster alias not working from any particular vendor's client hosts. For this reason, I have repeatedly opposed the use of a shared MAC address by VRRP. It confuses bridges and hubs, complicates troubleshooting, and makes VRRP harder to implement. I'll say it again, since the topic has arisen: there is no reason to require a shared MAC address. At most, this should be an optional provision in VRRP for those vendors who ill-advisedly wish to implement it. - Mark From VRRP-owner@drcoffsite.com Wed Jun 3 07:31:21 1998 Delivery-Date: Wed, 03 Jun 1998 07:31:22 -0400 Return-Path: VRRP-owner@drcoffsite.com Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id HAA15171 for ; Wed, 3 Jun 1998 07:31:21 -0400 (EDT) Received: from drcoffsite.com (gw.drcoffsite.com [209.150.7.1]) by cnri.reston.va.us (8.8.5/8.8.7a) with SMTP id HAA12416 for ; Wed, 3 Jun 1998 07:33:42 -0400 (EDT) Received: from mailgw3.lmco.com [192.35.35.23] by drcoffsite.com with ESMTP (SMTPD32-4.04) id A2493C20320; Wed, 03 Jun 1998 07:23:53 +03d00 Received: from emss04g01.ems.lmco.com ([166.17.13.122]) by mailgw3.lmco.com (8.8.8/8.8.8) with ESMTP id HAA21638 for ; Wed, 3 Jun 1998 07:22:32 -0400 (EDT) Received: from serling.motown.lmco.com ([129.204.6.42]) by lmco.com (PMDF V5.1-10 #20546) with ESMTP id <0ETZ00OO23LKGV@lmco.com> for vrrp@drcoffsite.com; Wed, 3 Jun 1998 07:22:32 -0400 (EDT) Received: from mtngt2kv6.motown.lmco.com (mtngt2kv6 [129.204.83.36]) by serling.motown.lmco.com (8.8.5/8.8.5) with SMTP id HAA23817 for ; Wed, 03 Jun 1998 07:22:31 -0400 (EDT) Date: Wed, 03 Jun 1998 07:28:08 -0700 From: Jeff Ostermiller Subject: Gratuitous ARP To: vrrp@drcoffsite.com Reply-to: jostermi@motown.lmco.com Message-id: <35755D78.5258@motown.lmco.com> Organization: Lockheed Martin MIME-version: 1.0 X-Mailer: Mozilla 3.0 (Win95; I; 16bit) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit Precedence: bulk Sender: VRRP-owner@drcoffsite.com Currently we have been envolved with a lot of test of gratuitous ARP at Lockheed Martin with different switch vendors, NIC manufactures, and router guys. HP-UX 10.01, 9.0x currently does not support gratuitous ARP. To get around this situation with HSRP we do not use the burned in MAC address, but instead the virtual MAC address that the routers negotiate. This is the same scheme that Bay Networks uses with HSRR, where you specify the virtual MAC address to work with the Virtual IP address for that router interface. I though VRRP could do both, negotiate a virtual or use the burned in address. Jeff -- Jeff Ostermiller Lockheed Martin Corporation GES/Computer Systems Engineering 199 Borton Landing Rd. MS 137-132 Moorestown, NJ 08057 voice: 609.722.2960 fax: 609.273.5379 Reply to mailto:jostermi@motown.lmco.com Visit the AEGIS LAN Interconnect System (ALIS) Online at https://alis.external.lmco.com/ From VRRP-owner@drcoffsite.com Wed Jun 3 13:47:55 1998 Delivery-Date: Wed, 03 Jun 1998 13:47:56 -0400 Return-Path: VRRP-owner@drcoffsite.com Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id NAA23442 for ; Wed, 3 Jun 1998 13:47:55 -0400 (EDT) Received: from drcoffsite.com (gw.drcoffsite.com [209.150.7.1]) by cnri.reston.va.us (8.8.5/8.8.7a) with SMTP id NAA14684 for ; Wed, 3 Jun 1998 13:50:12 -0400 (EDT) Received: from fwns2.raleigh.ibm.com [204.146.167.236] by drcoffsite.com with ESMTP (SMTPD32-4.04) id A86F44603C2; Wed, 03 Jun 1998 13:31:27 +03d00 Received: from rtpmail02.raleigh.ibm.com (rtpmail02.raleigh.ibm.com [9.37.172.48]) by fwns2.raleigh.ibm.com (AIX4.2/UCB 8.7/8.7RTP-FW1.1) with ESMTP id NAA05062; Wed, 3 Jun 1998 13:29:39 -0400 (EDT) Received: from aceman.raleigh.ibm.com (aceman.raleigh.ibm.com [9.37.177.119]) by rtpmail02.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id NAA27286; Wed, 3 Jun 1998 13:29:41 -0400 Received: from loopback by aceman.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA18328; Wed, 3 Jun 1998 13:29:29 -0400 X-Sender: acee@raleigh.ibm.com Message-Id: <357587F8.D97DA50C@raleigh.ibm.com> Date: Wed, 03 Jun 1998 13:29:28 -0400 From: Acee Lindem Organization: IBM Networking Divison X-Mailer: Mozilla 4.04 [en] (X11; I; AIX 4.1) Mime-Version: 1.0 To: Tony Li Cc: dwhipple@microsoft.com, abhatt@extremenetworks.com, vrrp@drcoffsite.com Subject: Re: Gratuitous ARP References: <199806030128.SAA19641@chimp.juniper.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Precedence: bulk Sender: VRRP-owner@drcoffsite.com Tony Li wrote: > > David, > > I was asking about systems that do not support router discovery. New > operating systems that do not support router discovery are clearly simply > flawed. BSD certainly now supports router discovery. Does Win98? NT? > > The ENTIRE point of HSRP was to support these legacy systems. Router > discovery is a clearly better solution in every respect. > > I won't claim to understand the technical design goals for VRRP. The > non-technical ones are obvious. VRRP supports systems which do not support gratuitous ARP just as HSRP does. The primary differences are: 1) VRRP does not require the concept of a virtual IP address. A backup router simply takes over forwarding responsibility for hosts having the master's IP address as their default gateway address. RFC 2238 explains (hopefully, clearly) what that entails. This avoids the problems associated with ICMP redirects and the virtual IP address. 2) VRRP runs on link basis rather than an IP subnet basis. Consequently, a single VRID can be used for multiple subnets on the same physical network. 3) VRRP's authentication encoding is more consistent with other protocols (e.g, RIPv2 and OSPF). However, this may be a moot point if one is using IPSEC encapsulation. -- Acee From VRRP-owner@drcoffsite.com Wed Jun 3 13:47:55 1998 Delivery-Date: Wed, 03 Jun 1998 13:47:57 -0400 Return-Path: VRRP-owner@drcoffsite.com Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id NAA23444 for ; Wed, 3 Jun 1998 13:47:55 -0400 (EDT) Received: from drcoffsite.com (gw.drcoffsite.com [209.150.7.1]) by cnri.reston.va.us (8.8.5/8.8.7a) with SMTP id NAA14685 for ; Wed, 3 Jun 1998 13:50:13 -0400 (EDT) Received: from fwns2.raleigh.ibm.com [204.146.167.236] by drcoffsite.com with ESMTP (SMTPD32-4.04) id AAB2D2803C0; Wed, 03 Jun 1998 13:41:06 +03d00 Received: from rtpmail03.raleigh.ibm.com (rtpmail03.raleigh.ibm.com [9.37.172.47]) by fwns2.raleigh.ibm.com (AIX4.2/UCB 8.7/8.7RTP-FW1.1) with ESMTP id NAA60732; Wed, 3 Jun 1998 13:39:34 -0400 (EDT) Received: from aceman.raleigh.ibm.com (aceman.raleigh.ibm.com [9.37.177.119]) by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id NAA38306; Wed, 3 Jun 1998 13:39:35 -0400 Received: from loopback by aceman.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA18344; Wed, 3 Jun 1998 13:39:35 -0400 X-Sender: acee@raleigh.ibm.com Message-Id: <35758A57.9FA6723C@raleigh.ibm.com> Date: Wed, 03 Jun 1998 13:39:35 -0400 From: Acee Lindem Organization: IBM Networking Divison X-Mailer: Mozilla 4.04 [en] (X11; I; AIX 4.1) Mime-Version: 1.0 To: jostermi@motown.lmco.com Cc: vrrp@drcoffsite.com Subject: Re: Gratuitous ARP References: <35755D78.5258@motown.lmco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Precedence: bulk Sender: VRRP-owner@drcoffsite.com Jeff Ostermiller wrote: > > Currently we have been envolved with a lot of test of gratuitous ARP at > Lockheed Martin with different switch vendors, NIC manufactures, and > router guys. HP-UX 10.01, 9.0x currently does not support gratuitous > ARP. There are also some token ring driver implementations that do not support gratuitous ARP on SRB (Source-Route Bridged) networks in order to avoid accepting a sub-optimal SRB bridge/ring path. The solution would be to always accept an ARP for a complete ARP entry if there is a MAC address change. > To get around this situation with HSRP we do not use the burned in > MAC address, but instead the virtual MAC address that the routers > negotiate. This is the same scheme that Bay Networks uses with HSRR, > where you specify the virtual MAC address to work with the Virtual IP > address for that router interface. I though VRRP could do both, > negotiate a virtual or use the burned in address. It is HSRP that has the burned-in address option. However, I think it would be a good option for VRRP as well given that some of the lower-cost LAN chip implementations do not support reception of packets for multiple MAC addresses without putting the chip in promiscuous mode. -- Acee From VRRP-owner@drcoffsite.com Wed Jun 3 13:54:53 1998 Delivery-Date: Wed, 03 Jun 1998 13:54:54 -0400 Return-Path: VRRP-owner@drcoffsite.com Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id NAA23625 for ; Wed, 3 Jun 1998 13:54:53 -0400 (EDT) Received: from drcoffsite.com (gw.drcoffsite.com [209.150.7.1]) by cnri.reston.va.us (8.8.5/8.8.7a) with SMTP id NAA14722 for ; Wed, 3 Jun 1998 13:57:09 -0400 (EDT) Received: from sol.extremenetworks.com [207.94.36.2] by drcoffsite.com with ESMTP (SMTPD32-4.04) id AC8C9BD035C; Wed, 03 Jun 1998 13:49:00 +03d00 Received: by SOL with Internet Mail Service (5.5.1960.3) id ; Wed, 3 Jun 1998 10:47:36 -0700 Message-ID: <8F76211F5DB3D1119F6F00A0C95A663039782F@SOL> From: Apoorva Bhatt To: vrrp@drcoffsite.com Subject: RE: Gratuitous ARP Date: Wed, 3 Jun 1998 10:47:34 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) Content-Type: text/plain; charset="iso-8859-1" Precedence: bulk Sender: VRRP-owner@drcoffsite.com -----Original Message----- From: Acee Lindem [SMTP:acee@raleigh.ibm.com] Sent: Wednesday, June 03, 1998 10:29 AM To: Tony Li Cc: dwhipple@microsoft.com; abhatt@extremenetworks.com; vrrp@drcoffsite.com Subject: Re: Gratuitous ARP Tony Li wrote: > > David, > > I was asking about systems that do not support router discovery. New > operating systems that do not support router discovery are clearly simply > flawed. BSD certainly now supports router discovery. Does Win98? NT? > > The ENTIRE point of HSRP was to support these legacy systems. Router > discovery is a clearly better solution in every respect. > > I won't claim to understand the technical design goals for VRRP. The > non-technical ones are obvious. VRRP supports systems which do not support gratuitous ARP just as HSRP does. The primary differences are: 1) VRRP does not require the concept of a virtual IP address. A backup router simply takes over forwarding responsibility for hosts having the master's IP address as their default gateway address. RFC 2238 explains (hopefully, clearly) what that entails. This avoids the problems associated with ICMP redirects and the virtual IP address. I didn't get it here... But the endhosts are going to send packets destined to the MacAddress of the Master Router which is down. It's going to be until after 20 minutes (max) or after reboot that the end host is going to learn of a new back-up router and thereby update its ARP cache. (Page 63, TCP/IP Illustrated Volume 1 by Stevens). If I haven't gotten your point right, then please shed more light here as to how to update the end host ARP cache entry. The problem is all endhost vendors do not comply 100% with ARP, hence the whole issue we have here... Its because of this reason, vendors have been forced to invent the hack of using multiple MacAddress which is plain ugly! To HP-UX fellas, please submit your data facts here whether HP-UX honors Gratuitous ARP or not. -Apoorva 2) VRRP runs on link basis rather than an IP subnet basis. Consequently, a single VRID can be used for multiple subnets on the same physical network. 3) VRRP's authentication encoding is more consistent with other protocols (e.g, RIPv2 and OSPF). However, this may be a moot point if one is using IPSEC encapsulation. -- Acee From VRRP-owner@drcoffsite.com Wed Jun 3 14:36:48 1998 Delivery-Date: Wed, 03 Jun 1998 14:36:48 -0400 Return-Path: VRRP-owner@drcoffsite.com Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id OAA24734 for ; Wed, 3 Jun 1998 14:36:48 -0400 (EDT) Received: from drcoffsite.com (gw.drcoffsite.com [209.150.7.1]) by cnri.reston.va.us (8.8.5/8.8.7a) with SMTP id OAA14930 for ; Wed, 3 Jun 1998 14:39:05 -0400 (EDT) Received: from fwns2.raleigh.ibm.com [204.146.167.236] by drcoffsite.com with ESMTP (SMTPD32-4.04) id A53E12B80386; Wed, 03 Jun 1998 14:26:06 +03d00 Received: from rtpmail02.raleigh.ibm.com (rtpmail02.raleigh.ibm.com [9.37.172.48]) by fwns2.raleigh.ibm.com (AIX4.2/UCB 8.7/8.7RTP-FW1.1) with ESMTP id OAA62050; Wed, 3 Jun 1998 14:24:33 -0400 (EDT) Received: from aceman.raleigh.ibm.com (aceman.raleigh.ibm.com [9.37.177.119]) by rtpmail02.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id OAA23388; Wed, 3 Jun 1998 14:24:36 -0400 Received: from loopback by aceman.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA20736; Wed, 3 Jun 1998 14:24:36 -0400 X-Sender: acee@raleigh.ibm.com Message-Id: <357594E3.9980B19C@raleigh.ibm.com> Date: Wed, 03 Jun 1998 14:24:35 -0400 From: Acee Lindem Organization: IBM Networking Divison X-Mailer: Mozilla 4.04 [en] (X11; I; AIX 4.1) Mime-Version: 1.0 To: Apoorva Bhatt Cc: vrrp@drcoffsite.com Subject: Re: Gratuitous ARP References: <8F76211F5DB3D1119F6F00A0C95A663039782F@SOL> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Precedence: bulk Sender: VRRP-owner@drcoffsite.com Apoorva Bhatt wrote: > > 1) VRRP does not require the concept of a virtual IP address. > A backup > router simply takes over forwarding responsibility for > hosts having > the master's IP address as their default gateway address. > RFC 2238 > explains (hopefully, clearly) what that entails. This > avoids the > problems associated with ICMP redirects and the virtual IP > address. > > I didn't get it here... But the endhosts are going to send > packets destined to the MacAddress of the Master Router which is down. > It's going to be until after 20 minutes (max) or after reboot that the > end host is going to learn of a new back-up router and thereby update > its ARP cache. (Page 63, TCP/IP Illustrated Volume 1 by Stevens). > If I haven't gotten your point right, then please shed more > light here as to how to update the end host ARP cache entry. Sorry for the confusion. Since both VRRP and HRSP are based on the concept of a virtual MAC, there is no problem with systems that do not support gratuitous ARP. When a route takes over forwarding responsibility for a VRID, it begins receiving packets addressed to the virtual MAC. > > The problem is all endhost vendors do not comply 100% with ARP, > hence the whole issue we have here... Its because of this reason, > vendors have been forced to invent the hack of using multiple MacAddress > which is plain ugly! It is ugly but one of the goals of VRRP was to provide a transparent redundancy mechanism for hosts. I don't think this should be changed (especially now that we've already done the work in our device drivers ;-)). However, the burned-in MAC address option is a good idea. -- Acee From VRRP-owner@drcoffsite.com Wed Jun 3 17:34:25 1998 Delivery-Date: Wed, 03 Jun 1998 17:34:25 -0400 Return-Path: VRRP-owner@drcoffsite.com Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id RAA27745 for ; Wed, 3 Jun 1998 17:34:25 -0400 (EDT) Received: from drcoffsite.com (gw.drcoffsite.com [209.150.7.1]) by cnri.reston.va.us (8.8.5/8.8.7a) with SMTP id RAA16004 for ; Wed, 3 Jun 1998 17:36:43 -0400 (EDT) Received: from mail3-b.microsoft.com [131.107.3.123] by drcoffsite.com with ESMTP (SMTPD32-4.04) id A09B26270392; Wed, 03 Jun 1998 17:31:07 +03d00 Received: by mail3-b.microsoft.com with Internet Mail Service (5.5.2328.0) id ; Wed, 3 Jun 1998 14:29:15 -0700 Message-ID: <4D0A23B3F74DD111ACCD00805F31D8100666B26A@red-msg-50.dns.microsoft.com> From: David Whipple To: "'M. T. Hollinger'" , "'tli@juniper.net'" Cc: "'vrrp@drcoffsite.com'" Subject: RE: Gratuitous ARP Date: Wed, 3 Jun 1998 14:29:12 -0700 X-Mailer: Internet Mail Service (5.5.2328.0) Precedence: bulk Sender: VRRP-owner@drcoffsite.com Mark & Tony, So here is the breakdown from our stack folks: Our various releases for both Win9X and NT have been Win95 RTM(Release to Manufacturing) Win95 SP1 Win95 OSR2 Win98 RTM NT 4.0 RTM NT 4.0 SP1 NT 4.0 SP2 NT 4.0 SP3 NT 4.0 SP4 NT 5.0 beta1 All of the above do indeed support gratuitous ARP(my mistake, I double checked with the developer). Only Win98, NT4.0 SP2 & Later, and NT 5.0 support router discovery. Thanks. David Whipple. -----Original Message----- From: David Whipple Sent: Tuesday, June 02, 1998 7:01 PM To: 'M. T. Hollinger'; vrrp@drcoffsite.com Cc: 'tli@juniper.net' Subject: RE: Gratuitous ARP Mark & Tony, I am pretty sure some versions do and some don't support both gratutious ARP, and router discovery. As you know the stack(s) certainly have been enhanced/fixed over time. However, I will get a current list of which versions of 9x/NT (with SP fixes) support both Gratutious ARP, and router discovery. I will forward the information to the group, so everyone has a complete picture. Thanks. David Whipple. -----Original Message----- From: M. T. Hollinger [mailto:myth@ucx.lkg.dec.com] Sent: Tuesday, June 02, 1998 6:36 PM To: David Whipple; vrrp@drcoffsite.com Subject: Re: Gratuitous ARP >Gratutious ARP is supported on Windows NT, not 9X. I am not real sure about >which Unix versions support it. Sorry, but I think you are mistaken. It works fine on Windows 95, and all the other legacy systems I have tried. I just did a quick test, using a Windows 95 system and two OpenVMS systems. The OpenVMS systems send out unsolicited ARP broadcasts every time you create a new interface (or add an IP address to an existing interface). I watched the output from "arp -a" in an MS-DOS window on the Windows 95 system as I created interfaces on the two OpenVMS systems, in turn, using the same IP address. The ARP cache on the Windows 95 system was immediately updated as I did this, repeated several times. In fact, the particular software product I work on (UCX) relies on other hosts updating their ARP caches upon receipt of such unsolicited broadcasts in order to support our cluster alias failover feature. Although our product has been on the market 10 years now, and has developed a large installed base, I have heard no complaints about cluster alias not working from any particular vendor's client hosts. For this reason, I have repeatedly opposed the use of a shared MAC address by VRRP. It confuses bridges and hubs, complicates troubleshooting, and makes VRRP harder to implement. I'll say it again, since the topic has arisen: there is no reason to require a shared MAC address. At most, this should be an optional provision in VRRP for those vendors who ill-advisedly wish to implement it. - Mark From VRRP-owner@drcoffsite.com Thu Jun 4 11:17:44 1998 Delivery-Date: Thu, 04 Jun 1998 11:17:44 -0400 Return-Path: VRRP-owner@drcoffsite.com Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id LAA15795 for ; Thu, 4 Jun 1998 11:17:37 -0400 (EDT) Received: from drcoffsite.com (gw.drcoffsite.com [209.150.7.1]) by cnri.reston.va.us (8.8.5/8.8.7a) with SMTP id LAA18986 for ; Thu, 4 Jun 1998 11:20:00 -0400 (EDT) Received: from mail12.digital.com [192.208.46.20] by drcoffsite.com with ESMTP (SMTPD32-4.04) id A90E20FA03F2; Thu, 04 Jun 1998 11:11:10 +03d00 Received: from muggsy.lkg.dec.com (muggsy.lkg.dec.com [16.20.32.219]) by mail12.digital.com (8.8.8/8.8.8/WV1.0e) with SMTP id LAA12335; Thu, 4 Jun 1998 11:09:42 -0400 (EDT) Received: from cei1.lkg.dec.com by muggsy.lkg.dec.com (5.65/DEC-Ultrix/4.3) with SMTP id AA23004; Thu, 4 Jun 1998 11:09:40 -0400 Received: from cei1.lkg.dec.com by cei1.lkg.dec.com; (5.65v3.2/1.1.8.2/07Jan96-0140PM) id AA12497; Thu, 4 Jun 1998 11:09:34 -0400 X-Sender: cei@lkg.dec.com Message-Id: <3576B8AD.FF6@cei1.lkg.dec.com> Date: Thu, 04 Jun 1998 11:09:33 -0400 From: Carol Iturralde X-Mailer: Mozilla 3.0Gold (X11; I; OSF1 V3.2 alpha) Mime-Version: 1.0 To: Tony Li Cc: dwhipple@microsoft.com, abhatt@extremenetworks.com, vrrp@drcoffsite.com Subject: Re: Gratuitous ARP References: <199806030057.RAA19555@chimp.juniper.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Precedence: bulk Sender: VRRP-owner@drcoffsite.com Tony: I don't see that the Gratuitous ARP 'fix'es anything with VRRP. In VRRP, when a router dies and is replaced, the new master uses the same IP:MAC binding (same IP address AND same MAC as the failed router). I conclude that the gratuitous ARP does not do any re-mapping of host's ARP entries. Carol Tony Li wrote: > > | Gratutious ARP is supported on Windows NT, not 9X. I am not real sure about > | which Unix versions support it. > > So how does that help the legacy systems that VRRP/HSRP was trying to fix? > > Tony From VRRP-owner@drcoffsite.com Thu Jun 4 14:04:14 1998 Delivery-Date: Thu, 04 Jun 1998 14:04:14 -0400 Return-Path: VRRP-owner@drcoffsite.com Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id OAA20087 for ; Thu, 4 Jun 1998 14:04:14 -0400 (EDT) Received: from drcoffsite.com (gw.drcoffsite.com [209.150.7.1]) by cnri.reston.va.us (8.8.5/8.8.7a) with SMTP id OAA20082 for ; Thu, 4 Jun 1998 14:06:29 -0400 (EDT) Received: from tor.securecomputing.com [199.71.190.98] by drcoffsite.com with ESMTP (SMTPD32-4.04) id AFCB50D603B6; Thu, 04 Jun 1998 13:56:27 +03d00 Received: by janus.tor.securecomputing.com id <11649>; Thu, 4 Jun 1998 13:56:21 -0400 From: "Alex Reidiboim" To: Subject: FW: Are there any VRRP implementations available yet? Date: Thu, 4 Jun 1998 14:01:05 -0400 Message-Id: <98Jun4.135621edt.11649@janus.tor.securecomputing.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Precedence: bulk Sender: VRRP-owner@drcoffsite.com Just a followup note. We would be interested any VRRP implementation that would save us coding time. We would also not be adverse to licensing any code. Thanks, AR. -----Original Message----- From: Alex Reidiboim [mailto:alex_reidiboim@securecomputing.com] Sent: May 28, 1998 12:45 PM To: vrrp@drcoffsite.com Subject: Are there any VRRP implementations available yet? Hello folks, I was wondering if there was any VRRP implementation source code available yet ? Any help is appreciated, AR. From VRRP-owner@drcoffsite.com Mon Jun 29 21:23:55 1998 Delivery-Date: Mon, 29 Jun 1998 21:23:56 -0400 Return-Path: VRRP-owner@drcoffsite.com Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id VAA28108 for ; Mon, 29 Jun 1998 21:23:50 -0400 (EDT) Received: from drcoffsite.com ([205.198.103.130]) by cnri.reston.va.us (8.8.5/8.8.7a) with SMTP id VAA07892 for ; Mon, 29 Jun 1998 21:25:57 -0400 (EDT) Received: from ntx [140.96.158.1] by drcoffsite.com (SMTPD32-4.06) id AC7E9F0382; Mon, 29 Jun 1998 21:16:46 +03d00 Received: by ntx; (5.65v4.0/1.3/10May95) id AA11669; Tue, 30 Jun 1998 09:16:31 +0800 Received: from oax2.ccl.itri.org.tw by mail.itri.org.tw; (5.65v4.0/1.1.8.2/10Dec96-0317PM) id AA09177; Tue, 30 Jun 1998 09:12:38 +0800 Received: from cclk400.ccl.itri.org.tw (cclk400.ccl.itri.org.tw [140.96.104.5]) by oax2.CCL.ITRI.Org.tw (8.8.5/8.8.5) with ESMTP id JAA07899 for ; Tue, 30 Jun 1998 09:14:16 +0800 (CST) Received: from CCLK400/MAILQ_K400 by cclk400.ccl.itri.org.tw (Mercury 1.21); 30 Jun 98 09:18:55 GMT+800 Received: from MAILQ_K400 by CCLK400 (Mercury 1.21); 30 Jun 98 09:18:45 GMT+800 Received: from cclk400.ccl.itri.org.tw by cclk400.ccl.itri.org.tw (Mercury 1.21) with ESMTP; 30 Jun 98 09:18:38 GMT+800 Message-Id: <35983F1D.12A3266A@cclk400.ccl.itri.org.tw> Date: Tue, 30 Jun 1998 09:27:58 +0800 From: Jen-Chi Liu X-Mailer: Mozilla 4.04 [en] (Win95; I) Mime-Version: 1.0 To: vrrp@drcoffsite.com Subject: VRRP current status??(current products/source codes??) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Precedence: bulk Sender: VRRP-owner@drcoffsite.com I know VRRP has became a RFC standard. So what is the current status?? How many products are following VRRP standard in market?? Where can I get(or buy) VRRP source codes?? Thanks a lot!! From VRRP-owner@drcoffsite.com Mon Jul 6 13:29:48 1998 Delivery-Date: Mon, 06 Jul 1998 13:29:48 -0400 Return-Path: VRRP-owner@drcoffsite.com Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id NAA25935 for ; Mon, 6 Jul 1998 13:29:47 -0400 (EDT) Received: from drcoffsite.com (dns1.drcoffsite.com [205.198.103.130]) by cnri.reston.va.us (8.8.5/8.8.7a) with SMTP id NAA04194 for ; Mon, 6 Jul 1998 13:32:06 -0400 (EDT) Received: from mailhost.iprg.nokia.com [205.226.5.12] by drcoffsite.com with ESMTP (SMTPD32-4.06) id A81575903B0; Mon, 06 Jul 1998 13:23:33 +03d00 Received: from spruce.iprg.nokia.com (spruce.iprg.nokia.com [205.226.1.63]) by mailhost.iprg.nokia.com (8.8.7/8.6.10) with SMTP id KAA04109; Mon, 6 Jul 1998 10:22:11 -0700 (PDT) Message-Id: <3.0.5.32.19980706102127.00ac0890@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Mon, 06 Jul 1998 10:21:27 -0700 To: vrrp@drcoffsite.com From: Bob Hinden Subject: Request for Agenda Items for VRRP session at Chicago IETF Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Precedence: bulk Sender: VRRP-owner@drcoffsite.com The VRRP working group will meet for one session at the Chicago IETF. It is: Tuesday, August 25 at 0900-1000 The tentative agenda is: - Finalizing VRRP MIB w/ goal of moving it to Proposed Standard - Start process of collecting implementation information in preparation for moving VRRP (RFC 2338) to Draft Standard Please me proposed agenda items including topic description and length of time required. Thanks, Bob Hinden VRRP w.g. Chair From VRRP-owner@drcoffsite.com Mon Jul 6 17:46:26 1998 Delivery-Date: Mon, 06 Jul 1998 17:46:26 -0400 Return-Path: VRRP-owner@drcoffsite.com Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id RAA01466 for ; Mon, 6 Jul 1998 17:46:26 -0400 (EDT) Received: from drcoffsite.com (dns1.drcoffsite.com [205.198.103.130]) by cnri.reston.va.us (8.8.5/8.8.7a) with SMTP id RAA05572 for ; Mon, 6 Jul 1998 17:48:47 -0400 (EDT) Received: from relay5.UU.NET [192.48.96.15] by drcoffsite.com with ESMTP (SMTPD32-4.06) id A4D93D801E0; Mon, 06 Jul 1998 17:42:49 +03d00 Received: from xedia.com by relay5.UU.NET with SMTP (peer crosschecked as: madway.xedia.com [198.202.232.199]) id QQewxi24366; Mon, 6 Jul 1998 17:41:27 -0400 (EDT) Received: from skye.xedia.com by xedia.com (4.1/SMI-4.1) id AA27438; Mon, 6 Jul 98 17:41:38 EDT Received: from skye by skye.xedia.com (SMI-8.6/SMI-SVR4) id RAA07852; Mon, 6 Jul 1998 17:41:24 -0400 X-Sender: sbarvick@xedia.com Message-Id: <35A14484.1542@xedia.com> Date: Mon, 06 Jul 1998 17:41:24 -0400 From: Scott Barvick X-Mailer: Mozilla 3.01Gold (X11; I; SunOS 5.6 sun4u) Mime-Version: 1.0 To: vrrp@drcoffsite.com Subject: Re: Request for Agenda Items for VRRP session at Chicago IETF References: <3.0.5.32.19980706102127.00ac0890@mailhost.iprg.nokia.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Precedence: bulk Sender: VRRP-owner@drcoffsite.com I believe there were several points raised on both the spec and the MIB after the last IETF. Some seemed to have been resolved and some just didn't get discussed anymore. Can we get the resolved items into new drafts and get a list of the open items that seemed to need action. Because I imagine that several implementations will be getting ready to ship soon, I'd like to get those items that might cause version problems resolved now. The TTL issue comes to mind. There were comments that it should be 1 instead of 255. Also, getting another round of the MIB that has the vrrpOperAssoIpAddrTable indexed by ifindex.vrid.ipaddress (not ipAddrIndex) and the vrrpOperProtocol field added to the vrrpOperTable as agreed (?) before Chicago would be very helpful. These were just from memory (I didn't go back through the archives) so there may be others. Scott Bob Hinden wrote: > > The VRRP working group will meet for one session at the Chicago IETF. It is: > > Tuesday, August 25 at 0900-1000 > > The tentative agenda is: > > - Finalizing VRRP MIB w/ goal of moving it to Proposed Standard > > - Start process of collecting implementation information in preparation > for moving VRRP (RFC 2338) to Draft Standard > > Please me proposed agenda items including topic description and > length of time required. > > Thanks, > > Bob Hinden > VRRP w.g. Chair -- Scott Barvick sbarvick@xedia.com (978) 952-6000 x162 From VRRP-owner@drcoffsite.com Mon Jul 6 18:13:55 1998 Delivery-Date: Mon, 06 Jul 1998 18:13:55 -0400 Return-Path: VRRP-owner@drcoffsite.com Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id SAA01779 for ; Mon, 6 Jul 1998 18:13:54 -0400 (EDT) Received: from drcoffsite.com (dns1.drcoffsite.com [205.198.103.130]) by cnri.reston.va.us (8.8.5/8.8.7a) with SMTP id SAA05701 for ; Mon, 6 Jul 1998 18:16:16 -0400 (EDT) Received: from drawbridge.ascend.com [198.4.92.1] by drcoffsite.com (SMTPD32-4.06) id ABA090026E; Mon, 06 Jul 1998 18:11:44 +03d00 Received: from ascend.com (fw-ext.ascend.com [198.4.92.5]) by drawbridge.ascend.com (8.6.12/8.6.12) with ESMTP id PAA05869; Mon, 6 Jul 1998 15:10:20 -0700 Received: from ascend.com by ascend.com (SMI-8.6/SMI-SVR4) id PAA13665; Mon, 6 Jul 1998 15:10:19 -0700 Received: from ascend.com by ascend.com id PAA24144; Mon, 6 Jul 1998 15:06:04 -0700 Message-Id: <3.0.5.32.19980706150859.00ba7dc0@darla.ascend.com> X-Sender: mhold@darla.ascend.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Mon, 06 Jul 1998 15:08:59 -0700 To: Bob Hinden From: Matt Holdrege Subject: Re: Request for Agenda Items for VRRP session at Chicago IETF Cc: vrrp@drcoffsite.com In-Reply-To: <3.0.5.32.19980706102127.00ac0890@mailhost.iprg.nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Precedence: bulk Sender: VRRP-owner@drcoffsite.com At 10:21 AM 7/6/98 -0700, Bob Hinden wrote: >The VRRP working group will meet for one session at the Chicago IETF. It is: > > Tuesday, August 25 at 0900-1000 > >The tentative agenda is: > > - Finalizing VRRP MIB w/ goal of moving it to Proposed Standard > > - Start process of collecting implementation information in preparation > for moving VRRP (RFC 2338) to Draft Standard What's the latest with IPR? Didn't Cisco send a note to this list a few months ago saying (something along the lines of) that they wouldn't allow any other company to ship VRRP? How can this move to draft standard with IPR restrictions? If anyone has more encouraging news, I'd love to hear it. From VRRP-owner@drcoffsite.com Mon Jul 6 18:33:22 1998 Delivery-Date: Mon, 06 Jul 1998 18:33:22 -0400 Return-Path: VRRP-owner@drcoffsite.com Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id SAA02001 for ; Mon, 6 Jul 1998 18:33:22 -0400 (EDT) Received: from drcoffsite.com (dns1.drcoffsite.com [205.198.103.130]) by cnri.reston.va.us (8.8.5/8.8.7a) with SMTP id SAA05757 for ; Mon, 6 Jul 1998 18:35:43 -0400 (EDT) Received: from red.juniper.net [208.197.169.254] by drcoffsite.com with ESMTP (SMTPD32-4.06) id AFF89F026E; Mon, 06 Jul 1998 18:30:16 +03d00 Received: from chimp.juniper.net (chimp.juniper.net [208.197.169.196]) by red.juniper.net (8.8.5/8.8.5) with ESMTP id PAA28112; Mon, 6 Jul 1998 15:28:25 -0700 (PDT) Received: (from tli@localhost) by chimp.juniper.net (8.7.6/8.7.3) id PAA19605; Mon, 6 Jul 1998 15:27:22 -0700 (PDT) Date: Mon, 6 Jul 1998 15:27:22 -0700 (PDT) Message-Id: <199807062227.PAA19605@chimp.juniper.net> From: Tony Li To: matt@ascend.com CC: hinden@iprg.nokia.com, vrrp@drcoffsite.com In-reply-to: <3.0.5.32.19980706150859.00ba7dc0@darla.ascend.com> (message from Matt Holdrege on Mon, 06 Jul 1998 15:08:59 -0700) Subject: Re: Request for Agenda Items for VRRP session at Chicago IETF Precedence: bulk Sender: VRRP-owner@drcoffsite.com | Didn't Cisco send a note to this list a few months ago saying (something | along the lines of) that they wouldn't allow any other company to ship | VRRP? How can this move to draft standard with IPR restrictions? More correctly: they said that they felt that a VRRP implementation would infringe on the HSRP patent. Of course, if you contact Cisco to try to get a license (for VRRP or HSRP), you get black holed. As to progressing the specification, RFC 2026, section 10.3.2 reads: 10.3.2. Standards Track Documents (A) Where any patents, patent applications, or other proprietary rights are known, or claimed, with respect to any specification on the standards track, and brought to the attention of the IESG, the IESG shall not advance the specification without including in the document a note indicating the existence of such rights, or claimed rights. Where implementations are required before advancement of a specification, only implementations that have, by statement of the implementors, taken adequate steps to comply with any such rights, or claimed rights, shall be considered for the purpose of showing the adequacy of the specification. Thus, lacking licensing, it may be difficult to demonstrate implementations. I would read this as saying that the implementors must either license or must make some convincing argument (to what audience?) that the Cisco patent is not pertinent. Tony From VRRP-owner@drcoffsite.com Mon Jul 6 18:58:18 1998 Delivery-Date: Mon, 06 Jul 1998 18:58:18 -0400 Return-Path: VRRP-owner@drcoffsite.com Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id SAA02222 for ; Mon, 6 Jul 1998 18:58:17 -0400 (EDT) Received: from drcoffsite.com (dns1.drcoffsite.com [205.198.103.130]) by cnri.reston.va.us (8.8.5/8.8.7a) with SMTP id TAA05840 for ; Mon, 6 Jul 1998 19:00:37 -0400 (EDT) Received: from fwns1.raleigh.ibm.com [204.146.167.235] by drcoffsite.com with ESMTP (SMTPD32-4.06) id A5E640401E0; Mon, 06 Jul 1998 18:55:34 +03d00 Received: from rtpmail02.raleigh.ibm.com (rtpmail02.raleigh.ibm.com [9.37.172.48]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id SAA24682; Mon, 6 Jul 1998 18:54:05 -0400 Received: from aceman.raleigh.ibm.com (aceman.raleigh.ibm.com [9.37.177.119]) by rtpmail02.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id SAA07104; Mon, 6 Jul 1998 18:54:06 -0400 Received: from loopback by aceman.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA18344; Mon, 6 Jul 1998 18:54:05 -0400 X-Sender: acee@raleigh.ibm.com Message-Id: <35A1558D.25BB6618@raleigh.ibm.com> Date: Mon, 06 Jul 1998 18:54:05 -0400 From: Acee Lindem Organization: IBM Networking Divison X-Mailer: Mozilla 4.04 [en] (X11; I; AIX 4.1) Mime-Version: 1.0 To: Tony Li Cc: matt@ascend.com, hinden@iprg.nokia.com, vrrp@drcoffsite.com Subject: Re: Request for Agenda Items for VRRP session at Chicago IETF References: <199807062227.PAA19605@chimp.juniper.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Precedence: bulk Sender: VRRP-owner@drcoffsite.com Tony Li wrote: > > | Didn't Cisco send a note to this list a few months ago saying (something > | along the lines of) that they wouldn't allow any other company to ship > | VRRP? How can this move to draft standard with IPR restrictions? > > More correctly: they said that they felt that a VRRP implementation would > infringe on the HSRP patent. > > Of course, if you contact Cisco to try to get a license (for VRRP or HSRP), > you get black holed. > > As to progressing the specification, RFC 2026, section 10.3.2 reads: > > 10.3.2. Standards Track Documents > > (A) Where any patents, patent applications, or other proprietary > rights are known, or claimed, with respect to any specification on > the standards track, and brought to the attention of the IESG, the > IESG shall not advance the specification without including in the > document a note indicating the existence of such rights, or > claimed rights. Where implementations are required before > advancement of a specification, only implementations that have, by > statement of the implementors, taken adequate steps to comply with > any such rights, or claimed rights, shall be considered for the > purpose of showing the adequacy of the specification. > > Thus, lacking licensing, it may be difficult to demonstrate > implementations. I would read this as saying that the implementors must > either license or must make some convincing argument (to what audience?) > that the Cisco patent is not pertinent. Possibly, an updated RFC is required with Cisco's claim documented. However, I'd hope the IP law issues could be debated/negotiated by the IP lawyers. -- Acee From VRRP-owner@drcoffsite.com Mon Jul 6 19:01:02 1998 Delivery-Date: Mon, 06 Jul 1998 19:01:02 -0400 Return-Path: VRRP-owner@drcoffsite.com Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id TAA02254 for ; Mon, 6 Jul 1998 19:01:01 -0400 (EDT) Received: from drcoffsite.com (dns1.drcoffsite.com [205.198.103.130]) by cnri.reston.va.us (8.8.5/8.8.7a) with SMTP id TAA05854 for ; Mon, 6 Jul 1998 19:03:21 -0400 (EDT) Received: from mailhost.iprg.nokia.com [205.226.5.12] by drcoffsite.com with ESMTP (SMTPD32-4.06) id A6C240F01E0; Mon, 06 Jul 1998 18:59:14 +03d00 Received: from spruce.iprg.nokia.com (spruce.iprg.nokia.com [205.226.1.63]) by mailhost.iprg.nokia.com (8.8.7/8.6.10) with SMTP id PAA14559; Mon, 6 Jul 1998 15:57:22 -0700 (PDT) Message-Id: <3.0.5.32.19980706155633.00a30210@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Mon, 06 Jul 1998 15:56:33 -0700 To: Matt Holdrege From: Bob Hinden Subject: Re: Request for Agenda Items for VRRP session at Chicago IETF Cc: vrrp@drcoffsite.com In-Reply-To: <3.0.5.32.19980706150859.00ba7dc0@darla.ascend.com> References: <3.0.5.32.19980706102127.00ac0890@mailhost.iprg.nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Precedence: bulk Sender: VRRP-owner@drcoffsite.com Matt, >What's the latest with IPR? Nothing new that I am aware of. Cisco and IBM have made statements regarding IPR (see minutes for more details). >Didn't Cisco send a note to this list a few months ago saying (something >along the lines of) that they wouldn't allow any other company to ship >VRRP? How can this move to draft standard with IPR restrictions? My understanding of the process is that there is no direct correlation with IPR issues and moving to Draft standard as long as the IETF procedures for moving documents to Draft standard are followed (e.g., multiple independent implementations, six months after Proposed status, etc.). I aware of one (and reasonably sure of a second) shipping VRRP product implementations and more in progress. I believe that this will meet the multiple implementation requirements for Draft. The IESG does not take a position on the merits of IPR claims. It comes down to each company considering adding a protocol to its products to evaluate the clams and decide if it thinks there is any infringement. Bob From VRRP-owner@drcoffsite.com Mon Jul 6 19:10:04 1998 Delivery-Date: Mon, 06 Jul 1998 19:10:04 -0400 Return-Path: VRRP-owner@drcoffsite.com Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id TAA02326 for ; Mon, 6 Jul 1998 19:10:04 -0400 (EDT) Received: from drcoffsite.com (dns1.drcoffsite.com [205.198.103.130]) by cnri.reston.va.us (8.8.5/8.8.7a) with SMTP id TAA05910 for ; Mon, 6 Jul 1998 19:12:22 -0400 (EDT) Received: from red.juniper.net [208.197.169.254] by drcoffsite.com with ESMTP (SMTPD32-4.06) id A8AE41801E0; Mon, 06 Jul 1998 19:07:26 +03d00 Received: from chimp.juniper.net (chimp.juniper.net [208.197.169.196]) by red.juniper.net (8.8.5/8.8.5) with ESMTP id QAA29998; Mon, 6 Jul 1998 16:05:03 -0700 (PDT) Received: (from tli@localhost) by chimp.juniper.net (8.7.6/8.7.3) id QAA19727; Mon, 6 Jul 1998 16:04:01 -0700 (PDT) Date: Mon, 6 Jul 1998 16:04:01 -0700 (PDT) Message-Id: <199807062304.QAA19727@chimp.juniper.net> From: Tony Li To: acee@raleigh.ibm.com CC: matt@ascend.com, hinden@iprg.nokia.com, vrrp@drcoffsite.com In-reply-to: <35A1558D.25BB6618@raleigh.ibm.com> (message from Acee Lindem on Mon, 06 Jul 1998 18:54:05 -0400) Subject: Re: Request for Agenda Items for VRRP session at Chicago IETF Precedence: bulk Sender: VRRP-owner@drcoffsite.com | Possibly, an updated RFC is required with Cisco's claim documented. | However, I'd hope the IP law issues could be debated/negotiated by the | IP lawyers. Acee, I don't see how either of these is relevant to satisfying RFC 2026. Tony From VRRP-owner@drcoffsite.com Mon Jul 6 19:22:29 1998 Delivery-Date: Mon, 06 Jul 1998 19:22:30 -0400 Return-Path: VRRP-owner@drcoffsite.com Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id TAA02351 for ; Mon, 6 Jul 1998 19:22:28 -0400 (EDT) Received: from drcoffsite.com (dns1.drcoffsite.com [205.198.103.130]) by cnri.reston.va.us (8.8.5/8.8.7a) with SMTP id TAA05936 for ; Mon, 6 Jul 1998 19:24:47 -0400 (EDT) Received: from fwns1.raleigh.ibm.com [204.146.167.235] by drcoffsite.com with ESMTP (SMTPD32-4.06) id AB9A42601E0; Mon, 06 Jul 1998 19:19:54 +03d00 Received: from rtpmail03.raleigh.ibm.com (rtpmail03.raleigh.ibm.com [9.37.172.47]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id TAA25950; Mon, 6 Jul 1998 19:18:23 -0400 Received: from aceman.raleigh.ibm.com (aceman.raleigh.ibm.com [9.37.177.119]) by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id TAA59568; Mon, 6 Jul 1998 19:18:25 -0400 Received: from loopback by aceman.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA19928; Mon, 6 Jul 1998 19:18:24 -0400 X-Sender: acee@raleigh.ibm.com Message-Id: <35A15B40.A4A37E30@raleigh.ibm.com> Date: Mon, 06 Jul 1998 19:18:24 -0400 From: Acee Lindem Organization: IBM Networking Divison X-Mailer: Mozilla 4.04 [en] (X11; I; AIX 4.1) Mime-Version: 1.0 To: Tony Li Cc: matt@ascend.com, hinden@iprg.nokia.com, vrrp@drcoffsite.com Subject: Re: Request for Agenda Items for VRRP session at Chicago IETF References: <199807062304.QAA19727@chimp.juniper.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Precedence: bulk Sender: VRRP-owner@drcoffsite.com Tony Li wrote: > > | Possibly, an updated RFC is required with Cisco's claim documented. > | However, I'd hope the IP law issues could be debated/negotiated by the > | IP lawyers. > > Acee, > > I don't see how either of these is relevant to satisfying RFC 2026. > -- 10.3.2. Standards Track Documents > > (A) Where any patents, patent applications, or other proprietary > rights are known, or claimed, with respect to any specification on > the standards track, and brought to the attention of the IESG, the > IESG shall not advance the specification without including in the > document a note indicating the existence of such rights, or > claimed rights. Why couldn't this be satisfied via documentation in a revision of the RFC? > Where implementations are required before > advancement of a specification, only implementations that have, by > statement of the implementors, taken adequate steps to comply with > any such rights, or claimed rights, shall be considered for the > purpose of showing the adequacy of the specification. As exemplified by your comment that the audience isn't specified, this is a rather nebulous requirement and possibly one that can best be handled by the IP lawyers, vis-a-vis, the IESG. Acee From VRRP-owner@drcoffsite.com Mon Jul 6 19:33:12 1998 Delivery-Date: Mon, 06 Jul 1998 19:33:12 -0400 Return-Path: VRRP-owner@drcoffsite.com Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id TAA02407 for ; Mon, 6 Jul 1998 19:33:11 -0400 (EDT) Received: from drcoffsite.com (dns1.drcoffsite.com [205.198.103.130]) by cnri.reston.va.us (8.8.5/8.8.7a) with SMTP id TAA05965 for ; Mon, 6 Jul 1998 19:35:29 -0400 (EDT) Received: from red.juniper.net [208.197.169.254] by drcoffsite.com with ESMTP (SMTPD32-4.06) id AE58FE0184; Mon, 06 Jul 1998 19:31:36 +03d00 Received: from chimp.juniper.net (chimp.juniper.net [208.197.169.196]) by red.juniper.net (8.8.5/8.8.5) with ESMTP id QAA01322; Mon, 6 Jul 1998 16:29:14 -0700 (PDT) Received: (from tli@localhost) by chimp.juniper.net (8.7.6/8.7.3) id QAA19828; Mon, 6 Jul 1998 16:28:11 -0700 (PDT) Date: Mon, 6 Jul 1998 16:28:11 -0700 (PDT) Message-Id: <199807062328.QAA19828@chimp.juniper.net> From: Tony Li To: acee@raleigh.ibm.com CC: matt@ascend.com, hinden@iprg.nokia.com, vrrp@drcoffsite.com In-reply-to: <35A15B40.A4A37E30@raleigh.ibm.com> (message from Acee Lindem on Mon, 06 Jul 1998 19:18:24 -0400) Subject: Re: Request for Agenda Items for VRRP session at Chicago IETF Precedence: bulk Sender: VRRP-owner@drcoffsite.com | > (A) Where any patents, patent applications, or other proprietary | > rights are known, or claimed, with respect to any specification on | > the standards track, and brought to the attention of the IESG, the | > IESG shall not advance the specification without including in the | > document a note indicating the existence of such rights, or | > claimed rights. | | Why couldn't this be satisfied via documentation in a revision of | the RFC? As this is legalese, you should notice that the requirement is to note the existence of the patent. Yes, that could be trivially satisfied. Note also that it is NOT necessary to document the details of the claim. | > Where implementations are required before | > advancement of a specification, only implementations that have, by | > statement of the implementors, taken adequate steps to comply with | > any such rights, or claimed rights, shall be considered for the | > purpose of showing the adequacy of the specification. | | As exemplified by your comment that the audience isn't specified, this is | a rather nebulous requirement and possibly one that can best be handled | by the IP lawyers, vis-a-vis, the IESG. I should have also included paragraph B: (B) The IESG disclaims any responsibility for identifying the existence of or for evaluating the applicability of any claimed copyrights, patents, patent applications, or other rights in the fulfilling of the its obligations under (A), and will take no position on the validity or scope of any such rights. This is also to say that the IESG _cannot_ deliberate on the applicability of a patent. Thus, the onus is still on the implementors. What's not clear is how seriously this will be taken. If an implementor claims that no licensing is necessary, is that sufficient? Obviously the IESG/IETF incur no liability by believing them. But that means that we could trivially also have situations where the implementors fibbed big and we ended up with specs based on infringing implementations. Yes, this is a messy area. No the process is not very clear here, and I don't think we've seen an analogous situation before in the IETF. Tony From VRRP-owner@drcoffsite.com Mon Jul 6 19:53:46 1998 Delivery-Date: Mon, 06 Jul 1998 19:53:46 -0400 Return-Path: VRRP-owner@drcoffsite.com Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id TAA02474 for ; Mon, 6 Jul 1998 19:53:45 -0400 (EDT) Received: from drcoffsite.com (dns1.drcoffsite.com [205.198.103.130]) by cnri.reston.va.us (8.8.5/8.8.7a) with SMTP id TAA06016 for ; Mon, 6 Jul 1998 19:56:04 -0400 (EDT) Received: from mailhost.iprg.nokia.com [205.226.5.12] by drcoffsite.com with ESMTP (SMTPD32-4.06) id A2E610B0184; Mon, 06 Jul 1998 19:51:02 +03d00 Received: from spruce.iprg.nokia.com (spruce.iprg.nokia.com [205.226.1.63]) by mailhost.iprg.nokia.com (8.8.7/8.6.10) with SMTP id QAA16283; Mon, 6 Jul 1998 16:48:07 -0700 (PDT) Message-Id: <3.0.5.32.19980706164722.00a3dbb0@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Mon, 06 Jul 1998 16:47:22 -0700 To: Tony Li From: Bob Hinden Subject: Re: Request for Agenda Items for VRRP session at Chicago IETF Cc: vrrp@drcoffsite.com In-Reply-To: <199807062304.QAA19727@chimp.juniper.net> References: <35A1558D.25BB6618@raleigh.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Precedence: bulk Sender: VRRP-owner@drcoffsite.com Tony, >I don't see how either of these is relevant to satisfying RFC 2026. Given that RFC 2026 was published in October 1996 and VRRP (RFC-2338) was published as a Proposed Standard in April 1998, the IESG must have had a different interpretation. I reread section 10 in RFC2026. The section quoted is part of section 10.3 pertaining to rights and permissions of contributed work. A good example of this was when Sun Microsystems turned over rights to RPC and XDR to the IETF. These protocols would not be made a standard until all IPR rights were resolved. I do not think Section 10.3.2 applies to IPR claims made against IETF developed technology (e.g., VRRP). Bob From VRRP-owner@drcoffsite.com Mon Jul 6 20:11:14 1998 Delivery-Date: Mon, 06 Jul 1998 20:11:15 -0400 Return-Path: VRRP-owner@drcoffsite.com Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id UAA02611 for ; Mon, 6 Jul 1998 20:11:14 -0400 (EDT) Received: from drcoffsite.com (dns1.drcoffsite.com [205.198.103.130]) by cnri.reston.va.us (8.8.5/8.8.7a) with SMTP id UAA06034 for ; Mon, 6 Jul 1998 20:13:33 -0400 (EDT) Received: from mailhost.iprg.nokia.com [205.226.5.12] by drcoffsite.com with ESMTP (SMTPD32-4.06) id A7343B00380; Mon, 06 Jul 1998 20:09:24 +03d00 Received: from spruce.iprg.nokia.com (spruce.iprg.nokia.com [205.226.1.63]) by mailhost.iprg.nokia.com (8.8.7/8.6.10) with SMTP id RAA16731; Mon, 6 Jul 1998 17:06:27 -0700 (PDT) Message-Id: <3.0.5.32.19980706170542.00a3daa0@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Mon, 06 Jul 1998 17:05:42 -0700 To: Tony Li From: Bob Hinden Subject: Re: Request for Agenda Items for VRRP session at Chicago IETF Cc: vrrp@drcoffsite.com In-Reply-To: <199807062328.QAA19828@chimp.juniper.net> References: <35A15B40.A4A37E30@raleigh.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Precedence: bulk Sender: VRRP-owner@drcoffsite.com Tony, Yes, this is all terribly messy. >Thus, the onus is still on the implementors. What's not clear is how >seriously this will be taken. If an implementor claims that no licensing >is necessary, is that sufficient? Obviously the IESG/IETF incur no >liability by believing them. But that means that we could trivially also >have situations where the implementors fibbed big and we ended up with >specs based on infringing implementations. I think that the IESG's approach is two fold: 1) They publish all IPR notices/disclosures/etc. on the IETF web site (www.ietf.org/ipr.html), and 2) They wait to see if multiple implementations get built. If multiple implementations do get built, then they assume that the IPR issues have been resolved. If not, then the protocol never gets to Draft Standard and eventually times out. >Yes, this is a messy area. No the process is not very clear here, and I >don't think we've seen an analogous situation before in the IETF. Yes, very messy. I think this is the first time I am aware of that an organization has tried to use it's IPR claims to keep people from exercising an open standard (as opposed to licensing it). Not good form IMHO. Bob From VRRP-owner@drcoffsite.com Mon Jul 6 20:11:52 1998 Delivery-Date: Mon, 06 Jul 1998 20:11:52 -0400 Return-Path: VRRP-owner@drcoffsite.com Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id UAA02616 for ; Mon, 6 Jul 1998 20:11:51 -0400 (EDT) Received: from drcoffsite.com (dns1.drcoffsite.com [205.198.103.130]) by cnri.reston.va.us (8.8.5/8.8.7a) with SMTP id UAA06037 for ; Mon, 6 Jul 1998 20:14:09 -0400 (EDT) Received: from kahn.drc.com [198.22.14.98] by drcoffsite.com (SMTPD32-4.06) id A71214E60332; Mon, 06 Jul 1998 20:08:50 +03d00 Received: from seattle.3com.com [129.213.128.97] by kahn.drc.com with ESMTP (SMTPD32-4.06) id A6C19F30544; Mon, 06 Jul 1998 20:07:29 EDT Received: from new-york.3com.com (new-york.3com.com [129.213.157.12]) by seattle.3com.com (8.8.8/8.8.8) with ESMTP id RAA22209; Mon, 6 Jul 1998 17:01:00 -0700 (PDT) Received: from chicago.nsd.3com.com (chicago.nsd.3com.com [129.213.157.11]) by new-york.3com.com (8.8.8/8.8.8) with ESMTP id RAA28860; Mon, 6 Jul 1998 17:00:59 -0700 (PDT) Received: from himagiri.nsd.3com.com (himagiri.nsd.3com.com [129.213.48.33]) by chicago.nsd.3com.com (8.8.8/8.8.8) with ESMTP id RAA17066; Mon, 6 Jul 1998 17:00:59 -0700 (PDT) Message-Id: <199807070000.RAA17066@chicago.nsd.3com.com> To: Tony Li cc: acee@raleigh.ibm.com, matt@ascend.com, hinden@iprg.nokia.com, vrrp@drcoffsite.com Subject: Re: Request for Agenda Items for VRRP session at Chicago IETF In-reply-to: Mail from Tony Li dated Mon, 06 Jul 1998 16:28:11 PDT <199807062328.QAA19828@chimp.juniper.net> Date: Mon, 06 Jul 1998 17:02:39 -0700 From: Venkat Prasad Precedence: bulk Sender: VRRP-owner@drcoffsite.com > > Yes, this is a messy area. No the process is not very clear here, and I > don't think we've seen an analogous situation before in the IETF. > > Tony The Compression Control Protocol from PPPEXT working group went through similar IP issues - vp From VRRP-owner@drcoffsite.com Mon Jul 6 20:13:50 1998 Delivery-Date: Mon, 06 Jul 1998 20:13:50 -0400 Return-Path: VRRP-owner@drcoffsite.com Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id UAA02626 for ; Mon, 6 Jul 1998 20:13:50 -0400 (EDT) Received: from drcoffsite.com (dns1.drcoffsite.com [205.198.103.130]) by cnri.reston.va.us (8.8.5/8.8.7a) with SMTP id UAA06043 for ; Mon, 6 Jul 1998 20:16:08 -0400 (EDT) Received: from red.juniper.net [208.197.169.254] by drcoffsite.com with ESMTP (SMTPD32-4.06) id A7433EF03EC; Mon, 06 Jul 1998 20:09:39 +03d00 Received: from chimp.juniper.net (chimp.juniper.net [208.197.169.196]) by red.juniper.net (8.8.5/8.8.5) with ESMTP id RAA03247; Mon, 6 Jul 1998 17:08:17 -0700 (PDT) Received: (from tli@localhost) by chimp.juniper.net (8.7.6/8.7.3) id RAA19961; Mon, 6 Jul 1998 17:07:15 -0700 (PDT) Date: Mon, 6 Jul 1998 17:07:15 -0700 (PDT) Message-Id: <199807070007.RAA19961@chimp.juniper.net> From: Tony Li To: hinden@iprg.nokia.com CC: vrrp@drcoffsite.com In-reply-to: <3.0.5.32.19980706164722.00a3dbb0@mailhost.iprg.nokia.com> (message from Bob Hinden on Mon, 06 Jul 1998 16:47:22 -0700) Subject: Re: Request for Agenda Items for VRRP session at Chicago IETF Precedence: bulk Sender: VRRP-owner@drcoffsite.com | I do not think Section 10.3.2 applies to IPR claims made against IETF | developed technology (e.g., VRRP). Based on previous experience dealing with IPR claims made against IETF developed technology in other WGs, it has most certainly been applied before. Tony From VRRP-owner@drcoffsite.com Mon Jul 6 20:28:35 1998 Delivery-Date: Mon, 06 Jul 1998 20:28:36 -0400 Return-Path: VRRP-owner@drcoffsite.com Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id UAA02704 for ; Mon, 6 Jul 1998 20:28:35 -0400 (EDT) Received: from drcoffsite.com (dns1.drcoffsite.com [205.198.103.130]) by cnri.reston.va.us (8.8.5/8.8.7a) with SMTP id UAA06077 for ; Mon, 6 Jul 1998 20:30:53 -0400 (EDT) Received: from red.juniper.net [208.197.169.254] by drcoffsite.com with ESMTP (SMTPD32-4.06) id AAD758F0362; Mon, 06 Jul 1998 20:24:55 +03d00 Received: from chimp.juniper.net (chimp.juniper.net [208.197.169.196]) by red.juniper.net (8.8.5/8.8.5) with ESMTP id RAA03985; Mon, 6 Jul 1998 17:23:33 -0700 (PDT) Received: (from tli@localhost) by chimp.juniper.net (8.7.6/8.7.3) id RAA20020; Mon, 6 Jul 1998 17:22:31 -0700 (PDT) Date: Mon, 6 Jul 1998 17:22:31 -0700 (PDT) Message-Id: <199807070022.RAA20020@chimp.juniper.net> From: Tony Li To: hinden@iprg.nokia.com CC: vrrp@drcoffsite.com In-reply-to: <3.0.5.32.19980706170542.00a3daa0@mailhost.iprg.nokia.com> (message from Bob Hinden on Mon, 06 Jul 1998 17:05:42 -0700) Subject: Re: Request for Agenda Items for VRRP session at Chicago IETF Precedence: bulk Sender: VRRP-owner@drcoffsite.com | Yes, very messy. I think this is the first time I am aware of that an | organization has tried to use it's IPR claims to keep people from | exercising an open standard (as opposed to licensing it). Not good form IMHO. Umm.... I'd say that it's pretty clear that it's not the first case. I was involved in a similar situation with another standard where the criteria for non-discrimanatory licensing was met, but the 'reasonable' criteria was clearly out the door. In this case, the IPR owner had a shaky claim that they were using as a club over the heads of the WG. This IS the first case that I've seen where a company has offered to license if their contribution was accepted (as required) and then been turned away. Tony From VRRP-owner@drcoffsite.com Mon Jul 6 20:31:13 1998 Delivery-Date: Mon, 06 Jul 1998 20:31:14 -0400 Return-Path: VRRP-owner@drcoffsite.com Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id UAA02747 for ; Mon, 6 Jul 1998 20:31:13 -0400 (EDT) Received: from drcoffsite.com (dns1.drcoffsite.com [205.198.103.130]) by cnri.reston.va.us (8.8.5/8.8.7a) with SMTP id UAA06084 for ; Mon, 6 Jul 1998 20:33:30 -0400 (EDT) Received: from mailhost.iprg.nokia.com [205.226.5.12] by drcoffsite.com with ESMTP (SMTPD32-4.06) id ABDB40903EC; Mon, 06 Jul 1998 20:29:15 +03d00 Received: from spruce.iprg.nokia.com (spruce.iprg.nokia.com [205.226.1.63]) by mailhost.iprg.nokia.com (8.8.7/8.6.10) with SMTP id RAA17306; Mon, 6 Jul 1998 17:27:20 -0700 (PDT) Message-Id: <3.0.5.32.19980706172635.008666b0@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Mon, 06 Jul 1998 17:26:35 -0700 To: Tony Li From: Bob Hinden Subject: Re: Request for Agenda Items for VRRP session at Chicago IETF Cc: vrrp@drcoffsite.com In-Reply-To: <199807070007.RAA19961@chimp.juniper.net> References: <3.0.5.32.19980706164722.00a3dbb0@mailhost.iprg.nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Precedence: bulk Sender: VRRP-owner@drcoffsite.com Tony, >| I do not think Section 10.3.2 applies to IPR claims made against IETF >| developed technology (e.g., VRRP). > > >Based on previous experience dealing with IPR claims made against IETF >developed technology in other WGs, it has most certainly been applied >before. Good thing we have the IESG to sort this stuff out :-) Bob From VRRP-owner@drcoffsite.com Mon Jul 6 23:19:08 1998 Delivery-Date: Mon, 06 Jul 1998 23:19:09 -0400 Return-Path: VRRP-owner@drcoffsite.com Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id XAA11150 for ; Mon, 6 Jul 1998 23:19:08 -0400 (EDT) Received: from drcoffsite.com (dns1.drcoffsite.com [205.198.103.130]) by cnri.reston.va.us (8.8.5/8.8.7a) with SMTP id XAA06371 for ; Mon, 6 Jul 1998 23:21:28 -0400 (EDT) Received: from drawbridge.ascend.com [198.4.92.1] by drcoffsite.com (SMTPD32-4.06) id A2F13F04B6; Mon, 06 Jul 1998 23:16:01 +03d00 Received: from ascend.com (fw-ext.ascend.com [198.4.92.5]) by drawbridge.ascend.com (8.6.12/8.6.12) with ESMTP id UAA20160; Mon, 6 Jul 1998 20:14:36 -0700 Received: from ascend.com by ascend.com (SMI-8.6/SMI-SVR4) id UAA27236; Mon, 6 Jul 1998 20:14:38 -0700 Received: from ascend.com by ascend.com id UAA25906; Mon, 6 Jul 1998 20:10:22 -0700 Message-Id: <3.0.5.32.19980706201309.00bd0320@darla.ascend.com> X-Sender: mhold@darla.ascend.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Mon, 06 Jul 1998 20:13:09 -0700 To: Tony Li From: Matt Holdrege Subject: Re: Request for Agenda Items for VRRP session at Chicago IETF Cc: hinden@iprg.nokia.com, vrrp@drcoffsite.com In-Reply-To: <199807070022.RAA20020@chimp.juniper.net> References: <3.0.5.32.19980706170542.00a3daa0@mailhost.iprg.nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Precedence: bulk Sender: VRRP-owner@drcoffsite.com At 05:22 PM 7/6/98 -0700, Tony Li wrote: >This IS the first case that I've seen where a company has offered to >license if their contribution was accepted (as required) and then been >turned away. Actually, that wasn't how it played out. When we did a show of hands to choose VRRP or HSRP, there had been no indication of any sort that Cisco would license either choice. In fact, there was clear indication that they would NOT license HSRP. However I vaguely recall verbal indication that Cisco would license whatever the IETF chose to standardize. Anyone with better memory of that statement? Matt Holdrege http://www.ascend.com matt@ascend.com From VRRP-owner@drcoffsite.com Mon Jul 13 21:02:39 1998 Delivery-Date: Mon, 13 Jul 1998 21:02:39 -0400 Return-Path: VRRP-owner@drcoffsite.com Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id VAA09413 for ; Mon, 13 Jul 1998 21:02:38 -0400 (EDT) Received: from drcoffsite.com (dns1.drcoffsite.com [205.198.103.130]) by cnri.reston.va.us (8.8.5/8.8.7a) with SMTP id VAA06810 for ; Mon, 13 Jul 1998 21:02:33 -0400 (EDT) Received: from mailgate.fore.com [169.144.68.6] by drcoffsite.com with ESMTP (SMTPD32-4.06) id AD2C5F402D4; Mon, 13 Jul 1998 20:58:20 +03d00 Received: from postman.sj.fore.com (postman.sj.fore.com [147.128.128.5]) by mailgate.fore.com (8.9.1/8.9.1) with ESMTP id UAA14532 for ; Mon, 13 Jul 1998 20:56:55 -0400 (EDT) Received: from fort1.sj.fore.com (fort1 [147.128.48.234]) by postman.sj.fore.com (8.8.8/8.8.8) with SMTP id RAA04332 for ; Mon, 13 Jul 1998 17:54:39 -0700 (PDT) Received: from localhost by fort1.sj.fore.com (SMI-8.6/SMI-SVR4) id RAA12944; Mon, 13 Jul 1998 17:55:05 -0700 Date: Mon, 13 Jul 1998 17:55:02 -0700 (PDT) From: Vivek Menezes To: vrrp@drcoffsite.com Subject: FDDI Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Precedence: bulk Sender: VRRP-owner@drcoffsite.com Hi, I am implementing VRRP. I was looking at section 9.1 of the RFC regarding FDDI. The section talks about problems when routers use a virtual MAC address during Master advertisements. Essentially FDDI devices remove packets with their own source address. So if a FDDI device on the network where to use the virtual MAC address it wouldnt know if the packet were from itself or from some other machine with the same virtual MAC address. The solution to the problem involves setting up a "unicast MAC address" filter on the FDDI device. I couldnt understand as to what they meant by this. Thanks, Vivek. From VRRP-owner@drcoffsite.com Tue Jul 14 12:42:43 1998 Delivery-Date: Tue, 14 Jul 1998 12:42:44 -0400 Return-Path: VRRP-owner@drcoffsite.com Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id MAA05430 for ; Tue, 14 Jul 1998 12:42:43 -0400 (EDT) Received: from drcoffsite.com (dns1.drcoffsite.com [205.198.103.130]) by cnri.reston.va.us (8.8.5/8.8.7a) with SMTP id MAA09870 for ; Tue, 14 Jul 1998 12:42:39 -0400 (EDT) Received: from mailhost.iprg.nokia.com [205.226.5.12] by drcoffsite.com with ESMTP (SMTPD32-4.06) id AA03900033A; Tue, 14 Jul 1998 12:40:35 +03d00 Received: from pfinger.iprg.nokia.com (pfinger.iprg.nokia.com [205.226.1.149]) by mailhost.iprg.nokia.com (8.8.8/8.6.10) with ESMTP id JAA13507; Tue, 14 Jul 1998 09:39:10 -0700 (PDT) Received: from localhost.iprg.nokia.com (localhost.iprg.nokia.com [127.0.0.1]) by pfinger.iprg.nokia.com (8.6.12/8.6.12) with SMTP id JAA25525; Tue, 14 Jul 1998 09:39:09 -0700 Message-Id: <199807141639.JAA25525@pfinger.iprg.nokia.com> X-Authentication-Warning: pfinger.iprg.nokia.com: Host localhost.iprg.nokia.com didn't use HELO protocol X-Mailer: exmh version 2.0beta 12/23/96 To: Vivek Menezes cc: vrrp@drcoffsite.com Subject: Re: FDDI In-reply-to: Your message of "Mon, 13 Jul 1998 17:55:02 PDT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 14 Jul 1998 09:39:09 -0700 From: Peter Hunt Precedence: bulk Sender: VRRP-owner@drcoffsite.com Vivek, some FDDI devices can be programmed to accept frames with MAC addresses other than the FDDI device's hardware address. This is done by specifying a set of MAC address filters which describe the destination MAC addresses of frames that the device will pass to the host. I think the feature was originally intended as a way to filter for specific multicast frames, rather than putting the device in promiscuous mode. But you can also add unicast MAC address filters to the set. The section recommends that when the router becomes vrrp master, the virtual router's unicast MAC address should be added to the FDDI device's set of MAC address filters, rather than reprogramming the device's hardware MAC address (for the reasons you've stated). If the device doesn't support MAC address filters, then the device should be put into promiscous mode, to accept all packets, and the filtering should be done in software. Hope this helps. Peter. From VRRP-owner@drcoffsite.com Tue Jul 14 17:23:21 1998 Delivery-Date: Tue, 14 Jul 1998 17:23:21 -0400 Return-Path: VRRP-owner@drcoffsite.com Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id RAA16396 for ; Tue, 14 Jul 1998 17:23:21 -0400 (EDT) Received: from drcoffsite.com (dns1.drcoffsite.com [205.198.103.130]) by cnri.reston.va.us (8.8.5/8.8.7a) with SMTP id RAA11617 for ; Tue, 14 Jul 1998 17:23:14 -0400 (EDT) Received: from mailgate.fore.com [169.144.68.6] by drcoffsite.com with ESMTP (SMTPD32-4.06) id ABF13D003B2; Tue, 14 Jul 1998 17:21:53 +03d00 Received: from postman.sj.fore.com (postman.sj.fore.com [147.128.128.5]) by mailgate.fore.com (8.9.1/8.9.1) with ESMTP id RAA24064; Tue, 14 Jul 1998 17:18:57 -0400 (EDT) Received: from fort1.sj.fore.com (fort1 [147.128.48.234]) by postman.sj.fore.com (8.8.8/8.8.8) with SMTP id OAA29569; Tue, 14 Jul 1998 14:16:41 -0700 (PDT) Received: from localhost by fort1.sj.fore.com (SMI-8.6/SMI-SVR4) id OAA13144; Tue, 14 Jul 1998 14:17:08 -0700 Date: Tue, 14 Jul 1998 14:17:08 -0700 (PDT) From: Vivek Menezes To: Peter Hunt cc: vrrp@drcoffsite.com Subject: Re: FDDI In-Reply-To: <199807141639.JAA25525@pfinger.iprg.nokia.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Precedence: bulk Sender: VRRP-owner@drcoffsite.com On Tue, 14 Jul 1998, Peter Hunt wrote: > Vivek, > > some FDDI devices can be programmed to accept frames with > MAC addresses other than the FDDI device's hardware address. This is done > by specifying a set of MAC address filters which describe the destination > MAC addresses of frames that the device will pass to the host. > Hi Peter, Thank you for your prompt response. I had a question related to how FDDI would treat a packet with a source address equal to the virtual MAC address. If the master were to transmit a vrrp advertisement using the virtual MAC address as the source. The question is how will this packet be taken of the ring. Will it continue to go around in circles because its source address doesnt match any of the source addresses of stations on the ring, or will it be dropped after sometime. thanks, Vivek. > I think the feature was originally intended as a way to filter for > specific multicast frames, rather than putting the device in promiscuous > mode. But you can also add unicast MAC address filters to the set. > > The section recommends that when the router becomes vrrp master, > the virtual router's unicast MAC address should be added to the FDDI > device's set of MAC address filters, rather than reprogramming the > device's hardware MAC address (for the reasons you've stated). > > If the device doesn't support MAC address filters, then the device > should be put into promiscous mode, to accept all packets, and the filtering > should be done in software. > > Hope this helps. > > Peter. > > > From VRRP-owner@drcoffsite.com Tue Jul 28 10:24:47 1998 Delivery-Date: Tue, 28 Jul 1998 10:24:48 -0400 Return-Path: VRRP-owner@drcoffsite.com Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id KAA12785 for ; Tue, 28 Jul 1998 10:24:47 -0400 (EDT) Received: from drcoffsite.com (dns1.drcoffsite.com [205.198.103.130]) by cnri.reston.va.us (8.8.5/8.8.7a) with SMTP id KAA10159 for ; Tue, 28 Jul 1998 10:24:32 -0400 (EDT) Received: from ietf.org [132.151.1.176] by drcoffsite.com with ESMTP (SMTPD32-4.06) id AEBD2D440094; Tue, 28 Jul 1998 10:22:53 +03d00 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id KAA12680; Tue, 28 Jul 1998 10:21:27 -0400 (EDT) Message-Id: <199807281421.KAA12680@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: vrrp@drcoffsite.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-vrrp-mib-02.txt Date: Tue, 28 Jul 1998 10:21:26 -0400 X-Sender: cclark@ns.cnri.reston.va.us Precedence: bulk Sender: VRRP-owner@drcoffsite.com --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Virtual Router Redundancy Protocol Working Group of the IETF. Title : Definitions of Managed Objects for the Virtual Router Redundancy Protocol using SNMPv2 Author(s) : B. Jewell, D. Chuang Filename : draft-ietf-vrrp-mib-02.txt Pages : 26 Date : 27-Jul-98 This specification defines an extension to the Management Information Base (MIB) for use with SNMP-based network management. In particular, it defines objects for configuring, monitoring, and controlling routers that employ the Virtual Router Redundancy Protocol (VRRP) [1]. This memo specifies a MIB module in a manner that is compliant with both the SNMPv2 SMI [5], and semantically identical to the SNMPv1 definitions [2]. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-vrrp-mib-02.txt". A URL for the Internet-Draft is: ftp://ftp.ietf.org/internet-drafts/draft-ietf-vrrp-mib-02.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ftp.ietf.org US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-vrrp-mib-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <19980727160055.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-vrrp-mib-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-vrrp-mib-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19980727160055.I-D@ietf.org> --OtherAccess-- --NextPart-- From VRRP-owner@drcoffsite.com Tue Jul 28 11:22:58 1998 Delivery-Date: Tue, 28 Jul 1998 11:22:58 -0400 Return-Path: VRRP-owner@drcoffsite.com Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id LAA14330 for ; Tue, 28 Jul 1998 11:22:57 -0400 (EDT) Received: from drcoffsite.com (dns1.drcoffsite.com [205.198.103.130]) by cnri.reston.va.us (8.8.5/8.8.7a) with SMTP id LAA10645 for ; Tue, 28 Jul 1998 11:22:41 -0400 (EDT) Received: from kahn.drc.com [198.22.14.98] by drcoffsite.com (SMTPD32-4.06) id AC652D7E0094; Tue, 28 Jul 1998 11:21:09 +03d00 Received: from seattle.3com.com [129.213.128.97] by kahn.drc.com with ESMTP (SMTPD32-4.06) id AC0E4E0508; Tue, 28 Jul 1998 11:19:42 EDT Received: from new-york.3com.com (new-york.3com.com [129.213.157.12]) by seattle.3com.com (8.8.8/8.8.8) with ESMTP id IAA15808 for ; Tue, 28 Jul 1998 08:13:20 -0700 (PDT) Received: from chicago.nsd.3com.com (chicago.nsd.3com.com [129.213.157.11]) by new-york.3com.com (8.8.8/8.8.8) with ESMTP id IAA09313 for ; Tue, 28 Jul 1998 08:13:20 -0700 (PDT) Received: from fubar.nsd.3com.com (fubar.nsd.3com.com [129.213.16.41]) by chicago.nsd.3com.com (8.8.8/8.8.8) with ESMTP id IAA08320; Tue, 28 Jul 1998 08:13:19 -0700 (PDT) From: Brian Jewell Received: (from bjewell@localhost) by fubar.nsd.3com.com (8.8.2/8.8.5) id IAA01806; Tue, 28 Jul 1998 08:13:17 -0700 (PDT) Date: Tue, 28 Jul 1998 08:13:17 -0700 (PDT) Message-Id: <199807281513.IAA01806@fubar.nsd.3com.com> To: vrrp@drcoffsite.com Subject: New Revision of VRRP MIB Draft Cc: bjewell@ewd.3Com.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-MD5: 0qIrIDmxV1mhJpfZGal8lA== Precedence: bulk Sender: VRRP-owner@drcoffsite.com Just wanted to do a follow-on to the posting of "Revision 02" of the VRRP MIB on the IETF website. This revision contains input received from email, telephone calls and the last VRRP WG meeting. There is a 'change log' at the end the draft which documents the changes from revision-to-revision. I have enclosed a copy of the change log entries for revision 02. Although I attempted to incorporate most of the suggested changes into the new draft, I may have missed a few. So please use the WG mailing list to promote any omissions I might have made, or any new suggestions that come to mind. I am assuming (perhaps, somewhat optimistically!) that there will be at least one more revision to the MIB Draft. Also, I will be on vacation the first week of August (next week). So there will be a period where I won't be responding to email (I'm not taking a laptop to the beach!) Thanks. -Brian Jewell -3Com, Inc. -bjewell@3com.com The following are my concerns about the new revision: - Should the 'vrrpTrapAuthFailure' trap be removed? This was suggested from some of the feedback. - After more thought, I think the row-creation/deletion mechanism in the 'vrrpOperTable' should be better explained. I will endeavor to do this in the next revision, or maybe post a modified "description" to the mailing list for comments. This is important to ensure that the table is adequate for managing VRRP routers. I received comments from a number of people who have indicated that they have been implementing the VRRP MIB. It would be good to obtain feedback from them as to whether the 'vrrpOperTable' works o.k. - Remove 'vrrpTrapPacketSrc' and 'vrrpTrapConfigErrorType' from compliances? Only used for 'vrrpTrapAuthFailure' trap. Change Log (from the MIB Draft): -------------------------------- * July, 1998: Changes in 2nd revision (draft-ietf-vrrp-mib-02.txt): - A number of changes were made to the 'textual content' of the draft as per feedback received at the last WG meeting. These changes were too numerous to document individually in this section. - The size of the "vrrpNodeVersion" object has been changed from 2 octets to 1 octet. - References to obsoleted RFC's have been replaced by references to later documents. Notably, references to RFC's 1442, 1443 and 1444 have been replaced by RFC 1902, RFC 1903 and RFC 1904, respectively. - The description for the "vrrpOperControl" was changed to reflect the fact that a virtual router does not necessarily transition directly from initialize state -> backup state. The description for the "vrrpStatsBecomeMaster" was also changed to more accurately convey this fact. - The SYNTAX of the "vrrpOperIpAddrCount" was changed to reflect the fact that a virtual router can support only up to 255 backup IP addresses. - Descriptions for vrrpOperAuthType and vrrpOperAuthKey expanded to indicate the per-interface assignment. - SYNTAX of vrrpOperPreemptMode object changed from INTEGER to 'truthValue' - The OIDs for the VRRP traps were fixed; incorrect ident- ifiers ('vrrpOperations') had been used in OID assignments. - The SYNTAX for the 'vrrpOperPriority' object was corrected to indicate that this can have a value of '0'. - The vrrpOperHMACMD5Key object was deleted. It was combined with the vrrpOperAuthKey object, whose SYNTAX was adjusted accordingly. - OID for 'vrrpTraps' changed to '{ vrrpNotifications 1 }' - The 'vrrpStatsPasswdSecurityViolations' and 'vrrpStatsHmac- SecurityViolations' objects have been combined into a single 'vrrpStatsSecurityViolations' object; this was suggested to avoid redundancy. - As per the last WG meeting, the 'vrrpAssoIpAddrIndex' object has been deleted from the 'vrrpAssoIpAddrTable'and replaced by 'vrrpAssoIpAddr'. - Removed references to 'vrrpAssoIpAddrIndex' in samples. - Added new object 'vrrpOperProtocol' to 'VrrpOperEntry'. - MAX-ACCESS for the 'vrrpOperVrId' object changed to 'not-accessible', as per RFC1902 (auxillary objects). - SYNTAX for 'vrrpOperVirtualRouterUpTime' changed to 'TimeStamp'. - Added importation of 'TruthValue'and 'TimeStamp' to accomodate changes listed above. Deleted importation of 'TimeTicks'. - Changed MAX-ACCESS to 'accessible-for-notify' for 'vrrpTrapPacketSrc' and 'vrrpTrapConfigErrorType' objects. - In the sample tables, the "if" values were incorrect for the sample tables for "IP B" (they used to read "I1"). - MAX-ACCESS for 'vrrpOperAuthType' and 'vrrpOperAuthKey' changed to 'read-only', since these objects are defined on a per-interface basis. - Overall review and editing of Section 5.0 (References) with deletion of references not used in this document. Also, added reference '9'. From adm Tue Jul 28 11:27:52 1998 Delivery-Date: Tue, 28 Jul 1998 11:40:41 -0400 Return-Path: adm Received: (from adm@localhost) by ietf.org (8.8.5/8.8.7a) id LAA14432 for ietf-123-outbound.10@ietf.org; Tue, 28 Jul 1998 11:25:03 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id KAA12680; Tue, 28 Jul 1998 10:21:27 -0400 (EDT) Message-Id: <199807281421.KAA12680@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: vrrp@drcoffsite.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-vrrp-mib-02.txt Date: Tue, 28 Jul 1998 10:21:26 -0400 Sender: cclark@ns.cnri.reston.va.us --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Virtual Router Redundancy Protocol Working Group of the IETF. Title : Definitions of Managed Objects for the Virtual Router Redundancy Protocol using SNMPv2 Author(s) : B. Jewell, D. Chuang Filename : draft-ietf-vrrp-mib-02.txt Pages : 26 Date : 27-Jul-98 This specification defines an extension to the Management Information Base (MIB) for use with SNMP-based network management. In particular, it defines objects for configuring, monitoring, and controlling routers that employ the Virtual Router Redundancy Protocol (VRRP) [1]. This memo specifies a MIB module in a manner that is compliant with both the SNMPv2 SMI [5], and semantically identical to the SNMPv1 definitions [2]. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-vrrp-mib-02.txt". A URL for the Internet-Draft is: ftp://ftp.ietf.org/internet-drafts/draft-ietf-vrrp-mib-02.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ftp.ietf.org US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-vrrp-mib-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <19980727160055.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-vrrp-mib-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-vrrp-mib-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19980727160055.I-D@ietf.org> --OtherAccess-- --NextPart-- From VRRP-owner@drcoffsite.com Wed Jul 29 01:28:54 1998 Delivery-Date: Wed, 29 Jul 1998 01:28:54 -0400 Return-Path: VRRP-owner@drcoffsite.com Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id BAA03152 for ; Wed, 29 Jul 1998 01:28:53 -0400 (EDT) Received: from drcoffsite.com (dns1.drcoffsite.com [205.198.103.130]) by cnri.reston.va.us (8.8.5/8.8.7a) with SMTP id BAA14527 for ; Wed, 29 Jul 1998 01:28:37 -0400 (EDT) Received: from joshua.drcoffsite.com [205.198.103.132] by drcoffsite.com (SMTPD32-4.06) id A2801E032E; Wed, 29 Jul 1998 01:26:33 +03d00 Received: from mailgate.fore.com [169.144.68.6] by joshua.drcoffsite.com with ESMTP (SMTPD32-4.06) id A5BE11E01F4; Tue, 28 Jul 1998 22:15:26 EDT Received: from postman.sj.fore.com (postman.sj.fore.com [147.128.128.5]) by mailgate.fore.com (8.9.1/8.9.1) with ESMTP id WAA15206 for ; Tue, 28 Jul 1998 22:08:41 -0400 (EDT) Received: from fort1.sj.fore.com (fort1 [147.128.48.234]) by postman.sj.fore.com (8.8.8/8.8.8) with SMTP id TAA21001 for ; Tue, 28 Jul 1998 19:05:09 -0700 (PDT) Received: from localhost by fort1.sj.fore.com (SMI-8.6/SMI-SVR4) id TAA19172; Tue, 28 Jul 1998 19:05:43 -0700 Date: Tue, 28 Jul 1998 19:05:41 -0700 (PDT) From: Vivek Menezes To: vrrp@drcoffsite.com Subject: primary key for virtual router Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Precedence: bulk Sender: VRRP-owner@drcoffsite.com Hi, In the draft for RFC 2338 a virtual router is described as "An abstract object that consists of a virtual router identifier and a set of ip addresses across a common lan" Question is, is the "vrid" the primary key to access this object. Should vrrp be implemented such that the router can setup virtual routers on different interfaces using the same vrid but with different ip addresses, or is this vrid unique. If the former is true then why would one use a vrid, when the ip addresses could act as the primary key. using the vrid as a primary key would improve VRRP performance drastically. Thanks, Vivek. From VRRP-owner@drcoffsite.com Wed Jul 29 09:52:53 1998 Delivery-Date: Wed, 29 Jul 1998 09:52:54 -0400 Return-Path: VRRP-owner@drcoffsite.com Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id JAA06098 for ; Wed, 29 Jul 1998 09:52:53 -0400 (EDT) Received: from drcoffsite.com (dns1.drcoffsite.com [205.198.103.130]) by cnri.reston.va.us (8.8.5/8.8.7a) with SMTP id JAA16038 for ; Wed, 29 Jul 1998 09:52:37 -0400 (EDT) Received: from fwns1.raleigh.ibm.com [204.146.167.235] by drcoffsite.com with ESMTP (SMTPD32-4.06) id A8676B03F4; Wed, 29 Jul 1998 09:49:27 +03d00 Received: from rtpmail02.raleigh.ibm.com (rtpmail02.raleigh.ibm.com [9.37.172.48]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id JAA24586; Wed, 29 Jul 1998 09:46:33 -0400 Received: from aceman.raleigh.ibm.com (aceman.raleigh.ibm.com [9.37.177.119]) by rtpmail02.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id JAA04372; Wed, 29 Jul 1998 09:46:33 -0400 Received: from loopback by aceman.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA20734; Wed, 29 Jul 1998 09:46:32 -0400 X-Sender: acee@raleigh.ibm.com Message-Id: <35BF27B7.12CA7DD9@raleigh.ibm.com> Date: Wed, 29 Jul 1998 09:46:31 -0400 From: Acee Lindem Organization: IBM Networking Divison X-Mailer: Mozilla 4.04 [en] (X11; I; AIX 4.1) Mime-Version: 1.0 To: Vivek Menezes Cc: vrrp@drcoffsite.com Subject: Re: primary key for virtual router References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Precedence: bulk Sender: VRRP-owner@drcoffsite.com Vivek Menezes wrote: > > Hi, > In the draft for RFC 2338 a virtual router is described as "An > abstract object that consists of a virtual router identifier and > a set of ip addresses across a common lan" > Question is, is the "vrid" the primary key to access this object. > Should vrrp be implemented such that the router can setup virtual routers > on different interfaces using the same vrid but with different ip > addresses, or is this vrid unique. Vivek, Since the VRID is used to derive the virtual MAC address each instance of VRRP (master and one or more backups) should be unique on a LAN segment. > If the former is true then why > would one use a vrid, when the ip addresses could act as the > primary key. You may want to define multiple VRIDs with the same set of addresses to load-share and still allow the Virtual Routers to back each other up. Isn't this clear in the RFC? > using the vrid as a primary key would improve VRRP > performance drastically. When you consider the total number of instructions to process a protocol packet and that most LAN segments with VRRP active will only be using 1 or 2 VRIDs I don't believe making VRIDs unique across a group of routers running VRRP would offer a great improvement. > > Thanks, > Vivek. -- Acee From VRRP-owner@drcoffsite.com Wed Jul 29 12:19:39 1998 Delivery-Date: Wed, 29 Jul 1998 12:19:40 -0400 Return-Path: VRRP-owner@drcoffsite.com Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id MAA09798 for ; Wed, 29 Jul 1998 12:19:39 -0400 (EDT) Received: from drcoffsite.com (dns1.drcoffsite.com [205.198.103.130]) by cnri.reston.va.us (8.8.5/8.8.7a) with SMTP id MAA17105 for ; Wed, 29 Jul 1998 12:19:24 -0400 (EDT) Received: from xylan.com [208.8.0.248] by drcoffsite.com with ESMTP (SMTPD32-4.06) id AB372703B0; Wed, 29 Jul 1998 12:17:59 +03d00 Received: from mailhub.xylan.com by xylan.com (8.8.7/SMI-SVR4 (xylan-mgw 2.1 [OUT])) id JAA02010; Wed, 29 Jul 1998 09:19:10 -0700 (PDT) Received: from utah.XYLAN.COM by mailhub.xylan.com (SMI-8.6/SMI-SVR4 (mailhub 2.1 [HUB])) id JAA03755; Wed, 29 Jul 1998 09:16:31 -0700 Received: from olympus.slcyp by utah.XYLAN.COM (SMI-8.6/SMI-SVR4 (xylan utah [SPOOL])) id KAA22850; Wed, 29 Jul 1998 10:16:30 -0600 From: lmick@xylan.com (Lori Mickelson) Message-Id: <199807291616.KAA22850@utah.XYLAN.COM> Subject: AuthType in VRRP MIB To: vrrp@drcoffsite.com Date: Wed, 29 Jul 1998 10:18:15 -0700 (PDT) X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Precedence: bulk Sender: VRRP-owner@drcoffsite.com Since the vrrpOperAuthType and vrrpOperAuthKey objects are defined as read-only in the VRRP MIB, how is one supposed to set the authentication type and key through snmp? Are you planning on defining another group in the MIB for the Authentication on a per-interface basis? Or should the Access for these objects be read-write? Thanks, Lori From VRRP-owner@drcoffsite.com Wed Jul 29 14:06:40 1998 Delivery-Date: Wed, 29 Jul 1998 14:06:41 -0400 Return-Path: VRRP-owner@drcoffsite.com Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id OAA11476 for ; Wed, 29 Jul 1998 14:06:40 -0400 (EDT) Received: from drcoffsite.com (dns1.drcoffsite.com [205.198.103.130]) by cnri.reston.va.us (8.8.5/8.8.7a) with SMTP id OAA17777 for ; Wed, 29 Jul 1998 14:06:25 -0400 (EDT) Received: from mailgate.fore.com [169.144.68.6] by drcoffsite.com with ESMTP (SMTPD32-4.06) id A3C4C902F2; Wed, 29 Jul 1998 14:02:44 +03d00 Received: from postman.sj.fore.com (postman.sj.fore.com [147.128.128.5]) by mailgate.fore.com (8.9.1/8.9.1) with ESMTP id NAA11996; Wed, 29 Jul 1998 13:58:53 -0400 (EDT) Received: from fort1.sj.fore.com (fort1 [147.128.48.234]) by postman.sj.fore.com (8.8.8/8.8.8) with SMTP id KAA08273; Wed, 29 Jul 1998 10:56:04 -0700 (PDT) Received: from localhost by fort1.sj.fore.com (SMI-8.6/SMI-SVR4) id KAA19240; Wed, 29 Jul 1998 10:56:39 -0700 Date: Wed, 29 Jul 1998 10:56:38 -0700 (PDT) From: Vivek Menezes To: Acee Lindem cc: vrrp@drcoffsite.com Subject: Re: primary key for virtual router In-Reply-To: <35BF27B7.12CA7DD9@raleigh.ibm.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Precedence: bulk Sender: VRRP-owner@drcoffsite.com On Wed, 29 Jul 1998, Acee Lindem wrote: > Vivek Menezes wrote: > > > > Hi, > > In the draft for RFC 2338 a virtual router is described as "An > > abstract object that consists of a virtual router identifier and > > a set of ip addresses across a common lan" > > Question is, is the "vrid" the primary key to access this object. > > Should vrrp be implemented such that the router can setup virtual routers > > on different interfaces using the same vrid but with different ip > > addresses, or is this vrid unique. > > Vivek, > I'm sorry but I later found out that the unique key for a virtual router is both the VRID and the set of IP addresses. (Its in VRRP overview) > Since the VRID is used to derive the virtual MAC address each instance > of VRRP (master and one or more backups) should be unique on a LAN > segment. > > > If the former is true then why > > would one use a vrid, when the ip addresses could act as the > > primary key. > > You may want to define multiple VRIDs with the same set of addresses > to load-share and still allow the Virtual Routers to back each > other up. Isn't this clear in the RFC? I dont think you should do this . An arp request for an ip address would reveal 2 or more mac address replies. Load balancing is achieved by dividing the hosts into groups using different IP addresses as their default routes. Vivek. > > > using the vrid as a primary key would improve VRRP > > performance drastically. > > When you consider the total number of instructions to process a > protocol packet and that most LAN segments with VRRP active will > only be using 1 or 2 VRIDs I don't believe making VRIDs unique > across a group of routers running VRRP would offer a great > improvement. > > > > > Thanks, > > Vivek. > > -- > Acee > From VRRP-owner@drcoffsite.com Wed Jul 29 14:24:25 1998 Delivery-Date: Wed, 29 Jul 1998 14:24:26 -0400 Return-Path: VRRP-owner@drcoffsite.com Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id OAA11616 for ; Wed, 29 Jul 1998 14:24:25 -0400 (EDT) Received: from drcoffsite.com (dns1.drcoffsite.com [205.198.103.130]) by cnri.reston.va.us (8.8.5/8.8.7a) with SMTP id OAA17887 for ; Wed, 29 Jul 1998 14:24:07 -0400 (EDT) Received: from fwns2.raleigh.ibm.com [204.146.167.236] by drcoffsite.com with ESMTP (SMTPD32-4.06) id A84BD10356; Wed, 29 Jul 1998 14:22:03 +03d00 Received: from rtpmail03.raleigh.ibm.com (rtpmail03.raleigh.ibm.com [9.37.172.47]) by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id OAA22744; Wed, 29 Jul 1998 14:20:34 -0400 Received: from aceman.raleigh.ibm.com (aceman.raleigh.ibm.com [9.37.177.119]) by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id OAA25568; Wed, 29 Jul 1998 14:20:37 -0400 Received: from loopback by aceman.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA19486; Wed, 29 Jul 1998 14:20:34 -0400 X-Sender: acee@raleigh.ibm.com Message-Id: <35BF67F2.7DE2EA7@raleigh.ibm.com> Date: Wed, 29 Jul 1998 14:20:34 -0400 From: Acee Lindem Organization: IBM Networking Divison X-Mailer: Mozilla 4.04 [en] (X11; I; AIX 4.1) Mime-Version: 1.0 To: Vivek Menezes Cc: vrrp@drcoffsite.com Subject: Re: primary key for virtual router References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Precedence: bulk Sender: VRRP-owner@drcoffsite.com Vivek Menezes wrote: > > On Wed, 29 Jul 1998, Acee Lindem wrote: > > > You may want to define multiple VRIDs with the same set of addresses > > to load-share and still allow the Virtual Routers to back each > > other up. Isn't this clear in the RFC? > > I dont think you should do this . An arp request for an ip address would > reveal 2 or more mac address replies. Load balancing is achieved by > dividing the hosts into groups using different IP addresses as their > default routes. This is exactly how you do it with VRRP. For simplicity, let's assume 2 groups with 2 default gateways. You'd then allocate 2 VRIDs and make each gateway the master wrt to one VRID and a backup wrt the other. -- Acee From VRRP-owner@drcoffsite.com Fri Jul 31 15:33:06 1998 Delivery-Date: Fri, 31 Jul 1998 15:33:06 -0400 Return-Path: VRRP-owner@drcoffsite.com Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id PAA28631 for ; Fri, 31 Jul 1998 15:33:05 -0400 (EDT) Received: from drcoffsite.com (dns1.drcoffsite.com [205.198.103.130]) by cnri.reston.va.us (8.8.5/8.8.7a) with SMTP id PAA00193 for ; Fri, 31 Jul 1998 15:32:49 -0400 (EDT) Received: from kahn.drc.com [198.22.14.98] by drcoffsite.com (SMTPD32-4.06) id AB6711D0342; Fri, 31 Jul 1998 15:30:47 +03d00 Received: from seattle.3com.com [129.213.128.97] by kahn.drc.com with ESMTP (SMTPD32-4.06) id AB151506FA; Fri, 31 Jul 1998 15:29:25 EDT Received: from new-york.3com.com (new-york.3com.com [129.213.157.12]) by seattle.3com.com (8.8.8/8.8.8) with ESMTP id MAA23061 for ; Fri, 31 Jul 1998 12:22:51 -0700 (PDT) Received: from chicago.nsd.3com.com (chicago.nsd.3com.com [129.213.157.11]) by new-york.3com.com (8.8.8/8.8.8) with ESMTP id MAA15678 for ; Fri, 31 Jul 1998 12:22:51 -0700 (PDT) Received: from fubar.nsd.3com.com (fubar.nsd.3com.com [129.213.16.41]) by chicago.nsd.3com.com (8.8.8/8.8.8) with ESMTP id MAA24883; Fri, 31 Jul 1998 12:22:50 -0700 (PDT) From: Brian Jewell Received: (from bjewell@localhost) by fubar.nsd.3com.com (8.8.2/8.8.5) id MAA04661; Fri, 31 Jul 1998 12:22:47 -0700 (PDT) Date: Fri, 31 Jul 1998 12:22:47 -0700 (PDT) Message-Id: <199807311922.MAA04661@fubar.nsd.3com.com> To: vrrp@drcoffsite.com Subject: Re: AuthType in VRRP MIB Cc: bjewell@ewd.3Com.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-MD5: LCVRUCx5FjZ8BSddOXj7ZQ== Precedence: bulk Sender: VRRP-owner@drcoffsite.com Lori, My interpretation of the 'vrrpOperAuthType' object is as follows: - It is defined on a "per-interface basis" (VRRP RFC, page 12), and hence doesn't fit very well into the 'vrrpOperTable'. - It is essentially in the 'vrrpOperTable' as it seems to be an important enough attribute of a virtual router, that maybe a network management application would want to know what it has been set to. My knowledge of IPSEC is limited, and the VRRP RFC does not go into great detail about where the authentication header (if used) would be validated (in VRRP or elsewhere?). But again, both objects would seem to provide useful information about a virtual router. Since, IPSEC is configurable from a different component than VRRP (at least on 3Com routers), it seemed to make sense to make the object "read-only", with the assumption that an equivalent object would exist as a read-write object in an (ifIndex-based) IPSEC MIB somewhere. However, I don't know that an IPSEC MIB exists yet. So, I am open to suggestions as to how to deal with 'vrrpOperAuthType' and 'vrrpOperAuthKey' in the MIB. As an aside, my interpretation of 'vrrpOperAuthKey' is that it would return a "hashed" value of the authentication key, as opposed to the actual key (for obvious security reasons). So at the very least, I think a more detailed description of this object is in order for the next MIB draft revision. In the meantime, I'll see what other input is received from concerned parties. Thanks. -Brian Jewell -3Com, Inc. -bjewell@3com.com Original comments follow: > > > Since the vrrpOperAuthType and vrrpOperAuthKey objects are defined as > read-only in the VRRP MIB, how is one supposed to set the authentication > type and key through snmp? Are you planning on defining another group > in the MIB for the Authentication on a per-interface basis? Or should > the Access for these objects be read-write? > > Thanks, > Lori > From VRRP-owner@drcoffsite.com Fri Jul 31 16:44:25 1998 Delivery-Date: Fri, 31 Jul 1998 16:44:26 -0400 Return-Path: VRRP-owner@drcoffsite.com Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id QAA29916 for ; Fri, 31 Jul 1998 16:44:25 -0400 (EDT) Received: from drcoffsite.com (dns1.drcoffsite.com [205.198.103.130]) by cnri.reston.va.us (8.8.5/8.8.7a) with SMTP id QAA00681 for ; Fri, 31 Jul 1998 16:44:11 -0400 (EDT) Received: from relay2.UU.NET [192.48.96.7] by drcoffsite.com with ESMTP (SMTPD32-4.06) id AC6659103F0; Fri, 31 Jul 1998 16:43:18 +03d00 Received: from xedia.com by relay2.UU.NET with SMTP (peer crosschecked as: madway.xedia.com [198.202.232.199]) id QQfalm21076; Fri, 31 Jul 1998 16:41:37 -0400 (EDT) Received: from skye.xedia.com by xedia.com (4.1/SMI-4.1) id AA00837; Fri, 31 Jul 98 16:41:29 EDT Received: from skye by skye.xedia.com (SMI-8.6/SMI-SVR4) id QAA24544; Fri, 31 Jul 1998 16:41:36 -0400 X-Sender: sbarvick@xedia.com Message-Id: <35C22BFF.43DC@xedia.com> Date: Fri, 31 Jul 1998 16:41:35 -0400 From: Scott Barvick X-Mailer: Mozilla 3.01Gold (X11; I; SunOS 5.6 sun4u) Mime-Version: 1.0 To: vrrp@drcoffsite.com Subject: Re: AuthType in VRRP MIB References: <199807311922.MAA04661@fubar.nsd.3com.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Precedence: bulk Sender: VRRP-owner@drcoffsite.com I forget why we are trying to make this a per-ifIndex thing. To me it is fine as a per-VR quantity. If we had a convenient per-interface MIB table, we might put it there, but because we do not, why make things confusing by trying to explain it that way. Each VR certainly can have the appropriate state to keep track of the authentication key and type and do the correct processing when an advertisement is received. Scott Brian Jewell wrote: > > Lori, > > My interpretation of the 'vrrpOperAuthType' object is as follows: > > - It is defined on a "per-interface basis" (VRRP RFC, page 12), and hence > doesn't fit very well into the 'vrrpOperTable'. > > - It is essentially in the 'vrrpOperTable' as it seems to be an important enough > attribute of a virtual router, that maybe a network management application would > want to know what it has been set to. > -- Scott Barvick sbarvick@xedia.com (978) 952-6000 x162 From VRRP-owner@drcoffsite.com Fri Jul 31 18:37:39 1998 Delivery-Date: Fri, 31 Jul 1998 18:37:40 -0400 Return-Path: VRRP-owner@drcoffsite.com Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id SAA02012 for ; Fri, 31 Jul 1998 18:37:39 -0400 (EDT) Received: from drcoffsite.com (dns1.drcoffsite.com [205.198.103.130]) by cnri.reston.va.us (8.8.5/8.8.7a) with SMTP id SAA01385 for ; Fri, 31 Jul 1998 18:37:20 -0400 (EDT) Received: from xylan.com [208.8.0.248] by drcoffsite.com with ESMTP (SMTPD32-4.06) id A6F923803CA; Fri, 31 Jul 1998 18:36:41 +03d00 Received: from mailhub.xylan.com by xylan.com (8.8.7/SMI-SVR4 (xylan-mgw 2.1 [OUT])) id PAA23824; Fri, 31 Jul 1998 15:37:57 -0700 (PDT) Received: from utah.XYLAN.COM by mailhub.xylan.com (SMI-8.6/SMI-SVR4 (mailhub 2.1 [HUB])) id PAA04822; Fri, 31 Jul 1998 15:35:16 -0700 Received: from olympus.slcyp by utah.XYLAN.COM (SMI-8.6/SMI-SVR4 (xylan utah [SPOOL])) id QAA13328; Fri, 31 Jul 1998 16:35:15 -0600 From: lmick@xylan.com (Lori Mickelson) Message-Id: <199807312235.QAA13328@utah.XYLAN.COM> Subject: Re: AuthType in VRRP MIB (fwd) To: vrrp@drcoffsite.com Date: Fri, 31 Jul 1998 16:37:01 -0700 (PDT) X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Precedence: bulk Sender: VRRP-owner@drcoffsite.com I agree with your statements, but what if the Auth type is set to None or Simple Text Password. These Authentication Types don't involve IPSEC. I realize they are still defined on a per-interface basis, but shouldn't there be a way to set this through the VRRP MIB? You have the IP Addresses as part of a separate table, maybe there should be a separate table for Authentication and have it indexed by the ifIndex. Lori Brian Jewell wrote: > My interpretation of the 'vrrpOperAuthType' object is as follows: > > - It is defined on a "per-interface basis" (VRRP RFC, page 12), and hence > doesn't fit very well into the 'vrrpOperTable'. > - It is essentially in the 'vrrpOperTable' as it seems to be an important enough > attribute of a virtual router, that maybe a network management application would > want to know what it has been set to. > > My knowledge of IPSEC is limited, and the VRRP RFC does not go into great detail > about where the authentication header (if used) would be validated (in VRRP or > elsewhere?). But again, both objects would seem to provide useful information > about a virtual router. > > Since, IPSEC is configurable from a different component than VRRP (at least on > 3Com routers), it seemed to make sense to make the object "read-only", with the > assumption that an equivalent object would exist as a read-write object in an > (ifIndex-based) IPSEC MIB somewhere. However, I don't know that an IPSEC MIB > exists yet. > > So, I am open to suggestions as to how to deal with 'vrrpOperAuthType' and > 'vrrpOperAuthKey' in the MIB. > > As an aside, my interpretation of 'vrrpOperAuthKey' is that it would return a > "hashed" value of the authentication key, as opposed to the actual key (for > obvious security reasons). So at the very least, I think a more detailed > description of this object is in order for the next MIB draft revision. > > In the meantime, I'll see what other input is received from concerned parties. > > Thanks. > > -Brian Jewell > -3Com, Inc. > -bjewell@3com.com > > Original comments follow: > > > > > > Since the vrrpOperAuthType and vrrpOperAuthKey objects are defined as > > read-only in the VRRP MIB, how is one supposed to set the authentication > > type and key through snmp? Are you planning on defining another group > > in the MIB for the Authentication on a per-interface basis? Or should > > the Access for these objects be read-write? > > > > Thanks, > > Lori > > >