Re: Minor correction to algorithm in section 6.4.2

That change seems sensible.

Steve, could you please incorporate that change in the next rev of the draft.

Thanks!
- Mukesh

________________________________
From: Sowmya Krishnaswamy [mailto:[email protected]]
Sent: Monday, July 27, 2009 11:26 AM
To: Don Provan; Mukesh Gupta
Cc: [email protected]
Subject: RE: [VRRP] Minor correction to algorithm in section 6.4.2

Hi Don/Mukesh,

After reading your mails I understand the reason behind algorithm used in section 6.4.2.

I wanted to make sure that your point was explicitly stated in the draft so that implementers of the draft understand the reasoning as well. It's covered in Section 2.3:

2.3.  Minimization of Unnecessary Service Disruptions

   Once Master election has been performed then any unnecessary
   transitions between Master and Backup routers can result in a
   disruption in service.  The protocol should ensure after Master
   election that no state transition is triggered by any Backup router
   of equal or lower preference as long as the Master continues to
   function properly.

Thanks for the clarifications.

Regards,
Sowmya

________________________________
From: Mukesh Gupta [mailto:[email protected]]
Sent: Friday, July 24, 2009 5:14 PM
To: Sowmya Krishnaswamy; Don Provan
Cc: [email protected]
Subject: RE: [VRRP] Minor correction to algorithm in section 6.4.2

 [WG chair hat off]

Sowmya,

I agree with Don that IP address is not, and should not be treated as, a sub-priority.

The suggested change will make the Master election deterministic. However, it has the following disadvantages in the case that you described:

1)       There will be two Masters for a brief period of time. The router with lower priority (A) will become Master and send the advertisement. However, the router with the higher IP (B) will ignore the advertisements and will become Master. At this point, both the routers will be Masters. Only after router A processes the advertisement from router B, it will transition to the Backup state.
2)       There will be an additional failover as described above.

If the operator wants determinism, they should configure the priorities accordingly. With the current text in the draft, the protocol converges in all the cases and it also minimizes unnecessary failovers and dual Masters.

Regards
Mukesh

________________________________
From: [email protected] [mailto:[email protected]] On Behalf Of Sowmya Krishnaswamy
Sent: Friday, July 24, 2009 1:54 PM
To: Don Provan
Cc: [email protected]
Subject: Re: [VRRP] Minor correction to algorithm in section 6.4.2

I think it's best to keep the algorithm used by Backup in Section 6.4.2 consistent with that used by the Master in Section 6.4.3. I ran this past the author of RFC 3768 (Bob Hinden) and he concurs on this point.

________________________________
From: Don Provan [mailto:[email protected]]
Sent: Friday, July 24, 2009 1:42 PM
To: Sowmya Krishnaswamy
Cc: [email protected]
Subject: RE: [VRRP] Minor correction to algorithm in section 6.4.2

No, I deny that's an error. The IP address is not a sub-priority, it is simply a discriminator to decide which of two routers, both in master mode, should step down when they see each other. Once that has been resolved, regardless of how it happened, the two routers remain in their current state.
-don

________________________________
From: [email protected] [mailto:[email protected]] On Behalf Of Sowmya Krishnaswamy
Sent: Friday, July 24, 2009 11:10 AM
To: [email protected]
Subject: [VRRP] Minor correction to algorithm in section 6.4.2
Hi Steve,

There was a minor error in RFC 3768 which I think got carried over into the draft-ietf-vrrp-unified-spec-03.txt.



The VRRP election selects the VRRP router with the higher priority as the master and when the priorities of the VRRP routers are the same, the master is the VRRP router with highest IP address.



Let's take the case of 2 VRRP routers with equal priority (where priority is not 255) starting up at around the same time. As per the Section 6.4.1 both would start out in Backup state.

If the master down timer fires on the router with the lower IP addresses first, it would transition to Master state and send out an advertisement. If this VRRP advertisement is received by the other VRRP router while it's still in Backup state. As per Section 6.4.2 "if the priority in the advertisement is greater than or equal to the local priority then the master down timer is set to Master_Down_Interval". This effectively results in the router with the lower IP address remain in the master state.

This is inconsistent with the rule we would expect VRRP to use in electing the VRRP master.

The following section needs a minor re-write:

Section 6.4.2: Backup


- If an ADVERTISEMENT is received, then:

         + If the Priority in the ADVERTISEMENT is Zero, then:

            * Set the Master_Down_Timer to Skew_Time

         + else // pri non-zero

            * If Preempt_Mode is False, or If the Priority in the

            ADVERTISEMENT is greater than or equal to the local

            Priority, then:

               @ Set Master_Adver_Interval to Adver Interval contained

               in the ADVERTISEMENT.

               @ Recompute the Master_Down_Interval

               @ Reset the Master_Down_Timer to Master_Down_Interval

            * else // preempt was true or pri was less

               @ Discard the ADVERTISEMENT

            *endif // preempt test

         +endif // was pri zero?

-endif // was adv recv?

Section 6.4.2: Backup


- If an ADVERTISEMENT is received, then:

         + If the Priority in the ADVERTISEMENT is Zero, then:

            * Set the Master_Down_Timer to Skew_Time

         + else // pri non-zero

            * If Preempt_Mode is False, or If the Priority in the

            ADVERTISEMENT is greater than the local

            Priority, then:

               @ Set Master_Adver_Interval to Adver Interval contained

               in the ADVERTISEMENT.

               @ Recompute the Master_Down_Interval

               @ Reset the Master_Down_Timer to Master_Down_Interval

            * else // preempt was true or pri was less

               @ Discard the ADVERTISEMENT

            *endif // preempt test

         +endif // was pri zero?

-endif // was adv recv?

Thanks,
Sowmya


Scanned by Check Point Total Security Gateway.

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