RE: FW: I-D ACTION:draft-nadas-vrrp-unified-spec-00.txt

Steve,

This looks good to me. I see no significant problems, but
I'm going to make a couple of functional comments followed
by some editorial comments of less importance.

Functional 1: I'm convinced that not only can we handle unmatched
intervals,
it's a good idea to support them for many reasons. Just in the simple
backup case, for example, it makes no sense for the backup router to
advertise on a subsecond interval while the primary router is down,
so we should expect it to be standard practice for the owner to be
configured with a much faster interval than the backup.

I mention this because I think some of the sections need to be
updated to reflect this. Section 5.2.7, for example, should explicitly
discuss the fact that routers can be configured to different values,
and, in my opinion, here (or somewhere) the spec should say that
implementations don't have to have centisecond granularity as long
as they report the interval they actually use.

This would be the logical place to put the discussion about
systems configured to smaller intervals should always have
higher priorities. Then section A.3.1 can just refer to the
general discussion while pointing out the essentially identical
case where the higher priority node is v3 and the lower one v2.

Similarly, the problem of a subsecond implementation overwhelming
a less capable implementation should be discussed here, and
A.3.2 should refer to it while mentioning that VRRPv2 implementations
don't expect subsecond advertisements.

If everyone agrees to the logic of this, I'm willing to take
the first crack at rewriting this section to include these
new ideas.

(By the way, shouldn't section 5.2.7 be "*Maximum* Advertisement
Interval"? The master is promising to send packets with that
interval or a smaller one, right?)

Functional 2: In section 6.4.3, in the master event processing
description, the master's handling of an arriving advertisement
with higher priority doesn't mention the PREEMPT flag. Is it
intentional that a preemption happen in this case even though
the PREEMPT flag is FALSE?

Editorial 1: Remove the editorial comment in the second sentence
in the first paragraph: I think section 4.1 is a perfectly reasonable
configuration, having a file server back up a router, for example.
But in any case, there's no reason for the spec to comment on
whether it is "expected to occur in actual practice".

Editorial 2: In section 8.1.1 (ICMP Redirects), the second paragraph
ends with "One method to deduce the virtual router used is to examine
the destination MAC address in the packet that triggered the redirect."
Is there another method? If so, I can't think of it. If not, then
explicitly say "The way to deduce...."

Editorial 3: In section A.1, I find the rational for "upgrade only"
to be weak, so I suggest removing it. Try the last half of the
section as, "2. 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." and leave it at that. In
other words, just explain that that's all the spec supports without
offering a weak justification.

Thanks, again. I think we're on the right track.
-don

> -----Original Message-----
> From: Stephen Nadas (RL/TNT) [mailto:[email protected]]
> Sent: Wednesday, August 15, 2007 1:20 PM
> To: [email protected]
> Subject: [VRRP] FW: I-D ACTION:draft-nadas-vrrp-unified-spec-00.txt 
> 
> 
> Here's a go at the unified approach.
> -steve  
> 
> -----Original Message-----
> From: [email protected] [mailto:[email protected]] 
> Sent: Wednesday, August 15, 2007 4:15 PM
> To: [email protected]
> Subject: I-D ACTION:draft-nadas-vrrp-unified-spec-00.txt 
> 
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> 
> 
> 	Title		: Virtual Router Redundancy Protocol Version 3
> for IPv4 and IPv6
> 	Author(s)	: S. Nadas
> 	Filename	: draft-nadas-vrrp-unified-spec-00.txt
> 	Pages		: 43
> 	Date		: 2007-8-15
> 	
>    This memo defines the Virtual Router Redundancy Protocol (VRRP) for
>    IPv4 and IPv6.  It 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.  VRRP specifies an election
>    protocol that dynamically assigns responsibility for a 
> virtual router
>    to one of the VRRP routers on a LAN.  The VRRP router 
> controlling the
>    IPv4 or IPv6 address(es) associated with a virtual router is called
>    the Master, and forwards packets sent to these IPv4 or IPv6
>    addresses.  VRRP Master routers are configured with virtual IPv4 or
>    IPv6 addresses and VRRP Backup routers infer the address family of
>    the virtual addresses being carried based on the transport 
> protocol.
>    IPv4 addresses and IPv6 addresses never belong to the same group,
>    that is, each address family has its own set of VRRP groups.  The
>    election process provides dynamic fail over in the forwarding
>    responsibility should the Master become unavailable.  For IPv4, the
>    advantage gained from using VRRP is a higher availability default
>    path without requiring configuration of dynamic routing or router
>    discovery protocols on every end-host.  For IPv6, the advantage
>    gained from using VRRP for IPv6 is a quicker switch over to back up
>    routers than can be obtained with standard IPv6 Neighbor Discover
>    (RFC 2461) mechanisms.
> 
> 
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-nadas-vrrp-unified-s
pec-00.txt

To remove yourself from the I-D Announcement list, send a message to 
[email protected] with the word unsubscribe in the body of 
the message. 
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the 
username "anonymous" and a password of your e-mail address. After 
logging in, type "cd internet-drafts" and then 
"get draft-nadas-vrrp-unified-spec-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email protected].
In the body type:
	"FILE /internet-drafts/draft-nadas-vrrp-unified-spec-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail
readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

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