|
That change seems sensible. Steve, could you please incorporate that
change in the next rev of the draft. Thanks! - Mukesh From: Sowmya
Krishnaswamy [mailto:skrishna at checkpoint.com] 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: [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:
vrrp-bounces at ietf.org [mailto:vrrp-bounces at ietf.org] On Behalf Of Sowmya Krishnaswamy 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:dprovan at bivio.net] 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:
vrrp-bounces at ietf.org [mailto:vrrp-bounces at ietf.org] On Behalf Of Sowmya Krishnaswamy 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 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
|