Subject: [VRRP] Dan's Discuss and Comment on draft-ietf-vrrp-unified-spec

From: Adrian Farrel <[email-masked]>
Date: Wed, 25 Nov 2009 21:54:39 +0000

Hi Dan,

Just trying to chase you as the holder of the last Discuss on 
draft-ietf-vrrp-unified-spec.

A new revision (-04) was posted on 23 October to address other Discusses and 
it includes the resolutions noted below. One issue remains for your 
agreement and would need a further revision.

Here are your Discuss and Comment with responses (thanks to Stephen).

**Discuss**

> 1. The version management and transition plan for VRRP is unlear to me.
> The Introduction section mentions that this is 'version three (3) of the
> protocol and it is based on VRRP (version 2) for IPv4 that is defined
> in RFC 3768 and on draft-ieft-vrrp-ipv6-spec-08.txt'. However RFC 3768
> does not make the claim to be VRRPv2, itlooks like this terminology was
> decided later and is defined here for the first time. On the other hand
> draft-ieft-vrrp-ipv6-spec-08.txt which VRRPv3 is based upon is just an
> informative reference and is actually an expired I-D? Should not this
> document update RFC 3768, and should not at least part of the migration
> and coexistence issues in Appendix A be moved to the Operational
> Issues section?

You are right about 3768. This I-D is now marked "obsoletes 3768"

The authors propose to move the following material from Appendix A to create 
new text in the Operational Issues section. Is that good enough?

VRRPv3 support of VRRPv2

   VRRPv2 and VRRPv3 interoperation is OPTIONAL. Mixing VRRPv2 and
   VRRPv3 should only be done when transitioning from VRRPv2 to VRRPv3.
   Mixing the two versions should not be considered a permanent
   solution.

   An implementation MAY implement a configuration flag that tells it to
   listen for and send both VRRPv2 and VRRPv3 advertisements.

   When configured this way and the Master, it MUST send both types at
   the configured rate, even if sub-second.

   When configured this way and the Backup, it should time out based on
   the rate advertised by the master; in the case of a VRRPv2 master
   this means it must translate the timeout value it receives (in
   seconds) into centi-seconds.  Also, a backup should ignore VRRPv2
   advertisements from the current master if it is also receiving VRRPv3
   packets from it.  It MAY report when a v3 master is *not* sending v2
   packets: that suggests they don't agree on whether they're supporting
   v2 routers.

> 2. I do not understand what is the logic of including a section 9
> 'Operation over FDDI, Token Ring, and ATM LANE' in this
> document. Has anybody heard about a deployment of any of these
> layer 2 networks lately, and with VRRP atop of them?

This has been moved to an appendix (Appendix B) in the latest revision. The 
rationale is that some future L2 may come someday and this thinking may be 
useful.  It seems not to hurt anything to keep is as an appendix.

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

The WG chairs polled the VRRP mailing list on this issue.

The consensu conclusion was to keep Accept_Mode as a configurable parameter 
that defaults to False.

**Comment**

> 1. Appendix B and part of Appendix C excepting the part refering
> to changes from RFC 3768 should be dropped at publication.

This has been done in the latest revision.

> 2. Another feature that at least one vendor implements is so-called
> Backup VRRP router passive ARP learning.  This is very useful,
> because otherwise when you switch from active to backup, the
> backup doesn't know ARP bindings for IP addresses and this
> increases the time needed to converge.  (The same feature should
> apply to ND I think) This would seem to be something that could be
> worth adding or at least discussing in the spec.

The WG chairs and the document author are keen to avoid feature creep in 
this document and also want to get this RFC published sooner rather than 
later. Since this new feature is not required for interoperability, they 
propose that (if there is WG interest) it should be brought forward in a 
separate I-D.

Cheers,
Adrian