[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: draft-ietf-shim6-proto-06 : Context confusion
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
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
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
Do we want this because we think the 47 bits of context tag is
insufficient? Or is there some other motivation?
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
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
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
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,