|
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] 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) 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] 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] 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 [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. |