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

From: Adrian Farrel <[email-masked]>
Date: Wed, 02 Dec 2009 22:06:54 +0000

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-masked]>
To: "Stephen Nadas" <[email-masked]>; <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>; <[email-masked]>; "Mukesh 
Gupta" <[email-masked]>
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
>
>

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Thu, 3 Dec 2009 12:37:23 +0100

I apologize for the delay. The changes are good, and they answer my
concerns. I am clearing my DISCUSS trusting that the last editorial
actions of moving text from the appendix to the Operational Issues
section will be performed as advised by Adrian. 

Thank you for addressing my concerns. 

Regards,

Dan

> -----Original Message-----
> From: Adrian Farrel [mailto:[email-masked]] 
> Sent: Thursday, December 03, 2009 12:07 AM
> To: Stephen Nadas; Romascanu, Dan (Dan)
> Cc: [email-masked]; [email-masked]; [email-masked]; Mukesh Gupta
> Subject: Re: Dan's Discuss and Comment on draft-ietf-vrrp-unified-spec
> 
> 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
> Cc: <[email-masked]>; <[email-masked]>; 
> <[email-masked]>; "Mukesh Gupta" <[email-masked]>
> > 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.
> >
> >> 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?
> >
> document. Has 
> >> anybody heard about a deployment of any of these layer 2 networks 
> >> lately, and with VRRP atop of them?
> >
> > 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.
> >
> >> 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).
> >>
> >> pain; hosts and management systems often ping the gateway 
> address to 
> >> see if the network is working, and this kills that assumption.
> >>
> >> Accept_Mode should still default to false, I'd consider revisiting 
> >> this position.
> >
> >> 1. Appendix B and part of Appendix C excepting the part 
> refering to 
> >> changes from RFC 3768 should be dropped at publication.
> >
> >> 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
> >
> > 
> 
>

---

From: Stephen Nadas <[email-masked]>
Date: Thu, 3 Dec 2009 10:13:49 -0500

Hi Dan, Adrian, 

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

Regards,
Steve  

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