Ok. We hear 2
responses; one recommending TRUE and the other recommending FALSE J
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 at bivio.net]
Sent: Tuesday, October 06, 2009 11:05
AM
To: John Cruz (johcruz); Mukesh Gupta;
vrrp at ietf.org
Cc: dromasca at 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 at ietf.org [mailto:vrrp-bounces at ietf.org] On Behalf Of John
Cruz (johcruz)
Sent: Tuesday, October 06, 2009 10:15
AM
To: Mukesh Gupta; vrrp at ietf.org
Cc: dromasca at 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 at juniper.net]
Sent: Tuesday, October 06, 2009 9:53
AM
To: John Cruz (johcruz); vrrp at ietf.org
Cc:
dromasca at 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 at cisco.com]
Sent: Monday, October 05, 2009
11:49 AM
To: Mukesh Gupta; vrrp at ietf.org
Cc:
dromasca at 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 at ietf.org [mailto:vrrp-bounces at ietf.org] On Behalf Of
Mukesh Gupta
Sent: Friday, October 02, 2009 4:26
PM
To: vrrp at ietf.org
Cc: dromasca at 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 J
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.