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

Looks good to me. Just one typo in A.1 point 1.
-don

> -----Original Message-----
> From: Stephen Nadas [mailto:[email protected]]
> Sent: Tuesday, October 16, 2007 6:23 PM
> To: Don Provan
> Cc: [email protected]
> Subject: RE: [VRRP] FW: I-D 
> ACTION:draft-nadas-vrrp-unified-spec-00.txt 
> 
> 
> Hi Don and list,
> 
> I have just posted draft-nadas-vrrp-unified-spec-01.txt.  
> 
> I would like to ask the working group to consider taking up this draft
> as a working group document. 
> 
> Thanks and regards, 
> Steve  
> 
> > -----Original Message-----
> > From: Stephen Nadas 
> > Sent: Saturday, October 06, 2007 4:06 PM
> > To: 'Don Provan'
> > Cc: [email protected]
> > Subject: RE: [VRRP] 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

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