<!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;">&nbsp;</span></font></p>
  <p class="MsoNormal"><font face="Times New Roman" size="3"><span
 style="font-size: 12pt;">4.2.7.4.2&nbsp; 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 &#8216;reconnect&#8217;
message to the new registrar (and the registrar shall respond with
either a &#8216;reconnected&#8217;
or &#8216;you-are-dead&#8217;).&nbsp; Good so far.&nbsp; But what if the node does not
receive a response from the registrar?&nbsp; I don&#8217;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;">&nbsp;</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 &#8216;reconnect&#8217; message.&nbsp; 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.&nbsp; The
intent is that:<br>
<br>
a)&nbsp;&nbsp; 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.&nbsp; (The same is true, really, of the effect on a
registrar of the imputed death of a configuration server.)<br>
<br>
b)&nbsp;&nbsp; At the expiration of any heartbeat period, the node is supposed to
send a heartbeat to the registrar.&nbsp; If it knows that the registrar is
running (at a known network location), great.&nbsp; 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)&nbsp;&nbsp; If there's no response (reconnected or you_are_dead) to the
reconnect message, no problem.&nbsp; 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.&nbsp; 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.&nbsp; I'll try to do that
this week, unless we don't agree that this approach is okay.&nbsp; What do
you think?<br>
<br>
Scott <br>
</body>
</html>