Subject: [VRRP] (re)post of minutes of VRRP WG, 7/16/2003, (this time without slides attached)

From: [email-masked]
Date: Tue, 29 Jul 2003 12:23:43 -0600 (MDT)

VRRP 7/16/2003

Milestone review

New milestones were proposed.
===
Mar 2003 - Resolve open issues with authentication methods [DONE MAR 2003]
Aug 2003 - Submit updated version of VRRP (IPv4) for Draft Standard
Oct 2003 - Submit VRRP for IPv6 (VRRPv3) for Proposed Standard
Dec 2003 - Submit MIB for VRRPv3 for Proposed Standard
Dec 2003 - Review the WG goals and future potential
===

VRRPv3 MIB

There was a discussion about whether there should just be a single
combined MIB for IPv4 and IPv6, or whether there should be two,
and if there were two, one should be IPv4-only, but should the
other be combined IPv4 and IPv6, or IPv6-only. The current
draft is assuming IPv4-only plus IPv6-only. The conclusion was
that it might be good to try to do a strawman IPv4+IPv6 and see
if that works well. One argument for why there couldn't be
a single MIB was that VRRPv2 is stable while VRRPv3 is still
evolving, and there ought to be a stable MIB to go along with
the stable protocol. Another is that VRRPv2 and VRRPv3 might
be sufficiently different protocols that it would be confusing
to try to combine them.

VRRPv2 spec update

Bob Hinden presented the changes to VRRPv2, which were mostly
editorial other than removing the authentication methods, and
adding to the security considerations section an explanation
for having done so. An issue was raised about having too many
listed authors, and some obsolete addresses for them. The conclusion
was that Bob Hinden should be listed as "editor", and a "contributors"
section should be added acknowledging the others.
There was an issue that had been raised on the mailing list about
possible pathological behavior when multiple backup routers had
equal priorities, and on the mailing list a suggestion had been
made for adding a tie-breaker based on IP address.
After discussion during the meeting,
it was concluded that the particular section of code involving backup
router ties would not be invoked, because a router, once it sends
a VRRP message, has already decided it is master, and the master
portion has the IP-address tie-breaker. So the conclusion was
that the election logic was fine as is.
The sense of the room was that VRRPv2 is ready for wg last call.

Sub-second Timers

Karen O'Donoghue gave a presentation explaining the need for
faster convergence (less than one second)
than could be done using timers in units of
seconds. The sense of the room was that they were convinced of
the need, at least for IPv6. It would be difficult to do it for
IPv4 because it would be an incompatible change, and it would
be undesirable to delay the specification. Various encoding
techniques were described, the most straightforward being making
the size of the timer field longer and the units smaller (perhaps
100 ms), and
other suggestions involving exponential encoding so as to fit
into the same sized field. The conclusion was to pursue this on
the mailing list for v6, and if it is desired for IPv4, to have
a new draft for a new version of VRRP for IPv4 (perhaps version
number 4). A quick check was made to ensure that VRRPv2 does indeed
say that a VRRPv2 router should drop VRRP messages with unknown
version numbers, which is required in order to safely roll out a new
version of VRRP.
 
VRRPv3

As with v2, removed authentication types and added explanation
in security considerations section.

An issue from the mailing list was discussed, which is that
using VMACs causes layer 2 addresses to change locations,
which is somewhat dangerous in a bridged LAN. For IPv4, VMACs
are necessary because there are implementations of hosts
(e.g., Win 95) that do not update their ARP caches when they
receive gratuitous ARP messages.
But the question was raised as to whether
VMACs, and perhaps even VRRP, could be avoided for IPv6.

The conclusion about whether VRRP for IPv6 could
be avoided was that it could not. VRRP for IPv6 could not be
avoided because the neighbor discovery mechanism in IPv6 would not
be able to react to changes as quickly as a mechanism such
as VRRP, confined to a community of a few routers.
And even if IPv6 neighbor discovery could in theory be modified to be as
responsive as VRRP, the VRRP WG could not impose changes to a different WG.

The second issue was whether VMACs could be avoided for IPv6,
i.e., have VRRPv3 still elect one router to represent
the IP address, but not move MAC addresses. The elected router would
use its own MAC address. The reasoning
was that in IPv6, nodes are required to update their ARP caches
if they see a gratuitous ARP, so as long as the newly elected
router did a gratuitous ARP, the ARP caches would all get
updated, and this approach would avoid having a MAC address move within
the topology. Some objected to this because
the endnodes would then be aware that the router had switched, but
others liked this proposal specifically because the endnode would
know that something had happened. There was also concern that if
the gratuitous ARP got lost, it might take a long time for ARP caches
to get fixed to the MAC adress of the new router.
Another argument was that
doing things very differently for VRRPv3 than VRRPv2 is
out of the charter of the WG. So the conclusion is that we will
assume for now that VRRPv3 will continue to use VMACs, but that
the issue can be discussed on the mailing list, and if there is
a lot of interest and a concrete proposal, we can revive this
issue.

_______________________________________________
vrrp mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/vrrp