Subject: RE: [VRRP] FW: I-D ACTION:draft-nadas-vrrp-unified-spec-00.txt

From: "Stephen Nadas" <[email-masked]>
Date: Fri, 5 Oct 2007 12:15:01 -0500

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-masked]] 
> Sent: Saturday, September 15, 2007 5:06 PM
> To: Stephen Nadas
> Cc: [email-masked]
> 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-masked]
https://www1.ietf.org/mailman/listinfo/vrrp

---

From: "Don Provan" <[email-masked]>
Date: Fri, 5 Oct 2007 11:39:11 -0700

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

> From: Stephen Nadas [mailto:[email-masked]]
> Sent: Friday, October 05, 2007 10:15 AM
> To: Don Provan
> Cc: [email-masked]
> 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?    
>

---

From: "Stephen Nadas" <[email-masked]>
Date: Sat, 6 Oct 2007 15:06:06 -0500

Hi Don,  

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

Thanks,
Steve  

> Sent: Friday, October 05, 2007 2:39 PM
> To: Stephen Nadas
> Cc: [email-masked]
> 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.  

> we are now 
> > granularity and hence the text is ok as is.
> > > [drp] Unless there's an actual problem, I think the spec should 
> > > avoid expressing any judgment at all.
> > > 
> > > [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.
> > > 
> > > [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.
> > > 
> > > 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
> > > 
> > 
>

---

From: "Stephen Nadas" <[email-masked]>
Date: Tue, 16 Oct 2007 20:22:50 -0500

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  

> From: Stephen Nadas 
> Sent: Saturday, October 06, 2007 4:06 PM
> To: 'Don Provan'
> Cc: [email-masked]
> 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.
> 
> > 
> routers can 
> > be configured to different timeouts, with the
> > priorities. So I'd like to see this in section 5.2.7 and, to the 
> > extent appropriate, removed from the appendix.
> > 
> 
> Impossible for me to decide consensus, unless I use silence 
> == agreement :-)  I'll take a crack at this as well.  
> 
> 
> > -don
> >

---

From: "Don Provan" <[email-masked]>
Date: Wed, 24 Oct 2007 13:59:53 -0700

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

> Sent: Tuesday, October 16, 2007 6:23 PM
> To: Don Provan
> Cc: [email-masked]
> it, so I