'[VRRP] do we need number of retries in VRRP3?'

[prev in list] [next in list] [prev in thread] [next in thread] 

List: ietf-vrrp
Subject: [VRRP] do we need number of retries in VRRP3?
From: "Changming Liu" <cliu () juniper ! net>
Date: 2005-02-01 0:03:29
Message-ID: F07F17B61B7FF545BC7D7E4BFBE15D2AB8DAC4 () hadron ! jnpr ! net
[Download RAW message or body]

--===============1601124334==
Content-class: urn:content-classes:message
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C507F1.75AD7CCC"

This is a multi-part message in MIME format.

Hi all,

Although I'm quite familiar with VRRPv2 but new to VRRPv3 because there
is no such demand till recently. We had implemented VRRP like protocol
in our product for long time and have added lots of enhancements to the
basic protocol.  VRRP is a simple protocol working well for a simple
network topology, which it is designed for. But it has some significant
drawbacks in any production network with some level of complexity.  

After reading the draft <draft-ietf-vrrp-ipv6-spec-07.txt>, I have some
questions and post here one by one hoping they can get answered.

1)       The draft changes the advertisement interval from unit of
second in VRRPv2 to centi-second. This is great improvement. Thanks for
the change. One of the big operation issues with VRRPv2 is the minimum 3
seconds fail-over time while our customers are asking sub-second
failover. But the operational experience tells us that if we shorten the
interval (say 200ms), we may want to increase the number of retries (say
from 3 to 4 or even 5) to compensate the potential delay or loss. So the
fixed retry of 3 times (as defined in master_down_time) sometimes may
not be good. Is it possible to use the 4-bit rsvd field to carry this
info?   

2)       In section 6.4.3 it states the master

-        MUST respond to ND Router Solicitation message for the virtual
But in section 6.4.2 it does not state the backup
-        MUST NOT respond to ND Router Solicitation message for the
virtual
 Has the author left that out for any good reason? Otherwise, developers
may get confused because everything else is kind of opposite in the two
sections.

3) In section 7.4 for the interface ID, there is one restriction about
using the virtual MAC to derive the interface ID. But it dose not state
the reason. I was thinking exactly to derive the interface ID from the
VMAC. This is to leave the interface ID derived in the normal manner for
addresses of local management. What is the harm of this approach? 

Thanks in advance.

Changming Liu

[Attachment #3 (text/html)]

<html>

<head>
<meta http-equiv=Content-Type content="text/html; charset=us-ascii">
<meta name=Generator content="Microsoft Word 10 (filtered)">

<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:Wingdings;
	panose-1:5 0 0 0 0 0 0 0 0 0;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;}
pre
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:10.0pt;
	font-family:"Courier New";}
span.EmailStyle17
	{font-family:Arial;
	color:windowtext;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.25in 1.0in 1.25in;}
div.Section1
	{page:Section1;}
 /* List Definitions */
 ol
	{margin-bottom:0in;}
ul
	{margin-bottom:0in;}
-->
</style>

</head>

<body lang=EN-US link=blue vlink=purple>

<div class=Section1>

<p class=MsoNormal><font size=3 face="Times New Roman"><span style='font-size:
12.0pt'>Hi all,</span></font></p>

<p class=MsoNormal><font size=3 face="Times New Roman"><span style='font-size:
12.0pt'>&nbsp;</span></font></p>

Although I&#8217;m quite familiar with VRRPv2 but new to VRRPv3 because
there is no such demand till recently. We had implemented VRRP like protocol in
our product for long time and have added lots of enhancements to the basic
protocol. &nbsp;VRRP is a simple protocol working well for a simple network topology,
which it is designed for. But it has some significant drawbacks in any production
network with some level of complexity. &nbsp;

<p class=MsoNormal><font size=3 face="Times New Roman"><span style='font-size:
12.0pt'>&nbsp;</span></font></p>

After reading the draft &lt;draft-ietf-vrrp-ipv6-spec-07.txt&gt;, I
have some questions and post here one by one hoping they can get answered. \
&nbsp;

<p class=MsoNormal><font size=2 face=Arial><span style='font-size:10.0pt;
font-family:Arial'>&nbsp;</span></font></p>

1)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; The draft changes the \
advertisement interval from unit of second in VRRPv2 to centi-second. \
This is great improvement. Thanks for the change. One of the big operation issues \
with VRRPv2 is the minimum 3 seconds fail-over time while our customers are asking \
sub-second failover. But the operational experience tells us that if we shorten the
interval (say 200ms), we may want to increase the number of retries (say from 3
to 4 or even 5) to compensate the potential delay or loss. So the fixed retry
of 3 times (as defined in master_down_time) sometimes may not be good. Is it
possible to use the 4-bit rsvd field to carry this info? &nbsp;&nbsp;

<p class=MsoNormal style='margin-left:.5in;text-indent:-.25in'><font size=2
face=Arial><span style='font-size:10.0pt;font-family:Arial'>2)<font size=1
face="Times New Roman"><span style='font:7.0pt "Times New \
Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span></font></span></font>In section \
6.4.3 it states the master</p>

<pre style='margin-left:42.0pt;text-indent:-.25in'>-&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; MUST \
respond to ND Router Solicitation message for the virtual</pre><pre \
style='margin-left:42.0pt'>But in section 6.4.2 it does not state the \
backup</pre><pre style='margin-left:42.0pt;text-indent:-.25in'>-&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; MUST \
NOT respond to ND Router Solicitation message for the virtual</pre><pre \
style='margin-left:24.0pt'> Has the author left that out for any good reason? \
Otherwise, developers may get confused because everything else is kind of opposite in \
the two sections.</pre><pre style='margin-left:24.0pt'>&nbsp;</pre><pre \
style='margin-left: 24.0pt'>3) In section 7.4 for the interface ID, there is one \
restriction about using the virtual MAC to derive the interface ID. But it dose not \
state the reason. I was thinking exactly to derive the interface ID from the VMAC. \
This is to leave the interface ID derived in the normal manner for addresses of local \
management. What is the harm of this approach? </pre><pre>&nbsp;</pre><pre>Thanks in advance.</pre>

<p class=MsoNormal><font size=2 face=Arial><span style='font-size:10.0pt;
font-family:Arial'>&nbsp;</span></font></p>

<p class=MsoNormal><font size=2 face=Arial><span style='font-size:10.0pt;
font-family:Arial'>&nbsp;</span></font></p>

<p class=MsoNormal><font size=2 face=Arial><span style='font-size:10.0pt;
font-family:Arial'>Changming Liu</span></font></p>

<p class=MsoNormal><font size=3 face="Times New Roman"><span style='font-size:
12.0pt'>&nbsp;</span></font></p>

<p class=MsoNormal><font size=3 face="Times New Roman"><span style='font-size:
12.0pt'>&nbsp;</span></font></p>

</div>

</body>

</html>

_______________________________________________
vrrp mailing list
vrrp@ietf.org
https://www1.ietf.org/mailman/listinfo/vrrp

--===============1601124334==--

[prev in list] [next in list] [prev in thread] [next in thread] 