Re: VRRPv3 Implementation Report

I think that having the Master be able to respond to packets sent to
the virtual IP address is very useful, and that the current
ASSERT_MODE setting in the draft addresses that need.

If I understand correctly, Lin's concern with the current draft is
that having to provide the behaviour of ACCEPT_MODE = FALSE
complicates the protocol implementation, and most users will set
ACCEPT_MODE to TRUE anyway. So can we just remove the setting
altogether and always accept traffic?

I think being able to refuse traffic to the VIP has two (minor) benefits:
1) it provides a way for VRRPv3 to behave like VRRPv2, so that people
who "trade up" don't get any nasty surprises.
2) It reinforces the notion that the VIP is really a forwarding
address, not a local address. Once you start to blur this distinction,
you can inadvertently raise expectations about retaining TCP
connections, VPN tunnels, etc.

An alternative to removing the setting altogether would be to make
ACCEPT_MODE be an optional setting, but require that implementations
that do not support it behave as if ACCEPT_MODE is TRUE.

This would introduce a wrinkle that anyone wanting to preserve VRRPv2
behaviour would need to select a VRRPv3 implementation that supported
the ACCEPT_MODE setting. But that's probably not the end of the world.

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