RE: Reminder of posting of draft-ietf-vrrp-ipv4-timers-01.txt
"Mathur Sonum-CSM109" <[email protected]>
| Newsgroups | gmane.ietf.vrrp |
|---|---|
| Message-ID | <[email protected]> |
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