Subject: [VRRP] Reminder of posting of draft-ietf-vrrp-ipv4-timers-01.txt

From: "Hott, Robert W CIV B35-Branch" <[email-masked]>
Date: Thu, 19 Jan 2006 08:55:36 -0600

All,
	This is just a reminder that the draft for providing sub-second timers for VRRP for IPv4 was posted. I would appreciate any comments that you might have on this draft.

Abstract: The router survivability capability provided by the Virtual Router Redundancy Protocol for IPv4 (VRRPv4) satisfies the requirements for many LAN environments. There are, however, LAN environments that have sub-second failover requirements and thus a need for finer granularity of the VRRP timers. This draft proposes extensions to VRRPv4 [RFC 3768] for specifying sub-second Advertisement Intervals. A new message type is introduced which permits the timer granularity for the Advertisement Interval to be specified. In addition, a new field is introduced permitting the specification of the number of missed ADVERTISEMENTs before a Virtual Router Master is declared down. 

Bob Hott 

Robert (Bob) W. Hott
NSWC-DD
Code B35, Bldg. 1500A/122A
17320 Dahlgren Road
Dahlgren, VA 22448-5100
540-653-1497 (W)
540-653-8673 (FAX)
[email-masked] (E-mail)

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

---

From: "Mathur Sonum-CSM109" <[email-masked]>
Date: Tue, 24 Jan 2006 19:43:35 -0500

Few comments on the draft

      If the VR_Mode = 1, then:
        o  Send an ADVERTISEMENT
        o  Set the Adver_Timer to Advertisement_Interval
       else:
        o  Send a FAST ADVERTISEMENT
        o  Set the Adver_2_Timer to Advertisement_Interval
 
For initialization, when VR_Mode = 1, then why are Fast Advts. not sent.
VR_Mode = 1 indicates that both types of VRRP implementations are
present. Then, to satisfy the backup routers with newer implementation,
Fast Advts. are needed. If not, they will declare Master Down and will
try to become Master causing more than one Masters to be active.
 
 -  If the Adver_2_Timer fires, then:
       If the VR_Mode is 1
       or
       if the VR_Type is 2, then:
        o  Send a FAST ADVERTISEMENT
        o  Reset the Adver_2_Timer to VR_Adver_Interval
 
When Adver_2_Timer fires, and VR_Type configured on the local router is
2, then local router should send a Fast Advt. Why do we need a check for
VR_Mode == 1 at all ? In my opinion, the only check for sending Fast
Advt should be VR_Type == 2. Please clarify.
 
I would like to suggest removal of parameter 'VR_Mode'.  If there is a
situation of new implementation inter operating with older one, we can
live with ignore and log. Although 'VR_Mode' takes care of this issue,
but implementation would be relatively simpler if we don't consider the
heterogeneous environment. This is just my opinion, if this topic is
still open for discussion.

--
Sonum 

________________________________

	From: [email-masked] [mailto:[email-masked]] On
Behalf Of Hott, Robert W CIV B35-Branch
	Sent: Thursday, January 19, 2006 6:56 AM
	To: [email-masked]
	Subject: [VRRP] Reminder of posting of
draft-ietf-vrrp-ipv4-timers-01.txt

	All, 
	        This is just a reminder that the draft for providing
sub-second timers for VRRP for IPv4 was posted. I would appreciate any
comments that you might have on this draft.

	Abstract: The router survivability capability provided by the
Virtual Router Redundancy Protocol for IPv4 (VRRPv4) satisfies the
requirements for many LAN environments. There are, however, LAN
environments that have sub-second failover requirements and thus a need
for finer granularity of the VRRP timers. This draft proposes extensions
to VRRPv4 [RFC 3768] for specifying sub-second Advertisement Intervals.
A new message type is introduced which permits the timer granularity for
the Advertisement Interval to be specified. In addition, a new field is
introduced permitting the specification of the number of missed
ADVERTISEMENTs before a Virtual Router Master is declared down. 

	Bob Hott 

	Robert (Bob) W. Hott 
	NSWC-DD

---

From: "Hott, Robert W CIV B35-Branch" <[email-masked]>
Date: Thu, 26 Jan 2006 07:29:34 -0600

Sonum,
	Thank you for your comments on the draft. I have included my response to your comments in-line.

Bob Hott

-----Original Message-----
From: Mathur Sonum-CSM109 [mailto:[email-masked]]
Sent: Tuesday, January 24, 2006 19:44
To: Hott, Robert W CIV B35-Branch; [email-masked]
Subject: RE: [VRRP] Reminder of posting of

 
 
<Bob Hott> This is a good observation. You caught an error in the draft. The "VR_Mode" in the IF statement, above and on page 8 in the draft, should have been "VR_Type"! During initialization, the VRRP router, when it is the Master, should send out the type of advertisement that it is configured to send. Thank you for catching this error.

 
<Bob Hott> For the above comment, this test is on pages 12 and 13 of the draft. I believe that we should have both tests following the firing of the Adver_2_Timer. It is possible that the VRRP router, although running this new implementation, would be configured to run as an older version (possibly to use authentication). Thus it should check to see if the VR_Mode is 1 (heterogeneous).

<Bob Hott> If you are in an environment in which a new implementation is interoperating with an older implementation, if the new implementation only logs and ignores the older implementation, then you run the risk of having two masters. If the new implementation is supposed to be the Master, it must force the older implementation to transition to a backup state. The older implementation will ignore the new FAST ADVERTISEMENTS, thus it will want to transition to Master, unless it sees an ADVERTISEMENT from the new implementation Master. For this reason, I don't think you want to ONLY ignore and log.

--
Sonum 

	All, 

	Bob Hott 

	Robert (Bob) W. Hott 
	NSWC-DD

---

From: "Mathur Sonum-CSM109" <[email-masked]>
Date: Thu, 26 Jan 2006 20:14:40 -0500

Comments inline

> When Adver_2_Timer fires, and VR_Type configured on the local 
> router is 2, then local router should send a Fast Advt. Why 
> do we need a check for VR_Mode == 1 at all ? In my opinion, 
> the only check for sending Fast Advt should be VR_Type == 2. 
> Please clarify.
>  
> <Bob Hott> For the above comment, this test is on pages 12 
> and 13 of the draft. I believe that we should have both tests 
> following the firing of the Adver_2_Timer. It is possible 
> that the VRRP router, although running this new 
> implementation, would be configured to run as an older 
> version (possibly to use authentication). Thus it should 
> check to see if the VR_Mode is 1 (heterogeneous). 

The 'or' condition is ok for Adver_Timer and is not needed for
Adver_2_Timer. We need to send regular Advt. when we are configured as
old version (VR_Type = 1) or when environment is heterogeneous (VR_Mode
= 1). For Fast Advt., we need to send it only when we are configured as
new version (VR_Type = 2). The truth table can look something like this

Type	Mode 	
1	0	Advt only
1	1	Advt only
2	0	Fast Advt only
2	1	Advt & Fast Advt

If a router (with new implementation) is configured to run as older
version (VR_Type = 1), then why do we want to send Fast Advt. at all
from this router ? We should never have the case of 'Adver_2_Timer'
firing at all when VR_Type = 1.  Once you make the correction of
changing VR_Mode to VR_Type on Page 8 for initialization, if VR_Type =
1, then we will set only Adver_Timer and won't touch Adver_2_Timer.
Correct me if I am not understanding this right and correct the table
accordingly.

Also, in initialization, if VR_Mode == 1 and VR_Type == 2, then we want
to send and trigger timers for both - Advt. and Fast Advt. So we will
need a check for VR_Mode in initialization also.

To avoid confusion, it might be a good idea to rename 'VR_Mode' or
'VR_Type' (or both). They can be renamed to something like VR_Conf (for
type) and VR_Envt (for mode) - just a suggestion.

> <Bob Hott> If you are in an environment in which a new 
> implementation is interoperating with an older 
> implementation, if the new implementation only logs and 
> ignores the older implementation, then you run the risk of 
> having two masters. If the new implementation is supposed to 
> be the Master, it must force the older implementation to 
> transition to a backup state. The older implementation will 
> ignore the new FAST ADVERTISEMENTS, thus it will want to 
> transition to Master, unless it sees an ADVERTISEMENT from 
> the new implementation Master. For this reason, I don't think 
> you want to ONLY ignore and log.

Agreed. We will need this if we want to make it backward compatible.

--
Sonum

> From: Hott, Robert W CIV B35-Branch [mailto:[email-masked]] 
> Sent: Thursday, January 26, 2006 5:30 AM
> To: Mathur Sonum-CSM109; [email-masked]
> 	Thank you for your comments on the draft. I have 
> included my response to your comments in-line.
> 
> Bob Hott
> 
> VR_Mode = 1 indicates that both types of VRRP implementations 
> are present. Then, to satisfy the backup routers with newer 
> implementation, Fast Advts. are needed. If not, they will 
> declare Master Down and will try to become Master causing 
> more than one Masters to be active.
>  
> <Bob Hott> This is a good observation. You caught an error in 
> the draft. The "VR_Mode" in the IF statement, above and on 
> page 8 in the draft, should have been "VR_Type"! During 
> initialization, the VRRP router, when it is the Master, 
> should send out the type of advertisement that it is 
> configured to send. Thank you for catching this error.
> 
> 
> 
> When Adver_2_Timer fires, and VR_Type configured on the local 
> router is 2, then local router should send a Fast Advt. Why 
> do we need a check for VR_Mode == 1 at all ? In my opinion, 
> the only check for sending Fast Advt should be VR_Type == 2. 
> Please clarify.
>  
> <Bob Hott> For the above comment, this test is on pages 12 
> and 13 of the draft. I believe that we should have both tests 
> following the firing of the Adver_2_Timer. It is possible 
> that the VRRP router, although running this new 
> implementation, would be configured to run as an older 
> version (possibly to use authentication). Thus it should 
> check to see if the VR_Mode is 1 (heterogeneous).
> 
> 
> I would like to suggest removal of parameter 'VR_Mode'.  If 
> there is a situation of new implementation inter operating 
> with older one, we can live with ignore and log. Although 
> 'VR_Mode' takes care of this issue, but implementation would 
> be relatively simpler if we don't consider the heterogeneous 
> environment. This is just my opinion, if this topic is still 
> open for discussion.
> 
> <Bob Hott> If you are in an environment in which a new 
> implementation is interoperating with an older 
> implementation, if the new implementation only logs and 
> ignores the older implementation, then you run the risk of 
> having two masters. If the new implementation is supposed to 
> be the Master, it must force the older implementation to 
> transition to a backup state. The older implementation will 
> ignore the new FAST ADVERTISEMENTS, thus it will want to 
> transition to Master, unless it sees an ADVERTISEMENT from 
> the new implementation Master. For this reason, I don't think 
> you want to ONLY ignore and log.
> 
> --
> Sonum 
> 
> 
> 	From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Hott, Robert W 
> CIV B35-Branch
> 	        This is just a reminder that the draft for 
> providing sub-second timers for VRRP for IPv4 was posted. I 
> would appreciate any comments that you might have on this draft.
> 
> 	Abstract: The router survivability capability provided 
> by the Virtual Router Redundancy Protocol for IPv4 (VRRPv4) 
> satisfies the requirements for many LAN environments. There 
> are, however, LAN environments that have sub-second failover 
> requirements and thus a need for finer granularity of the 
> VRRP timers. This draft proposes extensions to VRRPv4 [RFC 
> 3768] for specifying sub-second Advertisement Intervals.
> A new message type is introduced which permits the timer 
> granularity for the Advertisement Interval to be specified. 
> In addition, a new field is introduced permitting the 
> specification of the number of missed ADVERTISEMENTs before a 
> Virtual Router Master is declared down. 
> 
> 	Bob Hott 
> 
> 	Robert (Bob) W. Hott 
> 	NSWC-DD