[VRRP] recomputing skew time when receiving an advertisement from the master in rfc 5798
Vladica Stanisic <vladica.stanisic@ericsson.com> Mon, 17 January 2011 17:01 UTC
Return-Path: <vladica.stanisic@ericsson.com>
X-Original-To: vrrp@core3.amsl.com
Delivered-To: vrrp@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4CA3228C160 for <vrrp@core3.amsl.com>; Mon, 17 Jan 2011 09:01:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level:
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lMjbr3JJGI8t for <vrrp@core3.amsl.com>; Mon, 17 Jan 2011 09:01:23 -0800 (PST)
Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by core3.amsl.com (Postfix) with ESMTP id 5E4F728C15A for <vrrp@ietf.org>; Mon, 17 Jan 2011 09:01:22 -0800 (PST)
Received: from eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id p0HH3i1j028776 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for <vrrp@ietf.org>; Mon, 17 Jan 2011 11:03:57 -0600
Received: from EUSAACMS0702.eamcs.ericsson.se ([169.254.1.54]) by eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) with mapi; Mon, 17 Jan 2011 12:03:39 -0500
From: Vladica Stanisic <vladica.stanisic@ericsson.com>
To: "vrrp@ietf.org" <vrrp@ietf.org>, Shukri Abdallah <shukri.abdallah@ericsson.com>
Date: Mon, 17 Jan 2011 12:03:37 -0500
Thread-Topic: recomputing skew time when receiving an advertisement from the master in rfc 5798
Thread-Index: Acu2aHu4fTvMu1DOQBGlhtocV5Xt7g==
Message-ID: <FFA917582FF6524F94AB504C6DC3F16DBD00BC204B@EUSAACMS0702.eamcs.ericsson.se>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_FFA917582FF6524F94AB504C6DC3F16DBD00BC204BEUSAACMS0702e_"
MIME-Version: 1.0
X-Mailman-Approved-At: Mon, 17 Jan 2011 11:40:31 -0800
Subject: [VRRP] recomputing skew time when receiving an advertisement from the master in rfc 5798
X-BeenThere: vrrp@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Virtual Router Redundancy Protocol <vrrp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/vrrp>, <mailto:vrrp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/vrrp>
List-Post: <mailto:vrrp@ietf.org>
List-Help: <mailto:vrrp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/vrrp>, <mailto:vrrp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 17 Jan 2011 17:02:27 -0000
Based on the state machine in rfc 5798 on page 23 steps 450-460 when vrrp is in backup state and receives an advertisement there is no step to recompute the skew time. While in steps 740-765 on page 25 when vrrp is a master and receives an advertisement from some new master, it does recompute the skew time in step 750. Since skew time is part of master down interval, shouldn't it be recomputed in both states when advertisement is received from a master? Otherwise backup vrrp would continue to use skew time that was computed based on its configured value for advertisement interval when initially router transitions to backup. Is this skew time recalculation implied in the backup state or there should be an explicit step like in the master case? Vladica Stanisic
- [VRRP] recomputing skew time when receiving an ad… Vladica Stanisic