Subject: RE: [VRRP] Subsecond Timers for VRRPv3

From: Mathur Sonum-CSM109 <[email-masked]>
Date: Fri, 15 Aug 2003 15:10:54 -0500

We are in favor of 1/10 second. It is definitely a good idea to include this in the new version of VRRP for IPv4 and get it standardised. One suggestion to do this is to use one of the unused bits in the packet. The bit setting can indicate that the units in Advert Int are in seconds or in 1/10th of second. 

--
Sonum

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Friday, August 15, 2003 10:43 AM
> To: [email-masked]
> Subject: [VRRP] Subsecond Timers for VRRPv3
> 
> 
> Folks,
> 
> In the WG meeting in Vienna, we all agreed that the 
> sub-second timers should be allowed at least in VRRPv3 
> but we couldn't agree about the granularity of the 
> advertizing interval for allowing them.
> 
> There were concerns that if we allow the advertizing
> intervals in miliseconds, it will allow the user to
> bombard the LAN with VRRP packets which is dangerous.
> 
> Advertizing intervals in the units of 1/10 seconds
> or 1/100 seconds seemed like good choices.
> 
> We would like to know what is everyone's opinion 
> about this. Please reply with your preference.
> 
> 1) 1/10 second
> 2) 1/100 second
> 3) 1/1000 second (miliseconds)
> 
> regards
> Mukesh
> 
> _______________________________________________
> vrrp mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/vrrp
> 

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

---

From: Bob Hinden <[email-masked]>
Date: Fri, 15 Aug 2003 13:21:42 -0700

Sonum,

At 01:10 PM 8/15/2003, Mathur Sonum-CSM109 wrote:

>We are in favor of 1/10 second. It is definitely a good idea to include 
>this in the new version of VRRP for IPv4 and get it standardised. One 
>suggestion to do this is to use one of the unused bits in the packet. The 
>bit setting can indicate that the units in Advert Int are in seconds or in 
>1/10th of second.

But unless the version was changed, a receiver who didn't know about the 
change would not know to look at that bit and there would be 
interoperabiltiy and/or stability problems.  Might as well just redefine 
the value to be  1/10 of second in a new version.

Bob

---

From: [email-masked]
Date: Mon, 18 Aug 2003 20:33:05 -0500

> I haven't heard that the interval field is expanding, and it
> sounds as if we're avoid making the unit variable. In that case,
> 1/1000 seems wrong because the max interval is now 1/4 of a
> second. And 1/100 doesn't seem that much better, capping at 2.55
> seconds. So that would lead me to 1/10, but is this small enough
> to satisfy the requirement? I know the goal is faster failovers,
> but I don't recall if a minimum target was set.

After the removal of the security in VRRPv3, the auth type field 
(just before the Adver Int field) is now a reserved field. So we
have room for expanding the Advertising Interval to 2 bytes. That
will give us a range of 1 msec to 65 seconds if we choose 1/1000,
10 msec to 650 seconds. On the other hand, if we choose 1/10, we
can let the Advert Int field be 1 byte and have the range 100 msec
to 25 seconds.

So if we are convinced that we should go for 1/1000, we can go 
forward with it.

regards
Mukesh

---

From: Mathur Sonum-CSM109 <[email-masked]>
Date: Mon, 18 Aug 2003 21:06:51 -0500

We had a requirement to get failover time in the order of hundreds of milli seconds. But to keep the system interoperable with existing implementations, the check for milliseconds granularity is ignored in our implementation right now. If the router is configured for Advt Interval of 100 msecs, it would send value = 0 in the 1 byte Advt Interval field of the packet. This will be same for configured value of 100 to 900 msecs. 

If we have this requirement of minimum failover time in some milliseconds, then we need to either expand the field or use some of the unused bits in the packet. That leads to this question - what is the minimum failover time that we want to set in the standards ? We are ok with 100 msecs.

--
Sonum

> Sent: Monday, August 18, 2003 5:33 PM
> To: Sonum Mathur; [email-masked]
> Subject: RE: [VRRP] Subsecond Timers for VRRPv3
> 
> 
> Hi Sonum,
> 
> Would you please specify the reasoning behind your favor of 
> 1/10 second ?
> 
> Folks,
> 
> We have just received 2 mail with the preferences; one 
> with 1/10 and the other with 1/1000. It will be hard to make 
> the decision without knowing preferences from enough people.
> 
> Please respond with your choice and the reason behind that.
> 
> regards
> Mukesh
> 
> > From: ext Mathur Sonum-CSM109 [mailto:[email-masked]]
> > Sent: Friday, August 15, 2003 1:11 PM
> > To: Gupta Mukesh (IPRG/MtView); [email-masked]
> > Subject: RE: [VRRP] Subsecond Timers for VRRPv3
> > 
> > 
> > 
> > We are in favor of 1/10 second. It is definitely a good idea 
> > to include this in the new version of VRRP for IPv4 and get 
> > it standardised. One suggestion to do this is to use one of 
> > the unused bits in the packet. The bit setting can indicate 
> > that the units in Advert Int are in seconds or in 1/10th of second. 
> > 
> > --
> > Sonum
> >

---

From: "Karen O'Donoghue" <[email-masked]>
Date: Thu, 21 Aug 2003 10:47:37 -0400

My apologies for the delay in speaking up.  It required a
bit of prodding...  I am trying to take time off this
week...

 > since I missed the working group meeting and
 > didn't see explicit justification for this decision
 > in the meeting minutes I'm wondering if someone
 > could summarize the justification for this feature?

The US Navy has a shipboard application where we need subsecond
timers for survivability.  We currently have a solution that
uses HSRP tuned to meet these requirements.  We would like to
be able to deploy the same solution using vrrp (as an open
standard). We understand that there are other components
that are required to give us the full capability that we
require. We also understand that this approach should be
used with caution.

 > I don't have the paper right here in front of
 > me, but the original vrrpv2 design incorporated
 > findings from the higginson&shand DEC TR referenced
 > in the RFC.  a simple picture showing
 > a generalized internetwork, illustrating where
 > failures could occur in end-to-end connectivity,
 > and then expected recovery interval for typical
 > IETF standardized protocols.  basically illustrated
 > that protocol recovery on the order of seconds
 > was inline with Internet standards.

We understand that our application is not a typical
use of these protocols, but we need
to be able to survive any single fault transparently to
the application.

Mukesh has suggested a draft that addresses the
requirements for this capability along with options
and interoperability issues.  Perhaps as part of this
draft we can revisit the above discussion.  I have
agreed to help put this draft together, and I am
happy to accept assistance!

Regards,
Karen

 > have these findings changed?  is there a movement
 > toward end-to-end connectivity containing only
 > vrrp ``routing'' and L2 with transparent, sub-second
 > recovery?
 >
 > later,danny

-- 
************************************************************
Karen O'Donoghue
Code B35, NSWCDD, 17320 Dahlgren Rd., Dahlgren, VA 22448
+1-540-653-1567 (voice)
+1-540-653-8673 (fax)
+1-540-729-7509 (cell)
[email-masked]

---

From: "Karen O'Donoghue" <[email-masked]>
Date: Thu, 21 Aug 2003 10:02:30 -0400

Regards,
Karen