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