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

> -----Original Message-----
> From: Adrian Farrel [mailto:Adrian.Farrel@...]
> Sent: Thursday, December 03, 2009 12:07 AM
> To: Stephen Nadas; Romascanu, Dan (Dan)
> Cc: Radia.Perlman@...; vrrp@...; iesg@...; Mukesh Gupta
> Subject: 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" <Adrian.Farrel@...>
> To: "Stephen Nadas" <stephen.nadas@...>; <dromasca@...>
> Cc: <Radia.Perlman@...>; <vrrp@...>;
> <iesg@...>; "Mukesh Gupta" <mukesh@...>
> 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
> >
> >
>
>