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.
_______________________________________________
vrrp mailing list
vrrp at ietf.org
https://www.ietf.org/mailman/listinfo/vrrp