RE: How about one unified document?

Hi Don,

Thanks for responding to my strawman.  I agree with most of 
your suggestions, and have some comments & questions.  Please 
see inline, below. 

Regards,
Steve 

> -----Original Message-----
> From: Don Provan [mailto:[email protected]] 
> Sent: Monday, July 30, 2007 5:36 PM
> To: Stephen Nadas (RL/TNT); [email protected]
> Cc: 'Radia Perlman'
> Subject: RE: [VRRP] How about one unified document?
> 
> Hi, Steve,
> 
> First of all, I think the protocols themselves should be 
> entirely and completely ships in the night. BUT, I agree it 
> would not be that hard for a v3 protocol *implementation* to 
> support v2, and we should have a section describing those issues.
> 
> Combined v2/v3 support should, first of all, be presented as 
> being only for backwards compatibility during upgrading; 
> using it in a permanent situation should be discouraged.
> 

I agree.

> Consequently, I think the spec's advice should be simplistic: 
> an implementation MAY implement a configuration flag that 
> tells it to listen for and send both v2 and v3 
> advertisements. When configured this way and the master, it 
> MUST send both types at the configured rate, even if 
> sub-second. 

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.         
   
> When not master, it should time out based on the 
> rate advertised by the master -- I believe the v3 spec 
> already calls for this, except we want it to (when so 
> configured) adjust its timeout rate for v2 masters as well as or v3.
> 
> 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"?   

> 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?

> 
> And a system configured to listen to both v2 and v3 should 
> ignore v2 packets from the current master if it's also 
> getting v3 packets from it. Except it MAY report when a v3 
> master is *not* sending v2 packets: that suggests they don't 
> agree on whether they're supporting v2 routers.

I agree. 

> 
> One more thing: you mentioned VRRPv4 packets. Is that necessary?
> I'd assumed both IPv4 and IPv6 would carry VRRPv3 packets and 
> assume they're talking about the networking version that the 
> packets were sent over.

Yes, you are right of course. 

> 
> -don
> 
> > -----Original Message-----
> > From: Stephen Nadas (RL/TNT) [mailto:[email protected]]
> > Sent: Monday, July 30, 2007 1:12 PM
> > To: Don Provan; [email protected]
> > Cc: Radia Perlman
> > Subject: RE: [VRRP] How about one unified document?
> > 
> > 
> > Hi Don,
> > 
> > What do you (and the list) think of this approach for a world with 
> > both VRRPv2 vs. VRRPv3 on IPv4 networks.  It seems like either 
> > ships-in-the-night (SITN) or interoperate are the 
> possibilities. SITN 
> > is simpler, of course.  SITN by protocol design means VRRPv3 drops
[snipped]

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