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

[Stephen Nadas <[e-mail]>]

Hi Dan, Adrian, 

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

Regards,
Steve  

SJN> -----Original Message-----
SJN> From: Romascanu, Dan (Dan) [mailto:[e-mail]] 
SJN> Sent: Thursday, December 03, 2009 6:37 AM
SJN> To: Adrian Farrel; Stephen Nadas
SJN> Cc: [e-mail]; [e-mail]; [e-mail]; 
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:[e-mail]]
SJN> > Sent: Thursday, December 03, 2009 12:07 AM
SJN> > To: Stephen Nadas; Romascanu, Dan (Dan)
SJN> > Cc: [e-mail]; [e-mail]; [e-mail]; 
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" <[e-mail]>
SJN> > To: "Stephen Nadas" <[e-mail]>; 
SJN> <[e-mail]>
SJN> > Cc: <[e-mail]>; <[e-mail]>; 
SJN> <[e-mail]>; "Mukesh 
SJN> > Gupta" <[e-mail]>
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>