Subject: [NSIS] RE: qos-nslp-00

From: "Geib, Ruediger" <[email-masked]>
Date: Thu, 25 Sep 2003 11:55:40 +0200

Hello Cornelia,

it is not clear to me how the local node reacts once it learns 
that it maintains stale state. If the only answer is "not at all" 
I can't see a benefit of the RSN method against session ID based 
refreshes. On the opposite, the state you have to maintain 
locally will increase (besides session ID you will have to store 
incoming and outgoing RSN).

Regards, Rüdiger 

|> |We deliberately refer to the state to be refreshed by the RSN 
|> |(minimally) rather than by the session ID. 
|> |
|> |Summary refreshes should be handled with caution, we should be 
|> |sure it is the correct state that is being refreshed. If we 
|> |just use session ID, we dont know what possibly obsolete state 
|> |might be refreshed. By matching the RSN in the summary refresh 
|> |with the locally stored RSN, a nodes knows whether it is 
|> |refreshing the correct state. 
|> |
|> |Vice versa, when the RSN in the summary refresh does not match 
|> |the local RSN, the refresh will be disregared - which makes 
|> |sense, because a problem must have occurred (i.e. a node does 
|> |not have the most up-to-date state information).
|> 
|> Yes, and this node could be the one ignoring the refresh with 
|> the sequence number not matching the on in his local database.
|
|Exactly. Do I take it correctly you consider this a drawback 
|rather than a virtue? Why that?

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