Subject: RE: [VRRP] FW: I-D ACTION:draft-nadas-vrrp-unified-spec-00.txt

From: "Don Provan" <[email-masked]>
Date: Thu, 6 Sep 2007 18:04:03 -0700

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-masked]]
> Sent: Wednesday, August 15, 2007 1:20 PM
> To: [email-masked]
> 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-masked] [mailto:[email-masked]] 
> Sent: Wednesday, August 15, 2007 4:15 PM
> To: [email-masked]
> 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-masked] 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-masked].
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-masked]
https://www1.ietf.org/mailman/listinfo/vrrp

---

From: "Stephen Nadas (RL/TNT)" <[email-masked]>
Date: Fri, 7 Sep 2007 10:30:31 -0500

Hi Don, 

Thanks for the comments; please see inline @ [SJN<x>].  My plan is 
to resolve these comments and respin draft as -01.  Please also 
see [SJN3]; if you can send me some text I can then include it.   

Regards, 
Steve  

> From: Don Provan [mailto:[email-masked]] 
> Sent: Thursday, September 06, 2007 9:04 PM
> To: Stephen Nadas (RL/TNT); [email-masked]
> Subject: RE: [VRRP] 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 

[SJN1] I might change "it makes no sense" to "it may not make 
[SJN1] sense", but I'm ok with your point.

> 
> 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.

[SJN2] I think I am a bit confused about your last sentence 
[SJN2] wrt interop.  Can you please expand your comments? 

> 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.
> 
> the first crack at rewriting this section to include these new ideas.

[SJN3] This is a fine way forward as far as I am concerned; 
[SJN3] we can also what the list may have to say. 

> 
> (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?)
> 

[SJN4] I can reword along these lines. 

> 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?

[SJN5] not intentional. Hence, needs a fix. 

> 
> 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.

[SJN6] ok (this text is quite old. I think...) 

> 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...."
> 

[SJN7] ok. 

> 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.
> 

[SJN8] ok. 

> >    protocol that dynamically assigns responsibility for a virtual 
> > router
> controlling 
> > the
> To remove yourself from the I-D Announcement list, send a 
> message to [email-masked] with the word 
> unsubscribe in the body of the message. 
> 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 
> http://www.ietf.org/shadow.html or 
> ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> 
> 	a MIME-compliant mail reader.  Different MIME-compliant 
> mail readers
> Below is the data which will enable a MIME compliant mail 
> reader implementation to automatically retrieve the ASCII 
> version of the Internet-Draft.
>

---

From: "Don Provan" <[email-masked]>
Date: Sat, 15 Sep 2007 14:06:15 -0700

> [SJN1] sense", but I'm ok with your point.

[drp] Unless there's an actual problem, I think the spec
should avoid expressing any judgment at all.

> [SJN2] wrt interop.  Can you please expand your comments? 

[drp] My claim is that two systems can interoperate even when
they have different granularities as long as the master
announces its actual interval and the backup uses an interval
at least that large but possibly larger because it is using
a coarser granularity. Now that you're questioning it, though,
I realize this based more on gut feeling than rigid analysis.

[drp] This completely ignores the nuance of skew time: for
skew time to work as exactly as intended (i.e., to cause
the highest priority backup to be the first to detect the
master failure and announce itself as master), all backups
must have timers of equal granularity a couple of orders
of magnitude finer than the interval.

> [SJN3] we can also what the list may have to say.

[drp] I'll start working on it.

> [SJN5] not intentional. Hence, needs a fix.

[drp] OK. After 5 minutes thought, I'm actually thinking
that the functional behavior is correct: if some other
router that trumps the local system mistakenly thinks it
should take control, what difference does the PREEMPT flag
make? Ignoring the mistaken system would just lead to them
fighting. I think it makes sense for the PREEMPT flag to
mean *specifically* "do no preempt lower priority routers",
it should mean nothing about whether to expect higher
priority routers to preempt us. As far as I can see, that
would mean that each system can have its own independent
PREEMPT setting without destabilizing the protocol.

> [SJN6] ok (this text is quite old. I think...) 

Yeah, I think you're right. As I recall, this has bugged
me for years. I think I was too lazy to bring it up before....

-don