Re: Default Value of Accept_Mode

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

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


>
> Regards
> Mukesh
>
> From: Don Provan [mailto:[email protected]]
> Sent: Tuesday, October 06, 2009 11:05 AM
> To: John Cruz (johcruz); Mukesh Gupta; [email protected]
> Cc: [email protected]; 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 protected] [mailto:[email protected]] On Behalf  
> Of John Cruz (johcruz)
> Sent: Tuesday, October 06, 2009 10:15 AM
> To: Mukesh Gupta; [email protected]
> Cc: [email protected]; 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:[email protected]]
> Sent: Tuesday, October 06, 2009 9:53 AM
> To: John Cruz (johcruz); [email protected]
> Cc: [email protected]; 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:[email protected]]
> Sent: Monday, October 05, 2009 11:49 AM
> To: Mukesh Gupta; [email protected]
> Cc: [email protected]; 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: [email protected] [mailto:[email protected]] On Behalf  
> Of Mukesh Gupta
> Sent: Friday, October 02, 2009 4:26 PM
> To: [email protected]
> Cc: [email protected]; 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
> [email protected]
> https://www.ietf.org/mailman/listinfo/vrrp

_______________________________________________
vrrp mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/vrrp