RE: draft-ietf-vrrp-unified-spec-00 issues

Hi Don, 

1st subject: 

What I think Steve is saying is: "We are seeing more and more requests
to support rates of failure detection this draft addresses but it seems
likely that in another decade, with terabit speed links for example,
that we will see demands for failure detection 100 times faster than we
currently address." 

100x faster than 3 centisec is 3*10-4 (tenths of millisec).  So he
proposed 4 bits to signal 10**0->10**-15, which sure seems like overkill
to me.  Also this doesn't work completely correctly (nor does my earlier
suggestion of 10E-7) bcos Max_Adver_Int needs more bits to signal the
full range.   

Right now we signal 1-4096 centisec, a range of 1 centisec to 40 sec.
If units are 10**-4, the range possible is 1 tenth of ms -> .4 sec (I
don't like that this because it cannot _simply_ signal 1 sec).     

I think WG has been here already (read archives around 27 Jul 2006.)  My
memory is that there was not much enthuasism to make the vrrp header
wider to fully represent, say microsec.  In the end, I think we
concluded that centisec was fast enough for version 3 and if faster was
needed then version 4 would come.  Steve is pushing back on this point.


So, if WG feels centisec is not future proof enough, let me suggest:  

make Max_Adver_Int all 16 bits and fix the the units at 10E-4.  
- Steve has tenths of millisec resolution (100x faster than today) 
- you have 1 unit (no granularity is signalled).
For 10E-4 the possible signalled range is 1*10E-4 sec --> 6.5 sec.  

Or make Max_Adver_Int all 16 bits and fix units at 10E-3
- Steve has millisec resolution (10x faster than today) 
- you have 1 unit (no granularity is signalled).
and signalled range is 1 millisec -> 65 sec.  

I can live with either; if forced, I prefer the latter (otherwise I
prefer original agreement).  Beyond this we need a floating point format
or more bits.

In any case I would like to hear whether from WG whether centisec is not
future proof enough.  

For the list: Please Note That Silence Means No Change Is Needed (ie
centisec granularity is ok).  

2nd subject: 

I completely agree with you. 

Thanks,
Steve  

Stephen Nadas                           Ericsson IPI       
[email protected] (eudstna)    920 Main Campus Dr. 
Voice:  +1-919-472-9935 Fax: x/9999     Suite 500 
Mobile: +1-919-522-0991 ECN: 802 29935  Raleigh, NC 27606
 
 

> -----Original Message-----
> From: Don Provan [mailto:[email protected]] 
> Sent: Monday, January 14, 2008 3:04 PM
> To: Stephen Nadas; 'Steve Bates'
> Cc: [email protected]
> Subject: RE: [VRRP] draft-ietf-vrrp-unified-spec-00 issues
> 
> I don't have a good feel for the rate issue, but I dislike 
> unnecessary complication. Historically, the VRRP failover 
> time has been dominated by the protocol's increased overhead 
> at smaller times, but at some point the time starts to be 
> dominated by the time it takes for the infrastructure to 
> adjust to a failover such as switch learning and spanning 
> tree. The question is this: "Is the 3 centisecond limit for 
> failover time approaching the point at which the time it 
> takes the infrastructure to adjust is more significant?"
> Would simply reducing the units to milliseconds or tenths of 
> milliseconds -- certainly possible within the field, 
> particularly if we use the reserved bits -- get us down to 
> that point? If so, I would prefer that to having a 
> variable/scaled interval. Scaling was proposed earlier, and 
> my vague recollection is that it was rejected, but I don't 
> recall who rejected it or why.
> 
> Having said that, I don't really mean to argue against 
> scaling. I'm just raising considerations and will happily 
> join any consensus.
> 
> On the second subject, I'm not sure exactly what you're 
> thinking of as what Steve proposed as an alternative behavior.
> The suggestion I recall involved the backup sending an 
> advertisement, fully realizing it should be the backup.
> I definitely don't support that idea. On the other hand, if 
> he just wants to make his configuration so that the backup 
> issues an alarm and then drops out of the VR if the master's 
> interval is too short for the backup to handle, I don't have 
> a problem with that.
> 
> -don

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