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

Hi Dan, Adrian,

Thanks!  I just posted -05 w/this change.

Regards,
Steve  

SJN> -----Original Message-----
SJN> From: Romascanu, Dan (Dan) [mailto:dromasca@...]
SJN> Sent: Thursday, December 03, 2009 6:37 AM
SJN> To: Adrian Farrel; Stephen Nadas
SJN> Cc: Radia.Perlman@...; vrrp@...; iesg@...;
SJN> Mukesh Gupta
SJN> Subject: RE: Dan's Discuss and Comment on
SJN> draft-ietf-vrrp-unified-spec
SJN>
SJN> I apologize for the delay. The changes are good, and they
SJN> answer my concerns. I am clearing my DISCUSS trusting that
SJN> the last editorial actions of moving text from the
SJN> appendix to the Operational Issues section will be
SJN> performed as advised by Adrian.
SJN>
SJN> Thank you for addressing my concerns.
SJN>
SJN> Regards,
SJN>
SJN> Dan
SJN>  
SJN>
SJN> > -----Original Message-----
SJN> > From: Adrian Farrel [mailto:Adrian.Farrel@...]
SJN> > Sent: Thursday, December 03, 2009 12:07 AM
SJN> > To: Stephen Nadas; Romascanu, Dan (Dan)
SJN> > Cc: Radia.Perlman@...; vrrp@...; iesg@...;
SJN> Mukesh Gupta
SJN> > Subject: Re: Dan's Discuss and Comment on
SJN> draft-ietf-vrrp-unified-spec
SJN> >
SJN> > Dan has gone all silent on us. :-)
SJN> >
SJN> > Stephen, there was one action that had not been done -
SJN> moving text
SJN> > from the appendix to the Operational Issues section.
SJN> >
SJN> > Can I suggest you do this in a new revision (unless you
SJN> want to give
SJN> > me some text to include as an RFC Editor note) and then
SJN> we will have a
SJN> > perfect hand with which to beat Dan.
SJN> >
SJN> > Thanks,
SJN> > Adrian
SJN> > ----- Original Message -----
SJN> > From: "Adrian Farrel" <Adrian.Farrel@...>
SJN> > To: "Stephen Nadas" <stephen.nadas@...>;
SJN> <dromasca@...>
SJN> > Cc: <Radia.Perlman@...>; <vrrp@...>;
SJN> <iesg@...>; "Mukesh
SJN> > Gupta" <mukesh@...>
SJN> > Sent: Wednesday, November 25, 2009 9:54 PM
SJN> > Subject: Dan's Discuss and Comment on
SJN> draft-ietf-vrrp-unified-spec
SJN> >
SJN> >
SJN> > > Hi Dan,
SJN> > >
SJN> > > Just trying to chase you as the holder of the last Discuss on
SJN> > > draft-ietf-vrrp-unified-spec.
SJN> > >
SJN> > > A new revision (-04) was posted on 23 October to address other
SJN> > > Discusses and it includes the resolutions noted below.
SJN> One issue
SJN> > > remains for your agreement and would need a further revision.
SJN> > >
SJN> > > Here are your Discuss and Comment with responses (thanks to
SJN> > Stephen).
SJN> > >
SJN> > > **Discuss**
SJN> > >
SJN> > >> 1. The version management and transition plan for VRRP is
SJN> > unlear to me.
SJN> > >> The Introduction section mentions that this is 'version
SJN> > three (3) of
SJN> > >> the protocol and it is based on VRRP (version 2) for
SJN> IPv4 that is
SJN> > >> defined in RFC 3768 and on
SJN> > draft-ieft-vrrp-ipv6-spec-08.txt'. However
SJN> > >> RFC 3768 does not make the claim to be VRRPv2,
SJN> itlooks like this
SJN> > >> terminology was decided later and is defined here for the
SJN> > first time.
SJN> > >> On the other hand draft-ieft-vrrp-ipv6-spec-08.txt
SJN> which VRRPv3 is
SJN> > >> based upon is just an informative reference and is
SJN> actually an
SJN> > >> expired I-D? Should not this document update RFC 3768, and
SJN> > should not
SJN> > >> at least part of the migration and coexistence issues in
SJN> > Appendix A
SJN> > >> be moved to the Operational Issues section?
SJN> > >
SJN> > > You are right about 3768. This I-D is now marked
SJN> "obsoletes 3768"
SJN> > >
SJN> > > The authors propose to move the following material from
SJN> > Appendix A to
SJN> > > create new text in the Operational Issues section. Is that
SJN> > good enough?
SJN> > >
SJN> > > VRRPv3 support of VRRPv2
SJN> > >
SJN> > >   VRRPv2 and VRRPv3 interoperation is OPTIONAL. Mixing
SJN> VRRPv2 and
SJN> > >   VRRPv3 should only be done when transitioning from VRRPv2
SJN> > to VRRPv3.
SJN> > >   Mixing the two versions should not be considered a permanent
SJN> > >   solution.
SJN> > >
SJN> > >   An implementation MAY implement a configuration flag that
SJN> > tells it to
SJN> > >   listen for and send both VRRPv2 and VRRPv3 advertisements.
SJN> > >
SJN> > >   When configured this way and the Master, it MUST send
SJN> > both types at
SJN> > >   the configured rate, even if sub-second.
SJN> > >
SJN> > >   When configured this way and the Backup, it should time
SJN> > out based on
SJN> > >   the rate advertised by the master; in the case of a
SJN> VRRPv2 master
SJN> > >   this means it must translate the timeout value it
SJN> receives (in
SJN> > >   seconds) into centi-seconds.  Also, a backup should
SJN> ignore VRRPv2
SJN> > >   advertisements from the current master if it is also
SJN> > receiving VRRPv3
SJN> > >   packets from it.  It MAY report when a v3 master is *not*
SJN> > sending v2
SJN> > >   packets: that suggests they don't agree on whether
SJN> > they're supporting
SJN> > >   v2 routers.
SJN> > >
SJN> > >> 2. I do not understand what is the logic of including
SJN> a section 9
SJN> > >> 'Operation over FDDI, Token Ring, and ATM LANE' in this
SJN> > document. Has
SJN> > >> anybody heard about a deployment of any of these
SJN> layer 2 networks
SJN> > >> lately, and with VRRP atop of them?
SJN> > >
SJN> > > This has been moved to an appendix (Appendix B) in the
SJN> > latest revision.
SJN> > > The rationale is that some future L2 may come someday and this
SJN> > > thinking may be useful.  It seems not to hurt anything to
SJN> > keep is as an appendix.
SJN> > >
SJN> > >> 3. Accept_Mode defaulting to false seems unrealistic
SJN> at least in
SJN> > >> deployments I've seen.  Using accept-data config knob
SJN> seems very
SJN> > >> common. Unless enable Accept_Mode, when the virtual
SJN> > address moves to
SJN> > >> the Backup, the virtual address no longer responds to
SJN> > ping; I've also
SJN> > >> seen an implementation to reject pings to the virtual IP
SJN> > when it's in
SJN> > >> Master mode, but this seems like an implementation
SJN> bug if so (I'd
SJN> > >> like a confirmation if this is the case).
SJN> > >>
SJN> > >> In any case, this restriction makes troubleshooting and
SJN> > deployment a
SJN> > >> pain; hosts and management systems often ping the gateway
SJN> > address to
SJN> > >> see if the network is working, and this kills that assumption.
SJN> > >>
SJN> > >> Unless the WG has recently discussed and reached
SJN> consensus that
SJN> > >> Accept_Mode should still default to false, I'd
SJN> consider revisiting
SJN> > >> this position.
SJN> > >
SJN> > > The WG chairs polled the VRRP mailing list on this issue.
SJN> > >
SJN> > > The consensu conclusion was to keep Accept_Mode as a
SJN> configurable
SJN> > > parameter that defaults to False.
SJN> > >
SJN> > > **Comment**
SJN> > >
SJN> > >> 1. Appendix B and part of Appendix C excepting the part
SJN> > refering to
SJN> > >> changes from RFC 3768 should be dropped at publication.
SJN> > >
SJN> > > This has been done in the latest revision.
SJN> > >
SJN> > >> 2. Another feature that at least one vendor implements is
SJN> > so-called
SJN> > >> Backup VRRP router passive ARP learning.  This is
SJN> very useful,
SJN> > >> because otherwise when you switch from active to backup,
SJN> > the backup
SJN> > >> doesn't know ARP bindings for IP addresses and this
SJN> increases the
SJN> > >> time needed to converge.  (The same feature should
SJN> apply to ND I
SJN> > >> think) This would seem to be something that could be worth
SJN> > adding or
SJN> > >> at least discussing in the spec.
SJN> > >
SJN> > > The WG chairs and the document author are keen to avoid
SJN> > feature creep
SJN> > > in this document and also want to get this RFC published
SJN> > sooner rather
SJN> > > than later. Since this new feature is not required for
SJN> > > interoperability, they propose that (if there is WG
SJN> interest) it
SJN> > > should be brought forward in a separate I-D.
SJN> > >
SJN> > > Cheers,
SJN> > > Adrian
SJN> > >
SJN> > >
SJN> >
SJN> >
SJN>
_______________________________________________
vrrp mailing list
vrrp@...
https://www.ietf.org/mailman/listinfo/vrrp