headers
Don Provan | 7 Sep 2007 03:04
Favicon

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
(Continue reading)

Permalink | Reply | 7 comments |
headers
Stephen Nadas (RL/TNT | 7 Sep 2007 17:30
Picon
Favicon

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

Hi Don, 

Thanks for the comments; please see inline  <at>  [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  

> -----Original Message-----
> From: Don Provan [mailto:dprovan <at> bivio.net] 
> Sent: Thursday, September 06, 2007 9:04 PM
> To: Stephen Nadas (RL/TNT); vrrp <at> ietf.org
> 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 
> configured with a much faster interval than the backup.
(Continue reading)

Permalink | Reply | 6 comments |
headers
Don Provan | 15 Sep 2007 23:06
Favicon

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

> [SJN1] I might change "it makes no sense" to "it may not make 
> [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.

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

[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.
(Continue reading)

Permalink | Reply | 5 comments |

Gmane