Re: Dan's Discuss and Comment on draft-ietf-vrrp-unified-spec

Dan has gone all silent on us. :-)

Stephen, there was one action that had not been done - moving text from the 
appendix to the Operational Issues section.

Can I suggest you do this in a new revision (unless you want to give me some 
text to include as an RFC Editor note) and then we will have a perfect hand 
with which to beat Dan.

Thanks,
Adrian
----- Original Message ----- 
From: "Adrian Farrel" <[email protected]>
To: "Stephen Nadas" <[email protected]>; <[email protected]>
Cc: <[email protected]>; <[email protected]>; <[email protected]>; "Mukesh 
Gupta" <[email protected]>
Sent: Wednesday, November 25, 2009 9:54 PM
Subject: 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
>
> 

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