Re: draft-ietf-shim6-proto-06 : Context confusion

[marcelo bagnulo braun <marcelo@it.uc3m.es>]

Hi Erik,

El 22/11/2006, a las 2:22, Erik Nordmark escribió:

> marcelo bagnulo braun wrote:
>
> > So as i see it, there are two different scenarios that are not 
> > supported today and that we can update the spec to support:
> > - scenario 1: i call it virtual hosts. the supported feature here is 
> > to support the case of establishing context with the same peer with 
> > disjoint locator sets. For instance the scenario above where host A 
> > has locators A1 and A2 and host B has locators B1, B2, B3, B4 and to 
> > be able to estbalish two contexts A1,B1/B2 and another context with 
> > A2,B3/B4. In this case A and B would have something like two virtual 
> > hosts and they cannot merge. i.e. it is not possible that B adds B1 
> > to the second context
>
> Isn't this entirely an implementation matter? I run several Solaris 
> zones on my laptop today each with disjoint sets of IP addresses, and 
> no IETF standard had to be clarified to make that possible.
> What is important for a virtual host is that the IP stacks be 
> completely disjoint so that there can never be any confusion, but that 
> is an implementation matter.

ok, maybe the calling them virtual hosts was not a good idea.

Let me rephrase the scenario and see if we agree on supporting it or not

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

My understanding was that we we didn't mean not to support the above 
described scenario....
am i reading the draft correctly when i say that the current spec 
doesn't support this?
if so, should we support this case?


> > -scenario 2: host merging. In this case it is possible that B adds B1 
> > to the second context
>
> Why would we want to support this in any other way than we do today in 
> the spec? Any solution I've thought of would be quite complex.

I am not proposing supporting this, just wanted to verify that the 
agree on not supporting this, specially after the note from Sebastien

I am ok with not supporting this scenario

Regards, marcelo


> Do we want this because we think the 47 bits of context tag is 
> insufficient? Or is there some other motivation?
>
>    Erik
>
>
> > In order to support scenario 1, we would need to process incoming 
> > payload packets considering both the context tag and the locator pair 
> > and we would need to soften the MUST included above to soemthing 
> > like: If two context have disjoint locator sets at the moment of the 
> > context establishemnt, then they must always be disjoint. We need to 
> > phrase this very precisely, in order to be able to cope with loosing 
> > contexts and so on. (another way to describe it would be to include a 
> > section about virtual hosts, meaning that it is possible to support 
> > virtual hosts as long as they don't merge)
> > In order to support scenario 2 we need to modify quite a few things 
> > in the spec. In particular what do we do when the hosts merge through 
> > an UPDATe message and what do we do with the resulting contexts if 
> > they have the same context tag allocated. This would be quite hard to 
> > support. One option would be to renogotiate the context tag, but this 
> > would be quite complex. the other option would be to refuse the 
> > update messge, but we woud need to define a message to reject an 
> > UPDATe message.
> > So, imho, we may consider supporting the first case of virtual hosts 
> > (it would imply some rewriting of the spec though) but i don't think 
> > that it would be good idea to support the  second case, of merging 
> > hosts....
> > opinions?
> > Regards, marcelo
> > > 2. After some time, host B drops the first context.
> > > 3. Now he wants to create another one : <A1,B3/B4> with CTx.
> > > ----
> > >
> > > When A receives the I2 message from B, it is not able (as should be) 
> > > to detect that it is speaking with the same host, as the locator 
> > > sets are disjoint. As a consequence, the context in A with 
> > > CT(peer)=CTx will not be discarded. We are now in the situation of A 
> > > possibly sending packets to both the discarded context <A1,B1/B2> 
> > > and the newly created one <A1, B3/B4>, using CTx in both cases.
> > > IMHO, this can be detected by B, and should be stated in the draft 
> > > as another case of confusion detection (in fact both confusion and 
> > > context loss detection). For this to be done, section 12.1 could be 
> > > slightly changed, to say that a receiver MUST NOT assume that a 
> > > packet with the shim6 payload extension header and a context tag 
> > > matching with a context is really attached to the context. Rather, 
> > > to verify this, the source locator must be checked against Ls(peer) 
> > > :
> > > o if the source locator is included in Ls(peer), usual translation 
> > > is done.
> > > o if the source locator is not included in Ls(peer), then probably 
> > > this packet belongs to an old, dropped context, and an R1bis message 
> > > MUST be sent in this case, in order to recover the previously 
> > > discarded context (in my example <A1,B1/B2>).
> > >
> > > I hope this proposal is clearer and more realistic than the one 
> > > described in my previous mail.
> > >
> > > Thanks for any comment,
> > >
> > > Sébastien.