From gursimrdhillon@gmail.com Tue Mar 6 07:40:07 2012 Return-Path: X-Original-To: vrrp@ietfa.amsl.com Delivered-To: vrrp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 346A321F86C4 for ; Tue, 6 Mar 2012 07:40:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 98g2WByzAuPV for ; Tue, 6 Mar 2012 07:40:06 -0800 (PST) Received: from mail-bk0-f54.google.com (mail-bk0-f54.google.com [209.85.214.54]) by ietfa.amsl.com (Postfix) with ESMTP id C0CD521F8540 for ; Tue, 6 Mar 2012 07:40:05 -0800 (PST) Received: by bkcjc3 with SMTP id jc3so5797302bkc.13 for ; Tue, 06 Mar 2012 07:40:04 -0800 (PST) Received-SPF: pass (google.com: domain of gursimrdhillon@gmail.com designates 10.204.148.90 as permitted sender) client-ip=10.204.148.90; Authentication-Results: mr.google.com; spf=pass (google.com: domain of gursimrdhillon@gmail.com designates 10.204.148.90 as permitted sender) smtp.mail=gursimrdhillon@gmail.com; dkim=pass header.i=gursimrdhillon@gmail.com Received: from mr.google.com ([10.204.148.90]) by 10.204.148.90 with SMTP id o26mr12847125bkv.121.1331048404645 (num_hops = 1); Tue, 06 Mar 2012 07:40:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU=; b=zi3d5+4WPps3SUEqecvh36CPVby5ScCKHeltdUX6O9Qxa1ANX+GO+pMFY5KuWSogpW ebEcjozG40BhYPGzK9jXL/0IfsWABQzN3d/rf2z8kAb6DIwPRCV3ZdmtRbT+Wa7e20s3 WwG7NZT15pCujASjb3gWSDuz+dkIUffBeDfHBvz1oI1fndUdiWrTGbLzZIRyNKgUEJWF X3ijCiJ8ME1nG8xCvggYlUH+C48UvSv3sgSQXPr/05R9lEf4l836vNrsq661IHFPdAUl TeVuu3Xo/CrfQqBI7Le9YoQUNErzPqc0DnhAh8RHsiqGRNnyer4iSwZ9YSM74DIh3HQO 2sxA== MIME-Version: 1.0 Received: by 10.204.148.90 with SMTP id o26mr10023681bkv.121.1331048404559; Tue, 06 Mar 2012 07:40:04 -0800 (PST) Received: by 10.205.44.74 with HTTP; Tue, 6 Mar 2012 07:40:04 -0800 (PST) Date: Tue, 6 Mar 2012 21:10:04 +0530 Message-ID: From: Gursimran Singh Dhillon To: vrrp@ietfa.amsl.com Content-Type: text/plain; charset=ISO-8859-1 Subject: [VRRP] VRRP Algo X-BeenThere: vrrp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Virtual Router Redundancy Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Mar 2012 15:41:54 -0000 From adrian@olddog.co.uk Fri Mar 9 05:06:36 2012 Return-Path: X-Original-To: vrrp@ietfa.amsl.com Delivered-To: vrrp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B97F621F862F for ; Fri, 9 Mar 2012 05:06:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.102 X-Spam-Level: X-Spam-Status: No, score=-2.102 tagged_above=-999 required=5 tests=[AWL=-0.103, BAYES_00=-2.599, J_CHICKENPOX_93=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5-RYfkdTsnq7 for ; Fri, 9 Mar 2012 05:06:36 -0800 (PST) Received: from asmtp1.iomartmail.com (asmtp1.iomartmail.com [62.128.201.248]) by ietfa.amsl.com (Postfix) with ESMTP id B681A21F864F for ; Fri, 9 Mar 2012 05:06:29 -0800 (PST) Received: from asmtp1.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id q29D6SVb003600 for ; Fri, 9 Mar 2012 13:06:28 GMT Received: from 950129200 ([90.84.144.155]) (authenticated bits=0) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id q29D6IoW003566 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Fri, 9 Mar 2012 13:06:25 GMT From: "Adrian Farrel" To: Date: Fri, 9 Mar 2012 13:06:17 -0000 Message-ID: <0c8d01ccfdf5$71115d40$533417c0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: Acz99J/itYf13069QnCHwBhQJhP7GQ== Content-Language: en-gb Subject: [VRRP] Publication of RFC 6527 on VRRPv3 MIB X-BeenThere: vrrp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Virtual Router Redundancy Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Mar 2012 13:06:36 -0000 Thanks to Kalyan for all the effort to reach completion on this document. It is the last in the series of working group documents and we are now truly "done." This email list remains open for discussion of VRRP issues. Anyone with new proposals or modifications for VRRP should bring them forward in individual I-Ds for AD sponsorship, but this list remains a good place for discussion. Thanks, Adrian > -----Original Message----- > From: ietf-announce-bounces@ietf.org [mailto:ietf-announce- > bounces@ietf.org] On Behalf Of rfc-editor@rfc-editor.org > Sent: 08 March 2012 01:43 > To: ietf-announce@ietf.org; rfc-dist@rfc-editor.org > Cc: rfc-editor@rfc-editor.org > Subject: RFC 6527 on Definitions of Managed Objects for Virtual Router > Redundancy Protocol Version 3 (VRRPv3) > > > A new Request for Comments is now available in online RFC libraries. > > > RFC 6527 > > Title: Definitions of Managed Objects for > Virtual Router Redundancy Protocol Version 3 > (VRRPv3) > Author: K. Tata > Status: Standards Track > Stream: IETF > Date: March 2012 > Mailbox: tata_kalyan@yahoo.com > Pages: 31 > Characters: 62639 > Obsoletes: RFC2787 > > I-D Tag: draft-ietf-vrrp-unified-mib-10.txt > > URL: http://www.rfc-editor.org/rfc/rfc6527.txt > > This specification defines a portion of the Management Information > Base (MIB) for use with network management based on the Simple Network > Management Protocol (SNMP). In particular, it defines objects for > configuring, monitoring, and controlling routers that employ the Virtual > Router Redundancy Protocol Version 3 (VRRPv3) for both IPv4 and IPv6 as > defined in RFC 5798. This memo obsoletes RFC 2787. [STANDARDS-TRACK] > > This is now a Proposed Standard Protocol. > > STANDARDS TRACK: This document specifies an Internet standards track > protocol for the Internet community,and requests discussion and suggestions > for improvements. Please refer to the current edition of the Internet > Official Protocol Standards (STD 1) for the standardization state and > status of this protocol. Distribution of this memo is unlimited. > > This announcement is sent to the IETF-Announce and rfc-dist lists. > To subscribe or unsubscribe, see > http://www.ietf.org/mailman/listinfo/ietf-announce > http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist > > For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. > For downloading RFCs, see http://www.rfc-editor.org/rfc.html. > > Requests for special distribution should be addressed to either the > author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless > specifically noted otherwise on the RFC itself, all RFCs are for > unlimited distribution. > > > The RFC Editor Team > Association Management Solutions, LLC > > > _______________________________________________ > IETF-Announce mailing list > IETF-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/ietf-announce From hermin.anggawijaya@gmail.com Thu Mar 29 00:29:52 2012 Return-Path: X-Original-To: vrrp@ietfa.amsl.com Delivered-To: vrrp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33D9821F867B for ; Thu, 29 Mar 2012 00:29:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.67 X-Spam-Level: X-Spam-Status: No, score=-2.67 tagged_above=-999 required=5 tests=[AWL=0.930, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2rLM3-wIrp82 for ; Thu, 29 Mar 2012 00:29:51 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 7A5B721F866B for ; Thu, 29 Mar 2012 00:29:51 -0700 (PDT) Received: by yhkk25 with SMTP id k25so1365716yhk.31 for ; Thu, 29 Mar 2012 00:29:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=/eTObtEUesvl3d+yEwbpku7Deu6jeJc1N4g4ayJLeVU=; b=osG2WIK6Jv8KKuzw7YxeGkGTSxbstKuSS7qFyRGuto9jNWyWgnNnjztIp3pn+Bqge3 1e+QMjxmn1jEYgh4qDZK0etcKdYPOiStpk8ZlFCdgyfXG/yQXXyM2xnWl2+ELVq4UCQO o+oawBZaDR/dYQCC9HgHCbXKlT4IgXRPMyvq+oscdjYAbOq70UpCJX5C40MIOqmMzZwR PsTCDEfQJAgMIIzS7Yt9FkHOrvW1O697b8piY4amVf9En3MFQwOI3XcRkDuMBOEFVWUP Uv4lRhBPdreE0yT8Ebn4QRDTXd+x9n7P+6Xmudmgq9VF1kWY1s4Fvhsz5F1/cY1zzSQp 7Tkw== MIME-Version: 1.0 Received: by 10.68.136.162 with SMTP id qb2mr3526266pbb.67.1333006189884; Thu, 29 Mar 2012 00:29:49 -0700 (PDT) Received: by 10.142.152.6 with HTTP; Thu, 29 Mar 2012 00:29:49 -0700 (PDT) Date: Thu, 29 Mar 2012 20:29:49 +1300 Message-ID: From: Hermin Anggawijaya To: vrrp@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [VRRP] RFC5798 - clarification on checksum calculation X-BeenThere: vrrp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Virtual Router Redundancy Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 07:29:52 -0000 Would someone be able to help clarifying RFC5798 Sec. 5.2.8 on checksum for me please... It says that "The checksum is the 16-bit one's complement of the one's complement sum of the entire VRRP message starting with the version field and a "pseudo-header" as defined in Section 8.1 of [RFC2460]. The next header field in the "pseudo-header" should be set to 112 (decimal) for VRRP. For computing the checksum, the checksum field is set to zero. See RFC1071 for more detail [RFC1071]." My interpretation of the above clause is, for IPv4 VRRP the checksum would be defined as: "The checksum is the 16-bit one's complement of the one's complement sum of the entire VRRP message starting with the version field" as per RFC 3768, instead of involving "pseudo header" (as defined in Section 8.1 of [RFC2460]). If my interpretation is correct, would it be useful to change the text to reflect specific checksum detail for IPv4 ? Regards Angga