Re: [VRRP] Default Value of Accept_Mode
Stephen Nadas <stephen.nadas@ericsson.com> Wed, 14 October 2009 20:28 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 13AA63A682B for <vrrp@core3.amsl.com>; Wed, 14 Oct 2009 13:28:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.109
X-Spam-Level:
X-Spam-Status: No, score=-5.109 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, 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 ELRUpfEYOF5b for <vrrp@core3.amsl.com>; Wed, 14 Oct 2009 13:28:24 -0700 (PDT)
Received: from imr1.ericy.com (imr1.ericy.com [198.24.6.9]) by core3.amsl.com (Postfix) with ESMTP id 7D1FB3A68C0 for <vrrp@ietf.org>; Wed, 14 Oct 2009 13:28:24 -0700 (PDT)
Received: from eusrcmw751.eamcs.ericsson.se (eusrcmw751.exu.ericsson.se [138.85.77.51]) by imr1.ericy.com (8.13.1/8.13.1) with ESMTP id n9EKSJ9a011559; Wed, 14 Oct 2009 15:28:19 -0500
Received: from eusrcmw750.eamcs.ericsson.se ([138.85.77.50]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Wed, 14 Oct 2009 15:28:16 -0500
Received: from eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Wed, 14 Oct 2009 15:28:16 -0500
Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.224]) by eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) with mapi; Wed, 14 Oct 2009 16:28:15 -0400
From: Stephen Nadas <stephen.nadas@ericsson.com>
To: Mukesh Gupta <mukesh@juniper.net>, Don Provan <dprovan@bivio.net>, "John Cruz (johcruz)" <johcruz@cisco.com>, "vrrp@ietf.org" <vrrp@ietf.org>
Date: Wed, 14 Oct 2009 16:28:13 -0400
Thread-Topic: [VRRP] Default Value of Accept_Mode
Thread-Index: AcpDt7a0S0fo6R9bTVSNAA5SMibGxACNFBOAAC42R3AAAFesoAACHv7AADGoftABZdlDIA==
Message-ID: <450AE4BEC513614F96969DDA34F359349E0F610A@EUSAACMS0701.eamcs.ericsson.se>
References: <497B6D90E0023142AF34948DEFFAB38D3A66EEA26C@EMBX01-HQ.jnpr.net><9D0602B62D632D499E0A26CBCDA74A7D0616C03D@xmb-sjc-22a.amer.cisco.com><497B6D90E0023142AF34948DEFFAB38D3A671590B7@EMBX01-HQ.jnpr.net> <9D0602B62D632D499E0A26CBCDA74A7D0616C4F1@xmb-sjc-22a.amer.cisco.com> <D83235F0F3C86D4D889D8B9A0DA8C6D704A4EBD8@corpexc01.corp.networkrobots.com> <497B6D90E0023142AF34948DEFFAB38D3A67467986@EMBX01-HQ.jnpr.net>
In-Reply-To: <497B6D90E0023142AF34948DEFFAB38D3A67467986@EMBX01-HQ.jnpr.net>
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_450AE4BEC513614F96969DDA34F359349E0F610AEUSAACMS0701eam_"
MIME-Version: 1.0
X-OriginalArrivalTime: 14 Oct 2009 20:28:16.0857 (UTC) FILETIME=[DC8BB490:01CA4D0C]
Cc: "dromasca@avaya.com" <dromasca@avaya.com>, Adrian Farrel <Adrian.Farrel@huawei.com>
Subject: Re: [VRRP] Default Value of Accept_Mode
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, 14 Oct 2009 20:28:33 -0000
2 Thanks, Steve ________________________________ From: vrrp-bounces@ietf.org [mailto:vrrp-bounces@ietf.org] On Behalf Of Mukesh Gupta Sent: Wednesday, October 07, 2009 1:46 PM To: Don Provan; John Cruz (johcruz); vrrp@ietf.org Cc: dromasca@avaya.com; Adrian Farrel Subject: Re: [VRRP] Default Value of Accept_Mode Ok. We hear 2 responses; one recommending TRUE and the other recommending FALSE :) It would be good to hear preferences of other WG members. Please speak up. Here are the choices to make it easier. 1) Leave the default value to the implementers 2) Specify FALSE as the default value in the draft 3) Specify TRUE as the default value in the draft 4) I do not care Regards Mukesh From: Don Provan [mailto:dprovan@bivio.net] Sent: Tuesday, October 06, 2009 11:05 AM To: John Cruz (johcruz); Mukesh Gupta; vrrp@ietf.org Cc: dromasca@avaya.com; Adrian Farrel Subject: RE: [VRRP] Default Value of Accept_Mode By this logic, the default should be FALSE since that's been the default until now. Previous versions of the protocol didn't allow accepting such packets at all. -don ________________________________ From: vrrp-bounces@ietf.org [mailto:vrrp-bounces@ietf.org] On Behalf Of John Cruz (johcruz) Sent: Tuesday, October 06, 2009 10:15 AM To: Mukesh Gupta; vrrp@ietf.org Cc: dromasca@avaya.com; Adrian Farrel Subject: Re: [VRRP] Default Value of Accept_Mode Hi Mukesh, There are no interoperability issues w.r.t to the VRRP state machine. The interoperability issue that I mentioned refers to network deployments where customers have devices from different vendors on their network and each vendor has a different default value. In such situation, the onus is on the customers to know the default value for each implementation and set it accordingly, which I think is not a good idea. Let us choose a default value for all implementations. If the customer wants to change it, they can change it for all devices in the network. I believe, the concern is should it be TRUE or FALSE. With VRRP for IPv4, this option did not exists. Accept_mode is now being introduced for the unified spec. If there are no security/vulnerability issues w.r.t. accepting packets address to the virtual IP address, then let us default the value to TRUE. Here is a crude analogy - can the VRRP hello timer value be a default value per implementation? John From: Mukesh Gupta [mailto:mukesh@juniper.net] Sent: Tuesday, October 06, 2009 9:53 AM To: John Cruz (johcruz); vrrp@ietf.org Cc: dromasca@avaya.com; Adrian Farrel Subject: RE: [VRRP] Default Value of Accept_Mode John, Could you please explain a little more about the interoperability issues that you are referring to? As far as I understand, an operator will see different behavior from the devices with different default values when he/she tries to connect to the virtual address. However, it should not cause any protocol interoperability issues. Moreover, the operator would be able to change the default value using the configurable knob to see consistent behavior from all the devices. Regards Mukesh From: John Cruz (johcruz) [mailto:johcruz@cisco.com] Sent: Monday, October 05, 2009 11:49 AM To: Mukesh Gupta; vrrp@ietf.org Cc: dromasca@avaya.com; Adrian Farrel Subject: RE: [VRRP] Default Value of Accept_Mode Hi Mukesh, Leaving the default value to be implementation dependent may not be a good idea as it will cause interoperability issues in environments where customers have a mix of devices from different vendors. John From: vrrp-bounces@ietf.org [mailto:vrrp-bounces@ietf.org] On Behalf Of Mukesh Gupta Sent: Friday, October 02, 2009 4:26 PM To: vrrp@ietf.org Cc: dromasca@avaya.com; Adrian Farrel Subject: [VRRP] Default Value of Accept_Mode [WG Chair Hat Off] Folks, During the IESG review of the unified VRRP draft, Dan, Operations and Management AD, questioned the default value of the Accept_Mode in the draft. The current default value is False and he would like us to reconsider that (his comments in the end of this email). We had discussions about this on the mailing list. However, I don't remember having a clear WG consensus for either default value. Given the fact that the default value has absolutely no impact on the interoperability and the fact that both the values have their pros and cons, we are proposing that the draft should leave the default value to the implementations. The draft would say that the implementations are free to choose any default value. Please let us know if you agree/disagree. If we do not hear anything back, we will assume that the WG agrees :) Regards Mukesh Dan's Comment: ============= 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.
- [VRRP] Default Value of Accept_Mode Mukesh Gupta
- Re: [VRRP] Default Value of Accept_Mode John Cruz (johcruz)
- Re: [VRRP] Default Value of Accept_Mode Mukesh Gupta
- Re: [VRRP] Default Value of Accept_Mode John Cruz (johcruz)
- Re: [VRRP] Default Value of Accept_Mode Mukesh Gupta
- Re: [VRRP] Default Value of Accept_Mode Bob Hinden
- Re: [VRRP] Default Value of Accept_Mode Stephen Nadas