marcelo bagnulo braun wrote:
We have a single stack A with 4 addresses, A1, A2, A3 and A4.Suppose this host A wants to establish a two contexts: one with node B and another one with node C and A wants to include the following locator sets:context 1 between A and B : Ls(A1,A2) context 2 between A and C : Ls(A3,A4)As i understand the current draft this is not supported because we are requiring that all the locator sets that A uses in its shim context must be non disjoint
We do require that I2/I2bis/R2 include essentially the full locator set. But what problem are we trying to solve by changing this? A host can express its preferences among those locators already. Is it that the I2/I2bis/R2 packets are too big? Something else?The reason we need to understand the problem we are trying to solve by changing this is that any change will add complexity to shim6. And I frankly think it is sufficiently complex already. (Not that I know of a way to reduce the complexity and satisfy the same set of requirements, but I would want to think very carefully before adding new requirements.)
Should we have consensus to add more flexibility in this area, I wouldn't be surprised if the lowest complexity addition is simply to avoid context confusion by adding the CLOSE timers and messages that HIP uses. With those we have an upper bound on how long A and B can be out of synch (with one having retained the state and the other having discarded it).
Erik