sreenatha setty
2013-08-06 05:41:00 UTC
Hi Anurag,
I went through the draft. I have few queries.
The new "Change Event" you are trying to define is not actually new. In
earlier implementation also, if there is a change in Priority or
Advertisement Interval or VRIP address configurations, first VRRP will go to
Init state, then wait for some time (probably for Master down timer interval
if it's not the address owner) then becomes master if no eligible master is
available in the network. I think only for Priority 0 configuration we need
to define new event. (I guess this you discussed over this mailing list
earlier.)
And one more thing, I guess draft need to contain one more section
regarding the importance of the priority 0 configuration, before it talks
about the updates to RFC. Draft mentioned about this only in abstract. But
not really explaining in detail why we need to allow this configuration
(Priority 0). Can you please elaborate it further?
Thanks,
Sreenatha
Message: 1
Date: Sat, 3 Aug 2013 00:06:13 +0000
From: "Anurag Kothari (ankothar)" <***@cisco.com>
To: "***@olddog.co.uk" <***@olddog.co.uk>, "***@ietf.org"
<***@ietf.org>
Cc: "fhrp-team\(mailer list\)" <fhrp-***@cisco.com>
Subject: [VRRP] Graceful Failover for VRRP
Message-ID:
<***@xmb-rcd-x05.cisco.com>
Content-Type: text/plain; charset="us-ascii"
Hi
I have submitted the following I-D on this idea:
TXT:
http://www.ietf.org/internet-drafts/draft-kothari-vrrp-graceful-failover-00.
txt
HTML: http://tools.ietf.org/html/draft-kothari-vrrp-graceful-failover-00
Please review and provide feedback.
Thanks
-Anurag
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.
I went through the draft. I have few queries.
The new "Change Event" you are trying to define is not actually new. In
earlier implementation also, if there is a change in Priority or
Advertisement Interval or VRIP address configurations, first VRRP will go to
Init state, then wait for some time (probably for Master down timer interval
if it's not the address owner) then becomes master if no eligible master is
available in the network. I think only for Priority 0 configuration we need
to define new event. (I guess this you discussed over this mailing list
earlier.)
And one more thing, I guess draft need to contain one more section
regarding the importance of the priority 0 configuration, before it talks
about the updates to RFC. Draft mentioned about this only in abstract. But
not really explaining in detail why we need to allow this configuration
(Priority 0). Can you please elaborate it further?
Thanks,
Sreenatha
Message: 1
Date: Sat, 3 Aug 2013 00:06:13 +0000
From: "Anurag Kothari (ankothar)" <***@cisco.com>
To: "***@olddog.co.uk" <***@olddog.co.uk>, "***@ietf.org"
<***@ietf.org>
Cc: "fhrp-team\(mailer list\)" <fhrp-***@cisco.com>
Subject: [VRRP] Graceful Failover for VRRP
Message-ID:
<***@xmb-rcd-x05.cisco.com>
Content-Type: text/plain; charset="us-ascii"
Hi
I have submitted the following I-D on this idea:
TXT:
http://www.ietf.org/internet-drafts/draft-kothari-vrrp-graceful-failover-00.
txt
HTML: http://tools.ietf.org/html/draft-kothari-vrrp-graceful-failover-00
Please review and provide feedback.
Thanks
-Anurag
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.