gmane.ietf.vrrp

Re: Proposal for Maintenance Event for VRRP [RFC-5798]

Adrian Farrel — 2013-05-22T16:12:05

Hi,

If you are wondering how to progress this in the IETF, the answer is...

- write an I-D
- discuss it (here)
- polish it
- ask me to sponsor it for publication as an RFC.

Cheers,
Adrian

application) is to
this a
will now
a
then I
change in
manner
have
e-
any

_______________________________________________
vrrp mailing list
vrrp< at >ietf.org
https://www.ietf.org/mailman/listinfo/vrrp

draft-zhou-pim-vrrp-01

Adrian Farrel — 2013-05-22T16:10:45

Hello VRRP list,

Please be aware of this work in the PIM working group and comment there if you
have an opinion.

Thanks,
Adrian


_______________________________________________
vrrp mailing list
vrrp< at >ietf.org
https://www.ietf.org/mailman/listinfo/vrrp

Biggest Fake Conference in Computer Science

2013-04-27T17:54:57

We are researchers from different parts of the world and conducted a study on  
the world’s biggest bogus computer science conference WORLDCOMP 
( http://sites.google.com/site/worlddump1 ) organized by Prof. Hamid Arabnia 
from University of Georgia, USA.


We submitted a fake paper to WORLDCOMP 2011 and again (the same paper 
with a modified title) to WORLDCOMP 2012. This paper had numerous 
fundamental mistakes. Sample statements from that paper include: 

(1). Binary logic is fuzzy logic and vice versa
(2). Pascal developed fuzzy logic
(3). Object oriented languages do not exhibit any polymorphism or inheritance
(4). TCP and IP are synonyms and are part of OSI model 
(5). Distributed systems deal with only one computer
(6). Laptop is an example for a super computer
(7). Operating system is an example for computer hardware


Also, our paper did not express any conceptual meaning.  However, it 
was accepted both the times without any modifications (and without 
any reviews) and we were invited to submit t

Re: Proposal for Maintenance Event for VRRP [RFC-5798]

Anurag Kothari (ankothar — 2013-03-04T23:43:27

Hi Sreenatha

If you mean "if I am not wrong" then yes what you have said below is correct.

Also I believe the objective (particularly in case of time sensitive application) is to avoid any unnecessary switch overs; as already suggested earlier let's call this a "Change Event" instead of "Maintenance Event". The "Change Event" would be triggered by change in one of the following parameters of the VRRP Packet :

1) Priority (Section 5.2.4. of RFC-5798)
2) Max Adver Int (Section 5.2.7. of RFC-5798)

And possibly:

3) IPvX Address(es) (Section 5.2.9.  of RFC-5798)

The "Change Event" would only be handled in Master State and ignored in other state as the VRRP Packets are only supposed to be sent by the Master.

So to rephrase the proposal:

    - If a Change event is received, then:

    + Send an ADVERTISEMENT

    + Reset the Adver_Timer to Advertisement_Interval

    -endif // Change recv

To cover the failover scenario (in the absence of preemption) Priority = 0 will now have to be allowed along with the p

Re: Proposal for Maintenance Event for VRRP [RFC-5798]

sreenatha — 2013-03-02T08:17:07

Hi Anurag,
     Thanks for clarification.

      If i am wrong, user is allowed to configure Priority value as 
zero(i.e., Maintenance_Event), priority value will be changed. And 
handling of the Maintenance_Event is done only in Master state and 
ignored in Backup and Init state.

Thanks,
Sreenatha

On 03/01/2013 08:31 PM, Anurag Kothari (ankothar) wrote:

Disclaimer : 
This email communication may contain privileged and confidential information and is intended for the use of the addressee only.If you are not an intended recipient you are requested not to reproduce, copy disseminate or in any manner distribute this email communication as the same is strictly prohibited. If you have received this email in error, please notify the sender immediately by return e-mail and delete the communication sent in error. Email communications cannot be guaranteed to be secure & error free and IB Technology is not liable for any errors in the email communication or for the proper, timely and complete transmission thereof.

Re: Proposal for Maintenance Event for VRRP [RFC-5798]

Anurag Kothari (ankothar — 2013-03-01T15:01:42

Hi Sreenatha

I don't think we need to define a "Maintenance_Event" when the router is in either Init or Backup State. The intention of the "Maintenance_Event" is to trigger a failover from "Master" to a "Backup" router as soon as possible (especially when preemption is not configured).

But if you are asking if priority = 0 should be allowed (either by user configuration or dynamically) when the router is in "Init" or "Backup" state then I think the answer should be yes, It should be treated just like any other change in priority is treated when the router is in these states.

Please let me know if I am missing something.

Thanks
-Anurag

From: sreenatha [mailto:sreenatha.setty< at >ibtechnology.com] 
Sent: Friday, March 01, 2013 12:03 AM
To: Anurag Kothari (ankothar)
Cc: vrrp< at >ietf.org
Subject: Re: Proposal for Maintenance Event for VRRP [RFC-5798]

Hi Anurag,
    One more point on original proposal of handling Maintenance Event. 

Whether "Maintenance_Event" from user is allowed only in Master state or any o

Re: Proposal for Maintenance Event for VRRP [RFC-5798]

sreenatha — 2013-03-01T05:02:37

Hi Anurag,
     One more point on original proposal of handling Maintenance Event.

Whether "Maintenance_Event" from user is allowed only in Master state or 
any other state?

If Maintenance_Event comes in other state(Init or Backup) apart from the 
Master state, what would be the behaviour of the router?

This point also we need to take care.

Thanks,
Sreenatha Setty


On 03/01/2013 01:31 AM, Anurag Kothari (ankothar) wrote:

Disclaimer : 
This email communication may contain privileged and confidential information and is intended for the use of the addressee only.If you are not an intended recipient you are requested not to reproduce, copy disseminate or in any manner distribute this email communication as the same is strictly prohibited. If you have received this email in error, please notify the sender immediately by return e-mail and delete the communication sent in error. Email communications cannot be guaranteed to be secure & error free and IB Technology is not liable for any errors in the email comm

Re: Proposal for Maintenance Event for VRRP [RFC-5798]

Anurag Kothari (ankothar — 2013-02-28T20:01:29

Hi Sreenatha

Totally agree with your observation.

Also as pointed out by some other participants the additional backup router in my original analysis will never become master on seeing the first ADVERTISEMENT with priority zero as it will keep resetting it's Master_Down_Timer to Skew_Time in the storm of ADVERTISEMENTs with zero priority and the Master_Down_Timer will never fire for the additional backup router.

Thanks
-Anurag

P.S. Noticed the typos: the additional lines in my email should be numbered 706 and 707 (instead of 701 and 702) and probably yours should be 426 and 427 (instead of 421 and 422).

From: sreenatha [mailto:sreenatha.setty< at >ibtechnology.com]
Sent: Thursday, February 28, 2013 11:39 AM
To: vrrp< at >ietf.org
Cc: Anurag Kothari (ankothar)
Subject: Re: Proposal for Maintenance Event for VRRP [RFC-5798]

Hi Anurag,
    Modification to algorithm is correct. But this modification is taking care only when Router is in Master state.
What about if Backup router(priority value is zero) receives ADVER

Re: Proposal for Maintenance Event for VRRP [RFC-5798]

sreenatha — 2013-02-28T16:38:45

Hi Anurag,
     Modification to algorithm is correct. But this modification is 
taking care only when Router is in Master state.
What about if Backup router(priority value is zero) receives 
ADVERTISEMENT message with priority value as zero?

Same condition we will consider, where both VRRP routers priority is set 
to zero, and both sending ADVERTISEMENT messages with priority as zero. 
According to new modification any one router, lets take "Router A", will 
remain in Master state and other router, lets say "Router B", will 
transit to Backup state.

Now according to RFC-5798:
When "Router B" is in Backup state,

(420) - If an ADVERTISEMENT is received, then:

          (425) + If the Priority in the ADVERTISEMENT is zero, then:

             (430) * Set the Master_Down_Timer to Skew_Time

          (440) + else // priority non-zero

So this lead to Master_Down_Timer to expire soon.

Again in Backup state,
(365) - If the Master_Down_Timer fires, then:

          (370) + Send an ADVERTISEMENT

Re: Proposal for Maintenance Event for VRRP [RFC-5798]

Anurag Kothari (ankothar — 2013-02-26T15:13:51

Some concerns have been raised regarding the following situation / Corner Case:
Due to congestion or some other fault in the network the ADVERTISEMENTs from the Master router do not reach backup router(s). The Master_Down_timer fires and one of the back router transitions to Master State at the same time the priority of this router and the original Master is set to zero. How would the network behave in this case?

For sure the probability of this happening would be very low (as it is a double/multiple fault situation). Here is my analysis of the situation and solution for the same.

We will have two Master routers both sending ADVERTISEMENTs with Priority = 0. This will create a vicious circle of sending ADVERTISEMENTs (one router triggering the other) at a fast rate. This would also cause the Virtual MAC to shuttle continuously between two ports on the switch(es) at a fast rate. Both of these can probably cause high CPU utilization on the router and the LAN Switches.

If there is an additional backup router

Re: vrrp Digest, Vol 81, Issue 3

Anurag Kothari (ankothar — 2013-02-25T16:24:44

Hi Thirumavalavan

Yes the priority zero router will become backup on receiving the ADVERTISEMENT from other router which would have transitioned to Master.

Thanks
-Anurag

From: Thirumavalavan Periyannan [mailto:tperiyannan< at >extremenetworks.com]
Sent: Monday, February 25, 2013 11:19 AM
To: Anurag Kothari (ankothar); vrrp< at >ietf.org
Subject: RE: [VRRP] vrrp Digest, Vol 81, Issue 3

Yes Anurag, I agree that backup router will reset Master_Down_timer value as Skew_Time and
It will be become master when Master_Down_timer fired and will send VRRP Advertisements with their own priority.

After VRRP Master elected, What could be the VRRP state of priority ZERO configured router? Is it Backup?

Thanks & Regards,
Thirumavalavan Periyannan
Associate SQA Engineer  - VRRP Module Owner

[cid:image001.jpg< at >01CE134A.87062E80]

From: Anurag Kothari (ankothar) [mailto:ankothar< at >cisco.com]
Sent: Monday, February 25, 2013 8:44 PM
To: Thirumavalavan Periyannan; vrrp< at >ietf.org<mailto:vrrp< at >ietf.org>
Subject: RE: [VRRP] vrrp Digest, V

Re: vrrp Digest, Vol 81, Issue 3

Thirumavalavan Periyannan — 2013-02-25T16:19:21

Yes Anurag, I agree that backup router will reset Master_Down_timer value as Skew_Time and
It will be become master when Master_Down_timer fired and will send VRRP Advertisements with their own priority.

After VRRP Master elected, What could be the VRRP state of priority ZERO configured router? Is it Backup?

Thanks & Regards,
Thirumavalavan Periyannan
Associate SQA Engineer  - VRRP Module Owner

[cid:image001.jpg< at >01CE13A0.CD29B200]

From: Anurag Kothari (ankothar) [mailto:ankothar< at >cisco.com]
Sent: Monday, February 25, 2013 8:44 PM
To: Thirumavalavan Periyannan; vrrp< at >ietf.org
Subject: RE: [VRRP] vrrp Digest, Vol 81, Issue 3

Hi Thirumavalavan

The Master_Down_Timer is set to Skew_Time by the backup router on receiving an ADVERTISEMENT with Priority = 0. That is why I said will have to wait Skew_Time in the thread below. I am copy pasting the relevant section from the RFC for easy reference:

(420) - If an ADVERTISEMENT is received, then:

   (425) + If the Priority in the ADVERTISEMENT is zero, then:

Re: vrrp Digest, Vol 81, Issue 3

Anurag Kothari (ankothar — 2013-02-25T15:13:40

Hi Thirumavalavan

The Master_Down_Timer is set to Skew_Time by the backup router on receiving an ADVERTISEMENT with Priority = 0. That is why I said will have to wait Skew_Time in the thread below. I am copy pasting the relevant section from the RFC for easy reference:

(420) - If an ADVERTISEMENT is received, then:

   (425) + If the Priority in the ADVERTISEMENT is zero, then:

      (430) * Set the Master_Down_Timer to Skew_Time

   (440) + else // priority non-zero

Yes the Priority on the Master router will have to be set to zero to initiate a graceful failover.

Thanks
-Anurag

From: Thirumavalavan Periyannan [mailto:tperiyannan< at >extremenetworks.com]
Sent: Monday, February 25, 2013 10:08 AM
To: Anurag Kothari (ankothar); vrrp< at >ietf.org
Subject: RE: [VRRP] vrrp Digest, Vol 81, Issue 3



Hi Anurag,



Sorry for the late response.



See the inline [Thiru]



Here, I have a question,



1.Do We have to configure priority Zero on Master router to do graceful failover?

Thanks & Regards,
Thirumavalavan Peri

Re: vrrp Digest, Vol 81, Issue 3

Thirumavalavan Periyannan — 2013-02-25T15:07:37


Hi Anurag,



Sorry for the late response.



See the inline [Thiru]



Here, I have a question,



1.Do We have to configure priority Zero on Master router to do graceful failover?

Thanks & Regards,
Thirumavalavan Periyannan
Associate SQA Engineer  - VRRP Module Owner

[cid:image001.jpg< at >01CE1397.F2FD5080]


-----Original Message-----
From: Anurag Kothari (ankothar) [mailto:ankothar< at >cisco.com]
Sent: Saturday, February 23, 2013 12:57 AM
To: Thirumavalavan Periyannan; vrrp< at >ietf.org
Cc: Peter Hunt
Subject: RE: [VRRP] vrrp Digest, Vol 81, Issue 3



Hi Thirumavalavan



Here are couple of points:



1) With something like "disable vrrp" or "shutdown vrrp" it will not be graceful as the router will treat it as a shutdown event (which is a break before you make approach) and the router will "Transition to the {Initialize} state". The backup router will wait for "Skew_Time"[Thiru]I think, it's Master_Down_interval time. before it becomes master; So we probably will have traffic loss for a period approximately eq

Re: vrrp Digest, Vol 81, Issue 3

Anurag Kothari (ankothar — 2013-02-22T19:26:35

Hi Thirumavalavan

Here are couple of points:

1) With something like "disable vrrp" or "shutdown vrrp" it will not be graceful as the router will treat it as a shutdown event (which is a break before you make approach) and the router will "Transition to the {Initialize} state". The backup router will wait for "Skew_Time" before it becomes master; So we probably will have traffic loss for a period approximately equal to "Skew_Time". Even with Default configuration this will be close to 609 ms which would be a duration long enough for to impact time sensitive applications (e.g. voice calls). For sure the actual failover time will depend upon the size of the Network and the switches in between but with the method proposed below we can try to improve that time.

2) This will also improve convergence in scenarios where we want the failover to trigger because of up uplink interface from the router going down (tracking interface and decrementing the priority).

I am not sure if you saw the modified proposal which

Re: vrrp Digest, Vol 81, Issue 3

Thirumavalavan Periyannan — 2013-02-22T17:40:54

Hi Anurag,

If customer wants to do any maintenance work then they can do "disable vrrp" on MASTER Router which will generate VRRP Advertisement with "priority 0" and one among the backup router will become master based on the priority or higher interface IP addres.


Sent from my iPhone

On 22-Feb-2013, at 10:59 PM, "Anurag Kothari (ankothar)" <ankothar< at >cisco.com> wrote:

 will continue to provide service. A lack of failover will indicate to the operator that backup is missing / not working and he will have to troubleshoot the situation.

DISCLAIMER:
This e-mail and any attachments to it may contain confidential and proprietary material and is solely for the use of the intended recipient. Any review, use, disclosure, distribution or copying of this transmittal is prohibited except by or on behalf of the intended recipient.  If you have received this transmittal in error, please notify the sender and destroy this e-mail and any attachments and all copies, whether electronic or printed.
______________________

Re: vrrp Digest, Vol 81, Issue 3

Anurag Kothari (ankothar — 2013-02-22T17:29:38

Hi Peter

Please See my responses inline [Anurag]

Thanks
-Anurag

-----Original Message-----
From: Peter Hunt [mailto:pfhunt< at >gmail.com] 
Sent: Friday, February 22, 2013 11:59 AM
To: Anurag Kothari (ankothar)
Cc: Thirumavalavan Periyannan; vrrp< at >ietf.org
Subject: Re: [VRRP] vrrp Digest, Vol 81, Issue 3

Sorry to jump in here, but I'm having trouble understanding the motivation for the maintenance event.

It seems like its behaviour is to relinquish mastership immediately to a backup if it exists, but remain master silently otherwise. Is that correct?

[Anurag] The master will not remain silent it will keep sending Advertisements with Priority = 0 until some backup router takes over as Master.

If so, why is that desirable behaviour? It seems to me that you would either want to take the node out of the vrrp cluster completely, or have it participate at a reduced priority. What situation makes a silent-but-active master preferable?

[Anurag] Many mobile service providers disable preemption for VRRP as they do n

Re: vrrp Digest, Vol 81, Issue 3

Peter Hunt — 2013-02-22T16:58:54

Sorry to jump in here, but I'm having trouble understanding the motivation for the maintenance event.

It seems like its behaviour is to relinquish mastership immediately to a backup if it exists, but remain master silently otherwise. Is that correct?

If so, why is that desirable behaviour? It seems to me that you would either want to take the node out of the vrrp cluster completely, or have it participate at a reduced priority. What situation makes a silent-but-active master preferable?

Peter


On Feb 22, 2013, at 7:55 AM, "Anurag Kothari (ankothar)" <ankothar< at >cisco.com> wrote:

_______________________________________________
vrrp mailing list
vrrp< at >ietf.org
https://www.ietf.org/mailman/listinfo/vrrp

Re: vrrp Digest, Vol 81, Issue 3

Anurag Kothari (ankothar — 2013-02-22T15:55:47

Yes that is correct. 

The intention is to be able to switch the traffic to the backup router (with minimal traffic interruption) when preemption is not configured on the backup router without shutting down the interface or VRRP on Master.

Thanks
~Anurag

-----Original Message-----
From: vrrp-bounces< at >ietf.org [mailto:vrrp-bounces< at >ietf.org] On Behalf Of Thirumavalavan Periyannan
Sent: Friday, February 22, 2013 8:56 AM
To: vrrp< at >ietf.org
Cc: vrrp< at >ietf.org
Subject: Re: [VRRP] vrrp Digest, Vol 81, Issue 3

Hi Anurag,

You meant to say that when we do graceful failover on VRRP Master then traffic needs switch to VRRP backup router without waiting for Master_Down_Interval time.

Please correct me if I am wrong.

Sent from my iPhone

On 22-Feb-2013, at 5:11 PM, "vrrp-request< at >ietf.org" <vrrp-request< at >ietf.org> wrote:



DISCLAIMER:
This e-mail and any attachments to it may contain confidential and proprietary material and is solely for the use of the intended recipient. Any review, use, disclosure, distribution or co

Re: vrrp Digest, Vol 81, Issue 3

Thirumavalavan Periyannan — 2013-02-22T13:56:08

Hi Anurag,

You meant to say that when we do graceful failover on VRRP Master then traffic needs switch to VRRP backup router without waiting for Master_Down_Interval time.

Please correct me if I am wrong.

Sent from my iPhone

On 22-Feb-2013, at 5:11 PM, "vrrp-request< at >ietf.org" <vrrp-request< at >ietf.org> wrote:


DISCLAIMER:
This e-mail and any attachments to it may contain confidential and proprietary material and is solely for the use of the intended recipient. Any review, use, disclosure, distribution or copying of this transmittal is prohibited except by or on behalf of the intended recipient.  If you have received this transmittal in error, please notify the sender and destroy this e-mail and any attachments and all copies, whether electronic or printed.
_______________________________________________
vrrp mailing list
vrrp< at >ietf.org
https://www.ietf.org/mailman/listinfo/vrrp

Re: Proposal for Maintenance Event for VRRP [RFC-5798]

Anurag Kothari (ankothar — 2013-02-22T12:08:55

On Further Thought:

We may want to define maintenance event (probably rename it "Priority Change Event") being triggered by a change in priority for a VRID (including dynamic changes to the priority e.g. changes due to tracking interface).

This would make it more generic. Whenever the user configures priority = 0 (which will have to be allowed) it would trigger a failover to the backup router.

Thanks
-Anurag

From: vrrp-bounces< at >ietf.org [mailto:vrrp-bounces< at >ietf.org] On Behalf Of Anurag Kothari (ankothar)
Sent: Friday, February 22, 2013 6:42 AM
To: sreenatha
Cc: vrrp< at >ietf.org
Subject: Re: [VRRP] Proposal for Maintenance Event for VRRP [RFC-5798]

Hi Sreenatha

My bad, by cancel I meant reset the timer.

I would prefer defining maintenance event itself as (or being triggered by) priority being set to 0 for a VRID. So probably we can rephrase the proposal as:


- If a Maintenance event is received, then:



+ Send an ADVERTISEMENT



+ Reset the Adver_Timer to Advertisement_Interval



-endif // maintenance