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