Re: [VRRP] Clear draft-ietf-vrrp-unified-spec 5

Stephen Nadas <stephen.nadas@ericsson.com> Wed, 21 October 2009 21:27 UTC

Return-Path: <stephen.nadas@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 CEA2228C104 for <vrrp@core3.amsl.com>; Wed, 21 Oct 2009 14:27:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.854
X-Spam-Level:
X-Spam-Status: No, score=-5.854 tagged_above=-999 required=5 tests=[AWL=0.744, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
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 j3kJhWzS3E9Z for <vrrp@core3.amsl.com>; Wed, 21 Oct 2009 14:27:31 -0700 (PDT)
Received: from imr1.ericy.com (imr1.ericy.com [198.24.6.9]) by core3.amsl.com (Postfix) with ESMTP id C6DDC28C100 for <vrrp@ietf.org>; Wed, 21 Oct 2009 14:27:31 -0700 (PDT)
Received: from eusrcmw750.eamcs.ericsson.se (eusrcmw750.exu.ericsson.se [138.85.77.50]) by imr1.ericy.com (8.13.1/8.13.1) with ESMTP id n9LLRah9005668; Wed, 21 Oct 2009 16:27:36 -0500
Received: from eusrcmw750.eamcs.ericsson.se ([138.85.77.53]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Wed, 21 Oct 2009 16:27:23 -0500
Received: from eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Wed, 21 Oct 2009 16:27:22 -0500
Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.224]) by eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) with mapi; Wed, 21 Oct 2009 17:27:22 -0400
From: Stephen Nadas <stephen.nadas@ericsson.com>
To: "dromasca@avaya.com" <dromasca@avaya.com>
Date: Wed, 21 Oct 2009 17:26:35 -0400
Thread-Topic: Clear draft-ietf-vrrp-unified-spec 5
Thread-Index: AcpDeYX2uwXDCsT6SVu1uGMy43SgHwPGgE9w
Message-ID: <450AE4BEC513614F96969DDA34F359349E264C47@EUSAACMS0701.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_450AE4BEC513614F96969DDA34F359349E264C47EUSAACMS0701eam_"
MIME-Version: 1.0
X-OriginalArrivalTime: 21 Oct 2009 21:27:22.0868 (UTC) FILETIME=[47064B40:01CA5295]
Cc: "Radia.Perlman@Sun.COM" <Radia.Perlman@Sun.COM>, "vrrp@ietf.org" <vrrp@ietf.org>
Subject: Re: [VRRP] Clear draft-ietf-vrrp-unified-spec 5
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: Wed, 21 Oct 2009 21:27:32 -0000

Hi Dan,

Wrt to Accept Mode default, Mukesh asked the list over two weeks ago and the (weak, I'm afraid) consensus is to keep this configurable parameter defaulting to False.

Thanks,
Steve

_____________________________________________
From:   Stephen Nadas
Sent:   Friday, October 02, 2009 12:01 PM
To:     'dromasca@avaya.com'
Cc:     'adrian.farrel@huawei.com'; Radia.Perlman@Sun.COM; 'Mukesh Gupta'; 'vrrp@ietf.org'
Subject:        Clear draft-ietf-vrrp-unified-spec 5

Hi Dan,

Please see below for the various proposed resolutions.  Are they sufficient to clear the draft?

Thanks,
Steve

Discuss remarks;

[snipped]

3. Accept_Mode defaulting to false seems unrealistic at least in deployments
I've seen.  Using accept-data config knob seems very common. Unless enable
Accept_Mode, when the virtual address moves to the Backup, the virtual address
no longer responds to ping; I've also seen an implementation to reject pings to
the virtual IP when it's in Master mode, but this seems like an implementation
bug if so (I'd like a confirmation if this is the case).

In any case, this restriction makes troubleshooting and deployment a pain;
hosts and management systems often ping the gateway address to see if the
network is working, and this kills that assumption.

Unless the WG has recently discussed and reached consensus that Accept_Mode
should still default to false, I'd consider revisiting this position.

We are thinking that accept_mode needs a configuration control and that the default vaule could be an implementation choice.  This is TBD on the list.