RE: Reminder of posting of draft-ietf-vrrp-ipv4-timers-01.txt

Sonum,
	I apologize for taking so long to get back to this thread. I have given some thought to your discussion for the need to test for VR_Mode == 1 in the Master state. I believe that it is needed. I will attempt to explain why. Suppose that the router is configured to operate using the standard mode (VR_Type = 1) and therefore use ADVERTISEMENTS. If it is the MASTER, it sends the ADVERTISEMENT, assumes VR_Mode == 0 (everybody is using ADVERTISEMENTs), sets Adver_Timer, and transitions to the MASTER state. Now in the MASTER state, if we hear a new router come on line that uses FAST ADVERTISEMENTS, we start sending FAST ADVERTISEMENTS (and setting the Adver_2_Timer) to make it move to BACKUP state, unless it should become the Master. In either case, VR_Mode is now 1.

	The router could also get into the VR_Mode == 1 while in the BACKUP state, if originally in VR_Type = 1 and not a Master. While in the BACKUP state, it hears a FAST ADVERTISEMENT and thus enters VR_Mode = 1. If it were ever to become Master, it would send both types of advertisements and set the timers for both.

Bob Hott

-----Original Message-----
From: Mathur Sonum-CSM109 [mailto:[email protected]]
Sent: Thursday, January 26, 2006 20:15
To: Hott, Robert W CIV B35-Branch; [email protected]
Subject: RE: [VRRP] Reminder of posting of
draft-ietf-vrrp-ipv4-timers-01.txt


Comments inline

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


> -----Original Message-----
> From: Hott, Robert W CIV B35-Branch [mailto:[email protected]] 
> Sent: Thursday, January 26, 2006 5:30 AM
> To: Mathur Sonum-CSM109; [email protected]
> Subject: RE: [VRRP] Reminder of posting of 
> draft-ietf-vrrp-ipv4-timers-01.txt
> 
> 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 protected]]
> Sent: Tuesday, January 24, 2006 19:44
> To: Hott, Robert W CIV B35-Branch; [email protected]
> Subject: RE: [VRRP] Reminder of posting of 
> draft-ietf-vrrp-ipv4-timers-01.txt
> 
> 
> 
> 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.
>  
> <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.
> 
> 
> 
>  -  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.
>  
> <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 protected] 
> [mailto:[email protected]] On Behalf Of Hott, Robert W 
> CIV B35-Branch
> 	Sent: Thursday, January 19, 2006 6:56 AM
> 	To: [email protected]
> 	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 
> 	Code B35, Bldg. 1500A/122A 
> 	17320 Dahlgren Road 
> 	Dahlgren, VA 22448-5100 
> 	540-653-1497 (W) 
> 	540-653-8673 (FAX) 
> 	[email protected] (E-mail) 
> 

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