[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: comments on draft-ietf-shim6-proto-05.txt


El 23/10/2006, a las 19:33, David Meyer escribió:







  Context forking     A mechanism which allows ULPs that are aware of
                      multiple locators to use separate contexts for

dmm> a bit confusing, since ULPs shouldn't be aware of locators
dmm> in any event? what is an example of a ULP that would be
dmm> "locator-aware"?




this seems a fundamental issue with the concept of forking...

The idea of forking is to allow applications that "know better" to
actually manage the locators used for the communication through an
extended API. of course the basic idea is that apps are not aware of
locators, but in case of special apps that want to be able to do this,
this is how they do it. Several folks have brougth that this was
needed... maybe them can provide exmaples of such apps...


dmm> such examples would be very helpful. I'm still a little
dmm> leary of the lack of "information hiding", although that has
dmm> its ups and downs too...


will try to find some.

i think i have some in some old emails, will try to dig them out...




7.6.  Context confusion

  Since each end might garbage collect the context state we can have
  the 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
the
  previous 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
is
  A 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
2006


  o  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 of 
  locators in a Locator List option that the peer can determine
whether
  or 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?



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?


dmm> yes. Maybe exactly that text, or something like it, would clarify?



ok, i will add a similar text in this section

Regards, marcelo