[VRRP] Clear draft-ietf-vrrp-unified-spec 5

[Stephen Nadas <[e-mail]>]

Hi Dan,

Please see below for the various proposed resolutions.  Are they sufficient to clear the draft?

Thanks,
Steve

Discuss remarks;

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?

   We are changing draft to obsoletes 3768.

        If we move the below from appendix A to operational issues, will  that work for this item?

   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 is moved to an appendix with the rationale that some future L2 may come someday and this thinking may be useful.  It seems not to hurt anything to keep is as 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.

We are thinking that accept_mode needs a configuration control and that the default vaule could be an implementation choice.  This is TBD on the list.