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

From: Thomas Herzog <[email-masked]>
Date: Mon, 7 Nov 2005 14:14:41 +0100

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