[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: draft-ietf-shim6-proto-06 : Context confusion
Hi Marcelo, Erik,
Thanks for these detailed answers.
see below...
marcelo bagnulo braun wrote:
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?
That was also my understanding : section 7.6 was requiring to have an
intersection between each pair of locator sets announced to peers (as
well described in Marcelo's previous mail). As I understand it, this
would prohibit the above scheme of communication.
I also fully agree with Marcelo's solution to scenario 1, that is :
----
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)
----
I think also that part of this topic is an implementation issue, but
there is also an implication on the check for incoming packets, which is
worth mentioning in the draft, in the case we decide to support it :
So, I think the draft should be made clearer about :
- whether the above scheme (scenario 1) is supported.
- In such case, what are the checks to do in order to prevent context
confusion when disjoint locator sets are used.
Regarding the first point, my opinion is that indeed scenario 1 is
useful, because it allows applications (using some API) to choose
dedicated locator sets for certain types of communication. Nevertheless,
if it proves too hard to support this as is, we could just specify that
the 'scenario 1' feature is not supported, and let as an implementation
matter to find a workaround for supporting this kind of dedicated sets.
(For example by tuning locators preferences).
And regarding the second point (what to do to support scenario 1), we
should then, as aforementioned, check the destination address for
incoming packets against the peer locator. But as stated in Marcelo's
text above, there is a need to think more about what to do if one of two
disjoint contexts disappears.
Put more generally, I think there is a common problem in either
situation (current spec or scenario 1), which is to deal with limited
subsets of locators.
In current spec, the simplest case for assuring that locators sets are
not disjoint is to always send *all* locators to every peer, then
tuning preferences. This is the simplest for avoiding context confusion
the 'standard' way.
Now, if we want to deal with limited subsets of locators, there is in
both cases the following problem :
- B creates a locator set L_1, then drops it. Maybe the peer has still
the corresponding context in memory.
- Later it creates a second context with the same peer (but we don't
know it is the same peer, since we just dropped the previous context).
The problem now is that
*if following the spec, we MUST have overlapping locator set
with the previous one.
* if supporting scenario 1, we MUST have a locator set which is
disjoint with the previous one.
The problem in both cases is that we have precisely dropped the previous
context and don't know what the previous locator set was.
Now, there is an extreme solution for both cases :
- if following current spec, send all locators, then tune with locators
preferences (as proposed earlier in this mail)
- if supporting scenario 1, having a local configuration that enforces
disjoint locator sets to stay disjoint during the whole life of the
system. This seems to be more or less the solution of virtual hosts, and
could probably be dealt with entirely as an implementation problem
(because the requirement to check the context tag *and* the destination
locator could then be replaced by the use of separate context tag spaces).
Do you agree with this problem of sending subsets of locators ? (also in
the current spec). In fact that was the initial thing i didn't like very
much, but maybe this option it to complicated to deal with. But in such
case, i suppose it could be useful to clearly specify in the draft that
all locators must be sent to all peers, in order for context confusion
to be properly avoided.
A last idea : I am thinking now that, worse, one might one to hide some
locators to some peers. This would be impossible if i am not in the
wrong way with the previous paragraph...
-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
I also don't see scenario 2 as sufficiently useful to be worth
supporting in the spec.
regards,
Sébastien.
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.