From exim@www1.ietf.org Fri Aug 1 14:02:03 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02597 for ; Fri, 1 Aug 2003 14:02:03 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ieDi-0005TD-Ik for vrrp-archive@odin.ietf.org; Fri, 01 Aug 2003 14:01:38 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h71I1cop021018 for vrrp-archive@odin.ietf.org; Fri, 1 Aug 2003 14:01:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iac5-0005Fl-BA for vrrp-web-archive@optimus.ietf.org; Fri, 01 Aug 2003 10:10:33 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18810 for ; Fri, 1 Aug 2003 09:38:33 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19iZpt-0006V1-00 for vrrp-web-archive@ietf.org; Fri, 01 Aug 2003 09:20:45 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19iZmq-0005qi-00 for vrrp-web-archive@ietf.org; Fri, 01 Aug 2003 09:17:36 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iZap-0006zR-Eb for vrrp-web-archive@ietf.org; Fri, 01 Aug 2003 09:05:11 -0400 Date: Fri, 01 Aug 2003 09:05:11 -0400 Message-ID: <20030801130511.29120.20907.Mailman@www1.ietf.org> Subject: ietf.org mailing list memberships reminder From: mailman-owner@www1.ietf.org To: vrrp-web-archive@ietf.org X-No-Archive: yes X-Ack: no Sender: mailman-admin@ietf.org Errors-To: mailman-admin@ietf.org X-BeenThere: mailman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk This is a reminder, sent out once a month, about your ietf.org mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, vrrp-request@ietf.org) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. *************************************************************************** Note Well All statements related to the activities of the IETF and addressed to the IETF are subject to all provisions of Section 10 of RFC 2026, which grants to the IETF and its participants certain licenses and rights in such statements. Such statements include verbal statements in IETF meetings, as well as written and electronic communications made at any time or place, which are addressed to * the IETF plenary session, * any IETF working group or portion thereof, * the IESG, or any member thereof on behalf of the IESG, * the IAB or any member thereof on behalf of the IAB, * any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, * the RFC Editor or the Internet-Drafts function Statements made outside of an IETF meeting, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not subject to these provisions. *************************************************************************** If you have questions, problems, comments, etc, send them to mailman-owner@www1.ietf.org. Thanks! Passwords for vrrp-web-archive@ietf.org: List Password // URL ---- -------- vrrp@ietf.org mPhD https://www1.ietf.org/mailman/options/vrrp/vrrp-web-archive%40ietf.org From exim@www1.ietf.org Mon Aug 4 03:28:44 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA18730 for ; Mon, 4 Aug 2003 03:28:44 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19jZlR-0004wE-CK for vrrp-archive@odin.ietf.org; Mon, 04 Aug 2003 03:28:17 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h747SHWq018982 for vrrp-archive@odin.ietf.org; Mon, 4 Aug 2003 03:28:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19jZlQ-0004w3-Sg for vrrp-web-archive@optimus.ietf.org; Mon, 04 Aug 2003 03:28:16 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA18711 for ; Mon, 4 Aug 2003 03:28:13 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19jZlO-0006lV-00 for vrrp-web-archive@ietf.org; Mon, 04 Aug 2003 03:28:14 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19jZlO-0006lR-00 for vrrp-web-archive@ietf.org; Mon, 04 Aug 2003 03:28:14 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19jZlC-0004vI-8F; Mon, 04 Aug 2003 03:28:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19jZkG-0004ti-QB for vrrp@optimus.ietf.org; Mon, 04 Aug 2003 03:27:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA18687 for ; Mon, 4 Aug 2003 03:27:00 -0400 (EDT) From: Mukesh.Gupta@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19jZkE-0006l0-00 for vrrp@ietf.org; Mon, 04 Aug 2003 03:27:02 -0400 Received: from [63.78.179.217] (helo=mgw-dax2.ext.nokia.com) by ietf-mx with esmtp (Exim 4.12) id 19jZkD-0006kw-00 for vrrp@ietf.org; Mon, 04 Aug 2003 03:27:01 -0400 Received: from davir02nok.americas.nokia.com (davir02nok.americas.nokia.com [172.18.242.85]) by mgw-dax2.ext.nokia.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h747R2G14690 for ; Mon, 4 Aug 2003 02:27:02 -0500 (CDT) Received: from daebh001.NOE.Nokia.com (unverified) by davir02nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 4 Aug 2003 02:27:02 -0500 Received: from daebe009.NOE.Nokia.com ([172.18.242.190]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Mon, 4 Aug 2003 00:27:02 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Date: Mon, 4 Aug 2003 02:27:01 -0500 Message-ID: <8D260779A766FB4A9C1739A476F84FA42ABD3E@daebe009.americas.nokia.com> Thread-Topic: VRRP Messages thread-index: AcNYl1oI20oH8JUDT3iaaqXPWk6YIQBwmSa2 X-Priority: 1 Priority: Urgent Importance: high To: Cc: X-OriginalArrivalTime: 04 Aug 2003 07:27:02.0318 (UTC) FILETIME=[CC546CE0:01C35A59] Content-Transfer-Encoding: quoted-printable Subject: [VRRP] FW: VRRP Messages Sender: vrrp-admin@ietf.org Errors-To: vrrp-admin@ietf.org X-BeenThere: vrrp@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Virtual Router Redundancy Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable -----Original Message----- From: ext Hesham Elbakoury [mailto:helbakou@nortelnetworks.com] Sent: Fri 8/1/2003 6:42 PM To: Gupta Mukesh (IPRG/MtView) Cc:=09 Subject: VRRP Messages Hi Mukesh I have the following questions for you regarding VRRP: 1- When the master router responds to ARP request, does it use the virtual MAC address of the VR as the source MAC address of the layer 2 header of the ARP = response ? 2- What source MAC address is used by the routers in the VR = configuration when they send VR control messages (e.g. advertisements). Thanks Hesham _______________________________________________ vrrp mailing list vrrp@ietf.org https://www1.ietf.org/mailman/listinfo/vrrp From exim@www1.ietf.org Tue Aug 5 15:43:38 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26045 for ; Tue, 5 Aug 2003 15:43:38 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19k7iC-0005Ns-Bk for vrrp-archive@odin.ietf.org; Tue, 05 Aug 2003 15:43:12 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h75JhCOA020690 for vrrp-archive@odin.ietf.org; Tue, 5 Aug 2003 15:43:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19k7iC-0005Nd-3F for vrrp-web-archive@optimus.ietf.org; Tue, 05 Aug 2003 15:43:12 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26033 for ; Tue, 5 Aug 2003 15:43:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19k7iA-0005FB-00 for vrrp-web-archive@ietf.org; Tue, 05 Aug 2003 15:43:10 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19k7i9-0005F4-00 for vrrp-web-archive@ietf.org; Tue, 05 Aug 2003 15:43:09 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19k7i0-0005Mt-Vk; Tue, 05 Aug 2003 15:43:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19k7hQ-0005MI-U4 for vrrp@optimus.ietf.org; Tue, 05 Aug 2003 15:42:25 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26015 for ; Tue, 5 Aug 2003 15:42:20 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19k7hP-0005Ep-00 for vrrp@ietf.org; Tue, 05 Aug 2003 15:42:23 -0400 Received: from [216.142.75.231] (helo=exmail.bivio.net) by ietf-mx with smtp (Exim 4.12) id 19k7hO-0005El-00 for vrrp@ietf.org; Tue, 05 Aug 2003 15:42:22 -0400 Received: from dprovan1 ([192.168.24.137]) by exmail.bivio.net with Microsoft SMTPSVC(5.0.2195.2966); Tue, 5 Aug 2003 12:42:16 -0700 From: "Don Provan" To: Cc: Subject: RE: [VRRP] FW: VRRP Messages Date: Tue, 5 Aug 2003 12:42:16 -0700 Message-ID: <001001c35b89$acda9840$8918a8c0@corp.networkrobots.com> X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <8D260779A766FB4A9C1739A476F84FA42ABD3E@daebe009.americas.nokia.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Importance: Normal X-OriginalArrivalTime: 05 Aug 2003 19:42:16.0495 (UTC) FILETIME=[ACD763F0:01C35B89] Sender: vrrp-admin@ietf.org Errors-To: vrrp-admin@ietf.org X-BeenThere: vrrp@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Virtual Router Redundancy Protocol List-Post: List-Help: List-Subscribe: , > 1- When the master router responds to ARP request, does it use the > virtual MAC address of the VR > as the source MAC address of the layer 2 header of the > ARP response ? > 2- What source MAC address is used by the routers in the > VR configuration > when they send VR control > messages (e.g. advertisements). VR advertisements, and only VR advertisements, should be sent with a source address in the layer two header set to the VR MAC address. I think there are two principle reasons for not using the VR MAC address as the layer 2 source in any other packets. First, VR advertisements are the only packets guaranteed to only be sent when you own the address, so it avoids the possibility of using it when you shouldn't. Second, you always want to be able to identify the host that sent any given packet so you can debug problems. -don _______________________________________________ vrrp mailing list vrrp@ietf.org https://www1.ietf.org/mailman/listinfo/vrrp From exim@www1.ietf.org Wed Aug 6 21:02:35 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA12154 for ; Wed, 6 Aug 2003 21:02:35 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kZAO-0002Rm-Ka for vrrp-archive@odin.ietf.org; Wed, 06 Aug 2003 21:02:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h77128xl009402 for vrrp-archive@odin.ietf.org; Wed, 6 Aug 2003 21:02:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kZAO-0002RZ-Gv for vrrp-web-archive@optimus.ietf.org; Wed, 06 Aug 2003 21:02:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA12148 for ; Wed, 6 Aug 2003 21:02:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kZAM-00012r-00 for vrrp-web-archive@ietf.org; Wed, 06 Aug 2003 21:02:06 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19kZAL-00012n-00 for vrrp-web-archive@ietf.org; Wed, 06 Aug 2003 21:02:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kZAH-0002R1-3s; Wed, 06 Aug 2003 21:02:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kZ9a-0002Qi-KJ for vrrp@optimus.ietf.org; Wed, 06 Aug 2003 21:01:18 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA12129 for ; Wed, 6 Aug 2003 21:01:14 -0400 (EDT) From: Mukesh.Gupta@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kZ9Y-00012U-00 for vrrp@ietf.org; Wed, 06 Aug 2003 21:01:16 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 19kZ9X-00012Q-00 for vrrp@ietf.org; Wed, 06 Aug 2003 21:01:15 -0400 Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h7711EJ06726 for ; Thu, 7 Aug 2003 04:01:15 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Thu, 7 Aug 2003 04:01:14 +0300 Received: from daebh001.NOE.Nokia.com ([172.18.242.231]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 7 Aug 2003 04:01:14 +0300 Received: from daebe009.NOE.Nokia.com ([172.18.242.190]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 6 Aug 2003 17:59:58 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: FW: [VRRP] Working Group Last Call for draft-ietf-vrrp-spec-v2-08.txt Date: Wed, 6 Aug 2003 19:59:57 -0500 Message-ID: <8D260779A766FB4A9C1739A476F84FA476C3E1@daebe009.americas.nokia.com> Thread-Topic: Working Group Last Call for draft-ietf-vrrp-spec-v2-08.txt thread-index: AcNQdzfFbMKvv2PORvqXv1GGLC5tTQMBs0Bw To: X-OriginalArrivalTime: 07 Aug 2003 00:59:58.0345 (UTC) FILETIME=[39009F90:01C35C7F] Content-Transfer-Encoding: quoted-printable Sender: vrrp-admin@ietf.org Errors-To: vrrp-admin@ietf.org X-BeenThere: vrrp@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Virtual Router Redundancy Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable The WG last call for this draft has ended. The only thing that needs to be fixed is the authors list (unless Bob = has received any comments directly to him). In the WG meeting in Vienna, = the conclusion of the discussion was that Bob Hinden should be listed as = "editor", and a "contributors" section should be added acknowledging the = others. (this can be found in the meeting minutes) I want to confirm this decision on the mailing list. If anyone = (specially folks that are listed as authors in the draft) has any = opposition to this proposal, please respond. If I don't see any opposition till 10th Aug, I will assume that everyone = is ok with it and I will ask Bob to submit the final version of the = draft with this change. regards Mukesh -----Original Message----- From: ext Mukesh.Gupta@nokia.com [mailto:Mukesh.Gupta@nokia.com] Sent: Tuesday, July 22, 2003 10:33 AM To: vrrp@ietf.org Subject: [VRRP] Working Group Last Call for draft-ietf-vrrp-spec-v2-08.txt This is a VRRP working group last call for comments on advancing the = following document as a Draft Standard: Title : Virtual Router Redundancy Protocol Author(s) : R. Hinden, P. Hunt, D. Mitzel, P. Higginson, M. Shand, A. Lindem, S. Knight, D. Weaver, D. Whipple Filename : draft-ietf-vrrp-spec-v2-08.txt Pages : 31 Please send substantive comments to the VRRP mailing list, and minor = editorial comments to the author(s). This last call period will end two = week from today on Tuesday, August 5th, 2003. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-vrrp-spec-v2-08.txt - Mukesh & Radia _______________________________________________ vrrp mailing list vrrp@ietf.org https://www1.ietf.org/mailman/listinfo/vrrp _______________________________________________ vrrp mailing list vrrp@ietf.org https://www1.ietf.org/mailman/listinfo/vrrp From exim@www1.ietf.org Thu Aug 14 11:43:32 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15641 for ; Thu, 14 Aug 2003 11:43:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nKFm-0000w2-9N for vrrp-archive@odin.ietf.org; Thu, 14 Aug 2003 11:43:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7EFh6RX003590 for vrrp-archive@odin.ietf.org; Thu, 14 Aug 2003 11:43:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nKFl-0000vp-Qi for vrrp-web-archive@optimus.ietf.org; Thu, 14 Aug 2003 11:43:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15629 for ; Thu, 14 Aug 2003 11:43:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19nKFk-0003az-00 for vrrp-web-archive@ietf.org; Thu, 14 Aug 2003 11:43:04 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19nKFk-0003av-00 for vrrp-web-archive@ietf.org; Thu, 14 Aug 2003 11:43:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nKFh-0000vB-Df; Thu, 14 Aug 2003 11:43:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nJ4n-0004x1-Fd for vrrp@optimus.ietf.org; Thu, 14 Aug 2003 10:27:41 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11979; Thu, 14 Aug 2003 10:27:35 -0400 (EDT) Message-Id: <200308141427.KAA11979@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: vrrp@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Thu, 14 Aug 2003 10:27:35 -0400 Subject: [VRRP] I-D ACTION:draft-ietf-vrrp-spec-v2-09.txt Sender: vrrp-admin@ietf.org Errors-To: vrrp-admin@ietf.org X-BeenThere: vrrp@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Virtual Router Redundancy Protocol List-Post: List-Help: List-Subscribe: , --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) : R. Hinden Filename : draft-ietf-vrrp-spec-v2-09.txt Pages : 30 Date : 2003-8-14 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 replaces RFC2338 'Virtual Router Redundancy Protocol'. RFC2338 will become historic. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-vrrp-spec-v2-09.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also 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-v2-09.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-vrrp-spec-v2-09.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: <2003-8-14091812.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-vrrp-spec-v2-09.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-vrrp-spec-v2-09.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-8-14091812.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ vrrp mailing list vrrp@ietf.org https://www1.ietf.org/mailman/listinfo/vrrp From exim@www1.ietf.org Fri Aug 15 13:44:33 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06308 for ; Fri, 15 Aug 2003 13:44:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nicQ-0007wy-My for vrrp-archive@odin.ietf.org; Fri, 15 Aug 2003 13:44:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7FHi6s1030556 for vrrp-archive@odin.ietf.org; Fri, 15 Aug 2003 13:44:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nicQ-0007wl-IN for vrrp-web-archive@optimus.ietf.org; Fri, 15 Aug 2003 13:44:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06291 for ; Fri, 15 Aug 2003 13:44:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19nicO-0004cO-00 for vrrp-web-archive@ietf.org; Fri, 15 Aug 2003 13:44:04 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19nicN-0004cK-00 for vrrp-web-archive@ietf.org; Fri, 15 Aug 2003 13:44:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nicK-0007wG-Kb; Fri, 15 Aug 2003 13:44:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nibt-0007sM-9U for vrrp@optimus.ietf.org; Fri, 15 Aug 2003 13:43:33 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06267 for ; Fri, 15 Aug 2003 13:43:28 -0400 (EDT) From: Mukesh.Gupta@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19nibr-0004bf-00 for vrrp@ietf.org; Fri, 15 Aug 2003 13:43:31 -0400 Received: from [63.78.179.217] (helo=mgw-dax2.ext.nokia.com) by ietf-mx with esmtp (Exim 4.12) id 19nibq-0004bb-00 for vrrp@ietf.org; Fri, 15 Aug 2003 13:43:30 -0400 Received: from davir04nok.americas.nokia.com (davir04nok.americas.nokia.com [172.18.242.87]) by mgw-dax2.ext.nokia.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h7FHhQG20173 for ; Fri, 15 Aug 2003 12:43:26 -0500 (CDT) Received: from daebh002.NOE.Nokia.com (unverified) by davir04nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Fri, 15 Aug 2003 12:43:25 -0500 Received: from daebe009.NOE.Nokia.com ([172.18.242.190]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 15 Aug 2003 12:42:39 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 15 Aug 2003 12:42:39 -0500 Message-ID: <8D260779A766FB4A9C1739A476F84FA42ABD61@daebe009.americas.nokia.com> Thread-Topic: Subsecond Timers for VRRPv3 Thread-Index: AcNjVJ7QRtFS2l92QOmHEDCO6ujTpw== To: X-OriginalArrivalTime: 15 Aug 2003 17:42:39.0640 (UTC) FILETIME=[9F3BB980:01C36354] Content-Transfer-Encoding: quoted-printable Subject: [VRRP] Subsecond Timers for VRRPv3 Sender: vrrp-admin@ietf.org Errors-To: vrrp-admin@ietf.org X-BeenThere: vrrp@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Virtual Router Redundancy Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Folks, In the WG meeting in Vienna, we all agreed that the=20 sub-second timers should be allowed at least in VRRPv3=20 but we couldn't agree about the granularity of the=20 advertizing interval for allowing them. There were concerns that if we allow the advertizing intervals in miliseconds, it will allow the user to bombard the LAN with VRRP packets which is dangerous. Advertizing intervals in the units of 1/10 seconds or 1/100 seconds seemed like good choices. We would like to know what is everyone's opinion=20 about this. Please reply with your preference. 1) 1/10 second 2) 1/100 second 3) 1/1000 second (miliseconds) regards Mukesh _______________________________________________ vrrp mailing list vrrp@ietf.org https://www1.ietf.org/mailman/listinfo/vrrp From exim@www1.ietf.org Fri Aug 15 14:42:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08107 for ; Fri, 15 Aug 2003 14:42:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19njWW-0002s8-09 for vrrp-archive@odin.ietf.org; Fri, 15 Aug 2003 14:42:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7FIg3LP011034 for vrrp-archive@odin.ietf.org; Fri, 15 Aug 2003 14:42:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19njWV-0002rt-Rx for vrrp-web-archive@optimus.ietf.org; Fri, 15 Aug 2003 14:42:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08096 for ; Fri, 15 Aug 2003 14:41:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19njWT-00056K-00 for vrrp-web-archive@ietf.org; Fri, 15 Aug 2003 14:42:01 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19njWS-00056G-00 for vrrp-web-archive@ietf.org; Fri, 15 Aug 2003 14:42:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19njWU-0002rU-AE; Fri, 15 Aug 2003 14:42:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19njVy-0002qY-65 for vrrp@optimus.ietf.org; Fri, 15 Aug 2003 14:41:30 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08086 for ; Fri, 15 Aug 2003 14:41:24 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19njVv-000562-00 for vrrp@ietf.org; Fri, 15 Aug 2003 14:41:27 -0400 Received: from [147.28.0.15] (helo=elf.layer8.net) by ietf-mx with smtp (Exim 4.12) id 19njVu-00055I-00 for vrrp@ietf.org; Fri, 15 Aug 2003 14:41:26 -0400 Received: (qmail 69821 invoked by uid 1000); 15 Aug 2003 18:30:47 -0000 Date: Fri, 15 Aug 2003 11:30:47 -0700 From: Ben Black To: Mukesh.Gupta@nokia.com Cc: vrrp@ietf.org Subject: Re: [VRRP] Subsecond Timers for VRRPv3 Message-ID: <20030815183047.GD67258@layer8.net> References: <8D260779A766FB4A9C1739A476F84FA42ABD61@daebe009.americas.nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8D260779A766FB4A9C1739A476F84FA42ABD61@daebe009.americas.nokia.com> User-Agent: Mutt/1.4.1i Sender: vrrp-admin@ietf.org Errors-To: vrrp-admin@ietf.org X-BeenThere: vrrp@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Virtual Router Redundancy Protocol List-Post: List-Help: List-Subscribe: , It would be especially short-sighted to use coarse-grained timers. I don't see a problem with millisecond resolution. Also, keeping people from doing something stupid, like setting the timers to 1ms on a 10Mb/s LAN, would seem like an implementation decision, not the sort of thing that should be built into the protocol. Ben On Fri, Aug 15, 2003 at 12:42:39PM -0500, Mukesh.Gupta@nokia.com wrote: > Folks, > > In the WG meeting in Vienna, we all agreed that the > sub-second timers should be allowed at least in VRRPv3 > but we couldn't agree about the granularity of the > advertizing interval for allowing them. > > There were concerns that if we allow the advertizing > intervals in miliseconds, it will allow the user to > bombard the LAN with VRRP packets which is dangerous. > > Advertizing intervals in the units of 1/10 seconds > or 1/100 seconds seemed like good choices. > > We would like to know what is everyone's opinion > about this. Please reply with your preference. > > 1) 1/10 second > 2) 1/100 second > 3) 1/1000 second (miliseconds) > > regards > Mukesh > > _______________________________________________ > vrrp mailing list > vrrp@ietf.org > https://www1.ietf.org/mailman/listinfo/vrrp _______________________________________________ vrrp mailing list vrrp@ietf.org https://www1.ietf.org/mailman/listinfo/vrrp From exim@www1.ietf.org Fri Aug 15 14:53:34 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08360 for ; Fri, 15 Aug 2003 14:53:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19njhE-0003LQ-Pn for vrrp-archive@odin.ietf.org; Fri, 15 Aug 2003 14:53:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7FIr8lh012850 for vrrp-archive@odin.ietf.org; Fri, 15 Aug 2003 14:53:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19njhD-0003KT-8I for vrrp-web-archive@optimus.ietf.org; Fri, 15 Aug 2003 14:53:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08344 for ; Fri, 15 Aug 2003 14:53:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19njhA-00059u-00 for vrrp-web-archive@ietf.org; Fri, 15 Aug 2003 14:53:04 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19njh9-00059r-00 for vrrp-web-archive@ietf.org; Fri, 15 Aug 2003 14:53:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19njh6-0003IU-T4; Fri, 15 Aug 2003 14:53:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19njh5-0003ID-Ap for vrrp@optimus.ietf.org; Fri, 15 Aug 2003 14:52:59 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08329 for ; Fri, 15 Aug 2003 14:52:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19njh2-00059f-00 for vrrp@ietf.org; Fri, 15 Aug 2003 14:52:56 -0400 Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by ietf-mx with esmtp (Exim 4.12) id 19njh1-00059a-00 for vrrp@ietf.org; Fri, 15 Aug 2003 14:52:55 -0400 Received: from sydney.East.Sun.COM ([129.148.9.16]) by nwkea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h7FIqOQ3009730 for ; Fri, 15 Aug 2003 11:52:25 -0700 (PDT) Received: from sr1-ubur-06 (sr1-ubur-06 [129.148.9.86]) by sydney.East.Sun.COM (8.11.7+Sun/8.11.7/ENSMAIL,v2.2) with SMTP id h7FIqOs04457 for ; Fri, 15 Aug 2003 14:52:24 -0400 (EDT) Message-Id: <200308151852.h7FIqOs04457@sydney.East.Sun.COM> Date: Fri, 15 Aug 2003 14:52:24 -0400 (EDT) From: Radia Perlman - Boston Center for Networking Reply-To: Radia Perlman - Boston Center for Networking To: vrrp@ietf.org MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: 73nlt++Q1Ui0HYoNsfHjJw== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.5.3_06 SunOS 5.9 sun4u sparc Subject: [VRRP] And subsecond timers for IPv4 Sender: vrrp-admin@ietf.org Errors-To: vrrp-admin@ietf.org X-BeenThere: vrrp@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Virtual Router Redundancy Protocol List-Post: List-Help: List-Subscribe: , Doing it for v3 is straightforward, since there's no compatibility issue, and as Mukesh's note says, the only issue is what the units should be. The other issue is whether to make a new version of VRRP for IPv4 that uses subsecond timers. The issues for that are: 1) what is the encoding of the field, given that it can't be expanded beyond a byte. I think it was Bill Fenner at the meeting that said that some spec or another did some exponential type encoding, and that we might as well copy something someone else has done. If someone can give a pointer to that, that would be helpful. 2) how to (and whether to) mix VRRP-for-IPv4 routers that only do units of seconds with ones that do subseconds. Let's say we want to do this...where the new guys would like to use subsecond granularity, but will be willing to only be seconds if there's a VRRPv2 router on the link. So how do they do this? They could send a new version number (let's say 4), and it won't confuse the old guy (the spec says it must discard it). However, if there is an old guy, that means that the new guys have to speak v2, in units of seconds. Presumably they know an old guy is there because they see a VRRP message with version=2. Suppose someone upgrades the last old guy. How will the new guys know that their neighbors are really new guys even though those neighbors are emitting v2 messages? That, by the way, is why I like two fields "version of this message", and "version I can speak". In IKEv2, FYI, we did it with one additional bit: a flag that says "I could speak a higher version" But with the current VRRP encoding, I don't even see any reserved bits we could use to signal subsecond capability. Radia _______________________________________________ vrrp mailing list vrrp@ietf.org https://www1.ietf.org/mailman/listinfo/vrrp From exim@www1.ietf.org Fri Aug 15 15:59:34 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11387 for ; Fri, 15 Aug 2003 15:59:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nkj5-0007BS-OP for vrrp-archive@odin.ietf.org; Fri, 15 Aug 2003 15:59:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7FJx78o027608 for vrrp-archive@odin.ietf.org; Fri, 15 Aug 2003 15:59:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nkj5-0007BD-Jk for vrrp-web-archive@optimus.ietf.org; Fri, 15 Aug 2003 15:59:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11375 for ; Fri, 15 Aug 2003 15:59:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19nkj3-0005YR-00 for vrrp-web-archive@ietf.org; Fri, 15 Aug 2003 15:59:06 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19nkj3-0005YO-00 for vrrp-web-archive@ietf.org; Fri, 15 Aug 2003 15:59:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nkiz-0007Aj-3l; Fri, 15 Aug 2003 15:59:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nkiv-00078s-3j for vrrp@optimus.ietf.org; Fri, 15 Aug 2003 15:58:57 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11368 for ; Fri, 15 Aug 2003 15:58:52 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19nkit-0005Y9-00 for vrrp@ietf.org; Fri, 15 Aug 2003 15:58:55 -0400 Received: from web10603.mail.yahoo.com ([216.136.130.167]) by ietf-mx with smtp (Exim 4.12) id 19nkis-0005Y6-00 for vrrp@ietf.org; Fri, 15 Aug 2003 15:58:54 -0400 Message-ID: <20030815195853.29435.qmail@web10603.mail.yahoo.com> Received: from [63.99.114.4] by web10603.mail.yahoo.com via HTTP; Fri, 15 Aug 2003 12:58:53 PDT Date: Fri, 15 Aug 2003 12:58:53 -0700 (PDT) From: danny mitzel Subject: Re: [VRRP] Subsecond Timers for VRRPv3 To: Mukesh.Gupta@nokia.com, vrrp@ietf.org In-Reply-To: <8D260779A766FB4A9C1739A476F84FA42ABD61@daebe009.americas.nokia.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: vrrp-admin@ietf.org Errors-To: vrrp-admin@ietf.org X-BeenThere: vrrp@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Virtual Router Redundancy Protocol List-Post: List-Help: List-Subscribe: , --- Mukesh.Gupta@nokia.com wrote: > In the WG meeting in Vienna, we all agreed that the > sub-second timers should be allowed at least in > VRRPv3 since I missed the working group meeting and didn't see explicit justification for this decision in the meeting minutes I'm wondering if someone could summarize the justification for this feature? I don't have the paper right here in front of me, but the original vrrpv2 design incorporated findings from the higginson&shand DEC TR referenced in the RFC. a simple picture showing a generalized internetwork, illustrating where failures could occur in end-to-end connectivity, and then expected recovery interval for typical IETF standardized protocols. basically illustrated that protocol recovery on the order of seconds was inline with Internet standards. have these findings changed? is there a movement toward end-to-end connectivity containing only vrrp ``routing'' and L2 with transparent, sub-second recovery? later,danny __________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com _______________________________________________ vrrp mailing list vrrp@ietf.org https://www1.ietf.org/mailman/listinfo/vrrp From exim@www1.ietf.org Fri Aug 15 16:08:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11691 for ; Fri, 15 Aug 2003 16:08:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nkrj-0008CZ-7F for vrrp-archive@odin.ietf.org; Fri, 15 Aug 2003 16:08:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7FK83Yu031521 for vrrp-archive@odin.ietf.org; Fri, 15 Aug 2003 16:08:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nkrj-0008CK-3J for vrrp-web-archive@optimus.ietf.org; Fri, 15 Aug 2003 16:08:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11664 for ; Fri, 15 Aug 2003 16:07:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19nkrh-0005co-00 for vrrp-web-archive@ietf.org; Fri, 15 Aug 2003 16:08:01 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19nkrg-0005cl-00 for vrrp-web-archive@ietf.org; Fri, 15 Aug 2003 16:08:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nkrh-0008Bd-NL; Fri, 15 Aug 2003 16:08:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nkqz-000807-B4 for vrrp@optimus.ietf.org; Fri, 15 Aug 2003 16:07:17 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11619 for ; Fri, 15 Aug 2003 16:07:12 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19nkqx-0005cW-00 for vrrp@ietf.org; Fri, 15 Aug 2003 16:07:15 -0400 Received: from web10602.mail.yahoo.com ([216.136.130.166]) by ietf-mx with smtp (Exim 4.12) id 19nkqw-0005cT-00 for vrrp@ietf.org; Fri, 15 Aug 2003 16:07:14 -0400 Message-ID: <20030815200712.48723.qmail@web10602.mail.yahoo.com> Received: from [63.99.114.4] by web10602.mail.yahoo.com via HTTP; Fri, 15 Aug 2003 13:07:12 PDT Date: Fri, 15 Aug 2003 13:07:12 -0700 (PDT) From: danny mitzel Subject: Re: [VRRP] And subsecond timers for IPv4 To: Radia Perlman - Boston Center for Networking , vrrp@ietf.org In-Reply-To: <200308151852.h7FIqOs04457@sydney.East.Sun.COM> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: vrrp-admin@ietf.org Errors-To: vrrp-admin@ietf.org X-BeenThere: vrrp@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Virtual Router Redundancy Protocol List-Post: List-Help: List-Subscribe: , --- Radia Perlman - Boston Center for Networking wrote: > I think it was Bill Fenner at the meeting > that said that some spec or another did some > exponential type encoding, and that we might > as well copy something someone else has done. > If someone can give a pointer to that, that > would be helpful. look at the igmpv3 rfc3376. membership query message max response time (secton 4.1.1) or querier interval (section 4.1.7). these fields actually encode both a linear range of values and an exponential encoding based on a flag bit. __________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com _______________________________________________ vrrp mailing list vrrp@ietf.org https://www1.ietf.org/mailman/listinfo/vrrp From exim@www1.ietf.org Fri Aug 15 16:12:28 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11812 for ; Fri, 15 Aug 2003 16:12:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nkva-0008SO-Do for vrrp-archive@odin.ietf.org; Fri, 15 Aug 2003 16:12:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7FKC2YO032471 for vrrp-archive@odin.ietf.org; Fri, 15 Aug 2003 16:12:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nkva-0008RB-AB for vrrp-web-archive@optimus.ietf.org; Fri, 15 Aug 2003 16:12:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11800 for ; Fri, 15 Aug 2003 16:11:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19nkvY-0005em-00 for vrrp-web-archive@ietf.org; Fri, 15 Aug 2003 16:12:00 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19nkvY-0005ej-00 for vrrp-web-archive@ietf.org; Fri, 15 Aug 2003 16:12:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nkvY-0008PT-TH; Fri, 15 Aug 2003 16:12:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nkub-0008Oc-Ch for vrrp@optimus.ietf.org; Fri, 15 Aug 2003 16:11:01 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11785 for ; Fri, 15 Aug 2003 16:10:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19nkuZ-0005eH-00 for vrrp@ietf.org; Fri, 15 Aug 2003 16:10:59 -0400 Received: from motgate2.mot.com ([136.182.1.10]) by ietf-mx with esmtp (Exim 4.12) id 19nkuY-0005eE-00 for vrrp@ietf.org; Fri, 15 Aug 2003 16:10:59 -0400 Received: from az33exr04.mot.com (az33exr04.mot.com [10.64.251.234]) by motgate2.mot.com (Motorola/Motgate2) with ESMTP id h7FKAwAD027536 for ; Fri, 15 Aug 2003 13:10:58 -0700 (MST) Received: from il06exb01.corp.mot.com (il06exb01.corp.mot.com [10.0.111.59]) by az33exr04.mot.com (Motorola/az33exr04) with ESMTP id h7FKAuMP016047 for ; Fri, 15 Aug 2003 15:10:57 -0500 Received: by il06exb01.corp.mot.com with Internet Mail Service (5.5.2657.2) id ; Fri, 15 Aug 2003 15:10:56 -0500 Message-ID: <7BEC4504753E234FB2F71866AAAD196D37C3A1@il06exm03.corp.mot.com> From: Mathur Sonum-CSM109 To: "'Mukesh.Gupta@nokia.com'" , vrrp@ietf.org Subject: RE: [VRRP] Subsecond Timers for VRRPv3 Date: Fri, 15 Aug 2003 15:10:54 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.2) Content-Type: text/plain; charset="iso-8859-1" Sender: vrrp-admin@ietf.org Errors-To: vrrp-admin@ietf.org X-BeenThere: vrrp@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Virtual Router Redundancy Protocol List-Post: List-Help: List-Subscribe: , We are in favor of 1/10 second. It is definitely a good idea to include this in the new version of VRRP for IPv4 and get it standardised. One suggestion to do this is to use one of the unused bits in the packet. The bit setting can indicate that the units in Advert Int are in seconds or in 1/10th of second. -- Sonum > -----Original Message----- > From: Mukesh.Gupta@nokia.com [mailto:Mukesh.Gupta@nokia.com] > Sent: Friday, August 15, 2003 10:43 AM > To: vrrp@ietf.org > Subject: [VRRP] Subsecond Timers for VRRPv3 > > > Folks, > > In the WG meeting in Vienna, we all agreed that the > sub-second timers should be allowed at least in VRRPv3 > but we couldn't agree about the granularity of the > advertizing interval for allowing them. > > There were concerns that if we allow the advertizing > intervals in miliseconds, it will allow the user to > bombard the LAN with VRRP packets which is dangerous. > > Advertizing intervals in the units of 1/10 seconds > or 1/100 seconds seemed like good choices. > > We would like to know what is everyone's opinion > about this. Please reply with your preference. > > 1) 1/10 second > 2) 1/100 second > 3) 1/1000 second (miliseconds) > > regards > Mukesh > > _______________________________________________ > vrrp mailing list > vrrp@ietf.org > https://www1.ietf.org/mailman/listinfo/vrrp > _______________________________________________ vrrp mailing list vrrp@ietf.org https://www1.ietf.org/mailman/listinfo/vrrp From exim@www1.ietf.org Fri Aug 15 16:24:28 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12155 for ; Fri, 15 Aug 2003 16:24:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nl7C-0000yH-Ov for vrrp-archive@odin.ietf.org; Fri, 15 Aug 2003 16:24:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7FKO2U5003727 for vrrp-archive@odin.ietf.org; Fri, 15 Aug 2003 16:24:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nl7C-0000y2-Kw for vrrp-web-archive@optimus.ietf.org; Fri, 15 Aug 2003 16:24:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12124 for ; Fri, 15 Aug 2003 16:23:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19nl7A-0005kt-00 for vrrp-web-archive@ietf.org; Fri, 15 Aug 2003 16:24:00 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19nl7A-0005kq-00 for vrrp-web-archive@ietf.org; Fri, 15 Aug 2003 16:24:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nl7B-0000xZ-2D; Fri, 15 Aug 2003 16:24:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nl6s-0000wb-46 for vrrp@optimus.ietf.org; Fri, 15 Aug 2003 16:23:42 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12095 for ; Fri, 15 Aug 2003 16:23:37 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19nl6q-0005kD-00 for vrrp@ietf.org; Fri, 15 Aug 2003 16:23:40 -0400 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 19nl6p-0005jy-00 for vrrp@ietf.org; Fri, 15 Aug 2003 16:23:39 -0400 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h7FKN7T31987; Fri, 15 Aug 2003 13:23:07 -0700 X-mProtect: <200308152023> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.9.199, claiming to be "spruce.iprg.nokia.com") by darkstar.iprg.nokia.com smtpdPfRXc7; Fri, 15 Aug 2003 13:23:05 PDT Message-Id: <4.3.2.7.2.20030815131718.02aa4a30@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 15 Aug 2003 13:21:42 -0700 To: Mathur Sonum-CSM109 From: Bob Hinden Subject: RE: [VRRP] Subsecond Timers for VRRPv3 Cc: vrrp@ietf.org In-Reply-To: <7BEC4504753E234FB2F71866AAAD196D37C3A1@il06exm03.corp.mot. com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: vrrp-admin@ietf.org Errors-To: vrrp-admin@ietf.org X-BeenThere: vrrp@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Virtual Router Redundancy Protocol List-Post: List-Help: List-Subscribe: , Sonum, At 01:10 PM 8/15/2003, Mathur Sonum-CSM109 wrote: >We are in favor of 1/10 second. It is definitely a good idea to include >this in the new version of VRRP for IPv4 and get it standardised. One >suggestion to do this is to use one of the unused bits in the packet. The >bit setting can indicate that the units in Advert Int are in seconds or in >1/10th of second. But unless the version was changed, a receiver who didn't know about the change would not know to look at that bit and there would be interoperabiltiy and/or stability problems. Might as well just redefine the value to be 1/10 of second in a new version. Bob _______________________________________________ vrrp mailing list vrrp@ietf.org https://www1.ietf.org/mailman/listinfo/vrrp From exim@www1.ietf.org Fri Aug 15 17:40:30 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14963 for ; Fri, 15 Aug 2003 17:40:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nmIn-000610-Nv for vrrp-archive@odin.ietf.org; Fri, 15 Aug 2003 17:40:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7FLe5uB023116 for vrrp-archive@odin.ietf.org; Fri, 15 Aug 2003 17:40:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nmIn-00060l-IW for vrrp-web-archive@optimus.ietf.org; Fri, 15 Aug 2003 17:40:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14954 for ; Fri, 15 Aug 2003 17:39:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19nmIl-0006RU-00 for vrrp-web-archive@ietf.org; Fri, 15 Aug 2003 17:40:03 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19nmIk-0006RR-00 for vrrp-web-archive@ietf.org; Fri, 15 Aug 2003 17:40:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nmIi-000604-Uy; Fri, 15 Aug 2003 17:40:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nmIP-0005zR-De for vrrp@optimus.ietf.org; Fri, 15 Aug 2003 17:39:41 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14948 for ; Fri, 15 Aug 2003 17:39:35 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19nmIM-0006RI-00 for vrrp@ietf.org; Fri, 15 Aug 2003 17:39:38 -0400 Received: from [216.142.75.231] (helo=exmail.bivio.net) by ietf-mx with smtp (Exim 4.12) id 19nmIM-0006RF-00 for vrrp@ietf.org; Fri, 15 Aug 2003 17:39:38 -0400 Received: from dprovan1 ([192.168.24.137]) by exmail.bivio.net with Microsoft SMTPSVC(5.0.2195.2966); Fri, 15 Aug 2003 14:39:35 -0700 From: "Don Provan" To: "'Radia Perlman - Boston Center for Networking'" Cc: Subject: RE: [VRRP] And subsecond timers for IPv4 Date: Fri, 15 Aug 2003 14:39:33 -0700 Message-ID: <000301c36375$b83154b0$8918a8c0@corp.networkrobots.com> X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: <200308151852.h7FIqOs04457@sydney.East.Sun.COM> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 X-OriginalArrivalTime: 15 Aug 2003 21:39:35.0188 (UTC) FILETIME=[B85C3540:01C36375] Sender: vrrp-admin@ietf.org Errors-To: vrrp-admin@ietf.org X-BeenThere: vrrp@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Virtual Router Redundancy Protocol List-Post: List-Help: List-Subscribe: , > 2) how to (and whether to) mix VRRP-for-IPv4 routers that only do > units of seconds with ones that do subseconds. > > Let's say we want to do this...where the new guys would like to use > subsecond granularity, but will be willing to only be seconds > if there's a VRRPv2 router on the link. I could see something like this in other protocols, but the fact that only the master system sends VRRP packets makes it really hard to negotiate. The only way to hear from the dissenters involves them sending a packet that takes over the VR MAC address. Add to that the fact that different systems would be using different intervals depending on whether they think there are v2 nodes present, and I don't see much hope. If we want subsecond timers in IPv4, I think just redefining the unit for a new version is the most reasonable approach. For backward compatibility, the spec can suggest or even insist that implementations support both versions depending on how they're configured. Once all nodes are upgraded, changing the interval is simply a matter of reconfiguring all the routers, just like it is in v2. -don _______________________________________________ vrrp mailing list vrrp@ietf.org https://www1.ietf.org/mailman/listinfo/vrrp From exim@www1.ietf.org Fri Aug 15 18:14:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16138 for ; Fri, 15 Aug 2003 18:14:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nmpg-0007XT-KY for vrrp-archive@odin.ietf.org; Fri, 15 Aug 2003 18:14:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7FME4qM028973 for vrrp-archive@odin.ietf.org; Fri, 15 Aug 2003 18:14:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nmpg-0007XE-Ed for vrrp-web-archive@optimus.ietf.org; Fri, 15 Aug 2003 18:14:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16088 for ; Fri, 15 Aug 2003 18:13:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19nmpd-0006Vg-00 for vrrp-web-archive@ietf.org; Fri, 15 Aug 2003 18:14:01 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19nmpc-0006Vd-00 for vrrp-web-archive@ietf.org; Fri, 15 Aug 2003 18:14:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nmpc-0007Wl-Ow; Fri, 15 Aug 2003 18:14:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nmoj-0007Uq-5D for vrrp@optimus.ietf.org; Fri, 15 Aug 2003 18:13:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16012 for ; Fri, 15 Aug 2003 18:12:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19nmog-0006VZ-00 for vrrp@ietf.org; Fri, 15 Aug 2003 18:13:02 -0400 Received: from brmea-mail-3.sun.com ([192.18.98.34]) by ietf-mx with esmtp (Exim 4.12) id 19nmof-0006VW-00 for vrrp@ietf.org; Fri, 15 Aug 2003 18:13:01 -0400 Received: from sydney.East.Sun.COM ([129.148.9.16]) by brmea-mail-3.sun.com (8.12.9/8.12.9) with ESMTP id h7FMCs6Q015621; Fri, 15 Aug 2003 16:12:55 -0600 (MDT) Received: from sr1-ubur-06 (sr1-ubur-06 [129.148.9.86]) by sydney.East.Sun.COM (8.11.7+Sun/8.11.7/ENSMAIL,v2.2) with SMTP id h7FMCss26011; Fri, 15 Aug 2003 18:12:54 -0400 (EDT) Message-Id: <200308152212.h7FMCss26011@sydney.East.Sun.COM> Date: Fri, 15 Aug 2003 18:12:54 -0400 (EDT) From: Radia Perlman - Boston Center for Networking Reply-To: Radia Perlman - Boston Center for Networking Subject: RE: [VRRP] And subsecond timers for IPv4 To: Radia.Perlman@sun.com, dprovan@bivio.net Cc: vrrp@ietf.org MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: tUxAAs68kGQVg4d6YyPgCg== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.5.3_06 SunOS 5.9 sun4u sparc Sender: vrrp-admin@ietf.org Errors-To: vrrp-admin@ietf.org X-BeenThere: vrrp@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Virtual Router Redundancy Protocol List-Post: List-Help: List-Subscribe: , From: "Don Provan" >>the fact >>that only the master system sends VRRP packets makes it really hard >>to negotiate. Ah right. But perhaps that very property makes it possible without the extra bits for "I could support higher". Because maybe if the master can support faster granularity, it sends both the v2 VRRP messages with 1 second, and the v4(?) with, say, a timer of 13/100 seconds. Then all the v4 nodes will quickly jump in when he dies, but any v2 nodes will clunkily sit around and not notice for several seconds, but if there are any other v4 nodes, they will have in the meantime taken over as master. So the downside is the extra v2 VRRP message. But other than that it seems like it would work. If there are any other v4 nodes they would (regardless of priority) jump in ahead of any v2 nodes (assuming the VRRPv4 message had a timer much less than a second). Radia _______________________________________________ vrrp mailing list vrrp@ietf.org https://www1.ietf.org/mailman/listinfo/vrrp From exim@www1.ietf.org Fri Aug 15 18:36:28 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16762 for ; Fri, 15 Aug 2003 18:36:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nnAy-0008La-KR for vrrp-archive@odin.ietf.org; Fri, 15 Aug 2003 18:36:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7FMa4Tf032082 for vrrp-archive@odin.ietf.org; Fri, 15 Aug 2003 18:36:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nnAx-0008LN-41 for vrrp-web-archive@optimus.ietf.org; Fri, 15 Aug 2003 18:36:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16720 for ; Fri, 15 Aug 2003 18:35:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19nnAu-0006aU-00 for vrrp-web-archive@ietf.org; Fri, 15 Aug 2003 18:36:00 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19nnAt-0006aR-00 for vrrp-web-archive@ietf.org; Fri, 15 Aug 2003 18:35:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nnAv-0008Kt-Lq; Fri, 15 Aug 2003 18:36:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nnAj-0008Kf-JQ for vrrp@optimus.ietf.org; Fri, 15 Aug 2003 18:35:49 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16717 for ; Fri, 15 Aug 2003 18:35:43 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19nnAg-0006aN-00 for vrrp@ietf.org; Fri, 15 Aug 2003 18:35:46 -0400 Received: from zmamail04.zma.compaq.com ([161.114.64.104]) by ietf-mx with esmtp (Exim 4.12) id 19nnAc-0006aJ-00 for vrrp@ietf.org; Fri, 15 Aug 2003 18:35:42 -0400 Received: from taynzmail03.nz-tay.cpqcorp.net (taynzmail03.nz-tay.cpqcorp.net [16.47.4.103]) by zmamail04.zma.compaq.com (Postfix) with ESMTP id 7D3238B34 for ; Fri, 15 Aug 2003 18:35:38 -0400 (EDT) Received: from lassie-e0.ucx.lkg.dec.com (lassie-e0.ucx.lkg.dec.com [16.20.208.100]) by taynzmail03.nz-tay.cpqcorp.net (Postfix) with SMTP id 466D31230 for ; Fri, 15 Aug 2003 18:35:38 -0400 (EDT) Received: from portabrain (16.20.99.209) by lassie-e0.ucx.lkg.dec.com (KZLONGSTRING, OpenVMS V7.2-2 Alpha); Fri, 15 Aug 2003 18:37:36 -0400 (EDT) Message-ID: <02f101c3637d$9652b390$6400a8c0@PORTABRAIN> From: "M. T. Hollinger" To: References: <8D260779A766FB4A9C1739A476F84FA476C31E@daebe009.americas.nokia.com> <4.3.2.7.2.20030715074329.03553840@mailhost.iprg.nokia.com> Subject: Re: [VRRP] Virtual MAC for IPv6 Date: Fri, 15 Aug 2003 18:35:45 -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 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: 7bit Sender: vrrp-admin@ietf.org Errors-To: vrrp-admin@ietf.org X-BeenThere: vrrp@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Virtual Router Redundancy Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Bob, I think we will have to agree to disagree on this issue. I continue to believe that support for duplicate MAC addresses places additional constraints on the underlying data-link layer, creating potential restrictions or incompatibilities for VRRP as new IEEE 802 variants emerge or switch vendors develop new optimizations for traditional Ethernet links. Moreover, hiding the identity of the current router may complicate troubleshooting and keep "smart" workload management software on end hosts from noting and responding to network failures. To me, the argument that virtual MAC addresses have worked satisfactorily in the IPv4 VRRP world is not compelling. As I said in Vienna, NAT may be deployed and proven technology in the IPv4 world too, but that should not prevent us from considering architecturally cleaner designs as we move toward IPv6. In general, layer violations should be avoided because they introduce complexity and constraints. As someone who has experience with DECnet Phase IV, I have become painfully aware of the pitfalls of having upper-layer protocols override the hardware MAC address. Even without the added complication of suddenly moving the virtual MAC address to another part of the network, simply using a physical MAC address different from the hardware address brings confusion and dependencies. As you (Bob) pointed out, the picture gets even more complicated when considering subsecond timers and the goal of very fast failover. How quickly will your switches learn the new location of the router's VMAC address, and propagate their spanning tree data throughout the extended LAN? If it takes VRRP 3 seconds to initiate failover and your switches another 3 seconds, is that acceptable? Users who want fast failover will have to shop around for switches that respond quickly to movement of a unicast MAC address. On the other hand, if you get rid of VMAC, you eliminate the dependency on switch behavior. - Mark ----- Original Message ----- From: "Bob Hinden" To: "M. T. Hollinger" Cc: Sent: Tuesday, July 15, 2003 11:02 AM Subject: Re: [VRRP] Virtual MAC for IPv6 Mark, At 06:52 AM 7/15/2003, M. T. Hollinger wrote: >The vrrp-ipv6-spec-05 draft still specifies the use of virtual MAC >addresses, even with IPv6. > >I have long disliked the use of duplicate MAC addresses for v4, which was >justified with the argument that some older ARP implementations did not >properly receive and parse gratuitous ARP messages. > >That argument does not apply to IPv6. I oppose moving this document forward >until the use of virtual MAC is removed. (Alternatively, if there is a >strong justification, then text could be added to the document explaining >why this architecturally awful design was believed to be the best choice for >the IPv6 environment.) I don't agree that it is so bad or as you say an "architecturally awful design". I have thought about it as one of the great MAC address hacks :-) The advantage of this approach is that it works without the hosts having to do anything (e.g., receive and process an ND message, update tables, etc.). The switch over is transparent to the hosts. This approach is well proven in the IPv4 version of VRRP. It is running operationally in many places and I am not aware of any problems. Are you aware of any technical problems with the virtual MAC address approach? Thanks, Bob _______________________________________________ vrrp mailing list vrrp@ietf.org https://www1.ietf.org/mailman/listinfo/vrrp From exim@www1.ietf.org Mon Aug 18 20:36:34 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA10511 for ; Mon, 18 Aug 2003 20:36:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ouTn-0003jd-FH for vrrp-archive@odin.ietf.org; Mon, 18 Aug 2003 20:36:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7J0a7ks014355 for vrrp-archive@odin.ietf.org; Mon, 18 Aug 2003 20:36:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ouTn-0003jS-8S for vrrp-web-archive@optimus.ietf.org; Mon, 18 Aug 2003 20:36:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA10497 for ; Mon, 18 Aug 2003 20:36:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ouTl-0003jt-00 for vrrp-web-archive@ietf.org; Mon, 18 Aug 2003 20:36:05 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19ouTk-0003jp-00 for vrrp-web-archive@ietf.org; Mon, 18 Aug 2003 20:36:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ouTh-0003is-7G; Mon, 18 Aug 2003 20:36:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ouTN-0003iR-Dw for vrrp@optimus.ietf.org; Mon, 18 Aug 2003 20:35:41 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA10489 for ; Mon, 18 Aug 2003 20:35:37 -0400 (EDT) From: Mukesh.Gupta@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ouTL-0003jg-00 for vrrp@ietf.org; Mon, 18 Aug 2003 20:35:39 -0400 Received: from [63.78.179.217] (helo=mgw-dax2.ext.nokia.com) by ietf-mx with esmtp (Exim 4.12) id 19ouTK-0003jd-00 for vrrp@ietf.org; Mon, 18 Aug 2003 20:35:38 -0400 Received: from davir02nok.americas.nokia.com (davir02nok.americas.nokia.com [172.18.242.85]) by mgw-dax2.ext.nokia.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h7J0ZcG00698 for ; Mon, 18 Aug 2003 19:35:38 -0500 (CDT) Received: from daebh002.NOE.Nokia.com (unverified) by davir02nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 18 Aug 2003 19:35:38 -0500 Received: from daebe009.NOE.Nokia.com ([172.18.242.190]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Mon, 18 Aug 2003 19:33:29 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [VRRP] Subsecond Timers for VRRPv3 Date: Mon, 18 Aug 2003 19:33:28 -0500 Message-ID: <8D260779A766FB4A9C1739A476F84FA476C431@daebe009.americas.nokia.com> Thread-Topic: [VRRP] Subsecond Timers for VRRPv3 Thread-Index: AcNjaVpZ0LaxizjYQaOd8ejP//RgkACf5HSQ To: , X-OriginalArrivalTime: 19 Aug 2003 00:33:29.0124 (UTC) FILETIME=[82B5BE40:01C365E9] Content-Transfer-Encoding: quoted-printable Sender: vrrp-admin@ietf.org Errors-To: vrrp-admin@ietf.org X-BeenThere: vrrp@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Virtual Router Redundancy Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi Sonum, Would you please specify the reasoning behind your favor of=20 1/10 second ? Folks, We have just received 2 mail with the preferences; one=20 with 1/10 and the other with 1/1000. It will be hard to make=20 the decision without knowing preferences from enough people. Please respond with your choice and the reason behind that. regards Mukesh > -----Original Message----- > From: ext Mathur Sonum-CSM109 [mailto:sonum@motorola.com] > Sent: Friday, August 15, 2003 1:11 PM > To: Gupta Mukesh (IPRG/MtView); vrrp@ietf.org > Subject: RE: [VRRP] Subsecond Timers for VRRPv3 >=20 >=20 >=20 > We are in favor of 1/10 second. It is definitely a good idea=20 > to include this in the new version of VRRP for IPv4 and get=20 > it standardised. One suggestion to do this is to use one of=20 > the unused bits in the packet. The bit setting can indicate=20 > that the units in Advert Int are in seconds or in 1/10th of second.=20 >=20 > -- > Sonum >=20 > > -----Original Message----- > > From: Mukesh.Gupta@nokia.com [mailto:Mukesh.Gupta@nokia.com] > > Sent: Friday, August 15, 2003 10:43 AM > > To: vrrp@ietf.org > > Subject: [VRRP] Subsecond Timers for VRRPv3 > >=20 > >=20 > > Folks, > >=20 > > In the WG meeting in Vienna, we all agreed that the=20 > > sub-second timers should be allowed at least in VRRPv3=20 > > but we couldn't agree about the granularity of the=20 > > advertizing interval for allowing them. > >=20 > > There were concerns that if we allow the advertizing > > intervals in miliseconds, it will allow the user to > > bombard the LAN with VRRP packets which is dangerous. > >=20 > > Advertizing intervals in the units of 1/10 seconds > > or 1/100 seconds seemed like good choices. > >=20 > > We would like to know what is everyone's opinion=20 > > about this. Please reply with your preference. > >=20 > > 1) 1/10 second > > 2) 1/100 second > > 3) 1/1000 second (miliseconds) > >=20 > > regards > > Mukesh > >=20 > > _______________________________________________ > > vrrp mailing list > > vrrp@ietf.org > > https://www1.ietf.org/mailman/listinfo/vrrp > >=20 >=20 _______________________________________________ vrrp mailing list vrrp@ietf.org https://www1.ietf.org/mailman/listinfo/vrrp From exim@www1.ietf.org Mon Aug 18 20:38:31 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA10589 for ; Mon, 18 Aug 2003 20:38:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ouVf-00046x-Iy for vrrp-archive@odin.ietf.org; Mon, 18 Aug 2003 20:38:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7J0c3vZ015799 for vrrp-archive@odin.ietf.org; Mon, 18 Aug 2003 20:38:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ouVf-00046k-Ft for vrrp-web-archive@optimus.ietf.org; Mon, 18 Aug 2003 20:38:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA10551 for ; Mon, 18 Aug 2003 20:37:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ouVd-0003kc-00 for vrrp-web-archive@ietf.org; Mon, 18 Aug 2003 20:38:01 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19ouVc-0003kY-00 for vrrp-web-archive@ietf.org; Mon, 18 Aug 2003 20:38:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ouVd-00044A-Od; Mon, 18 Aug 2003 20:38:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ouVH-00040q-6L for vrrp@optimus.ietf.org; Mon, 18 Aug 2003 20:37:39 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA10546 for ; Mon, 18 Aug 2003 20:37:35 -0400 (EDT) From: Mukesh.Gupta@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ouVE-0003kT-00 for vrrp@ietf.org; Mon, 18 Aug 2003 20:37:37 -0400 Received: from [63.78.179.217] (helo=mgw-dax2.ext.nokia.com) by ietf-mx with esmtp (Exim 4.12) id 19ouVE-0003kQ-00 for vrrp@ietf.org; Mon, 18 Aug 2003 20:37:36 -0400 Received: from davir02nok.americas.nokia.com (davir02nok.americas.nokia.com [172.18.242.85]) by mgw-dax2.ext.nokia.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h7J0baG01022 for ; Mon, 18 Aug 2003 19:37:36 -0500 (CDT) Received: from daebh002.NOE.Nokia.com (unverified) by davir02nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 18 Aug 2003 19:37:36 -0500 Received: from daebe009.NOE.Nokia.com ([172.18.242.190]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Mon, 18 Aug 2003 19:36:26 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [VRRP] And subsecond timers for IPv4 Date: Mon, 18 Aug 2003 19:36:26 -0500 Message-ID: <8D260779A766FB4A9C1739A476F84FA476C432@daebe009.americas.nokia.com> Thread-Topic: [VRRP] And subsecond timers for IPv4 Thread-Index: AcNjepj33H8konJ/T4Wig7GqcoxDOgCbvIDQ To: , Cc: X-OriginalArrivalTime: 19 Aug 2003 00:36:26.0970 (UTC) FILETIME=[ECB6E3A0:01C365E9] Content-Transfer-Encoding: quoted-printable Sender: vrrp-admin@ietf.org Errors-To: vrrp-admin@ietf.org X-BeenThere: vrrp@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Virtual Router Redundancy Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable What about someone coming up with a draft about this detailing all=20 the schemes and interoperability issues ? We can make the decision about whether we should go forward with that or not after reading the draft ? Anyone wants to volunteer ?? Regards, Mukesh > -----Original Message----- > From: ext Radia Perlman - Boston Center for Networking > [mailto:Radia.Perlman@sun.com] > Sent: Friday, August 15, 2003 3:13 PM > To: Radia.Perlman@sun.com; dprovan@bivio.net > Cc: vrrp@ietf.org > Subject: RE: [VRRP] And subsecond timers for IPv4 >=20 >=20 >=20 > From: "Don Provan" > >>the fact > >>that only the master system sends VRRP packets makes it really hard > >>to negotiate. >=20 > Ah right. But perhaps that very property makes it possible without the > extra bits for "I could support higher". >=20 > Because maybe if the master can support faster granularity, it sends > both the v2 VRRP messages with 1 second, and the v4(?) with, say, > a timer of 13/100 seconds. Then all the v4 nodes will quickly jump > in when he dies, but any v2 nodes will clunkily sit around and not > notice for several seconds, but if there are any other v4 nodes,=20 > they will have in the meantime taken over as master. >=20 > So the downside is the extra v2 VRRP message. But other than that > it seems like it would work. If there are any other v4 nodes they > would (regardless of priority) jump in ahead of any v2 nodes (assuming > the VRRPv4 message had a timer much less than a second). >=20 > Radia >=20 >=20 > _______________________________________________ > vrrp mailing list > vrrp@ietf.org > https://www1.ietf.org/mailman/listinfo/vrrp >=20 _______________________________________________ vrrp mailing list vrrp@ietf.org https://www1.ietf.org/mailman/listinfo/vrrp From exim@www1.ietf.org Mon Aug 18 20:50:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA10898 for ; Mon, 18 Aug 2003 20:50:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ouhG-0004dX-QS for vrrp-archive@odin.ietf.org; Mon, 18 Aug 2003 20:50:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7J0o2Uv017817 for vrrp-archive@odin.ietf.org; Mon, 18 Aug 2003 20:50:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ouhG-0004dI-N7 for vrrp-web-archive@optimus.ietf.org; Mon, 18 Aug 2003 20:50:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA10890 for ; Mon, 18 Aug 2003 20:49:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ouhE-0003qy-00 for vrrp-web-archive@ietf.org; Mon, 18 Aug 2003 20:50:00 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19ouhD-0003qv-00 for vrrp-web-archive@ietf.org; Mon, 18 Aug 2003 20:49:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ouhF-0004cb-2E; Mon, 18 Aug 2003 20:50:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ougr-0004bq-9n for vrrp@optimus.ietf.org; Mon, 18 Aug 2003 20:49:37 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA10887 for ; Mon, 18 Aug 2003 20:49:33 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ougo-0003qp-00 for vrrp@ietf.org; Mon, 18 Aug 2003 20:49:34 -0400 Received: from [216.142.75.231] (helo=exmail.bivio.net) by ietf-mx with smtp (Exim 4.12) id 19ougo-0003qm-00 for vrrp@ietf.org; Mon, 18 Aug 2003 20:49:34 -0400 Received: from dprovan1 ([192.168.24.137]) by exmail.bivio.net with Microsoft SMTPSVC(5.0.2195.2966); Mon, 18 Aug 2003 17:49:34 -0700 From: "Don Provan" To: Cc: Subject: RE: [VRRP] Subsecond Timers for VRRPv3 Date: Mon, 18 Aug 2003 17:49:32 -0700 Message-ID: <000a01c365eb$c1d2e650$8918a8c0@corp.networkrobots.com> X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal In-Reply-To: <8D260779A766FB4A9C1739A476F84FA476C431@daebe009.americas.nokia.com> X-OriginalArrivalTime: 19 Aug 2003 00:49:34.0090 (UTC) FILETIME=[C1DFDEA0:01C365EB] Sender: vrrp-admin@ietf.org Errors-To: vrrp-admin@ietf.org X-BeenThere: vrrp@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Virtual Router Redundancy Protocol List-Post: List-Help: List-Subscribe: , I haven't heard that the interval field is expanding, and it sounds as if we're avoid making the unit variable. In that case, 1/1000 seems wrong because the max interval is now 1/4 of a second. And 1/100 doesn't seem that much better, capping at 2.55 seconds. So that would lead me to 1/10, but is this small enough to satisfy the requirement? I know the goal is faster failovers, but I don't recall if a minimum target was set. -don > -----Original Message----- > From: vrrp-admin@ietf.org [mailto:vrrp-admin@ietf.org]On Behalf Of > Mukesh.Gupta@nokia.com > Sent: Monday, August 18, 2003 5:33 PM > To: sonum@motorola.com; vrrp@ietf.org > Subject: RE: [VRRP] Subsecond Timers for VRRPv3 > > > Hi Sonum, > > Would you please specify the reasoning behind your favor of > 1/10 second ? > > Folks, > > We have just received 2 mail with the preferences; one > with 1/10 and the other with 1/1000. It will be hard to make > the decision without knowing preferences from enough people. > > Please respond with your choice and the reason behind that. > > regards > Mukesh > > > -----Original Message----- > > From: ext Mathur Sonum-CSM109 [mailto:sonum@motorola.com] > > Sent: Friday, August 15, 2003 1:11 PM > > To: Gupta Mukesh (IPRG/MtView); vrrp@ietf.org > > Subject: RE: [VRRP] Subsecond Timers for VRRPv3 > > > > > > > > We are in favor of 1/10 second. It is definitely a good idea > > to include this in the new version of VRRP for IPv4 and get > > it standardised. One suggestion to do this is to use one of > > the unused bits in the packet. The bit setting can indicate > > that the units in Advert Int are in seconds or in 1/10th of second. > > > > -- > > Sonum > > > > > -----Original Message----- > > > From: Mukesh.Gupta@nokia.com [mailto:Mukesh.Gupta@nokia.com] > > > Sent: Friday, August 15, 2003 10:43 AM > > > To: vrrp@ietf.org > > > Subject: [VRRP] Subsecond Timers for VRRPv3 > > > > > > > > > Folks, > > > > > > In the WG meeting in Vienna, we all agreed that the > > > sub-second timers should be allowed at least in VRRPv3 > > > but we couldn't agree about the granularity of the > > > advertizing interval for allowing them. > > > > > > There were concerns that if we allow the advertizing > > > intervals in miliseconds, it will allow the user to > > > bombard the LAN with VRRP packets which is dangerous. > > > > > > Advertizing intervals in the units of 1/10 seconds > > > or 1/100 seconds seemed like good choices. > > > > > > We would like to know what is everyone's opinion > > > about this. Please reply with your preference. > > > > > > 1) 1/10 second > > > 2) 1/100 second > > > 3) 1/1000 second (miliseconds) > > > > > > regards > > > Mukesh > > > > > > _______________________________________________ > > > vrrp mailing list > > > vrrp@ietf.org > > > https://www1.ietf.org/mailman/listinfo/vrrp > > > > > > > _______________________________________________ > vrrp mailing list > vrrp@ietf.org > https://www1.ietf.org/mailman/listinfo/vrrp _______________________________________________ vrrp mailing list vrrp@ietf.org https://www1.ietf.org/mailman/listinfo/vrrp From exim@www1.ietf.org Mon Aug 18 20:55:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA11007 for ; Mon, 18 Aug 2003 20:55:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19oum6-0004jq-PF for vrrp-archive@odin.ietf.org; Mon, 18 Aug 2003 20:55:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7J0t20l018206 for vrrp-archive@odin.ietf.org; Mon, 18 Aug 2003 20:55:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19oum6-0004jZ-LC for vrrp-web-archive@optimus.ietf.org; Mon, 18 Aug 2003 20:55:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA10998 for ; Mon, 18 Aug 2003 20:54:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19oum4-0003sZ-00 for vrrp-web-archive@ietf.org; Mon, 18 Aug 2003 20:55:00 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19oum3-0003sW-00 for vrrp-web-archive@ietf.org; Mon, 18 Aug 2003 20:54:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19oum5-0004j6-AG; Mon, 18 Aug 2003 20:55:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19oulv-0004ii-Og for vrrp@optimus.ietf.org; Mon, 18 Aug 2003 20:54:51 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA10994 for ; Mon, 18 Aug 2003 20:54:47 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19oult-0003sT-00 for vrrp@ietf.org; Mon, 18 Aug 2003 20:54:49 -0400 Received: from [216.142.75.231] (helo=exmail.bivio.net) by ietf-mx with smtp (Exim 4.12) id 19ouls-0003sQ-00 for vrrp@ietf.org; Mon, 18 Aug 2003 20:54:48 -0400 Received: from dprovan1 ([192.168.24.137]) by exmail.bivio.net with Microsoft SMTPSVC(5.0.2195.2966); Mon, 18 Aug 2003 17:54:49 -0700 From: "Don Provan" To: "'Radia Perlman - Boston Center for Networking'" Cc: Subject: RE: [VRRP] And subsecond timers for IPv4 Date: Mon, 18 Aug 2003 17:54:48 -0700 Message-ID: <000b01c365ec$7dc1b580$8918a8c0@corp.networkrobots.com> X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal In-Reply-To: <200308152212.h7FMCss26011@sydney.East.Sun.COM> X-OriginalArrivalTime: 19 Aug 2003 00:54:49.0288 (UTC) FILETIME=[7DBF4480:01C365EC] Sender: vrrp-admin@ietf.org Errors-To: vrrp-admin@ietf.org X-BeenThere: vrrp@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Virtual Router Redundancy Protocol List-Post: List-Help: List-Subscribe: , > Because maybe if the master can support faster granularity, it sends > both the v2 VRRP messages with 1 second, and the v4(?) with, say, > a timer of 13/100 seconds. Then all the v4 nodes will quickly jump > in when he dies, but any v2 nodes will clunkily sit around and not > notice for several seconds, but if there are any other v4 nodes, > they will have in the meantime taken over as master. Pretty slick. Running v2 and v4 concurrently on the same network for the same VR. I'm sure we could make it work, but once we've spelled out all the details about the relation between the two protocols, what with preemption, priorities, and those kinds of requirements, I think we'll have a lot of rules for very little gain. After all, if someone really thinks it's important to failover in .3 seconds instead of 3 seconds, I'm not sure why they'd be messing around with v2-only implementations anywhere in the picture. -don _______________________________________________ vrrp mailing list vrrp@ietf.org https://www1.ietf.org/mailman/listinfo/vrrp From exim@www1.ietf.org Mon Aug 18 21:34:28 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA11573 for ; Mon, 18 Aug 2003 21:34:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ovNr-0005qi-41 for vrrp-archive@odin.ietf.org; Mon, 18 Aug 2003 21:34:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7J1Y3Gc022479 for vrrp-archive@odin.ietf.org; Mon, 18 Aug 2003 21:34:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ovNr-0005qU-1B for vrrp-web-archive@optimus.ietf.org; Mon, 18 Aug 2003 21:34:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA11570 for ; Mon, 18 Aug 2003 21:33:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ovNo-00040L-00 for vrrp-web-archive@ietf.org; Mon, 18 Aug 2003 21:34:00 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19ovNn-00040I-00 for vrrp-web-archive@ietf.org; Mon, 18 Aug 2003 21:33:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ovNo-0005pq-QK; Mon, 18 Aug 2003 21:34:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ovMz-0005me-9v for vrrp@optimus.ietf.org; Mon, 18 Aug 2003 21:33:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA11540 for ; Mon, 18 Aug 2003 21:33:04 -0400 (EDT) From: Mukesh.Gupta@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ovMw-0003zi-00 for vrrp@ietf.org; Mon, 18 Aug 2003 21:33:06 -0400 Received: from [63.78.179.217] (helo=mgw-dax2.ext.nokia.com) by ietf-mx with esmtp (Exim 4.12) id 19ovMv-0003zf-00 for vrrp@ietf.org; Mon, 18 Aug 2003 21:33:05 -0400 Received: from davir02nok.americas.nokia.com (davir02nok.americas.nokia.com [172.18.242.85]) by mgw-dax2.ext.nokia.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h7J1X6G09464 for ; Mon, 18 Aug 2003 20:33:06 -0500 (CDT) Received: from daebh002.NOE.Nokia.com (unverified) by davir02nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 18 Aug 2003 20:33:06 -0500 Received: from daebe009.NOE.Nokia.com ([172.18.242.190]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Mon, 18 Aug 2003 20:33:05 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [VRRP] Subsecond Timers for VRRPv3 Date: Mon, 18 Aug 2003 20:33:05 -0500 Message-ID: <8D260779A766FB4A9C1739A476F84FA476C435@daebe009.americas.nokia.com> Thread-Topic: [VRRP] Subsecond Timers for VRRPv3 Thread-Index: AcNl68wuGOcsWPhXTKiWoqHbZ0+eQgABSy/Q To: Cc: X-OriginalArrivalTime: 19 Aug 2003 01:33:05.0951 (UTC) FILETIME=[D6AA3AF0:01C365F1] Content-Transfer-Encoding: quoted-printable Sender: vrrp-admin@ietf.org Errors-To: vrrp-admin@ietf.org X-BeenThere: vrrp@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Virtual Router Redundancy Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable > I haven't heard that the interval field is expanding, and it > sounds as if we're avoid making the unit variable. In that case, > 1/1000 seems wrong because the max interval is now 1/4 of a > second. And 1/100 doesn't seem that much better, capping at 2.55 > seconds. So that would lead me to 1/10, but is this small enough > to satisfy the requirement? I know the goal is faster failovers, > but I don't recall if a minimum target was set. After the removal of the security in VRRPv3, the auth type field=20 (just before the Adver Int field) is now a reserved field. So we have room for expanding the Advertising Interval to 2 bytes. That will give us a range of 1 msec to 65 seconds if we choose 1/1000, 10 msec to 650 seconds. On the other hand, if we choose 1/10, we can let the Advert Int field be 1 byte and have the range 100 msec to 25 seconds. So if we are convinced that we should go for 1/1000, we can go=20 forward with it. regards Mukesh _______________________________________________ vrrp mailing list vrrp@ietf.org https://www1.ietf.org/mailman/listinfo/vrrp From exim@www1.ietf.org Mon Aug 18 22:08:32 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA12252 for ; Mon, 18 Aug 2003 22:08:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ovup-00079x-3s for vrrp-archive@odin.ietf.org; Mon, 18 Aug 2003 22:08:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7J287VH027520 for vrrp-archive@odin.ietf.org; Mon, 18 Aug 2003 22:08:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ovup-00079n-15 for vrrp-web-archive@optimus.ietf.org; Mon, 18 Aug 2003 22:08:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA12249 for ; Mon, 18 Aug 2003 22:08:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ovum-0004Ap-00 for vrrp-web-archive@ietf.org; Mon, 18 Aug 2003 22:08:04 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19ovul-0004Am-00 for vrrp-web-archive@ietf.org; Mon, 18 Aug 2003 22:08:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ovuj-00077u-EG; Mon, 18 Aug 2003 22:08:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ovtn-0006sr-Fx for vrrp@optimus.ietf.org; Mon, 18 Aug 2003 22:07:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA12230 for ; Mon, 18 Aug 2003 22:06:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ovtk-0004Ad-00 for vrrp@ietf.org; Mon, 18 Aug 2003 22:07:00 -0400 Received: from motgate4.mot.com ([144.189.100.102]) by ietf-mx with esmtp (Exim 4.12) id 19ovtj-0004Aa-00 for vrrp@ietf.org; Mon, 18 Aug 2003 22:06:59 -0400 Received: from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by motgate4.mot.com (Motorola/Motgate4) with ESMTP id h7J26xDR009648 for ; Mon, 18 Aug 2003 19:06:59 -0700 (MST) Received: from il06exb01.corp.mot.com (il06exb01.corp.mot.com [10.0.111.59]) by il06exr04.mot.com (Motorola/il06exr04) with ESMTP id h7J26j01019555 for ; Mon, 18 Aug 2003 21:06:45 -0500 Received: by il06exb01.corp.mot.com with Internet Mail Service (5.5.2657.2) id ; Mon, 18 Aug 2003 21:06:58 -0500 Message-ID: <7BEC4504753E234FB2F71866AAAD196D37C3AC@il06exm03.corp.mot.com> From: Mathur Sonum-CSM109 To: "'Mukesh.Gupta@nokia.com'" , vrrp@ietf.org Subject: RE: [VRRP] Subsecond Timers for VRRPv3 Date: Mon, 18 Aug 2003 21:06:51 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.2) Content-Type: text/plain; charset="iso-8859-1" Sender: vrrp-admin@ietf.org Errors-To: vrrp-admin@ietf.org X-BeenThere: vrrp@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Virtual Router Redundancy Protocol List-Post: List-Help: List-Subscribe: , We had a requirement to get failover time in the order of hundreds of milli seconds. But to keep the system interoperable with existing implementations, the check for milliseconds granularity is ignored in our implementation right now. If the router is configured for Advt Interval of 100 msecs, it would send value = 0 in the 1 byte Advt Interval field of the packet. This will be same for configured value of 100 to 900 msecs. If we have this requirement of minimum failover time in some milliseconds, then we need to either expand the field or use some of the unused bits in the packet. That leads to this question - what is the minimum failover time that we want to set in the standards ? We are ok with 100 msecs. -- Sonum > -----Original Message----- > From: Mukesh.Gupta@nokia.com [mailto:Mukesh.Gupta@nokia.com] > Sent: Monday, August 18, 2003 5:33 PM > To: Sonum Mathur; vrrp@ietf.org > Subject: RE: [VRRP] Subsecond Timers for VRRPv3 > > > Hi Sonum, > > Would you please specify the reasoning behind your favor of > 1/10 second ? > > Folks, > > We have just received 2 mail with the preferences; one > with 1/10 and the other with 1/1000. It will be hard to make > the decision without knowing preferences from enough people. > > Please respond with your choice and the reason behind that. > > regards > Mukesh > > > -----Original Message----- > > From: ext Mathur Sonum-CSM109 [mailto:sonum@motorola.com] > > Sent: Friday, August 15, 2003 1:11 PM > > To: Gupta Mukesh (IPRG/MtView); vrrp@ietf.org > > Subject: RE: [VRRP] Subsecond Timers for VRRPv3 > > > > > > > > We are in favor of 1/10 second. It is definitely a good idea > > to include this in the new version of VRRP for IPv4 and get > > it standardised. One suggestion to do this is to use one of > > the unused bits in the packet. The bit setting can indicate > > that the units in Advert Int are in seconds or in 1/10th of second. > > > > -- > > Sonum > > > > > -----Original Message----- > > > From: Mukesh.Gupta@nokia.com [mailto:Mukesh.Gupta@nokia.com] > > > Sent: Friday, August 15, 2003 10:43 AM > > > To: vrrp@ietf.org > > > Subject: [VRRP] Subsecond Timers for VRRPv3 > > > > > > > > > Folks, > > > > > > In the WG meeting in Vienna, we all agreed that the > > > sub-second timers should be allowed at least in VRRPv3 > > > but we couldn't agree about the granularity of the > > > advertizing interval for allowing them. > > > > > > There were concerns that if we allow the advertizing > > > intervals in miliseconds, it will allow the user to > > > bombard the LAN with VRRP packets which is dangerous. > > > > > > Advertizing intervals in the units of 1/10 seconds > > > or 1/100 seconds seemed like good choices. > > > > > > We would like to know what is everyone's opinion > > > about this. Please reply with your preference. > > > > > > 1) 1/10 second > > > 2) 1/100 second > > > 3) 1/1000 second (miliseconds) > > > > > > regards > > > Mukesh > > > > > > _______________________________________________ > > > vrrp mailing list > > > vrrp@ietf.org > > > https://www1.ietf.org/mailman/listinfo/vrrp > > > > > > _______________________________________________ vrrp mailing list vrrp@ietf.org https://www1.ietf.org/mailman/listinfo/vrrp From exim@www1.ietf.org Mon Aug 18 23:31:34 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA13395 for ; Mon, 18 Aug 2003 23:31:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19oxDA-0000o4-0W for vrrp-archive@odin.ietf.org; Mon, 18 Aug 2003 23:31:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7J3V7Sc003101 for vrrp-archive@odin.ietf.org; Mon, 18 Aug 2003 23:31:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19oxD9-0000nw-RR for vrrp-web-archive@optimus.ietf.org; Mon, 18 Aug 2003 23:31:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA13374 for ; Mon, 18 Aug 2003 23:31:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19oxD7-0004Vb-00 for vrrp-web-archive@ietf.org; Mon, 18 Aug 2003 23:31:05 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19oxD7-0004VY-00 for vrrp-web-archive@ietf.org; Mon, 18 Aug 2003 23:31:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19oxD4-0000nJ-8e; Mon, 18 Aug 2003 23:31:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19oxCl-0000mJ-D9 for vrrp@optimus.ietf.org; Mon, 18 Aug 2003 23:30:43 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA13350 for ; Mon, 18 Aug 2003 23:30:38 -0400 (EDT) From: Kalyan.Tata@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19oxCj-0004VE-00 for vrrp@ietf.org; Mon, 18 Aug 2003 23:30:41 -0400 Received: from [63.78.179.217] (helo=mgw-dax2.ext.nokia.com) by ietf-mx with esmtp (Exim 4.12) id 19oxCi-0004VB-00 for vrrp@ietf.org; Mon, 18 Aug 2003 23:30:40 -0400 Received: from davir02nok.americas.nokia.com (davir02nok.americas.nokia.com [172.18.242.85]) by mgw-dax2.ext.nokia.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h7J3UfG25802 for ; Mon, 18 Aug 2003 22:30:41 -0500 (CDT) Received: from daebh001.NOE.Nokia.com (unverified) by davir02nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Mon, 18 Aug 2003 22:30:41 -0500 Received: from mvebe001.NOE.Nokia.com ([172.18.140.37]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Mon, 18 Aug 2003 20:30:26 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 18 Aug 2003 20:30:25 -0700 Message-ID: <4D7B558499107545BB45044C63822DDE03873B2E@mvebe001.americas.nokia.com> Thread-Topic: VRRP MIB(s) - some questions and request for comments Thread-Index: AcNmAjpKZ3+cyn7fRdGw0VylfpPEcw== To: X-OriginalArrivalTime: 19 Aug 2003 03:30:26.0857 (UTC) FILETIME=[3B5F3990:01C36602] Content-Transfer-Encoding: quoted-printable Subject: [VRRP] VRRP MIB(s) - some questions and request for comments Sender: vrrp-admin@ietf.org Errors-To: vrrp-admin@ietf.org X-BeenThere: vrrp@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Virtual Router Redundancy Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable HI, We published a draft "draft-ietf-vrrp-ipv6-mib-00.txt " that defines = managed object for VRRPv3=20 defined in " draft-ietf-vrrp-ipv6-spec-05.txt".=20 There were some question at the WG meeting about the rational behind=20 two different MIBs, one for VRRP for IPv4 and another for VRRP for IPv6. The following "were" the reasons for defining two separate MIBs. The main Reason: -VRRP protocol is inherently IP version specific. Though the protocol seems similar in certain aspects, VRRP for IPv6 is different from VRRP for IPv4 and hence require two different MIBs. Other reasons: - We already have a working VRRP IPv4 protocol and a corresponding MIB definition that is being used by industry. - It is not necessary to update the VRRP for IPv4 MIB (RFC 2787)=20 to make it IPv6 address aware - according to RFC3291: =3D=3D=3D=3D MIB modules which define management information that is=20 specific to particular IP version (either IPv4 or IPv6) and which is very unlikely to ever be applicable to=20 another IP version do not need to be redefined. =3D=3D=3D=3D =20 This being said, we would like to know the views of every one=20 who understand both the protocols to express if it "makes sense"=20 to have a single MIB definition. - With the removal of authentication in VRRP for IPv4, both the=20 protocols are much closer than before (from = configuration/management/statistics point of view) - Major difference being "associated IP address" in VRRPv2.=20 - With the changes specified in "draft-ietf-vrrp-spec-v2-09.txt" we will require to define a new MIB for VRRPv2 any way. - The present MIB tables are indexed on "interface Index" and "VRID". I = can=20 see a way to introduce "Version" into the index to identify if the row=20 corresponds to VRRPv2 or VRRPv3 (and hence if it is IPv4 or IPv6). This=20 could be messy but we can come up with a way to define one MIB. - Putting on a network administrator hat, would you expect statistics=20 (for example Invalid vrID packets received) in one table for both the = protocols?=20 Or=20 one table with two entries - one for VRRPv2 and the other for VRRPv3?=20 Or Two separate tables each having statistics for one particular protocol = version? Please voice your opinion for and against having two different MIBs and = the reason(s) behind your opinion. Based on your input, we will proceed with the changes to the existing = draft. thanks Brian Kripa Kalyan. _______________________________________________ vrrp mailing list vrrp@ietf.org https://www1.ietf.org/mailman/listinfo/vrrp From exim@www1.ietf.org Tue Aug 19 01:20:33 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA15133 for ; Tue, 19 Aug 2003 01:20:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19oyuc-0003nh-W3 for vrrp-archive@odin.ietf.org; Tue, 19 Aug 2003 01:20:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7J5K6H8014603 for vrrp-archive@odin.ietf.org; Tue, 19 Aug 2003 01:20:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19oyuc-0003nS-QN for vrrp-web-archive@optimus.ietf.org; Tue, 19 Aug 2003 01:20:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA15078 for ; Tue, 19 Aug 2003 01:20:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19oyuZ-0004vD-00 for vrrp-web-archive@ietf.org; Tue, 19 Aug 2003 01:20:03 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19oyuZ-0004vA-00 for vrrp-web-archive@ietf.org; Tue, 19 Aug 2003 01:20:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19oyuW-0003mm-U4; Tue, 19 Aug 2003 01:20:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19oyuC-0003mF-6D for vrrp@optimus.ietf.org; Tue, 19 Aug 2003 01:19:40 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA15061 for ; Tue, 19 Aug 2003 01:19:36 -0400 (EDT) From: esa.sarkama@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19oyu9-0004uj-00 for vrrp@ietf.org; Tue, 19 Aug 2003 01:19:37 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 19oyu8-0004ug-00 for vrrp@ietf.org; Tue, 19 Aug 2003 01:19:36 -0400 Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h7J5JZ422241 for ; Tue, 19 Aug 2003 08:19:36 +0300 (EET DST) Received: from esebh004.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 19 Aug 2003 08:19:35 +0300 Received: from esebe009.NOE.Nokia.com ([172.21.138.41]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 19 Aug 2003 08:19:35 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [VRRP] Subsecond Timers for VRRPv3 Date: Tue, 19 Aug 2003 08:19:34 +0300 Message-ID: Thread-Topic: [VRRP] Subsecond Timers for VRRPv3 Thread-Index: AcNl9rzdYy/3RQiBRrOYq/YcdJcMmQAGZGjQ To: , , X-OriginalArrivalTime: 19 Aug 2003 05:19:35.0524 (UTC) FILETIME=[7AAE8240:01C36611] Content-Transfer-Encoding: quoted-printable Sender: vrrp-admin@ietf.org Errors-To: vrrp-admin@ietf.org X-BeenThere: vrrp@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Virtual Router Redundancy Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Telecom operators are used to 50ms (SDH, Sonet) failover time. MPLS is promising 50ms. There is work going on in OSPF and IS-IS to reach "millisecond = convergence" From application side : SS7 signaling doesn't behave well if there is = over 700ms cut. So 100ms granularity is too big. Probably 10ms granularity would be OK.=20 br esa > -----Original Message----- > From: ext Mathur Sonum-CSM109 [mailto:sonum@motorola.com] > Sent: 19 August, 2003 05:07 > To: Gupta Mukesh (IPRG/MtView); vrrp@ietf.org > Subject: RE: [VRRP] Subsecond Timers for VRRPv3 >=20 >=20 >=20 > We had a requirement to get failover time in the order of=20 > hundreds of milli seconds. But to keep the system=20 > interoperable with existing implementations, the check for=20 > milliseconds granularity is ignored in our implementation=20 > right now. If the router is configured for Advt Interval of=20 > 100 msecs, it would send value =3D 0 in the 1 byte Advt=20 > Interval field of the packet. This will be same for=20 > configured value of 100 to 900 msecs.=20 >=20 > If we have this requirement of minimum failover time in some=20 > milliseconds, then we need to either expand the field or use=20 > some of the unused bits in the packet. That leads to this=20 > question - what is the minimum failover time that we want to=20 > set in the standards ? We are ok with 100 msecs. >=20 > -- > Sonum >=20 > > -----Original Message----- > > From: Mukesh.Gupta@nokia.com [mailto:Mukesh.Gupta@nokia.com] > > Sent: Monday, August 18, 2003 5:33 PM > > To: Sonum Mathur; vrrp@ietf.org > > Subject: RE: [VRRP] Subsecond Timers for VRRPv3 > >=20 > >=20 > > Hi Sonum, > >=20 > > Would you please specify the reasoning behind your favor of=20 > > 1/10 second ? > >=20 > > Folks, > >=20 > > We have just received 2 mail with the preferences; one=20 > > with 1/10 and the other with 1/1000. It will be hard to make=20 > > the decision without knowing preferences from enough people. > >=20 > > Please respond with your choice and the reason behind that. > >=20 > > regards > > Mukesh > >=20 > > > -----Original Message----- > > > From: ext Mathur Sonum-CSM109 [mailto:sonum@motorola.com] > > > Sent: Friday, August 15, 2003 1:11 PM > > > To: Gupta Mukesh (IPRG/MtView); vrrp@ietf.org > > > Subject: RE: [VRRP] Subsecond Timers for VRRPv3 > > >=20 > > >=20 > > >=20 > > > We are in favor of 1/10 second. It is definitely a good idea=20 > > > to include this in the new version of VRRP for IPv4 and get=20 > > > it standardised. One suggestion to do this is to use one of=20 > > > the unused bits in the packet. The bit setting can indicate=20 > > > that the units in Advert Int are in seconds or in 1/10th=20 > of second.=20 > > >=20 > > > -- > > > Sonum > > >=20 > > > > -----Original Message----- > > > > From: Mukesh.Gupta@nokia.com [mailto:Mukesh.Gupta@nokia.com] > > > > Sent: Friday, August 15, 2003 10:43 AM > > > > To: vrrp@ietf.org > > > > Subject: [VRRP] Subsecond Timers for VRRPv3 > > > >=20 > > > >=20 > > > > Folks, > > > >=20 > > > > In the WG meeting in Vienna, we all agreed that the=20 > > > > sub-second timers should be allowed at least in VRRPv3=20 > > > > but we couldn't agree about the granularity of the=20 > > > > advertizing interval for allowing them. > > > >=20 > > > > There were concerns that if we allow the advertizing > > > > intervals in miliseconds, it will allow the user to > > > > bombard the LAN with VRRP packets which is dangerous. > > > >=20 > > > > Advertizing intervals in the units of 1/10 seconds > > > > or 1/100 seconds seemed like good choices. > > > >=20 > > > > We would like to know what is everyone's opinion=20 > > > > about this. Please reply with your preference. > > > >=20 > > > > 1) 1/10 second > > > > 2) 1/100 second > > > > 3) 1/1000 second (miliseconds) > > > >=20 > > > > regards > > > > Mukesh > > > >=20 > > > > _______________________________________________ > > > > vrrp mailing list > > > > vrrp@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/vrrp > > > >=20 > > >=20 > >=20 >=20 > _______________________________________________ > vrrp mailing list > vrrp@ietf.org > https://www1.ietf.org/mailman/listinfo/vrrp >=20 _______________________________________________ vrrp mailing list vrrp@ietf.org https://www1.ietf.org/mailman/listinfo/vrrp From exim@www1.ietf.org Tue Aug 19 01:29:28 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA15342 for ; Tue, 19 Aug 2003 01:29:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19oz3G-0003yW-DY for vrrp-archive@odin.ietf.org; Tue, 19 Aug 2003 01:29:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7J5T2gB015276 for vrrp-archive@odin.ietf.org; Tue, 19 Aug 2003 01:29:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19oz3G-0003yJ-Ak for vrrp-web-archive@optimus.ietf.org; Tue, 19 Aug 2003 01:29:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA15332 for ; Tue, 19 Aug 2003 01:28:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19oz3D-0004yI-00 for vrrp-web-archive@ietf.org; Tue, 19 Aug 2003 01:28:59 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19oz3C-0004yF-00 for vrrp-web-archive@ietf.org; Tue, 19 Aug 2003 01:28:58 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19oz3F-0003xq-02; Tue, 19 Aug 2003 01:29:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19oz2h-0003xY-Kk for vrrp@optimus.ietf.org; Tue, 19 Aug 2003 01:28:27 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA15327 for ; Tue, 19 Aug 2003 01:28:23 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19oz2e-0004yC-00 for vrrp@ietf.org; Tue, 19 Aug 2003 01:28:24 -0400 Received: from [147.28.0.15] (helo=elf.layer8.net) by ietf-mx with smtp (Exim 4.12) id 19oz2e-0004xz-00 for vrrp@ietf.org; Tue, 19 Aug 2003 01:28:24 -0400 Received: (qmail 32582 invoked by uid 1000); 19 Aug 2003 05:17:27 -0000 Date: Mon, 18 Aug 2003 22:17:27 -0700 From: Ben Black To: esa.sarkama@nokia.com, vrrp@ietf.org Subject: Re: [VRRP] Subsecond Timers for VRRPv3 Message-ID: <20030819051727.GA13507@layer8.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i Sender: vrrp-admin@ietf.org Errors-To: vrrp-admin@ietf.org X-BeenThere: vrrp@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Virtual Router Redundancy Protocol List-Post: List-Help: List-Subscribe: , Good points, but why is everyone suggesting engineering to exactly the current requirements instead of leaving room for future enhancements? I say again that the resolution should be millisecond (if not smaller), and any restrictions on that should be in implementations, not in the specification. Ben On Tue, Aug 19, 2003 at 08:19:34AM +0300, esa.sarkama@nokia.com wrote: > > Telecom operators are used to 50ms (SDH, Sonet) failover time. > MPLS is promising 50ms. > There is work going on in OSPF and IS-IS to reach "millisecond convergence" > > >From application side : SS7 signaling doesn't behave well if there is over 700ms cut. > > So 100ms granularity is too big. > Probably 10ms granularity would be OK. > > br esa > > > -----Original Message----- > > From: ext Mathur Sonum-CSM109 [mailto:sonum@motorola.com] > > Sent: 19 August, 2003 05:07 > > To: Gupta Mukesh (IPRG/MtView); vrrp@ietf.org > > Subject: RE: [VRRP] Subsecond Timers for VRRPv3 > > > > > > > > We had a requirement to get failover time in the order of > > hundreds of milli seconds. But to keep the system > > interoperable with existing implementations, the check for > > milliseconds granularity is ignored in our implementation > > right now. If the router is configured for Advt Interval of > > 100 msecs, it would send value = 0 in the 1 byte Advt > > Interval field of the packet. This will be same for > > configured value of 100 to 900 msecs. > > > > If we have this requirement of minimum failover time in some > > milliseconds, then we need to either expand the field or use > > some of the unused bits in the packet. That leads to this > > question - what is the minimum failover time that we want to > > set in the standards ? We are ok with 100 msecs. > > > > -- > > Sonum > > > > > -----Original Message----- > > > From: Mukesh.Gupta@nokia.com [mailto:Mukesh.Gupta@nokia.com] > > > Sent: Monday, August 18, 2003 5:33 PM > > > To: Sonum Mathur; vrrp@ietf.org > > > Subject: RE: [VRRP] Subsecond Timers for VRRPv3 > > > > > > > > > Hi Sonum, > > > > > > Would you please specify the reasoning behind your favor of > > > 1/10 second ? > > > > > > Folks, > > > > > > We have just received 2 mail with the preferences; one > > > with 1/10 and the other with 1/1000. It will be hard to make > > > the decision without knowing preferences from enough people. > > > > > > Please respond with your choice and the reason behind that. > > > > > > regards > > > Mukesh > > > > > > > -----Original Message----- > > > > From: ext Mathur Sonum-CSM109 [mailto:sonum@motorola.com] > > > > Sent: Friday, August 15, 2003 1:11 PM > > > > To: Gupta Mukesh (IPRG/MtView); vrrp@ietf.org > > > > Subject: RE: [VRRP] Subsecond Timers for VRRPv3 > > > > > > > > > > > > > > > > We are in favor of 1/10 second. It is definitely a good idea > > > > to include this in the new version of VRRP for IPv4 and get > > > > it standardised. One suggestion to do this is to use one of > > > > the unused bits in the packet. The bit setting can indicate > > > > that the units in Advert Int are in seconds or in 1/10th > > of second. > > > > > > > > -- > > > > Sonum > > > > > > > > > -----Original Message----- > > > > > From: Mukesh.Gupta@nokia.com [mailto:Mukesh.Gupta@nokia.com] > > > > > Sent: Friday, August 15, 2003 10:43 AM > > > > > To: vrrp@ietf.org > > > > > Subject: [VRRP] Subsecond Timers for VRRPv3 > > > > > > > > > > > > > > > Folks, > > > > > > > > > > In the WG meeting in Vienna, we all agreed that the > > > > > sub-second timers should be allowed at least in VRRPv3 > > > > > but we couldn't agree about the granularity of the > > > > > advertizing interval for allowing them. > > > > > > > > > > There were concerns that if we allow the advertizing > > > > > intervals in miliseconds, it will allow the user to > > > > > bombard the LAN with VRRP packets which is dangerous. > > > > > > > > > > Advertizing intervals in the units of 1/10 seconds > > > > > or 1/100 seconds seemed like good choices. > > > > > > > > > > We would like to know what is everyone's opinion > > > > > about this. Please reply with your preference. > > > > > > > > > > 1) 1/10 second > > > > > 2) 1/100 second > > > > > 3) 1/1000 second (miliseconds) > > > > > > > > > > regards > > > > > Mukesh > > > > > > > > > > _______________________________________________ > > > > > vrrp mailing list > > > > > vrrp@ietf.org > > > > > https://www1.ietf.org/mailman/listinfo/vrrp > > > > > > > > > > > > > > > > _______________________________________________ > > vrrp mailing list > > vrrp@ietf.org > > https://www1.ietf.org/mailman/listinfo/vrrp > > > > _______________________________________________ > vrrp mailing list > vrrp@ietf.org > https://www1.ietf.org/mailman/listinfo/vrrp _______________________________________________ vrrp mailing list vrrp@ietf.org https://www1.ietf.org/mailman/listinfo/vrrp From exim@www1.ietf.org Tue Aug 19 14:20:31 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27815 for ; Tue, 19 Aug 2003 14:20:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pB5R-0002JN-VI for vrrp-archive@odin.ietf.org; Tue, 19 Aug 2003 14:20:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7JIK53G008879 for vrrp-archive@odin.ietf.org; Tue, 19 Aug 2003 14:20:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pB5R-0002J8-R0 for vrrp-web-archive@optimus.ietf.org; Tue, 19 Aug 2003 14:20:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27791 for ; Tue, 19 Aug 2003 14:20:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19pB5P-00050c-00 for vrrp-web-archive@ietf.org; Tue, 19 Aug 2003 14:20:03 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19pB5O-00050Z-00 for vrrp-web-archive@ietf.org; Tue, 19 Aug 2003 14:20:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pB5N-0002IM-JL; Tue, 19 Aug 2003 14:20:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pB0R-0001vb-Ur for vrrp@optimus.ietf.org; Tue, 19 Aug 2003 14:14:56 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27407 for ; Tue, 19 Aug 2003 14:14:47 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19pB0M-0004tR-00 for vrrp@ietf.org; Tue, 19 Aug 2003 14:14:50 -0400 Received: from emerson.torrentnet.com ([198.78.51.110]) by ietf-mx with esmtp (Exim 4.12) id 19pB0L-0004tN-00 for vrrp@ietf.org; Tue, 19 Aug 2003 14:14:49 -0400 Received: from imperial.torrentnet.com (imperial.torrentnet.com [198.78.51.109]) by emerson.torrentnet.com (8.11.6p2/8.11.2) with ESMTP id h7JIEnq55555; Tue, 19 Aug 2003 14:14:49 -0400 (EDT) Received: from ericsson.com (gibran.torrentnet.com [4.18.161.27]) by imperial.torrentnet.com (8.11.6p2/8.11.2) with ESMTP id h7JIEmn15075; Tue, 19 Aug 2003 14:14:48 -0400 (EDT) Message-ID: <3F426918.4080109@ericsson.com> Date: Tue, 19 Aug 2003 14:14:48 -0400 From: Vikram Pendharkar Reply-To: vikram.pendharkar@ericsson.com Organization: Ericsson IP Infrastructure User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20021003 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Kalyan.Tata@nokia.com CC: vrrp@ietf.org Subject: Re: [VRRP] VRRP MIB(s) - some questions and request for comments References: <4D7B558499107545BB45044C63822DDE03873B2E@mvebe001.americas.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: vrrp-admin@ietf.org Errors-To: vrrp-admin@ietf.org X-BeenThere: vrrp@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Virtual Router Redundancy Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Kalyan.Tata@nokia.com wrote: >- Putting on a network administrator hat, would you expect statistics >(for example Invalid vrID packets received) in one table for both the protocols? >Or >one table with two entries - one for VRRPv2 and the other for VRRPv3? >Or >Two separate tables each having statistics for one particular protocol version? > >Please voice your opinion for and against having two different MIBs and the reason(s) >behind your opinion. > > We think that keeping the tables separate would be a cleaner approach. The query would usually be for v4 or v6 but not both at the same time. Regards, Vikram > > -- Vikram Pendharkar Ericsson IP Infrastructure _______________________________________________ vrrp mailing list vrrp@ietf.org https://www1.ietf.org/mailman/listinfo/vrrp From exim@www1.ietf.org Tue Aug 19 15:54:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05558 for ; Tue, 19 Aug 2003 15:54:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pCYN-0007S8-2k for vrrp-archive@odin.ietf.org; Tue, 19 Aug 2003 15:54:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7JJs3K0028642 for vrrp-archive@odin.ietf.org; Tue, 19 Aug 2003 15:54:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pCYM-0007Rt-Ul for vrrp-web-archive@optimus.ietf.org; Tue, 19 Aug 2003 15:54:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05510 for ; Tue, 19 Aug 2003 15:53:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19pCYL-0006z2-00 for vrrp-web-archive@ietf.org; Tue, 19 Aug 2003 15:54:01 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19pCYK-0006yz-00 for vrrp-web-archive@ietf.org; Tue, 19 Aug 2003 15:54:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pCYK-0007RN-ME; Tue, 19 Aug 2003 15:54:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pCXV-0007Pe-AS for vrrp@optimus.ietf.org; Tue, 19 Aug 2003 15:53:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05435 for ; Tue, 19 Aug 2003 15:53:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19pCXT-0006xd-00 for vrrp@ietf.org; Tue, 19 Aug 2003 15:53:07 -0400 Received: from brmea-mail-3.sun.com ([192.18.98.34]) by ietf-mx with esmtp (Exim 4.12) id 19pCXS-0006xZ-00 for vrrp@ietf.org; Tue, 19 Aug 2003 15:53:06 -0400 Received: from sydney.East.Sun.COM ([129.148.9.16]) by brmea-mail-3.sun.com (8.12.9/8.12.9) with ESMTP id h7JJr6to017553; Tue, 19 Aug 2003 13:53:06 -0600 (MDT) Received: from sr1-ubur-06 (sr1-ubur-06 [129.148.9.86]) by sydney.East.Sun.COM (8.11.7+Sun/8.11.7/ENSMAIL,v2.2) with SMTP id h7JJr5s24031; Tue, 19 Aug 2003 15:53:05 -0400 (EDT) Message-Id: <200308191953.h7JJr5s24031@sydney.East.Sun.COM> Date: Tue, 19 Aug 2003 15:53:05 -0400 (EDT) From: Radia Perlman - Boston Center for Networking Reply-To: Radia Perlman - Boston Center for Networking Subject: Re: [VRRP] VRRP MIB(s) - some questions and request for comments To: vrrp@ietf.org, Kalyan.Tata@nokia.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: ZgTmf9IzFcGcZyyNIE/H/w== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.5.3_06 SunOS 5.9 sun4u sparc Sender: vrrp-admin@ietf.org Errors-To: vrrp-admin@ietf.org X-BeenThere: vrrp@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Virtual Router Redundancy Protocol List-Post: List-Help: List-Subscribe: , Re: one MIB for IPv4+IPv6 that would obsolete the current IPv4-only, or two MIBs, one for IPv4-only, and one for IPv6-only: It would be good if someone would ask Bert Wijnen his opinion on this. And a question...are we assuming the existence of mixed-IPv4/IPv6 VRRP environments? (as in, might a single router be simultaneously involved in an IPv4 and an IPv6 election)? If so, that might argue for being one MIB. I think the authors (and others) have made good cases for 2 documents forever (rather than temporarily V4-only, to be obsoleted). But I got the impression that Bert Wijnen would prefer a single document. Radia _______________________________________________ vrrp mailing list vrrp@ietf.org https://www1.ietf.org/mailman/listinfo/vrrp From exim@www1.ietf.org Tue Aug 19 16:19:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07024 for ; Tue, 19 Aug 2003 16:19:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pCwY-0000t2-W3 for vrrp-archive@odin.ietf.org; Tue, 19 Aug 2003 16:19:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7JKJ2kf003402 for vrrp-archive@odin.ietf.org; Tue, 19 Aug 2003 16:19:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pCwY-0000sn-T6 for vrrp-web-archive@optimus.ietf.org; Tue, 19 Aug 2003 16:19:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07008 for ; Tue, 19 Aug 2003 16:18:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19pCwX-0007Ob-00 for vrrp-web-archive@ietf.org; Tue, 19 Aug 2003 16:19:01 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19pCwW-0007OY-00 for vrrp-web-archive@ietf.org; Tue, 19 Aug 2003 16:19:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pCwX-0000sB-3M; Tue, 19 Aug 2003 16:19:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pCwK-0000qC-Jw for vrrp@optimus.ietf.org; Tue, 19 Aug 2003 16:18:48 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06981 for ; Tue, 19 Aug 2003 16:18:43 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19pCwH-0007O9-00 for vrrp@ietf.org; Tue, 19 Aug 2003 16:18:45 -0400 Received: from dns.nexthop.com ([65.247.36.216] helo=presque.nexthop.com) by ietf-mx with esmtp (Exim 4.12) id 19pCwG-0007Ng-00 for vrrp@ietf.org; Tue, 19 Aug 2003 16:18:44 -0400 Received: (from root@localhost) by presque.nexthop.com (8.12.9/8.11.1) id h7JKIElj050076; Tue, 19 Aug 2003 16:18:14 -0400 (EDT) (envelope-from jhaas@jhaas.nexthop.com) Received: from jhaas.nexthop.com (jhaas.nexthop.com [65.247.36.31]) by presque.nexthop.com (8.12.9/8.12.8) with ESMTP id h7JKI7Ag050051; Tue, 19 Aug 2003 16:18:08 -0400 (EDT) (envelope-from jhaas@jhaas.nexthop.com) Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id h7JKI2A14117; Tue, 19 Aug 2003 16:18:02 -0400 (EDT) Date: Tue, 19 Aug 2003 16:18:02 -0400 From: Jeffrey Haas To: Radia Perlman - Boston Center for Networking Cc: vrrp@ietf.org, Kalyan.Tata@nokia.com Subject: Re: [VRRP] VRRP MIB(s) - some questions and request for comments Message-ID: <20030819161802.H11511@nexthop.com> References: <200308191953.h7JJr5s24031@sydney.East.Sun.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200308191953.h7JJr5s24031@sydney.East.Sun.COM>; from Radia.Perlman@Sun.COM on Tue, Aug 19, 2003 at 03:53:05PM -0400 X-Virus-Scanned: by AMaViS perl-11 Sender: vrrp-admin@ietf.org Errors-To: vrrp-admin@ietf.org X-BeenThere: vrrp@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Virtual Router Redundancy Protocol List-Post: List-Help: List-Subscribe: , I don't presume to speak for anyone in the OPS group, but... If you have one MIB, you tie advancement of both protocols to that MIB in the standards process. All must advance as one. On Tue, Aug 19, 2003 at 03:53:05PM -0400, Radia Perlman - Boston Center for Networking wrote: > Re: one MIB for IPv4+IPv6 that would obsolete the current IPv4-only, > or two MIBs, one for IPv4-only, and one for IPv6-only: > > It would be good if someone would ask Bert Wijnen his opinion on this. > > And a question...are we assuming the existence of mixed-IPv4/IPv6 VRRP > environments? (as in, might a single router be simultaneously involved > in an IPv4 and an IPv6 election)? If so, that might argue for being > one MIB. I think the authors (and others) have made good cases for > 2 documents forever (rather than temporarily V4-only, to be obsoleted). > But I got the impression that Bert Wijnen would prefer a single document. > > Radia > > > _______________________________________________ > vrrp mailing list > vrrp@ietf.org > https://www1.ietf.org/mailman/listinfo/vrrp -- Jeff Haas NextHop Technologies _______________________________________________ vrrp mailing list vrrp@ietf.org https://www1.ietf.org/mailman/listinfo/vrrp From exim@www1.ietf.org Tue Aug 19 18:25:44 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13118 for ; Tue, 19 Aug 2003 18:25:44 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pEul-000787-OB for vrrp-archive@odin.ietf.org; Tue, 19 Aug 2003 18:25:20 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7JMPJcg027406 for vrrp-archive@odin.ietf.org; Tue, 19 Aug 2003 18:25:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pEul-00077v-Ht for vrrp-web-archive@optimus.ietf.org; Tue, 19 Aug 2003 18:25:19 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13057 for ; Tue, 19 Aug 2003 18:25:12 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19pEui-0000wy-00 for vrrp-web-archive@ietf.org; Tue, 19 Aug 2003 18:25:16 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19pEuf-0000wX-00 for vrrp-web-archive@ietf.org; Tue, 19 Aug 2003 18:25:13 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pEuW-00071T-51; Tue, 19 Aug 2003 18:25:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pE86-0004Y9-HN for vrrp@optimus.ietf.org; Tue, 19 Aug 2003 17:35:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10185 for ; Tue, 19 Aug 2003 17:34:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19pE84-0000UL-00 for vrrp@ietf.org; Tue, 19 Aug 2003 17:35:00 -0400 Received: from emerson.torrentnet.com ([198.78.51.110]) by ietf-mx with esmtp (Exim 4.12) id 19pE83-0000UI-00 for vrrp@ietf.org; Tue, 19 Aug 2003 17:34:59 -0400 Received: from imperial.torrentnet.com (imperial.torrentnet.com [198.78.51.109]) by emerson.torrentnet.com (8.11.6p2/8.11.2) with ESMTP id h7JLYrR57844; Tue, 19 Aug 2003 17:34:53 -0400 (EDT) Received: from ericsson.com (gibran.torrentnet.com [4.18.161.27]) by imperial.torrentnet.com (8.11.6p2/8.11.2) with ESMTP id h7JLYrf29523; Tue, 19 Aug 2003 17:34:53 -0400 (EDT) Message-ID: <3F4297FC.60601@ericsson.com> Date: Tue, 19 Aug 2003 17:34:52 -0400 From: Vikram Pendharkar Reply-To: vikram.pendharkar@ericsson.com Organization: Ericsson IP Infrastructure User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20021003 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Radia Perlman - Boston Center for Networking CC: vrrp@ietf.org, Kalyan.Tata@nokia.com Subject: Re: [VRRP] VRRP MIB(s) - some questions and request for comments References: <200308191953.h7JJr5s24031@sydney.East.Sun.COM> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: vrrp-admin@ietf.org Errors-To: vrrp-admin@ietf.org X-BeenThere: vrrp@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Virtual Router Redundancy Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Radia Perlman - Boston Center for Networking wrote: >Re: one MIB for IPv4+IPv6 that would obsolete the current IPv4-only, >or two MIBs, one for IPv4-only, and one for IPv6-only: > >It would be good if someone would ask Bert Wijnen his opinion on this. > >And a question...are we assuming the existence of mixed-IPv4/IPv6 VRRP >environments? (as in, might a single router be simultaneously involved >in an IPv4 and an IPv6 election)? > Some of the Ericsson solutions do envision the existence of mixed-IPv4/IPv-6 VRRP environments. >If so, that might argue for being >one MIB. I think the authors (and others) have made good cases for >2 documents forever (rather than temporarily V4-only, to be obsoleted). >But I got the impression that Bert Wijnen would prefer a single document. > >Radia > > >_______________________________________________ >vrrp mailing list >vrrp@ietf.org >https://www1.ietf.org/mailman/listinfo/vrrp > > > -- Vikram Pendharkar Ericsson IP Infrastructure _______________________________________________ vrrp mailing list vrrp@ietf.org https://www1.ietf.org/mailman/listinfo/vrrp From exim@www1.ietf.org Tue Aug 19 20:46:32 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA18868 for ; Tue, 19 Aug 2003 20:46:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pH70-0005Ir-JM for vrrp-archive@odin.ietf.org; Tue, 19 Aug 2003 20:46:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7K0k6OL020381 for vrrp-archive@odin.ietf.org; Tue, 19 Aug 2003 20:46:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pH70-0005Ie-GG for vrrp-web-archive@optimus.ietf.org; Tue, 19 Aug 2003 20:46:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA18828 for ; Tue, 19 Aug 2003 20:46:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19pH6y-0002JR-00 for vrrp-web-archive@ietf.org; Tue, 19 Aug 2003 20:46:04 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19pH6x-0002JO-00 for vrrp-web-archive@ietf.org; Tue, 19 Aug 2003 20:46:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pH6u-0005I1-Up; Tue, 19 Aug 2003 20:46:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pH6A-0005FO-98 for vrrp@optimus.ietf.org; Tue, 19 Aug 2003 20:45:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA18786 for ; Tue, 19 Aug 2003 20:45:09 -0400 (EDT) From: Kalyan.Tata@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19pH67-0002IV-00 for vrrp@ietf.org; Tue, 19 Aug 2003 20:45:12 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 19pH67-0002IS-00 for vrrp@ietf.org; Tue, 19 Aug 2003 20:45:11 -0400 Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h7K0jA415532 for ; Wed, 20 Aug 2003 03:45:11 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 20 Aug 2003 03:45:10 +0300 Received: from daebh002.NOE.Nokia.com ([172.18.242.232]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 20 Aug 2003 03:45:10 +0300 Received: from mvebe001.NOE.Nokia.com ([172.18.140.37]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 19 Aug 2003 19:45:07 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [VRRP] VRRP MIB(s) - some questions and request for comments Date: Tue, 19 Aug 2003 17:45:06 -0700 Message-ID: <4D7B558499107545BB45044C63822DDE03873B30@mvebe001.americas.nokia.com> Thread-Topic: [VRRP] VRRP MIB(s) - some questions and request for comments Thread-Index: AcNmmfYRJqTPCUCASsef5NX/jN2ajAAC5SUw To: , Cc: X-OriginalArrivalTime: 20 Aug 2003 00:45:07.0754 (UTC) FILETIME=[4D89F8A0:01C366B4] Content-Transfer-Encoding: quoted-printable Sender: vrrp-admin@ietf.org Errors-To: vrrp-admin@ietf.org X-BeenThere: vrrp@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Virtual Router Redundancy Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable hi,=20 The bottom line question here is: Do we envision having managed objects that are VRRP-IP version = independent? i.e., at the configuration/monitoring level user/administrator is = looking at VRRP and not VRRP-IPv4 and VRRP-IPv6?=20 Do we think that one definition of "invalidVRID" (as an example)=20 is good enough to specify invalidVRIDs on both VRRP-IPv4 and VRRP-IPv6=20 protocols in a mixed environment? If we *do not* need the granularity=20 to define per protocol basis, then extending the existing definition=20 to include VRRP-IPv6 is the way to go (and hence have one MIB). I think that we will require the granularity of configuration objects at protocol level (to debug misconfigurations for example), Which means that we need to put in protocol version for all the common objects to=20 distinguish between two protocols. Please note that there are a number of differences between the two=20 protocols too. Which means that we would have to define some of the=20 parameters that apply for VRRP-IPv4 only and some for VRRP-IPv6 only. Defining one MIB means: - No backward compatibility (the new MIB structure will have to be=20 different from the existing structure) - The MIB will have protocol version specific objects that apply=20 to only one particular protocol any way. From the development point of view, I think VRRP-IPv6 will be = implemented=20 separate from the VRRP-IPv4 implementation, which means that it is = easier to implement a separate new MIB than to change existing MIB = implementation=20 (well this is debatable - I know..) Thanks kalyan Radia Perlman - Boston Center for Networking wrote: >Re: one MIB for IPv4+IPv6 that would obsolete the current IPv4-only, >or two MIBs, one for IPv4-only, and one for IPv6-only: > >It would be good if someone would ask Bert Wijnen his opinion on this. > >And a question...are we assuming the existence of mixed-IPv4/IPv6 VRRP >environments? (as in, might a single router be simultaneously involved >in an IPv4 and an IPv6 election)?=20 > Some of the Ericsson solutions do envision the existence of=20 mixed-IPv4/IPv-6 VRRP environments. >If so, that might argue for being >one MIB. I think the authors (and others) have made good cases for >2 documents forever (rather than temporarily V4-only, to be obsoleted). >But I got the impression that Bert Wijnen would prefer a single = document. > >Radia > > >_______________________________________________ >vrrp mailing list >vrrp@ietf.org >https://www1.ietf.org/mailman/listinfo/vrrp > > =20 > --=20 Vikram Pendharkar =09 Ericsson IP Infrastructure _______________________________________________ vrrp mailing list vrrp@ietf.org https://www1.ietf.org/mailman/listinfo/vrrp From exim@www1.ietf.org Wed Aug 20 13:49:39 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24549 for ; Wed, 20 Aug 2003 13:49:39 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pX58-00019g-H0 for vrrp-archive@odin.ietf.org; Wed, 20 Aug 2003 13:49:15 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7KHnE2Z004436 for vrrp-archive@odin.ietf.org; Wed, 20 Aug 2003 13:49:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pX58-00019T-Dj for vrrp-web-archive@optimus.ietf.org; Wed, 20 Aug 2003 13:49:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24407 for ; Wed, 20 Aug 2003 13:49:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19pX56-0004U7-00 for vrrp-web-archive@ietf.org; Wed, 20 Aug 2003 13:49:12 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19pX4y-0004U1-00 for vrrp-web-archive@ietf.org; Wed, 20 Aug 2003 13:49:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pX4v-00011R-5J; Wed, 20 Aug 2003 13:49:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pX4q-000118-Cu for vrrp@optimus.ietf.org; Wed, 20 Aug 2003 13:48:56 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24398 for ; Wed, 20 Aug 2003 13:48:50 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19pX4o-0004Tk-00 for vrrp@ietf.org; Wed, 20 Aug 2003 13:48:54 -0400 Received: from [216.142.75.231] (helo=exmail.bivio.net) by ietf-mx with smtp (Exim 4.12) id 19pX4n-0004Te-00 for vrrp@ietf.org; Wed, 20 Aug 2003 13:48:53 -0400 Received: from dprovan1 ([192.168.24.137]) by exmail.bivio.net with Microsoft SMTPSVC(5.0.2195.2966); Wed, 20 Aug 2003 10:48:52 -0700 From: "Don Provan" To: Cc: "'M. T. Hollinger'" Subject: RE: [VRRP] Virtual MAC for IPv6 Date: Wed, 20 Aug 2003 10:48:52 -0700 Message-ID: <002001c36743$5188dea0$8918a8c0@corp.networkrobots.com> X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: <02f101c3637d$9652b390$6400a8c0@PORTABRAIN> Importance: Normal X-OriginalArrivalTime: 20 Aug 2003 17:48:52.0593 (UTC) FILETIME=[51989610:01C36743] Sender: vrrp-admin@ietf.org Errors-To: vrrp-admin@ietf.org X-BeenThere: vrrp@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Virtual Router Redundancy Protocol List-Post: List-Help: List-Subscribe: , I wanted to weigh in *against* the artificial, shared MAC addresses, too. Contrary to Bob's assertion, I found them a significant problem even in IPv4, well worth avoiding if there's any possibility. One problem I've previously brought up here is the one switch I ran into that dropped any packet that changed a learned addresses. This resulted in a ping-pong problem where two routers would both be happily sending advertisements once a second yet never hearing one another. (My implementation routinely sends two advertisements at a time, one using the natural MAC address as the source, just to make sure this isn't a problem.) But even beyond that, I found that during development, implementation problems could lead to strange problems that were hard to diagnose. Some problems were hard to even detect. For example, one switch had a configuration parameter that caused it to interpret the duplicate MAC address not as a move, but as extending the MAC address to two links. Then it would happily send traffic for that MAC down both the links, wasting bandwidth on the link that was no longer supporting the VR. Originally I saw the VRRP MAC address as a clever trick to provide maximum support for even the stupidest of remote nodes. But now that I've encountered such a wide range of reactions by modern switches, I'm not so sure I think it's a good idea in IPv4, let alone in IPv6. -don > -----Original Message----- > From: vrrp-admin@ietf.org [mailto:vrrp-admin@ietf.org]On > Behalf Of M. T. > Hollinger > Sent: Friday, August 15, 2003 3:36 PM > To: vrrp@ietf.org > Subject: Re: [VRRP] Virtual MAC for IPv6 > > > Bob, I think we will have to agree to disagree on this issue. > > I continue to believe that support for duplicate MAC addresses places > additional constraints on the underlying data-link layer, > creating potential > restrictions or incompatibilities for VRRP as new IEEE 802 > variants emerge > or switch vendors develop new optimizations for traditional > Ethernet links. > Moreover, hiding the identity of the current router may complicate > troubleshooting and keep "smart" workload management software > on end hosts > from noting and responding to network failures. > > To me, the argument that virtual MAC addresses have worked > satisfactorily in > the IPv4 VRRP world is not compelling. As I said in Vienna, > NAT may be > deployed and proven technology in the IPv4 world too, but > that should not > prevent us from considering architecturally cleaner designs as we move > toward IPv6. > > In general, layer violations should be avoided because they introduce > complexity and constraints. As someone who has experience > with DECnet Phase > IV, I have become painfully aware of the pitfalls of having > upper-layer > protocols override the hardware MAC address. Even without the added > complication of suddenly moving the virtual MAC address to > another part of > the network, simply using a physical MAC address different > from the hardware > address brings confusion and dependencies. > > As you (Bob) pointed out, the picture gets even more complicated when > considering subsecond timers and the goal of very fast failover. How > quickly will your switches learn the new location of the router's VMAC > address, and propagate their spanning tree data throughout > the extended LAN? > If it takes VRRP 3 seconds to initiate failover and your > switches another 3 > seconds, is that acceptable? Users who want fast failover > will have to shop > around for switches that respond quickly to movement of a unicast MAC > address. > > On the other hand, if you get rid of VMAC, you eliminate the > dependency on > switch behavior. > > - Mark > > ----- Original Message ----- > From: "Bob Hinden" > To: "M. T. Hollinger" > Cc: > Sent: Tuesday, July 15, 2003 11:02 AM > Subject: Re: [VRRP] Virtual MAC for IPv6 > > > Mark, > > At 06:52 AM 7/15/2003, M. T. Hollinger wrote: > >The vrrp-ipv6-spec-05 draft still specifies the use of virtual MAC > >addresses, even with IPv6. > > > >I have long disliked the use of duplicate MAC addresses for > v4, which was > >justified with the argument that some older ARP > implementations did not > >properly receive and parse gratuitous ARP messages. > > > >That argument does not apply to IPv6. I oppose moving this document > forward > >until the use of virtual MAC is removed. (Alternatively, if > there is a > >strong justification, then text could be added to the > document explaining > >why this architecturally awful design was believed to be the > best choice > for > >the IPv6 environment.) > > I don't agree that it is so bad or as you say an > "architecturally awful > design". I have thought about it as one of the great MAC > address hacks :-) > > The advantage of this approach is that it works without the > hosts having to > do anything (e.g., receive and process an ND message, update tables, > etc.). The switch over is transparent to the hosts. > > This approach is well proven in the IPv4 version of VRRP. It > is running > operationally in many places and I am not aware of any > problems. Are you > aware of any technical problems with the virtual MAC address approach? > > Thanks, > Bob > > > _______________________________________________ > vrrp mailing list > vrrp@ietf.org > https://www1.ietf.org/mailman/listinfo/vrrp _______________________________________________ vrrp mailing list vrrp@ietf.org https://www1.ietf.org/mailman/listinfo/vrrp From exim@www1.ietf.org Thu Aug 21 10:45:31 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08433 for ; Thu, 21 Aug 2003 10:45:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pqgV-0001qe-3G for vrrp-archive@odin.ietf.org; Thu, 21 Aug 2003 10:45:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7LEj7Oa007100 for vrrp-archive@odin.ietf.org; Thu, 21 Aug 2003 10:45:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pqgU-0001qR-VM for vrrp-web-archive@optimus.ietf.org; Thu, 21 Aug 2003 10:45:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08412 for ; Thu, 21 Aug 2003 10:45:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19pqgS-00047Q-00 for vrrp-web-archive@ietf.org; Thu, 21 Aug 2003 10:45:04 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19pqgS-00047M-00 for vrrp-web-archive@ietf.org; Thu, 21 Aug 2003 10:45:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pqgO-0001pI-MY; Thu, 21 Aug 2003 10:45:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pqfs-0001oA-9m for vrrp@optimus.ietf.org; Thu, 21 Aug 2003 10:44:28 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08378 for ; Thu, 21 Aug 2003 10:43:41 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19pqfB-00046a-00 for vrrp@ietf.org; Thu, 21 Aug 2003 10:43:45 -0400 Received: from athena.nswc.navy.mil ([198.91.70.29]) by ietf-mx with esmtp (Exim 4.12) id 19pqfB-00046X-00 for vrrp@ietf.org; Thu, 21 Aug 2003 10:43:45 -0400 Received: from relay.nswc.navy.mil (relay.nswc.navy.mil [128.38.1.41]) by athena.nswc.navy.mil (8.11.6p2/8.11.6) with ESMTP id h7LEhiF06662 for ; Thu, 21 Aug 2003 10:43:44 -0400 (PDT) Received: from relay.nswc.navy.mil (localhost [127.0.0.1]) by relay.nswc.navy.mil (8.11.6p2/8.11.6) with ESMTP id h7LEhig27702 for ; Thu, 21 Aug 2003 10:43:44 -0400 (EDT) Received: from titanic.nswc.navy.mil (titanic.nswc.navy.mil [128.38.42.115]) by relay.nswc.navy.mil (8.11.6p2/8.11.6) with ESMTP id h7LEhh627697 for ; Thu, 21 Aug 2003 10:43:43 -0400 (EDT) Received: from nswc.navy.mil (localhost [127.0.0.1]) by titanic.nswc.navy.mil (8.11.7+Sun/8.9.3) with ESMTP id h7LEhgi23223 for ; Thu, 21 Aug 2003 10:43:42 -0400 (EDT) Message-ID: <3F44DB89.9060504@nswc.navy.mil> Date: Thu, 21 Aug 2003 10:47:37 -0400 From: "Karen O'Donoghue" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: vrrp Subject: Re: FW: [VRRP] Subsecond Timers for VRRPv3 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: vrrp-admin@ietf.org Errors-To: vrrp-admin@ietf.org X-BeenThere: vrrp@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Virtual Router Redundancy Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit My apologies for the delay in speaking up. It required a bit of prodding... I am trying to take time off this week... >>In the WG meeting in Vienna, we all agreed that the >>sub-second timers should be allowed at least in >>VRRPv3 > > since I missed the working group meeting and > didn't see explicit justification for this decision > in the meeting minutes I'm wondering if someone > could summarize the justification for this feature? The US Navy has a shipboard application where we need subsecond timers for survivability. We currently have a solution that uses HSRP tuned to meet these requirements. We would like to be able to deploy the same solution using vrrp (as an open standard). We understand that there are other components that are required to give us the full capability that we require. We also understand that this approach should be used with caution. > I don't have the paper right here in front of > me, but the original vrrpv2 design incorporated > findings from the higginson&shand DEC TR referenced > in the RFC. a simple picture showing > a generalized internetwork, illustrating where > failures could occur in end-to-end connectivity, > and then expected recovery interval for typical > IETF standardized protocols. basically illustrated > that protocol recovery on the order of seconds > was inline with Internet standards. We understand that our application is not a typical use of these protocols, but we need to be able to survive any single fault transparently to the application. Mukesh has suggested a draft that addresses the requirements for this capability along with options and interoperability issues. Perhaps as part of this draft we can revisit the above discussion. I have agreed to help put this draft together, and I am happy to accept assistance! Regards, Karen > have these findings changed? is there a movement > toward end-to-end connectivity containing only > vrrp ``routing'' and L2 with transparent, sub-second > recovery? > > later,danny -- ************************************************************ Karen O'Donoghue Code B35, NSWCDD, 17320 Dahlgren Rd., Dahlgren, VA 22448 +1-540-653-1567 (voice) +1-540-653-8673 (fax) +1-540-729-7509 (cell) odonoghuekf@nswc.navy.mil _______________________________________________ vrrp mailing list vrrp@ietf.org https://www1.ietf.org/mailman/listinfo/vrrp From exim@www1.ietf.org Thu Aug 21 19:24:36 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA08678 for ; Thu, 21 Aug 2003 19:24:36 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pymo-0007fk-0Q for vrrp-archive@odin.ietf.org; Thu, 21 Aug 2003 19:24:10 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7LNO9WJ029492 for vrrp-archive@odin.ietf.org; Thu, 21 Aug 2003 19:24:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pymn-0007fb-Rx for vrrp-web-archive@optimus.ietf.org; Thu, 21 Aug 2003 19:24:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA08668 for ; Thu, 21 Aug 2003 19:24:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19pymm-0003X8-00 for vrrp-web-archive@ietf.org; Thu, 21 Aug 2003 19:24:08 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19pyml-0003X5-00 for vrrp-web-archive@ietf.org; Thu, 21 Aug 2003 19:24:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pyme-0007ea-TL; Thu, 21 Aug 2003 19:24:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ppxb-0008Go-0P for vrrp@optimus.ietf.org; Thu, 21 Aug 2003 09:58:43 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05660 for ; Thu, 21 Aug 2003 09:58:35 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ppxX-0003em-00 for vrrp@ietf.org; Thu, 21 Aug 2003 09:58:39 -0400 Received: from athena.nswc.navy.mil ([198.91.70.29]) by ietf-mx with esmtp (Exim 4.12) id 19ppxW-0003ej-00 for vrrp@ietf.org; Thu, 21 Aug 2003 09:58:38 -0400 Received: from relay.nswc.navy.mil (relay.nswc.navy.mil [128.38.1.41]) by athena.nswc.navy.mil (8.11.6p2/8.11.6) with ESMTP id h7LDwcF27219 for ; Thu, 21 Aug 2003 09:58:38 -0400 (PDT) Received: from relay.nswc.navy.mil (localhost [127.0.0.1]) by relay.nswc.navy.mil (8.11.6p2/8.11.6) with ESMTP id h7LDwbg08675 for ; Thu, 21 Aug 2003 09:58:37 -0400 (EDT) Received: from titanic.nswc.navy.mil (titanic.nswc.navy.mil [128.38.42.115]) by relay.nswc.navy.mil (8.11.6p2/8.11.6) with ESMTP id h7LDwb608671 for ; Thu, 21 Aug 2003 09:58:37 -0400 (EDT) Received: from nswc.navy.mil (localhost [127.0.0.1]) by titanic.nswc.navy.mil (8.11.7+Sun/8.9.3) with ESMTP id h7LDwZi21612 for ; Thu, 21 Aug 2003 09:58:35 -0400 (EDT) Message-ID: <3F44D0F6.8080006@nswc.navy.mil> Date: Thu, 21 Aug 2003 10:02:30 -0400 From: "Karen O'Donoghue" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: vrrp@ietf.org Subject: Re: FW: [VRRP] Subsecond Timers for VRRPv3 References: <8D260779A766FB4A9C1739A476F84FA476C41B@daebe009.americas.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: vrrp-admin@ietf.org Errors-To: vrrp-admin@ietf.org X-BeenThere: vrrp@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Virtual Router Redundancy Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit My apologies for the delay in speaking up. It required a bit of prodding... I am trying to take time off this week... >>In the WG meeting in Vienna, we all agreed that the >>sub-second timers should be allowed at least in >>VRRPv3 > > since I missed the working group meeting and > didn't see explicit justification for this decision > in the meeting minutes I'm wondering if someone > could summarize the justification for this feature? The US Navy has a shipboard application where we need subsecond timers for survivability. We currently have a solution that uses HSRP tuned to meet these requirements. We would like to be able to deploy the same solution using vrrp (as an open standard). We understand that there are other components that are required to give us the full capability that we require. We also understand that this approach should be used with caution. > I don't have the paper right here in front of > me, but the original vrrpv2 design incorporated > findings from the higginson&shand DEC TR referenced > in the RFC. a simple picture showing > a generalized internetwork, illustrating where > failures could occur in end-to-end connectivity, > and then expected recovery interval for typical > IETF standardized protocols. basically illustrated > that protocol recovery on the order of seconds > was inline with Internet standards. We understand that our application is not a typical use of these protocols, but we need to be able to survive any single fault transparently to the application. Mukesh has suggested a draft that addresses the requirements for this capability along with options and interoperability issues. Perhaps as part of this draft we can revisit the above discussion. I have agreed to help put this draft together, and I am happy to accept assistance! Regards, Karen > have these findings changed? is there a movement > toward end-to-end connectivity containing only > vrrp ``routing'' and L2 with transparent, sub-second > recovery? > > later,danny -- ************************************************************ Karen O'Donoghue Code B35, NSWCDD, 17320 Dahlgren Rd., Dahlgren, VA 22448 +1-540-653-1567 (voice) +1-540-653-8673 (fax) +1-540-729-7509 (cell) odonoghuekf@nswc.navy.mil _______________________________________________ vrrp mailing list vrrp@ietf.org https://www1.ietf.org/mailman/listinfo/vrrp From exim@www1.ietf.org Mon Aug 25 02:08:35 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA23128 for ; Mon, 25 Aug 2003 02:08:35 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19rAWQ-0006WG-To for vrrp-archive@odin.ietf.org; Mon, 25 Aug 2003 02:08:11 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7P68ASA025019 for vrrp-archive@odin.ietf.org; Mon, 25 Aug 2003 02:08:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19rAWO-0006V4-GP for vrrp-web-archive@optimus.ietf.org; Mon, 25 Aug 2003 02:08:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA22574 for ; Mon, 25 Aug 2003 02:08:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19rAWL-0002QQ-00 for vrrp-web-archive@ietf.org; Mon, 25 Aug 2003 02:08:05 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19rAWK-0002QM-00 for vrrp-web-archive@ietf.org; Mon, 25 Aug 2003 02:08:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19rAWI-0006Ss-9U; Mon, 25 Aug 2003 02:08:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19rAW3-0006PA-Br for vrrp@optimus.ietf.org; Mon, 25 Aug 2003 02:07:47 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA22219 for ; Mon, 25 Aug 2003 02:07:41 -0400 (EDT) From: esa.sarkama@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19rAVz-0002Q8-00 for vrrp@ietf.org; Mon, 25 Aug 2003 02:07:43 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 19rAVy-0002Q4-00 for vrrp@ietf.org; Mon, 25 Aug 2003 02:07:43 -0400 Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h7P67g414148 for ; Mon, 25 Aug 2003 09:07:43 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Mon, 25 Aug 2003 09:07:42 +0300 Received: from esebe009.NOE.Nokia.com ([172.21.138.41]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Mon, 25 Aug 2003 09:07:42 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 25 Aug 2003 09:07:41 +0300 Message-ID: Thread-Topic: [VRRP] Subsecond Timers for VRRPv3 Thread-Index: AcNmEqXPmaL2hV9sQh2VtsPjNdDeMQEuQhXQ To: X-OriginalArrivalTime: 25 Aug 2003 06:07:42.0163 (UTC) FILETIME=[31BB2A30:01C36ACF] Content-Transfer-Encoding: quoted-printable Subject: [VRRP] Subsecond Timers - Adv Interval Sender: vrrp-admin@ietf.org Errors-To: vrrp-admin@ietf.org X-BeenThere: vrrp@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Virtual Router Redundancy Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi, I propose following way to code the Advertisement Interval octet: divide the octet in two parts : the first two bits are "divider" (in = base 10) and the last 6 bits are the actual value. 00xxxxxx -> divide the x's by 10^0 (=3D 1)-> Adv Int range is 0 ... = 63sec, with sec granularity 01xxxxxx -> divide the x's by 10^1 (=3D 10) -> Adv Int range is 0 ... = 6.3sec, with 100ms granularity 10xxxxxx -> divide the x's by 10^2 (=3D100) -> Adv Int range is 0 ... = 0.63sec , with 10ms granularity 11xxxxxx -> divide the x's by 10^3 (=3D1000) -> Adv Int range is 0... = 0.063sec , with 1ms granularity With the above coding existing implementations will work,=20 1) the adv interval is one octet 2) I think in the real life, longer than 60 sec adv interval is not = used. Milli second granularity is needed in the small time scales.=20 When using long (e.g. 1sec) Adv Interval, the 1ms granularity is not = needed. I would say 100ms is enough. br esa =20 _______________________________________________ vrrp mailing list vrrp@ietf.org https://www1.ietf.org/mailman/listinfo/vrrp From exim@www1.ietf.org Wed Aug 27 02:27:04 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA21222 for ; Wed, 27 Aug 2003 02:27:04 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19rtTk-0000r0-6X for vrrp-archive@odin.ietf.org; Wed, 27 Aug 2003 02:08:24 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7R68Mwb003272 for vrrp-archive@odin.ietf.org; Wed, 27 Aug 2003 02:08:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19rr4y-0000zO-SH for vrrp-web-archive@optimus.ietf.org; Tue, 26 Aug 2003 23:34:40 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA13227 for ; Tue, 26 Aug 2003 23:34:35 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19rr4w-0002gK-00 for vrrp-web-archive@ietf.org; Tue, 26 Aug 2003 23:34:38 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19rr4w-0002gG-00 for vrrp-web-archive@ietf.org; Tue, 26 Aug 2003 23:34:38 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19rmpU-0005IS-HZ; Tue, 26 Aug 2003 19:02:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19rdpx-0003JU-CP for vrrp@optimus.ietf.org; Tue, 26 Aug 2003 09:26:17 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03239 for ; Tue, 26 Aug 2003 09:26:11 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19rdpv-0000eE-00 for vrrp@ietf.org; Tue, 26 Aug 2003 09:26:15 -0400 Received: from hoemail2.lucent.com ([192.11.226.163] helo=hoemail2.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 19rdpu-0000e7-00 for vrrp@ietf.org; Tue, 26 Aug 2003 09:26:14 -0400 Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by hoemail2.firewall.lucent.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h7QDPeC27975 for ; Tue, 26 Aug 2003 08:25:40 -0500 (CDT) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2653.19) id ; Tue, 26 Aug 2003 15:25:39 +0200 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B1550245BDFA@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: vrrp@ietf.org Date: Tue, 26 Aug 2003 15:25:36 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [VRRP] IPv4 and IPv6 crrpMIB vs one combined MIB Sender: vrrp-admin@ietf.org Errors-To: vrrp-admin@ietf.org X-BeenThere: vrrp@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Virtual Router Redundancy Protocol List-Post: List-Help: List-Subscribe: , Mmmm... just so you can check for your self, if I just look at the MIB structure, then it seems to me that there is A LOT of commonality? So that seems to "justify" or "guide" to try and come up with a single common MIB module. OID tree 1.3.6.1.2.1.xx vrrpIpv6MIB [VRRP-IPv6-MIB]: module-identity 1.3.6.1.2.1.xx.0 vrrpIpv6Notifications [VRRP-IPv6-MIB]: oid-value-assignment 1.3.6.1.2.1.xx.0.1 vrrpIpv6TrapNewMaster [VRRP-IPv6-MIB]: notification-type 1.3.6.1.2.1.xx.0.2 vrrpIpv6TrapProtoError [VRRP-IPv6-MIB]: notification-type 1.3.6.1.2.1.xx.1 vrrpIpv6Operations [VRRP-IPv6-MIB]: oid-value-assignment 1.3.6.1.2.1.xx.1.1 vrrpIpv6NodeVersion [VRRP-IPv6-MIB]: scalar-object-type 1.3.6.1.2.1.xx.1.2 vrrpIpv6NotificationCntl [VRRP-IPv6-MIB]: scalar-object-type 1.3.6.1.2.1.xx.1.3 vrrpIpv6OperTable [VRRP-IPv6-MIB]: table-object-type 1.3.6.1.2.1.xx.1.3.1 vrrpIpv6OperEntry [VRRP-IPv6-MIB]: row-object-type 1.3.6.1.2.1.xx.1.3.1.1 vrrpIpv6OperVrId [VRRP-IPv6-MIB]: columnar-object-type 1.3.6.1.2.1.xx.1.3.1.2 vrrpIpv6OperVirtualMacAddr [VRRP-IPv6-MIB]: columnar-object-type 1.3.6.1.2.1.xx.1.3.1.3 vrrpIpv6OperState [VRRP-IPv6-MIB]: columnar-object-type 1.3.6.1.2.1.xx.1.3.1.4 vrrpIpv6OperAdminState [VRRP-IPv6-MIB]: columnar-object-type 1.3.6.1.2.1.xx.1.3.1.5 vrrpIpv6OperPriority [VRRP-IPv6-MIB]: columnar-object-type 1.3.6.1.2.1.xx.1.3.1.6 vrrpIpv6OperIpAddrType [VRRP-IPv6-MIB]: columnar-object-type 1.3.6.1.2.1.xx.1.3.1.7 vrrpIpv6OperMasterIpAddr [VRRP-IPv6-MIB]: columnar-object-type 1.3.6.1.2.1.xx.1.3.1.8 vrrpIpv6OperAdvInterval [VRRP-IPv6-MIB]: columnar-object-type 1.3.6.1.2.1.xx.1.3.1.9 vrrpIpv6OperPreemptMode [VRRP-IPv6-MIB]: columnar-object-type 1.3.6.1.2.1.xx.1.3.1.10 vrrpIpv6OperVirtualRouterUpTime [VRRP-IPv6-MIB]: columnar-object-type 1.3.6.1.2.1.xx.1.3.1.11 vrrpIpv6OperProtocol [VRRP-IPv6-MIB]: columnar-object-type 1.3.6.1.2.1.xx.1.3.1.12 vrrpIpv6OperRowStatus [VRRP-IPv6-MIB]: columnar-object-type 1.3.6.1.2.1.xx.1.6 vrrpIpv6TrapNewMasterReason [VRRP-IPv6-MIB]: scalar-object-type 1.3.6.1.2.1.xx.1.7 vrrpIpv6TrapProtoErrReason [VRRP-IPv6-MIB]: scalar-object-type 1.3.6.1.2.1.xx.2 vrrpIpv6Statistics [VRRP-IPv6-MIB]: oid-value-assignment 1.3.6.1.2.1.xx.2.1 vrrpIpv6RouterChecksumErrors [VRRP-IPv6-MIB]: scalar-object-type 1.3.6.1.2.1.xx.2.2 vrrpIpv6RouterVersionErrors [VRRP-IPv6-MIB]: scalar-object-type 1.3.6.1.2.1.xx.2.3 vrrpIpv6RouterVrIdErrors [VRRP-IPv6-MIB]: scalar-object-type 1.3.6.1.2.1.xx.2.4 vrrpIpv6RouterStatsTable [VRRP-IPv6-MIB]: table-object-type 1.3.6.1.2.1.xx.2.4.1 vrrpIpv6RouterStatsEntry [VRRP-IPv6-MIB]: row-object-type 1.3.6.1.2.1.xx.2.4.1.1 vrrpIpv6StatsBecomeMaster [VRRP-IPv6-MIB]: columnar-object-type 1.3.6.1.2.1.xx.2.4.1.2 vrrpIpv6StatsAsMasterUpTime [VRRP-IPv6-MIB]: columnar-object-type 1.3.6.1.2.1.xx.2.4.1.3 vrrpIpv6StatsAdvRcvd [VRRP-IPv6-MIB]: columnar-object-type 1.3.6.1.2.1.xx.2.4.1.4 vrrpIpv6StatsAdvIntervalErrors [VRRP-IPv6-MIB]: columnar-object-type 1.3.6.1.2.1.xx.2.4.1.5 vrrpIpv6StatsHopLimitErrors [VRRP-IPv6-MIB]: columnar-object-type 1.3.6.1.2.1.xx.2.4.1.6 vrrpIpv6StatsPriZeroPktsRcvd [VRRP-IPv6-MIB]: columnar-object-type 1.3.6.1.2.1.xx.2.4.1.7 vrrpIpv6StatsPriZeroPktsSent [VRRP-IPv6-MIB]: columnar-object-type 1.3.6.1.2.1.xx.2.4.1.8 vrrpIpv6StatsInvalidTypePktsRcvd [VRRP-IPv6-MIB]: columnar-object-type 1.3.6.1.2.1.xx.2.4.1.9 vrrpIpv6StatsAddressListErrors [VRRP-IPv6-MIB]: columnar-object-type 1.3.6.1.2.1.xx.2.4.1.10 vrrpIpv6StatsPacketLengthErrors [VRRP-IPv6-MIB]: columnar-object-type 1.3.6.1.2.1.xx.3 vrrpIpv6Conformance [VRRP-IPv6-MIB]: oid-value-assignment 1.3.6.1.2.1.xx.3.1 vrrpIpv6MIBCompliances [VRRP-IPv6-MIB]: oid-value-assignment 1.3.6.1.2.1.xx.3.1.1 vrrpIpv6MIBCompliance [VRRP-IPv6-MIB]: module-compliance 1.3.6.1.2.1.xx.3.2 vrrpIpv6MIBGroups [VRRP-IPv6-MIB]: oid-value-assignment 1.3.6.1.2.1.xx.3.2.1 vrrpIpv6OperGroup [VRRP-IPv6-MIB]: object-group 1.3.6.1.2.1.xx.3.2.2 vrrpIpv6StatsGroup [VRRP-IPv6-MIB]: object-group 1.3.6.1.2.1.xx.3.2.3 vrrpIpv6TrapGroup [VRRP-IPv6-MIB]: object-group 1.3.6.1.2.1.xx.3.2.4 vrrpIpv6NotificationGroup [VRRP-IPv6-MIB]: notification-group **end of oid tree** --------------- OID tree 1.3.6.1.2.1.68 vrrpMIB [VRRP-MIB]: module-identity 1.3.6.1.2.1.68.0 vrrpNotifications [VRRP-MIB]: oid-value-assignment 1.3.6.1.2.1.68.0.1 vrrpTrapNewMaster [VRRP-MIB]: notification-type 1.3.6.1.2.1.68.0.2 vrrpTrapAuthFailure [VRRP-MIB]: notification-type 1.3.6.1.2.1.68.1 vrrpOperations [VRRP-MIB]: oid-value-assignment 1.3.6.1.2.1.68.1.1 vrrpNodeVersion [VRRP-MIB]: scalar-object-type 1.3.6.1.2.1.68.1.2 vrrpNotificationCntl [VRRP-MIB]: scalar-object-type 1.3.6.1.2.1.68.1.3 vrrpOperTable [VRRP-MIB]: table-object-type 1.3.6.1.2.1.68.1.3.1 vrrpOperEntry [VRRP-MIB]: row-object-type 1.3.6.1.2.1.68.1.3.1.1 vrrpOperVrId [VRRP-MIB]: columnar-object-type 1.3.6.1.2.1.68.1.3.1.2 vrrpOperVirtualMacAddr [VRRP-MIB]: columnar-object-type 1.3.6.1.2.1.68.1.3.1.3 vrrpOperState [VRRP-MIB]: columnar-object-type 1.3.6.1.2.1.68.1.3.1.4 vrrpOperAdminState [VRRP-MIB]: columnar-object-type 1.3.6.1.2.1.68.1.3.1.5 vrrpOperPriority [VRRP-MIB]: columnar-object-type 1.3.6.1.2.1.68.1.3.1.6 vrrpOperIpAddrCount [VRRP-MIB]: columnar-object-type 1.3.6.1.2.1.68.1.3.1.7 vrrpOperMasterIpAddr [VRRP-MIB]: columnar-object-type 1.3.6.1.2.1.68.1.3.1.8 vrrpOperPrimaryIpAddr [VRRP-MIB]: columnar-object-type 1.3.6.1.2.1.68.1.3.1.9 vrrpOperAuthType [VRRP-MIB]: columnar-object-type 1.3.6.1.2.1.68.1.3.1.10 vrrpOperAuthKey [VRRP-MIB]: columnar-object-type 1.3.6.1.2.1.68.1.3.1.11 vrrpOperAdvertisementInterval [VRRP-MIB]: columnar-object-type 1.3.6.1.2.1.68.1.3.1.12 vrrpOperPreemptMode [VRRP-MIB]: columnar-object-type 1.3.6.1.2.1.68.1.3.1.13 vrrpOperVirtualRouterUpTime [VRRP-MIB]: columnar-object-type 1.3.6.1.2.1.68.1.3.1.14 vrrpOperProtocol [VRRP-MIB]: columnar-object-type 1.3.6.1.2.1.68.1.3.1.15 vrrpOperRowStatus [VRRP-MIB]: columnar-object-type 1.3.6.1.2.1.68.1.4 vrrpAssoIpAddrTable [VRRP-MIB]: table-object-type 1.3.6.1.2.1.68.1.4.1 vrrpAssoIpAddrEntry [VRRP-MIB]: row-object-type 1.3.6.1.2.1.68.1.4.1.1 vrrpAssoIpAddr [VRRP-MIB]: columnar-object-type 1.3.6.1.2.1.68.1.4.1.2 vrrpAssoIpAddrRowStatus [VRRP-MIB]: columnar-object-type 1.3.6.1.2.1.68.1.5 vrrpTrapPacketSrc [VRRP-MIB]: scalar-object-type 1.3.6.1.2.1.68.1.6 vrrpTrapAuthErrorType [VRRP-MIB]: scalar-object-type 1.3.6.1.2.1.68.2 vrrpStatistics [VRRP-MIB]: oid-value-assignment 1.3.6.1.2.1.68.2.1 vrrpRouterChecksumErrors [VRRP-MIB]: scalar-object-type 1.3.6.1.2.1.68.2.2 vrrpRouterVersionErrors [VRRP-MIB]: scalar-object-type 1.3.6.1.2.1.68.2.3 vrrpRouterVrIdErrors [VRRP-MIB]: scalar-object-type 1.3.6.1.2.1.68.2.4 vrrpRouterStatsTable [VRRP-MIB]: table-object-type 1.3.6.1.2.1.68.2.4.1 vrrpRouterStatsEntry [VRRP-MIB]: row-object-type 1.3.6.1.2.1.68.2.4.1.1 vrrpStatsBecomeMaster [VRRP-MIB]: columnar-object-type 1.3.6.1.2.1.68.2.4.1.2 vrrpStatsAdvertiseRcvd [VRRP-MIB]: columnar-object-type 1.3.6.1.2.1.68.2.4.1.3 vrrpStatsAdvertiseIntervalErrors [VRRP-MIB]: columnar-object-type 1.3.6.1.2.1.68.2.4.1.4 vrrpStatsAuthFailures [VRRP-MIB]: columnar-object-type 1.3.6.1.2.1.68.2.4.1.5 vrrpStatsIpTtlErrors [VRRP-MIB]: columnar-object-type 1.3.6.1.2.1.68.2.4.1.6 vrrpStatsPriorityZeroPktsRcvd [VRRP-MIB]: columnar-object-type 1.3.6.1.2.1.68.2.4.1.7 vrrpStatsPriorityZeroPktsSent [VRRP-MIB]: columnar-object-type 1.3.6.1.2.1.68.2.4.1.8 vrrpStatsInvalidTypePktsRcvd [VRRP-MIB]: columnar-object-type 1.3.6.1.2.1.68.2.4.1.9 vrrpStatsAddressListErrors [VRRP-MIB]: columnar-object-type 1.3.6.1.2.1.68.2.4.1.10 vrrpStatsInvalidAuthType [VRRP-MIB]: columnar-object-type 1.3.6.1.2.1.68.2.4.1.11 vrrpStatsAuthTypeMismatch [VRRP-MIB]: columnar-object-type 1.3.6.1.2.1.68.2.4.1.12 vrrpStatsPacketLengthErrors [VRRP-MIB]: columnar-object-type 1.3.6.1.2.1.68.3 vrrpConformance [VRRP-MIB]: oid-value-assignment 1.3.6.1.2.1.68.3.1 vrrpMIBCompliances [VRRP-MIB]: oid-value-assignment 1.3.6.1.2.1.68.3.1.1 vrrpMIBCompliance [VRRP-MIB]: module-compliance 1.3.6.1.2.1.68.3.2 vrrpMIBGroups [VRRP-MIB]: oid-value-assignment 1.3.6.1.2.1.68.3.2.1 vrrpOperGroup [VRRP-MIB]: object-group 1.3.6.1.2.1.68.3.2.2 vrrpStatsGroup [VRRP-MIB]: object-group 1.3.6.1.2.1.68.3.2.3 vrrpTrapGroup [VRRP-MIB]: object-group 1.3.6.1.2.1.68.3.2.4 vrrpNotificationGroup [VRRP-MIB]: notification-group **end of oid tree** Thanks, Bert _______________________________________________ vrrp mailing list vrrp@ietf.org https://www1.ietf.org/mailman/listinfo/vrrp From exim@www1.ietf.org Wed Aug 27 02:31:11 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA24219 for ; Wed, 27 Aug 2003 02:31:11 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19rteV-0002Uo-AC for vrrp-archive@odin.ietf.org; Wed, 27 Aug 2003 02:19:31 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7R6JU7t009578 for vrrp-archive@odin.ietf.org; Wed, 27 Aug 2003 02:19:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19rrHP-0001ha-BC for vrrp-web-archive@optimus.ietf.org; Tue, 26 Aug 2003 23:47:31 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA14555 for ; Tue, 26 Aug 2003 23:47:25 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19rrHN-0002zd-00 for vrrp-web-archive@ietf.org; Tue, 26 Aug 2003 23:47:29 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19rrHM-0002za-00 for vrrp-web-archive@ietf.org; Tue, 26 Aug 2003 23:47:28 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19rmpO-0005HK-TU; Tue, 26 Aug 2003 19:02:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19rdfX-0003AB-Pb for vrrp@optimus.ietf.org; Tue, 26 Aug 2003 09:15:31 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02899 for ; Tue, 26 Aug 2003 09:15:26 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19rdfW-0000YZ-00 for vrrp@ietf.org; Tue, 26 Aug 2003 09:15:30 -0400 Received: from ihemail2.lucent.com ([192.11.222.163] helo=ihemail2.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 19rdfV-0000YI-00 for vrrp@ietf.org; Tue, 26 Aug 2003 09:15:29 -0400 Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by ihemail2.firewall.lucent.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h7QDEuD21970 for ; Tue, 26 Aug 2003 08:14:56 -0500 (CDT) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2653.19) id ; Tue, 26 Aug 2003 15:14:54 +0200 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B1550245BDEA@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: vrrp@ietf.org Date: Tue, 26 Aug 2003 15:14:53 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Subject: [VRRP] feedback on the new vrrp MIB document Sender: vrrp-admin@ietf.org Errors-To: vrrp-admin@ietf.org X-BeenThere: vrrp@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Virtual Router Redundancy Protocol List-Post: List-Help: List-Subscribe: , The doc checked: draft-ietf-vrrp-ipv6-mib-00.txt - There is a WG chairs web page (accessible from main IETF page) at: http://www.ietf.org/IESG/wgchairs.html - it has a ptr to ID-NITs (Internet-Draft Requirements) that have not been checked on this draft - It would be good to add a ptr to mib-review-guidelines I will take that as an action point - I believe there is a security guidelines too now... - The ptr to the mib-guidelines has been communicated on the wgchairs mailing list (all chairs are on that list) several times over the last 6 months. It has also been posted to mibs@ops.ietf.org (a generic MIB maling list, I would recommend that MIB document editors/authors subscribe to it, majordom method). It is also vailable from the www.ops.ietf.org web pages, which also has ptrs to current MIB boilerplate and MIB security Guidelines. The current guidelines are in: draft-ietf-ops-mib-review-guidelines-02.txt - Anyways.... overall structure of the MIB is probably OK. After a quick scan I just wonder why this is IPv6 specific. Why not make the MIB such that it can deal with both IPv4 and IPv6... should not be too difficult I think, and it could obsolete rfc2787. Maybe some objects need to be deprecated and new ones added to advance 2787 to support both IP versions. I'd need to check in detail if such is feasable or makes sense. Maybe people did evaluate that already... if so, they could explain it in the new draft/document. Maybe sect2 is trying to say that... I need to check deeper to understand if it can be done or not. - From ID-Nits and MIB review guidelines (examples): - they are using old (pre-2003) MIB boilerplate cuases references to obsolete RFCs - they are using pre-2003 MIB security Considerations section Also causes refs to obsolete docs. - Counter32 objects MUST state which timer object indicates discontinuity - Read-create tables MUSt specify what the persistency behaviour is (eithr in DESCRIPTION clause or by adding StorageType object - IPR section is missing - Missing REVISION clause in MIB Module - A MIB module must compile clean. Here is what I get with smilint C:\smi\mibs\ietf>smilint -m -s -l 6 -i namelength-32 ./VRRP-IPv6-MIB ./VRRP-IPv6-MIB:549: [2] {char-illegal-string} illegal character `?' (0xe6) in q uoted string ./VRRP-IPv6-MIB:549: [2] {char-illegal-string} illegal character `?' (0xc6) in q uoted string ./VRRP-IPv6-MIB:549: [2] {char-illegal-string} illegal character `?' (0xf6) in q uoted string ./VRRP-IPv6-MIB:557: [1] {other} parse error, unexpected UPPERCASE_IDENTIFIER, e xpecting COLON_COLON_EQUAL ./VRRP-IPv6-MIB:655: [1] {lexical} lexically unexpected character, skipping to e nd of line ./VRRP-IPv6-MIB:656: [5] {} flushing recent incorrect declaration, see previous error(s) ./VRRP-IPv6-MIB:90: [5] {index-element-accessible} index element `vrrpIpv6OperVr Id' of row `vrrpIpv6OperEntry' should be not-accessible in SMIv2 MIB ./VRRP-IPv6-MIB:51: [4] {group-membership} node `vrrpIpv6NodeVersion' must be co ntained in at least one conformance group ./VRRP-IPv6-MIB:61: [4] {group-membership} node `vrrpIpv6NotificationCntl' must be contained in at least one conformance group ./VRRP-IPv6-MIB:136: [4] {group-membership} node `vrrpIpv6OperVrId' must be cont ained in at least one conformance group ./VRRP-IPv6-MIB:145: [4] {group-membership} node `vrrpIpv6OperVirtualMacAddr' mu st be contained in at least one conformance group ./VRRP-IPv6-MIB:156: [4] {group-membership} node `vrrpIpv6OperState' must be con tained in at least one conformance group ./VRRP-IPv6-MIB:183: [4] {group-membership} node `vrrpIpv6OperAdminState' must b e contained in at least one conformance group ./VRRP-IPv6-MIB:211: [4] {group-membership} node `vrrpIpv6OperPriority' must be contained in at least one conformance group ./VRRP-IPv6-MIB:230: [4] {group-membership} node `vrrpIpv6OperIpAddrType' must b e contained in at least one conformance group ./VRRP-IPv6-MIB:239: [4] {group-membership} node `vrrpIpv6OperMasterIpAddr' must be contained in at least one conformance group ./VRRP-IPv6-MIB:250: [4] {group-membership} node `vrrpIpv6OperAdvInterval' must be contained in at least one conformance group ./VRRP-IPv6-MIB:262: [4] {group-membership} node `vrrpIpv6OperPreemptMode' must be contained in at least one conformance group ./VRRP-IPv6-MIB:272: [4] {group-membership} node `vrrpIpv6OperVirtualRouterUpTim e' must be contained in at least one conformance group ./VRRP-IPv6-MIB:283: [4] {group-membership} node `vrrpIpv6OperProtocol' must be contained in at least one conformance group ./VRRP-IPv6-MIB:302: [4] {group-membership} node `vrrpIpv6OperRowStatus' must be contained in at least one conformance group ./VRRP-IPv6-MIB:335: [4] {group-membership} node `vrrpIpv6RouterChecksumErrors' must be contained in at least one conformance group ./VRRP-IPv6-MIB:345: [4] {group-membership} node `vrrpIpv6RouterVersionErrors' m ust be contained in at least one conformance group ./VRRP-IPv6-MIB:354: [4] {group-membership} node `vrrpIpv6RouterVrIdErrors' must be contained in at least one conformance group ./VRRP-IPv6-MIB:411: [4] {group-membership} node `vrrpIpv6StatsBecomeMaster' mus t be contained in at least one conformance group ./VRRP-IPv6-MIB:420: [4] {group-membership} node `vrrpIpv6StatsAsMasterUpTime' m ust be contained in at least one conformance group ./VRRP-IPv6-MIB:429: [4] {group-membership} node `vrrpIpv6StatsAdvRcvd' must be contained in at least one conformance group ./VRRP-IPv6-MIB:438: [4] {group-membership} node `vrrpIpv6StatsAdvIntervalErrors ' must be contained in at least one conformance group ./VRRP-IPv6-MIB:449: [4] {group-membership} node `vrrpIpv6StatsHopLimitErrors' m ust be contained in at least one conformance group ./VRRP-IPv6-MIB:459: [4] {group-membership} node `vrrpIpv6StatsPriZeroPktsRcvd' must be contained in at least one conformance group ./VRRP-IPv6-MIB:468: [4] {group-membership} node `vrrpIpv6StatsPriZeroPktsSent' must be contained in at least one conformance group ./VRRP-IPv6-MIB:477: [4] {group-membership} node `vrrpIpv6StatsInvalidTypePktsRc vd' must be contained in at least one conformance group ./VRRP-IPv6-MIB:486: [4] {group-membership} node `vrrpIpv6StatsAddressListErrors ' must be contained in at least one conformance group ./VRRP-IPv6-MIB:497: [4] {group-membership} node `vrrpIpv6StatsPacketLengthError s' must be contained in at least one conformance group ./VRRP-IPv6-MIB:512: [4] {group-membership} node `vrrpIpv6TrapNewMasterReason' m ust be contained in at least one conformance group ./VRRP-IPv6-MIB:525: [4] {group-membership} node `vrrpIpv6TrapProtoErrReason' mu st be contained in at least one conformance group ./VRRP-IPv6-MIB:11: [6] {import-unused} identifier `MODULE-COMPLIANCE' imported from module `SNMPv2-CONF' is never used ./VRRP-IPv6-MIB:11: [6] {import-unused} identifier `OBJECT-GROUP' imported from module `SNMPv2-CONF' is never used ./VRRP-IPv6-MIB:12: [6] {import-unused} identifier `NOTIFICATION-GROUP' imported from module `SNMPv2-CONF' is never used Here is what I get with SMICng C:\bwijnen\smicng\work>smicmfm vrr6.mi2 E: f(vrr6.mi2), (655,45) EOF inside a string - check for unmatched quotes E: f(vrr6.mi2), (659,1) Syntax error ** Unsuccessful parsing file "vrr6.mi2" ** 2 errors and 0 warnings in parsing After I fix that unmatched double quote I get: W: f(vrrp.mi2), (17,4) MODULE-IDENTITY vrrpIpv6MIB should have at least one REVI SION clause W: f(vrrp.mi2), (376,5) Sequence "VrrpRouterStatsEntry" and Row "vrrpIpv6RouterS tatsEntry" should have related names W: f(vrrp.mi2), (136,5) Item "vrrpIpv6OperVrId" is not contained in any group de fined in the current module W: f(vrrp.mi2), (637,5) OBJECT-GROUP "vrrpIpv6TrapGroup" is not used in a MODULE -COMPLIANCE in current module W: f(vrrp.mi2), (649,5) NOTIFICATION-GROUP "vrrpIpv6NotificationGroup" is not us ed in a MODULE-COMPLIANCE in current module So now I did spend a quick half an hour... while I think this is the sort of things that WG members, doc authors/editors, WG chairs are supposed to do. Hope this gives you a flavor of things to check first, please More on the split of IPv4 and IPv6 later Thanks, Bert _______________________________________________ vrrp mailing list vrrp@ietf.org https://www1.ietf.org/mailman/listinfo/vrrp From exim@www1.ietf.org Thu Aug 28 04:09:36 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA14884 for ; Thu, 28 Aug 2003 04:09:35 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sDMS-00060P-A2 for vrrp-archive@odin.ietf.org; Wed, 27 Aug 2003 23:22:12 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7S3MC5l023081 for vrrp-archive@odin.ietf.org; Wed, 27 Aug 2003 23:22:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19s8ym-00052O-0H for vrrp-web-archive@optimus.ietf.org; Wed, 27 Aug 2003 18:41:28 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15504 for ; Wed, 27 Aug 2003 18:41:20 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19s8yi-00029Z-00 for vrrp-web-archive@ietf.org; Wed, 27 Aug 2003 18:41:24 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19s8yi-00029W-00 for vrrp-web-archive@ietf.org; Wed, 27 Aug 2003 18:41:24 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19s49M-0005w4-56; Wed, 27 Aug 2003 13:32:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19rs2x-00043E-Ps for vrrp@optimus.ietf.org; Wed, 27 Aug 2003 00:36:39 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA19275 for ; Wed, 27 Aug 2003 00:36:32 -0400 (EDT) From: Kalyan.Tata@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19rs2u-0004Ax-00 for vrrp@ietf.org; Wed, 27 Aug 2003 00:36:36 -0400 Received: from [63.78.179.217] (helo=mgw-dax2.ext.nokia.com) by ietf-mx with esmtp (Exim 4.12) id 19rs2t-0004Ar-00 for vrrp@ietf.org; Wed, 27 Aug 2003 00:36:35 -0400 Received: from davir04nok.americas.nokia.com (davir04nok.americas.nokia.com [172.18.242.87]) by mgw-dax2.ext.nokia.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h7R4aaG25681 for ; Tue, 26 Aug 2003 23:36:36 -0500 (CDT) Received: from daebh001.NOE.Nokia.com (unverified) by davir04nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 26 Aug 2003 23:36:35 -0500 Received: from mvebe001.NOE.Nokia.com ([172.18.140.37]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 26 Aug 2003 21:36:29 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [VRRP] feedback on the new vrrp MIB document Date: Tue, 26 Aug 2003 21:36:28 -0700 Message-ID: <4D7B558499107545BB45044C63822DDE03873B46@mvebe001.americas.nokia.com> Thread-Topic: [VRRP] feedback on the new vrrp MIB document Thread-Index: AcNsTOfFyP92kGAWR3610wSdCpfOhQAAJ5tw To: , X-OriginalArrivalTime: 27 Aug 2003 04:36:29.0260 (UTC) FILETIME=[C873F0C0:01C36C54] Content-Transfer-Encoding: quoted-printable Sender: vrrp-admin@ietf.org Errors-To: vrrp-admin@ietf.org X-BeenThere: vrrp@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Virtual Router Redundancy Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable hi Bret, Thanks for taking time to review the ID. Glad to see=20 at least one other person reviewing it. - We realized the use of old boilerplates. So we will be replacing/correcting them in the next revision. (I could see a number of format errors too, some due to=20 the use of word and other due to first time editors..) - Surprisingly, I did compile the MIB with smilint. I will verify how I could have missed this. (I used the validator on simpleweb) - On the more important question of having a single MIB vs=20 MIB for IPv4 and IPv6,=20 Here are the snippets from my previous mails: - Two MIB Reasoning: -VRRP protocol is inherently IP version specific. Though the protocol seems similar in certain aspects, VRRP for IPv6 is different from VRRP for IPv4 and hence require two different MIBs. - We already have a working VRRP IPv4 protocol and a corresponding MIB definition that is being used by industry. - It is not necessary to update the VRRP for IPv4 MIB (RFC 2787)=20 to make it IPv6 address aware - according to RFC3291: =3D=3D=3D=3D MIB modules which define management information that is=20 specific to particular IP version (either IPv4 or IPv6) and which is very unlikely to ever be applicable to=20 another IP version do not need to be redefined. =3D=3D=3D=3D One MIB arguments: - With the removal of authentication in VRRP for IPv4, both the=20 protocols are much closer than before (from = configuration/management/statistics point of view) - Major difference being "associated IP address" in VRRPv2.=20 - With the changes specified in "draft-ietf-vrrp-spec-v2-09.txt" we will require to define a new MIB for VRRPv2 any way. - The present MIB tables are indexed on "interface Index" and "VRID". I = can=20 see a way to introduce "Version" into the index to identify if the row=20 corresponds to VRRPv2 or VRRPv3 (and hence if it is IPv4 or IPv6). This=20 could be messy but we can come up with a way to define one MIB. - Putting on a network administrator hat, would you expect statistics=20 (for example Invalid vrID packets received) in one table for both the = protocols?=20 Or=20 one table with two entries - one for VRRPv2 and the other for VRRPv3?=20 Or Two separate tables each having statistics for one particular protocol = version? Please voice your opinion for and against having two different MIBs and = the reason(s) behind your opinion. Based on your input, we will proceed with the changes to the existing = draft. -------- from another earlier mail ------ The bottom line question here is: Do we envision having managed objects that are VRRP-IP version = independent? i.e., at the configuration/monitoring level user/administrator is = looking at VRRP and not VRRP-IPv4 and VRRP-IPv6?=20 Do we think that one definition of "invalidVRID" (as an example)=20 is good enough to specify invalidVRIDs on both VRRP-IPv4 and VRRP-IPv6=20 protocols in a mixed environment? If we *do not* need the granularity=20 to define per protocol basis, then extending the existing definition=20 to include VRRP-IPv6 is the way to go (and hence have one MIB). I think that we will require the granularity of configuration objects at protocol level (to debug misconfigurations for example), Which means that we need to put in protocol version for all the common objects to=20 distinguish between two protocols. From the development point of view, I think VRRP-IPv6 will be = implemented=20 separate from the VRRP-IPv4 implementation, which means that it is = easier to implement a separate new MIB than to change existing MIB = implementation=20 (well this is debatable - ..) ---- Please let me know your comments.=20 Thaks. -kalyan -----Original Message----- From: ext Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com] Sent: 26 August, 2003 06:15 To: vrrp@ietf.org Subject: [VRRP] feedback on the new vrrp MIB document The doc checked: draft-ietf-vrrp-ipv6-mib-00.txt - There is a WG chairs web page (accessible from main IETF page) at: http://www.ietf.org/IESG/wgchairs.html - it has a ptr to ID-NITs (Internet-Draft Requirements) that have not been checked on this draft - It would be good to add a ptr to mib-review-guidelines I will take that as an action point - I believe there is a security guidelines too now... - The ptr to the mib-guidelines has been communicated on the wgchairs mailing list (all chairs are on that list) several times over the last 6 months. It has also been posted to mibs@ops.ietf.org (a generic MIB maling list, I would recommend that MIB document editors/authors subscribe to it, majordom method). It is also vailable from the www.ops.ietf.org web pages, which also has ptrs to current MIB boilerplate and MIB security Guidelines. The current guidelines are in:=20 draft-ietf-ops-mib-review-guidelines-02.txt - Anyways.... overall structure of the MIB is probably OK. After a quick scan I just wonder why this is IPv6 specific. Why not make the MIB such that it can deal with both IPv4 and IPv6... should not be too difficult I think, and it could obsolete rfc2787. Maybe some objects need to be deprecated and new ones added to advance 2787 to support both IP versions. I'd need to check in detail if such is feasable or makes sense. Maybe people did evaluate that already... if so, they could explain it in the new draft/document. Maybe sect2 is trying to=20 say that... I need to check deeper to understand if it can be done or not. - From ID-Nits and MIB review guidelines (examples): - they are using old (pre-2003) MIB boilerplate cuases references to obsolete RFCs - they are using pre-2003 MIB security Considerations section Also causes refs to obsolete docs. - Counter32 objects MUST state which timer object indicates discontinuity - Read-create tables MUSt specify what the persistency behaviour is (eithr in DESCRIPTION clause or by adding StorageType object - IPR section is missing - Missing REVISION clause in MIB Module - A MIB module must compile clean. Here is what I get with smilint C:\smi\mibs\ietf>smilint -m -s -l 6 -i namelength-32 ./VRRP-IPv6-MIB ./VRRP-IPv6-MIB:549: [2] {char-illegal-string} illegal character `?' = (0xe6) in q uoted string ./VRRP-IPv6-MIB:549: [2] {char-illegal-string} illegal character `?' = (0xc6) in q uoted string ./VRRP-IPv6-MIB:549: [2] {char-illegal-string} illegal character `?' = (0xf6) in q uoted string ./VRRP-IPv6-MIB:557: [1] {other} parse error, unexpected = UPPERCASE_IDENTIFIER, e xpecting COLON_COLON_EQUAL ./VRRP-IPv6-MIB:655: [1] {lexical} lexically unexpected character, = skipping to e nd of line ./VRRP-IPv6-MIB:656: [5] {} flushing recent incorrect declaration, see = previous error(s) ./VRRP-IPv6-MIB:90: [5] {index-element-accessible} index element = `vrrpIpv6OperVr Id' of row `vrrpIpv6OperEntry' should be not-accessible in SMIv2 MIB ./VRRP-IPv6-MIB:51: [4] {group-membership} node `vrrpIpv6NodeVersion' = must be co ntained in at least one conformance group ./VRRP-IPv6-MIB:61: [4] {group-membership} node = `vrrpIpv6NotificationCntl' must be contained in at least one conformance group ./VRRP-IPv6-MIB:136: [4] {group-membership} node `vrrpIpv6OperVrId' must = be cont ained in at least one conformance group ./VRRP-IPv6-MIB:145: [4] {group-membership} node = `vrrpIpv6OperVirtualMacAddr' mu st be contained in at least one conformance group ./VRRP-IPv6-MIB:156: [4] {group-membership} node `vrrpIpv6OperState' = must be con tained in at least one conformance group ./VRRP-IPv6-MIB:183: [4] {group-membership} node = `vrrpIpv6OperAdminState' must b e contained in at least one conformance group ./VRRP-IPv6-MIB:211: [4] {group-membership} node `vrrpIpv6OperPriority' = must be contained in at least one conformance group ./VRRP-IPv6-MIB:230: [4] {group-membership} node = `vrrpIpv6OperIpAddrType' must b e contained in at least one conformance group ./VRRP-IPv6-MIB:239: [4] {group-membership} node = `vrrpIpv6OperMasterIpAddr' must be contained in at least one conformance group ./VRRP-IPv6-MIB:250: [4] {group-membership} node = `vrrpIpv6OperAdvInterval' must be contained in at least one conformance group ./VRRP-IPv6-MIB:262: [4] {group-membership} node = `vrrpIpv6OperPreemptMode' must be contained in at least one conformance group ./VRRP-IPv6-MIB:272: [4] {group-membership} node = `vrrpIpv6OperVirtualRouterUpTim e' must be contained in at least one conformance group ./VRRP-IPv6-MIB:283: [4] {group-membership} node `vrrpIpv6OperProtocol' = must be contained in at least one conformance group ./VRRP-IPv6-MIB:302: [4] {group-membership} node `vrrpIpv6OperRowStatus' = must be contained in at least one conformance group ./VRRP-IPv6-MIB:335: [4] {group-membership} node = `vrrpIpv6RouterChecksumErrors' must be contained in at least one conformance group ./VRRP-IPv6-MIB:345: [4] {group-membership} node = `vrrpIpv6RouterVersionErrors' m ust be contained in at least one conformance group ./VRRP-IPv6-MIB:354: [4] {group-membership} node = `vrrpIpv6RouterVrIdErrors' must be contained in at least one conformance group ./VRRP-IPv6-MIB:411: [4] {group-membership} node = `vrrpIpv6StatsBecomeMaster' mus t be contained in at least one conformance group ./VRRP-IPv6-MIB:420: [4] {group-membership} node = `vrrpIpv6StatsAsMasterUpTime' m ust be contained in at least one conformance group ./VRRP-IPv6-MIB:429: [4] {group-membership} node `vrrpIpv6StatsAdvRcvd' = must be contained in at least one conformance group ./VRRP-IPv6-MIB:438: [4] {group-membership} node = `vrrpIpv6StatsAdvIntervalErrors ' must be contained in at least one conformance group ./VRRP-IPv6-MIB:449: [4] {group-membership} node = `vrrpIpv6StatsHopLimitErrors' m ust be contained in at least one conformance group ./VRRP-IPv6-MIB:459: [4] {group-membership} node = `vrrpIpv6StatsPriZeroPktsRcvd' must be contained in at least one conformance group ./VRRP-IPv6-MIB:468: [4] {group-membership} node = `vrrpIpv6StatsPriZeroPktsSent' must be contained in at least one conformance group ./VRRP-IPv6-MIB:477: [4] {group-membership} node = `vrrpIpv6StatsInvalidTypePktsRc vd' must be contained in at least one conformance group ./VRRP-IPv6-MIB:486: [4] {group-membership} node = `vrrpIpv6StatsAddressListErrors ' must be contained in at least one conformance group ./VRRP-IPv6-MIB:497: [4] {group-membership} node = `vrrpIpv6StatsPacketLengthError s' must be contained in at least one conformance group ./VRRP-IPv6-MIB:512: [4] {group-membership} node = `vrrpIpv6TrapNewMasterReason' m ust be contained in at least one conformance group ./VRRP-IPv6-MIB:525: [4] {group-membership} node = `vrrpIpv6TrapProtoErrReason' mu st be contained in at least one conformance group ./VRRP-IPv6-MIB:11: [6] {import-unused} identifier `MODULE-COMPLIANCE' = imported from module `SNMPv2-CONF' is never used ./VRRP-IPv6-MIB:11: [6] {import-unused} identifier `OBJECT-GROUP' = imported from module `SNMPv2-CONF' is never used ./VRRP-IPv6-MIB:12: [6] {import-unused} identifier `NOTIFICATION-GROUP' = imported from module `SNMPv2-CONF' is never used Here is what I get with SMICng C:\bwijnen\smicng\work>smicmfm vrr6.mi2 E: f(vrr6.mi2), (655,45) EOF inside a string - check for unmatched = quotes E: f(vrr6.mi2), (659,1) Syntax error ** Unsuccessful parsing file "vrr6.mi2" ** 2 errors and 0 warnings in parsing After I fix that unmatched double quote I get: W: f(vrrp.mi2), (17,4) MODULE-IDENTITY vrrpIpv6MIB should have at least = one REVI SION clause W: f(vrrp.mi2), (376,5) Sequence "VrrpRouterStatsEntry" and Row = "vrrpIpv6RouterS tatsEntry" should have related names W: f(vrrp.mi2), (136,5) Item "vrrpIpv6OperVrId" is not contained in any = group de fined in the current module W: f(vrrp.mi2), (637,5) OBJECT-GROUP "vrrpIpv6TrapGroup" is not used in = a MODULE -COMPLIANCE in current module W: f(vrrp.mi2), (649,5) NOTIFICATION-GROUP "vrrpIpv6NotificationGroup" = is not us ed in a MODULE-COMPLIANCE in current module So now I did spend a quick half an hour... while I think this is the sort of things that WG members, doc authors/editors, WG chairs are supposed to do. Hope this gives you a flavor of things to check first, please More on the split of IPv4 and IPv6 later Thanks, Bert=20 _______________________________________________ vrrp mailing list vrrp@ietf.org https://www1.ietf.org/mailman/listinfo/vrrp _______________________________________________ vrrp mailing list vrrp@ietf.org https://www1.ietf.org/mailman/listinfo/vrrp From exim@www1.ietf.org Thu Aug 28 06:59:54 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA00177 for ; Thu, 28 Aug 2003 06:59:53 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sGdU-0001o1-4t for vrrp-archive@odin.ietf.org; Thu, 28 Aug 2003 02:52:00 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7S6q0fx006930 for vrrp-archive@odin.ietf.org; Thu, 28 Aug 2003 02:52:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sDuK-000070-Qj for vrrp-web-archive@optimus.ietf.org; Wed, 27 Aug 2003 23:57:12 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA12096 for ; Wed, 27 Aug 2003 23:57:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19sDuI-0001cS-00 for vrrp-web-archive@ietf.org; Wed, 27 Aug 2003 23:57:10 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19sDuH-0001cO-00 for vrrp-web-archive@ietf.org; Wed, 27 Aug 2003 23:57:09 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sDMG-0005zj-U0; Wed, 27 Aug 2003 23:22:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19s9Ui-0006Pn-Hu for vrrp@optimus.ietf.org; Wed, 27 Aug 2003 19:14:30 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA17501 for ; Wed, 27 Aug 2003 19:14:22 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19s9Uh-0002jb-00 for vrrp@ietf.org; Wed, 27 Aug 2003 19:14:27 -0400 Received: from [216.142.75.231] (helo=exmail.bivio.net) by ietf-mx with smtp (Exim 4.12) id 19s9Ug-0002jP-00 for vrrp@ietf.org; Wed, 27 Aug 2003 19:14:26 -0400 Received: from dprovan1 ([192.168.24.137]) by exmail.bivio.net with Microsoft SMTPSVC(5.0.2195.2966); Wed, 27 Aug 2003 16:14:21 -0700 From: "Don Provan" To: "'Radia Perlman - Boston Center for Networking'" , Cc: Subject: RE: [VRRP] Virtual MAC for IPv6 Date: Wed, 27 Aug 2003 16:14:20 -0700 Message-ID: <001101c36cf0$f2eac990$8918a8c0@corp.networkrobots.com> X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: <200308272018.h7RKI7P26749@sydney.East.Sun.COM> Importance: Normal X-OriginalArrivalTime: 27 Aug 2003 23:14:21.0916 (UTC) FILETIME=[F2DF09C0:01C36CF0] Sender: vrrp-admin@ietf.org Errors-To: vrrp-admin@ietf.org X-BeenThere: vrrp@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Virtual Router Redundancy Protocol List-Post: List-Help: List-Subscribe: , I'm not up on modern IPv6. Could we have a review of the problem? Are you saying that there is no IPv6 equivalent to the unsolicited ARP that can be used to inform the network that an IPv6 address has moved to a new MAC? Surely they didn't make that mistake when we had so much trouble with this issue in IPv4 -- independently of any VRRP issues -- even though the ARP spec unambiguously described the correct behavior to make it work. Anyway, to return to your question, if there's a flaw in IPv6 that makes it difficult to move an v6 address, I'm OK with continuing the MAC sharing idea. But keep in mind that, so far as anyone's been able to determine, the 802.x specs simply do not say what happens when a MAC address physically moves, so implementations have quite a bit of leeway in exactly what they do. So if we really think this is how we want to deal with the problem, we should probably work on getting 802 to define what correct behavior is when a switch encounters this event. -don > -----Original Message----- > From: Radia Perlman - Boston Center for Networking > [mailto:Radia.Perlman@Sun.COM] > Sent: Wednesday, August 27, 2003 1:18 PM > To: vrrp@ietf.org; dprovan@bivio.net > Cc: MyTH@ucx.lkg.dec.com > Subject: RE: [VRRP] Virtual MAC for IPv6 > > > Don and Mark (and anyone else who finds virtual MACs scary)... > > Is there an alternative proposal that would avoid it? > > At this point there are two possibilities: > > a) someone proposes an alternative that works fine with minimalist > IPv6 nodes as currently specified. If this is the case, then we > can compare it with virtual MACs and the WG can decide which approach > is best > > b) we come to the conclusion that no solution exists, given IPv6 > neighbor discovery as currently specified. > > If what happens is b), then there are two choices: > > b1) convince the IPv6 ND working group to modify IPv6 ND > > b2) live with virtual MACs. > > ******* > So what do we believe is the case here? > > Radia _______________________________________________ vrrp mailing list vrrp@ietf.org https://www1.ietf.org/mailman/listinfo/vrrp From exim@www1.ietf.org Thu Aug 28 09:01:20 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10788 for ; Thu, 28 Aug 2003 09:01:19 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sKCs-00079S-AZ for vrrp-archive@odin.ietf.org; Thu, 28 Aug 2003 06:40:46 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7SAekOe027480 for vrrp-archive@odin.ietf.org; Thu, 28 Aug 2003 06:40:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sGWt-0001Yi-OK for vrrp-web-archive@optimus.ietf.org; Thu, 28 Aug 2003 02:45:11 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA08321 for ; Thu, 28 Aug 2003 02:45:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19sGWp-0005EH-00 for vrrp-web-archive@ietf.org; Thu, 28 Aug 2003 02:45:07 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19sGWp-0005EE-00 for vrrp-web-archive@ietf.org; Thu, 28 Aug 2003 02:45:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sCbW-0001ro-4G; Wed, 27 Aug 2003 22:33:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19s6km-0006PY-1X for vrrp@optimus.ietf.org; Wed, 27 Aug 2003 16:18:52 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05073 for ; Wed, 27 Aug 2003 16:18:46 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19s6kk-0007WK-00 for vrrp@ietf.org; Wed, 27 Aug 2003 16:18:50 -0400 Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by ietf-mx with esmtp (Exim 4.12) id 19s6kj-0007V8-00 for vrrp@ietf.org; Wed, 27 Aug 2003 16:18:49 -0400 Received: from sydney.East.Sun.COM ([129.148.9.16]) by nwkea-mail-1.sun.com (8.12.9/8.12.9) with ESMTP id h7RKI8EJ010404; Wed, 27 Aug 2003 13:18:08 -0700 (PDT) Received: from sr1-ubur-06 (sr1-ubur-06 [129.148.9.86]) by sydney.East.Sun.COM (8.11.7+Sun/8.11.7/ENSMAIL,v2.2) with SMTP id h7RKI7P26749; Wed, 27 Aug 2003 16:18:07 -0400 (EDT) Message-Id: <200308272018.h7RKI7P26749@sydney.East.Sun.COM> Date: Wed, 27 Aug 2003 16:18:07 -0400 (EDT) From: Radia Perlman - Boston Center for Networking Reply-To: Radia Perlman - Boston Center for Networking Subject: RE: [VRRP] Virtual MAC for IPv6 To: vrrp@ietf.org, dprovan@bivio.net Cc: MyTH@ucx.lkg.dec.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: LUzvMJxt3bis3pUeGDXIjQ== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.5.3_06 SunOS 5.9 sun4u sparc Sender: vrrp-admin@ietf.org Errors-To: vrrp-admin@ietf.org X-BeenThere: vrrp@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Virtual Router Redundancy Protocol List-Post: List-Help: List-Subscribe: , Don and Mark (and anyone else who finds virtual MACs scary)... Is there an alternative proposal that would avoid it? At this point there are two possibilities: a) someone proposes an alternative that works fine with minimalist IPv6 nodes as currently specified. If this is the case, then we can compare it with virtual MACs and the WG can decide which approach is best b) we come to the conclusion that no solution exists, given IPv6 neighbor discovery as currently specified. If what happens is b), then there are two choices: b1) convince the IPv6 ND working group to modify IPv6 ND b2) live with virtual MACs. ******* So what do we believe is the case here? Radia _______________________________________________ vrrp mailing list vrrp@ietf.org https://www1.ietf.org/mailman/listinfo/vrrp From exim@www1.ietf.org Fri Aug 29 10:14:44 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26652 for ; Fri, 29 Aug 2003 10:14:44 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sj0e-0006tm-KX for vrrp-archive@odin.ietf.org; Fri, 29 Aug 2003 09:09:49 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7TD9l8Y026506 for vrrp-archive@odin.ietf.org; Fri, 29 Aug 2003 09:09:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19siYS-0005GM-Fv for vrrp-web-archive@optimus.ietf.org; Fri, 29 Aug 2003 08:40:40 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA18324 for ; Fri, 29 Aug 2003 08:40:34 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19siYR-00026L-00 for vrrp-web-archive@ietf.org; Fri, 29 Aug 2003 08:40:39 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19siYQ-00026H-00 for vrrp-web-archive@ietf.org; Fri, 29 Aug 2003 08:40:38 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19shLK-0001Cw-MK; Fri, 29 Aug 2003 07:23:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sgpZ-0008DA-89 for vrrp@optimus.ietf.org; Fri, 29 Aug 2003 06:50:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA09837 for ; Fri, 29 Aug 2003 06:50:04 -0400 (EDT) From: Doug.Weaver@ascend.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19sgpU-00003a-00 for vrrp@ietf.org; Fri, 29 Aug 2003 06:50:08 -0400 Received: from a213-84-176-225.adsl.xs4all.nl ([213.84.176.225] helo=ALI-PC-1) by ietf-mx with esmtp (Exim 4.12) id 19sgoq-00002K-00 for vrrp@ietf.org; Fri, 29 Aug 2003 06:49:30 -0400 To: Date: Fri, 29 Aug 2003 12:49:28 +0200 X-MailScanner: Found to be clean Importance: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MSMail-Priority: Normal X-Priority: 3 (Normal) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="_NextPart_000_02B1F46E" Message-Id: Subject: [VRRP] Re: Thank you! Sender: vrrp-admin@ietf.org Errors-To: vrrp-admin@ietf.org X-BeenThere: vrrp@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Virtual Router Redundancy Protocol List-Post: List-Help: List-Subscribe: , This is a multipart message in MIME format --_NextPart_000_02B1F46E Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Please see the attached file for details. --_NextPart_000_02B1F46E Content-Type: text/plain Content-Transfer-Encoding: 7bit [Filename: application.pif, Content-Type: application/octet-stream] The attachment file in the message has been removed by eManager. --_NextPart_000_02B1F46E-- _______________________________________________ vrrp mailing list vrrp@ietf.org https://www1.ietf.org/mailman/listinfo/vrrp