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

Hi Don,  

My responses are inline.  I think I can drop -01 soon.  

Thanks,
Steve  

> -----Original Message-----
> From: Don Provan [mailto:[email protected]] 
> Sent: Friday, October 05, 2007 2:39 PM
> To: Stephen Nadas
> Cc: [email protected]
> Subject: RE: [VRRP] 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.

Forgotten.

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

I'll take a crack at this. 

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

Impossible for me to decide consensus, unless I use silence == agreement
:-)  I'll take a crack at this as well.  


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