RE: How about one unified document?

> I am a little concerned that a v3 sending at 1 centi-sec could  
> overwhelm a v2 with potentially unclear results.  But given the 
> previous paragraphs cautions about running this way during upgrade, 
> this should be a temporary condition so I am okay.  To me, it 
> seems prudent, in the upgrade cases, to initially run the v3 rtrs 
> with lower frequencies (eg 100 centi-sec) until the v2 rtrs are 
> upgraded.  Then, once one has convinced oneself that all is working, 
> unconfigure v2 support and then increase the vrrp v3 frequency as 
> desired.  Perhaps some description along these lines should go into 
> the draft.         

Good point. As I see it there are three reasonable possibilities:

1. v2 and v3 sent at the same rate, so the admin better be sure
the v2's aren't overwhelmed. One way to help avoid the v2's being
overwhelmed is to suggest the upgrade procedure you described:
keeping the v3 nodes at or close to second rates until the v2's
are gone.

2. v3 sent at rate, v2 sent at the configured rate rounded up to
seconds. This doesn't completely avoid the problem of overwhelming
v2 nodes, but it reduces the overhead to spotting the version in
order to reject the packet. I didn't mention this approach before
because #1 is simpler to implement, and I definitely see no reason
to recommend multiple possibilities.

3. Simply say that v2 cannot share a VR with v3.

I think these are all perfectly valid, so I'm OK with any of these
so long as we pick just *one* and stick with it. Currently, I still
think #1 is best, with the warning about v2 overhead and your
suggestion of lower rates during the transition. As long as
this is just a suggested practices section, we don't have to be
too rigid about the details, particularly as long as we're clear
that the v2/v3 node should do nothing that would break the v2
protocol. (hmmmm.... now that I said that, perhaps #2 is the
right choices....)

> > At the same time, I'm not too comfortable with a slow master, 
> > so we should recommend against configuring a VR with one 
> > router using a slower transmit rate then the others but a 
> > higher priority. 
> 
> I agree that don't understand the rationale for the normal 
> master (highest priority) to run at, say, 20 centisec, but when it 
> fails the backup that takes over runs at 10 centisec.  Is this what 
> you mean by "not too comfortable"?   

Yes, that's what I meant. My mental experiments tells me that
higher priority nodes with slower transmission rates are
unstable because low priority nodes configured to faster rates
could come on line and decide they should be masters before they
heard anything from the higher priority master with a slower rate.
I think the spec still claims differing rates are a mistake even
though the protocol can now deal with them, so I probably
shouldn't have brought this up, but I couldn't help myself because
I'm a big fan of differing rates, so long as the rates are in
priority order. It really has nothing to do with IPv4 in v3....

> > The
> > v2 router interacting with a sub-second v3 router is the most 
> > important example of that, of course. In fact, I'd have no 
> > problem prohibiting this kind of configuration if 
> everyone's willing.
> 
> I think that I am missing something here.  How would we prohibit 
> "this kind of configuration"?  Is this back to your 1st paragraph?

By "prohibit", I just meant put something into the v2 section
along the lines of "A v2-only implementation should *never* be
given a higher priority than a v2/v3 implementation it is
interacting with if the v2/v3 rate is subsecond."

-don

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