caches and mappings

[I took the liberty to change the subject since this isn't about the
persistence of the IDs; it is whether the mappings from IDs->foo
can be viewed as caches or whether they are hard endpoint state]

> However, i wonder if this issue is not more general and it is not 
> limited to only ephemeral ids proposals
> 
> (not considering the refferral and call back cases here)
> 
> I mean, in any proposal that manages bindings between multiple locators 
> that can be used to reach a single endpoint, you need some state in the 
> endpoints about the binding. This state has to be preserved as long as 
> the communication exists, and some garbage collection mechanism is 
> needed to delete this state after it is used.
> As you mention, the wedge layer does not have knowledge about the apps 
> still need the binding state, so how do you know when to delete it?

One possibility is that the information is a cache, similar in nature
to the ARP cache,
where information can be discarded because it can be rediscovered
based on what exists elsewhere in the node. That would make the
caching strategy a performance tradeoff - how much state to retain
compared to how much does it cost to recreate the state.

Given that the ULP might only have a 128 bit handle, it is hard for
me to see how one can recreate the state in the presence of 
unreachability for some locators, without some 3rd party infrastructure.

> One problem is that if the endpoints are incapable of obtaining the 
> locators associated with a given identifier (as in HIP), it is 
> impossible for the endpoints to recover the lost state, so perhaps 
> having a mechanism for mapping id to locators is a must?

I think I agree, but I would rephrase it as
For existing applictions, whatever 128-bit thing they pass to sendto() and
connect(), should have the property that the multi6 layer/sublayer
can create or recreate whatever state it needs based on that bit string.

I wonder, assuming we are successful, there will be applications that are
aware of the id/locator split thus will know to deal with both quantities
instead of just a 128-bit string, which is why I rephrased it as above.

  Erik