Subject: [VRRP] Default Value of Accept_Mode

From: Mukesh Gupta <[email-masked]>
Date: Fri, 2 Oct 2009 16:26:05 -0700

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

---

From: "John Cruz (johcruz)" <[email-masked]>
Date: Mon, 5 Oct 2009 11:48:44 -0700

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: [email-masked] [mailto:[email-masked]] On Behalf Of
Mukesh Gupta
Sent: Friday, October 02, 2009 4:26 PM
To: [email-masked]
Cc: [email-masked]; 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

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

Unless the WG has recently discussed and reached consensus that
Accept_Mode

---

From: Mukesh Gupta <[email-masked]>
Date: Tue, 6 Oct 2009 09:53:15 -0700

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:[email-masked]]
Sent: Monday, October 05, 2009 11:49 AM
To: Mukesh Gupta; [email-masked]
Cc: [email-masked]; Adrian Farrel
Subject: RE: [VRRP] Default Value of Accept_Mode

Hi Mukesh,

John

From: [email-masked] [mailto:[email-masked]] On Behalf Of Mukesh Gupta
Sent: Friday, October 02, 2009 4:26 PM
To: [email-masked]
Cc: [email-masked]; Adrian Farrel
Subject: [VRRP] Default Value of Accept_Mode

[WG Chair Hat Off]

Folks,

Regards
Mukesh

Dan's  Comment:
=============

---

From: "John Cruz (johcruz)" <[email-masked]>
Date: Tue, 6 Oct 2009 10:14:55 -0700

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:[email-masked]] 
Sent: Tuesday, October 06, 2009 9:53 AM
To: John Cruz (johcruz); [email-masked]
Cc: [email-masked]; 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

Hi Mukesh,

vendors.

John

[WG Chair Hat Off]

Folks,

Regards

Mukesh

Dan's  Comment:

=============

---

From: Mukesh Gupta <[email-masked]>
Date: Wed, 7 Oct 2009 10:46:21 -0700

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:[email-masked]]
Sent: Tuesday, October 06, 2009 11:05 AM
To: John Cruz (johcruz); Mukesh Gupta; [email-masked]
Cc: [email-masked]; 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: [email-masked] [mailto:[email-masked]] On Behalf Of John Cruz (johcruz)
Sent: Tuesday, October 06, 2009 10:15 AM
To: Mukesh Gupta; [email-masked]
Cc: [email-masked]; 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

John,

Regards
Mukesh

Hi Mukesh,

John

[WG Chair Hat Off]

Folks,

Regards
Mukesh

Dan's  Comment:
=============

---

From: Bob Hinden <[email-masked]>
Date: Wed, 7 Oct 2009 11:03:39 -0700

On Oct 7, 2009, at 10:46 AM, Mukesh Gupta wrote:

> 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.
>

I think the main issue is that it should have a default value and not  
be left to implementers.  I would go with FALSE to be compatible with  
earlier versions of the protocol (as Don Provan suggested).

Bob

> 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
>
> Here is a crude analogy – can the VRRP hello timer value be a  
> default value per implementation?
>
> John
>
> 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
>
> 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  
> 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:
> =============
> _______________________________________________
> vrrp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/vrrp

---

From: Stephen Nadas <[email-masked]>
Date: Wed, 14 Oct 2009 16:28:13 -0400

2

Thanks,
Steve

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Mukesh Gupta
Sent: Wednesday, October 07, 2009 1:46 PM
To: Don Provan; John Cruz (johcruz); [email-masked]
Cc: [email-masked]; Adrian Farrel
Subject: Re: [VRRP] Default Value of Accept_Mode

Regards
Mukesh

John

John,

Regards
Mukesh

Hi Mukesh,

John

[WG Chair Hat Off]

Folks,

Regards
Mukesh

Dan's  Comment:
=============