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

Hi, Steve.

Thanks for yanking me back on course: I was off on a
tangent that I've now abandoned, so consider the extra
ideas mere food for thought. I'll get back to business:

1. Forget granularity. I don't think we've ever mentioned
it, so I don't think we need to start now. Sorry for the
distraction. But I do want to mention that with a
centisecond timer, the skew time theoretically requires
a timer accurate to 0.04 milliseconds. But I'm happy to
leave this issue as an implementation detail.

2. SJN2: I do want to promote to full status the idea
that routers can be configured to different timeouts,
with the (undefended) requirement that longer timeouts
must have lower priorities. So I'd like to see this
in section 5.2.7 and, to the extent appropriate, removed
from the appendix.

3. SJN5: If the consensus is that my claim is correct
(i.e., that PREEMPT should apply only to how you treat
lower priority routers), then 6.4.3 should mention
explicitly that the PREEMPT flag should not be considered
in the case of *being* preempted. I would also update the
description of the flag itself to make clear it only
applies to whether this system preempts lower priority
systems. I don't recall whether there's any text that
explicitly requires PREEMPT to be set the same in all
routers, but obviously any such text should be removed.

-don

> -----Original Message-----
> From: Stephen Nadas [mailto:[email protected]]
> Sent: Friday, October 05, 2007 10:15 AM
> To: Don Provan
> Cc: [email protected]
> Subject: RE: [VRRP] FW: I-D 
> ACTION:draft-nadas-vrrp-unified-spec-00.txt 
> 
> 
> Hi Don, 
> 
> I had some cycles to work on this and have reworded text to 
> address [SJN4,6,7,8] (labels from the from the earlier note 
> actually... ) 
> 
> Seems to me that [SJN1, 2, 3] are somewhat intertwined.  But 
> based on this note: 
> 
> A) wrt [SJN2, SJN3] I am confused bcos I'm not sure whether 
> we are now saying that for skew time to work right everyone 
> needs to use same granularity and hence the text is ok as is. 
>  Or else I am waiting on text from you?    
> 
> B) wrt to [SJN5] this note seems to say leave text as it is. 
> 
> Please advise.
> 
> Thanks,
> Steve 
> 
> > -----Original Message-----
> > From: Don Provan [mailto:[email protected]] 
> > Sent: Saturday, September 15, 2007 5:06 PM
> > To: Stephen Nadas
> > Cc: [email protected]
> > Subject: RE: [VRRP] 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.
> > 
> > > [SJN3] This is a fine way forward as far as I am concerned; 
> > [SJN3] we 
> > > can also what the list may have to say.
> > 
> > [drp] I'll start working on it.
> > 
> > > > 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.
> > 
> > [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.
> > 
> > > > 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".
> > > 
> > > [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
> > 
>

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