Hi, I have a doubt regarding context confusion, please find my comment below :
As far as I understand this explanation, we are in the situation of two contexts being created using disjoint sets of locators. The assumption is that until both contexts die, the sets won't intersect. Right ? But why those locators should never intersect ? I think the point for avoiding context confusion is to have, as stated in the original text, a sufficiently large set of locators, so that each context established with a given host will have at least one locator present in the Locator List Option. Maybe it's simpler to discuss with an example : 1. host A has two contexts with host B, one with the set of locators <A1,B1/B2> and CTx, the other with <A2,B3/B4> and CTy....the assumption here is that there is no situation of merging hosts, meaning that if two contexts are initiated with a disjoint set of locators, they will remain disjoint during the lifetiem of the context, and the situation where two contexts have disjoint sets and then later on one of them adds new locators that interject with another previously disjoint context is not supported. This is what the above assumption is expressing... makes sense?7.6. Context confusion Since each end might garbage collect the context state we can havethe case when one end has retained the context state and tries to use it, while the other end has lost the state. We discussed this in theprevious section on recovery. But for the same reasons, when one host retains context tag X as CT(peer) for ULID pair <A1, B1>, the other end might end up allocating that context tag as CT(local) for another ULID pair, e.g., <A3, B1> between the same hosts. In this case we can not use the recovery mechanisms since there needs to be separate context tags for the two ULID pairs.This type of "confusion" can be observed in two cases (assuming it isA that has retained the state and B has dropped it): o B decides to create a context for ULID pair <A3, B1>, and allocates X as its context tag for this, and sends an I1 to A.Nordmark & Bagnulo Expires November 16, 2006 [Page 58]Internet-Draft Shim6 Protocol May 2006o A decides to create a context for ULID pair <A3, B1>, and starts the exchange by sending I1 to B. When B receives the I2 message, it allocates X as the context tag for this context.In both cases, A can detect that B has allocated X for ULID pair <A3,B1> even though that A still X as CT(peer) for ULID pair <A1, B1>. Thus A can detect that B must have lost the context for <A1, B1>. The confusion can be detected when I2/I2bis/R2 is received since we require that those messages MUST include a sufficiently large set oflocators in a Locator List option that the peer can determine whetheror not two contexts have the same host as the peer by comparing if there is any common locators in Ls(peer). dmm> not really sure how this works. Is it not possible to have dmm> a situation where Ls_i(peer) \intersect Ls_j(peer) is empty dmm> (where Ls_1(peer),...,Ls_n(peer) is the sequence of changing dmm> locator sets for peer)? Or is the "sufficiently slowly dmm> changing locator sets" assumption operative here?dmm> yes. Maybe exactly that text, or something like it, would clarify?
2. After some time, host B drops the first context.3. Now he wants to create another one. B knows (for example from a fixed configuration) that it usually announce as locators B1/B2 for one purpose (say low cost links) and B3/B4 for another purpose (say low delay links). Because of that, B knows that A may have an old context with either one of these pairs. So he creates a context in A with locators <A1,B1/B3/B4> and CTx. This is correct because the locator list option contains at least one locator from each set. 4. Indeed A will notice that the context <A1,B1/B2>, CTx is established with the same peer, and will discard it.
The example above illustrates a scenario with no special problem. Now let's suppose that between step 1 and step 2, B receives a new prefix, with which it creates a new address B5 and announce it to both contexts in A. We have now in A (<A1,B1/B2/B5>,CTx) and (<A2,B3/B4/B5>,CTy). This change is exactly (as far as i understand it) what it assumed not to be supported, because the two sets were initially disjoint, but this is not the case anymore. Where is the problem ? On the contrary, the situation appears to me as simpler : now step 3 is still correct, and another correct case appears, which is to create a context with locators <A1,B5> and CTx.
---------------Now I have another question, regarding the original text. The above scenario serves also the purpose of my second question. I have chosen a case where B uses always locators B1/B2 for one type of traffic (low cost), and B3/B4 for the other type (low delay). The above example shows that dealing with it is impossible to keep these two sets fully disjoint. The reason is that if they are disjoint one time, then we have to mix them next, in order to enable context confusion detection. Do you see any good solution for that ? Or am i misunderstanding something ? One idea I have to solve this problem is to split the context tag space in B in two parts, so that 'low cost' context tags are always different from 'low delay' context tags. Put in a more general way, I would say that if there is a need within a host to separate the locators into disjoint locators sets (for example in order to deal with different QoS requirements), then the Context Tag space must also be split into disjoint context tag spaces, one context tag space for each locator set. Now one could argue that the case where a host suddenly decides to split his locator sets is still a problem, as newly allocated contexts (with split locator sets) may create undetected confusion with previously allocated contexts. Well, for that problem I have'nt a solution right now. In fact I would like to have some confirmation that I'm not misunderstanding some things before to think more about this problem.
Another idea would be to rely on the random cycle through the 2^47 context tag values (section 7.1). But if this option is chosen, maybe the SHOULD statement in section 7.1 should become a MUST. In that case it is probably no longer necessary to split the context tags space the way I described it previously.
Sébastien. -- Sébastien Barré Researcher, CSE department, UCLouvain, Belgium