Subject: RE: [NSIS] GIST API: InvalidateRoutingstate setting state to"Tentative" - what use would it have?

From: "Hancock, Robert" <[email-masked]>
Date: Thu, 15 Dec 2005 13:32:48 -0000

Hi Thomas,

[written in vancouver but i obviously forget to send it...]

No doubt it is a subtle subject. There's one simple point and
one complex one.

1. [Could just be a clarification:] You say below "Currently, 
I set the state to "TENTATIVE", when entering a Refresh cycle".
Just to be clear: *if* you set the routing quality to tentative,
*then* you must enter awaiting refresh/response; however, the
converse is not true. In other words, *if* you enter awaiting
refresh because of normal routing state timer behaviour, you
should *not* automatically change routing quality to tentative.

2. [Your main question:] If the NSLP sets the routing state to
tentative, the state machine may transition to either awaiting
response or awaiting refresh. Which to do is a matter of local
policy. The protocol will work correctly in either case. A 
reasonable policy would be always to move to awaiting refresh, 
but I can think of several other reasonable policies; it really 
has to be left open as implementation freedom.

In either case, at some subsequent stage the handshake *must*
take place (see the first sentence after the list of options in
section 7.1.3); if the transition is marked urgent this *must* be
done immediately, otherwise the GIST layer is free to schedule 
it as it sees fit.

I think your main question is: what is the point of the NSLP
setting the state to 'tentative' if you do not immediately try 
to refresh it (i.e. do not set the urgent flag). I think the 
basic answer to this is that it is a way for the NSLP to be 
notified when the state is confirmed as Good, without disrupting 
on-going signalling or triggering a storm of Query updates. 
(How much NSLPs would use this functionality I cannot say, but
it seems unwise to rule it out.)

Hope this helps,

robert h.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Thomas Herzog
> Sent: 07 November 2005 05:15
> To: [email-masked]
> Subject: [NSIS] GIST API: InvalidateRoutingstate setting 
> state to"Tentative" - what use would it have?
> 
> 
> Hi, I am currently implementing the InvalidateRoutingstate and 
> SetStateLifetime API calls und stumbled about one thing:
> 
> According to the I-D, NSLP may invalidate Routing State to "BAD" and 
> "TENTATIVE" and also supply a "urgency" Flag, as to whether 
> GIST should 
> reestablish the Route instantly or if it can delay this until 
> the next 
> SendMessage call.
> 
> In my eyes, setting state to "BAD" would be killing Routing 
> State, so that 
> only the SII-Handle may be used to contact the peer after 
> that call, and the 
> "urgency" flag would tell GIST to do a new handshake and 
> install new Routing 
> State for all the (MRI/SID/NSLPID) tuples the 
> InvalidateRoutingState API call 
> applied to.
> 
> But what would the case of NSLP setting the state to 
> "TENTATIVE" cause GIST to 
> do? Would it cause a Routing State REFRESH, if the urgency 
> flag is set?
> 
> What happens, if the NSLP sets the state to "TENTATIVE" and 
> not set the 
> "urgency" flag? GIST would then only know "this routing state 
> can be wrong" 
> when the next SendMessage arrives, I can see no use for this 
> case at all, can 
> someone enlighten me? Should GIST then start a refresh on the next 
> SendMessage call? (it would in the meantime also do Refreshes 
> due to periodic 
> probing...)
> 
> Currently, I set the state to "TENTATIVE", when entering a 
> Refresh cycle and 
> to "BAD" when the state times out. "GOOD" I use when the 
> state machine enters 
> the "established" states.
> 
> So, it would be helpful, if someone could clearify what 
> exactly GIST is 
> supposed to do when:
> 
> - NSLP sets the state to "tentative" and provides urgency flag
> - NSLP sets the state to "tentative" and does not provide urgency flag
> 
> Thanks in advance,
> Thomas
> 
> _______________________________________________
> nsis mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/nsis
> 

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