|
»
« Return to Thread: Dan's Discuss and Comment on draft-ietf-vrrp-unified-spec
Dan's Discuss and Comment on draft-ietf-vrrp-unified-spec
by Adrian Farrel
::
Rate this Message:
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
vrrp@...
https://www.ietf.org/mailman/listinfo/vrrp
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
vrrp@...
https://www.ietf.org/mailman/listinfo/vrrp
« Return to Thread: Dan's Discuss and Comment on draft-ietf-vrrp-unified-spec
| Free embeddable forum powered by Nabble | Forum Help |
