<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Ray, Timothy J. (GSFC-583.0) wrote:
<blockquote
cite="mid:C3B9C435D7725E4EABE2B62200A42C12A3FAF2@NDMSEVS36A.ndc.nasa.gov"
type="cite">
<meta http-equiv="Content-Type" content="text/html; ">
<meta name="Generator" content="Microsoft Word 11 (filtered)">
<style>
<!--
/* Font Definitions */
@font-face
        {font-family:"MS Mincho";
        panose-1:2 2 6 9 4 2 5 8 3 4;}
@font-face
        {font-family:"\@MS Mincho";
        panose-1:2 2 6 9 4 2 5 8 3 4;}
/* 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;}
p.StyleParagraph4Kernat14pt, li.StyleParagraph4Kernat14pt, div.StyleParagraph4Kernat14pt
        {margin-top:12.0pt;
        margin-right:0in;
        margin-bottom:0in;
        margin-left:0in;
        margin-bottom:.0001pt;
        text-align:justify;
        line-height:14.0pt;
        font-size:12.0pt;
        font-family:"Times New Roman";}
span.EmailStyle18
        {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>
<div class="Section1">
<p class="MsoNormal"><font face="Arial" size="2"><span
style="font-size: 10pt; font-family: Arial;">Dear WG members,</span></font></p>
<p class="MsoNormal"><font face="Arial" size="2"><span
style="font-size: 10pt; font-family: Arial;"> </span></font></p>
<p class="MsoNormal"><font face="Times New Roman" size="3"><span
style="font-size: 12pt;">4.2.7.4.2 specifies that a node shall (in
response to imputing the
death of its registrar) query the configuration server to determine the
network
location of the restarted registrar, and then send a ‘reconnect’
message to the new registrar (and the registrar shall respond with
either a ‘reconnected’
or ‘you-are-dead’). Good so far. But what if the node does not
receive a response from the registrar? I don’t think our spec covers
this situation.</span></font></p>
<p class="MsoNormal"><font face="Times New Roman" size="3"><span
style="font-size: 12pt;"> </span></font></p>
<p class="MsoNormal"><font face="Times New Roman" size="3"><span
style="font-size: 12pt;">In my opinion, AMS should require the node to
start a timer when it
sends the ‘reconnect’ message. AMS should also specify the action to
be taken if the timer expires.<br>
</span></font></p>
</div>
</blockquote>
Tim, good point; the spec is not as clear on this as it should be. The
intent is that:<br>
<br>
a) The immediate response of a node to the imputed death of a
registrar should be simply to note that the registrar is no longer
running, nothing more. (The same is true, really, of the effect on a
registrar of the imputed death of a configuration server.)<br>
<br>
b) At the expiration of any heartbeat period, the node is supposed to
send a heartbeat to the registrar. If it knows that the registrar is
running (at a known network location), great. If not, the node is
supposed to try to determine the new location of the restarted
registrar, by interrogating the configuration server, and then -- if
that attempt was successful -- send a reconnect message to the
restarted registrar at its new location.<br>
<br>
c) If there's no response (reconnected or you_are_dead) to the
reconnect message, no problem. At the expiration of the next heartbeat
period, the node will do step (b) again and this will result in (at
most) transmission of another reconnect.<br>
<br>
That is, the reconnect cycle is "soft state"; in effect, the heartbeat
cycle functions as the timer on reconnect messages.<br>
<br>
I like this approach, as it is pretty simple and at this point I think
we want to avoid introducing any more complexity (such as another
timer) into the spec if we can possibly help it. But what I have
written here is really hard to infer from the current text of 4.2.7, so
I need to do some serious reworking of this text. I'll try to do that
this week, unless we don't agree that this approach is okay. What do
you think?<br>
<br>
Scott <br>
</body>
</html>