[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

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