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]> |
Thanks for clarifying the proposed behavior. So, even if VR_Type == 1, we will send Fast Advts. in certain cases. I was under the assumption that if we are configured as VR_Type ==1, then we will never send Fast Advts. So now, with your explanation, if VR_Mode == 1, then we will _always_ send both types of Advts. You might want to document this on page 9 that whenever VR_Mode is set to 1, we will have to start the Adver_Timer or Adver_2_Timer (depending on VR_Type). -- Sonum > -----Original Message----- > From: Hott, Robert W CIV B35-Branch [mailto:[email protected]] > Sent: Monday, February 06, 2006 3:28 PM > To: Mathur Sonum-CSM109; [email protected] > Subject: RE: [VRRP] 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