Subject: [NSIS] Re: MA-Hello request/response processing (was: RE: GIST MA Keep-alive/Liveliness)

From: Roland Bless <[email-masked]>
Date: Mon, 06 Nov 2006 06:14:34 +0100

Hancock, Robert schrieb:
> Hi roland,
> 
> Some good questions. I think the facility is useful (see below)
> and so we need to keep it, but a small protocol change is 

I'm not saying that it's not useful. I just wanted a little
more rationale for it.

> Basically I think that since it is up to the originating node
> to decide whether to make such a liveness test, we don't need
> to be totally prescriptive about how to go about it. After all,

That's ok.

> a conformant node can just decide never to do such a test in
> the first place. What I think does need to be stated is that
> you can use the MA-Hello to test liveness and Die if the test
> fails. Text is added in 6.4 to say just that.

Yep. But the proposed text just mentions a mismatching
Hello-ID as failure. I guess that it's more likely that
the testing node wants to set also a timeout. The value
of the latter may be a local decision.

> This is the crucial point. I've proposed adding a Hello-ID
> to the MA-Hello message. It is set to a non-zero value in
> request (R=1) messages, and echoed in any reply; otherwise
> it is set to zero. Note that replies must have R=0. No-one
> ever has to generate R=1 messages, but if you get one you 
> have to send a response with R=0 including the Hello-ID.
> (I think this meets the matching requirement safely.)

Ok. So receiving an MA-Hello with R=1 but Hello-ID=0
is considered to be a protocol error (object value error?).

> I think of it as a diagnostic. You don't have to invoke it,
> but it is useful to define normatively how peers will respond
> to it. At the moment, it's a simple way to check that the

That's fine.

> GIST layer at the peer is still functioning without having
> to send some made-up data (which might interact with an 
> NSLP). It might even be used mainly by user tools (a GIST
> ping). It can also be used to test the whether outstanding 
> messages have been delivered to the other end of an MA, which
> can be useful in some circumstances.

I'd like to see this or similar text in the spec as rationale.

> The currently proposed text is in the issue tracker at
> http://nsis.srmr.co.uk/cgi-bin/roundup.cgi/nsis-ntlp-issues/issue157

Ok for me if you also include the explanatory text such as:
The request/response exchange is essentially a diagnostic, which a node
may invoke whenever it wants (including never). It is up to the node to
decide when to invoke it and how, and what to do with the result.

Regards,
 Roland

_______________________________________________
nsis mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nsis

---

From: "Robert Hancock" <[email-masked]>
Date: Mon, 6 Nov 2006 09:31:08 -0800

Hi Roland,

thanks for the inputs. I've made some changes to the proposed text;
please check out 
http://nsis.srmr.co.uk/cgi-bin/roundup.cgi/nsis-ntlp-issues/issue157
and see what you think.

cheers,

robert h.

> -----Original Message-----
> From: Roland Bless [mailto:[email-masked]] 
> Sent: 05 November 2006 21:15
> To: Hancock, Robert
> Cc: [email-masked]
> Subject: Re: MA-Hello request/response processing (was: RE: 
> GIST MA Keep-alive/Liveliness)
> 
> 
> Hancock, Robert schrieb:
> > Hi roland,
> > 
> > Some good questions. I think the facility is useful (see 
> below) and so 
> > we need to keep it, but a small protocol change is
> 
> > Basically I think that since it is up to the originating node to 
> > decide whether to make such a liveness test, we don't need to be 
> > totally prescriptive about how to go about it. After all,
> 
> That's ok.
> 
> > a conformant node can just decide never to do such a test 
> in the first 
> > place. What I think does need to be stated is that you can use the 
> > MA-Hello to test liveness and Die if the test fails. Text 
> is added in 
> > 6.4 to say just that.
> 
> > to the MA-Hello message. It is set to a non-zero value in request 
> > (R=1) messages, and echoed in any reply; otherwise it is 
> set to zero. 
> > Note that replies must have R=0. No-one ever has to generate R=1 
> > messages, but if you get one you have to send a response with R=0 
> > including the Hello-ID. (I think this meets the matching 
> requirement 
> > safely.)
> 
> but it is 
> > useful to define normatively how peers will respond to it. At the 
> > moment, it's a simple way to check that the
> 
> That's fine.
> 
> The request/response exchange is essentially a diagnostic, 
> which a node may invoke whenever it wants (including never). 
> It is up to the node to decide when to invoke it and how, and 
> what to do with the result.
> 
> Regards,
>  Roland
> 
>