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