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

Re: shim design vs mobility/renumbering

Hi Pekka,


El 23/04/2005, a las 22:18, Pekka Savola escribió:

Hi,

This may be an obvious thing, but possibly worth bringing up explicitly..

When I read the specs, the obvious architectural approach taken by the shim6 approach -- not defining a separate identified name space -- has most implications in particular on renumbering and mobility.

In particular, especially with mobility, the locators are expected to become obsolete in a relatively frequent basis. As the ULID is tied to the locators, this has a couple of implications:

 1) what to do when the locator used for ULID has been removed from
    the node (permanently)?


well, this may well be the case in site multihoming too, like when we have a long lasting outage in a direct link to one of the providers. In such case, i guess it would make sense to deprecate the associated prefix, right?
In the failure detection draft i think there is some discussion about this... I think we have considered the possibility of defining a signaling message to inform that one of the locators is out, so that the peer doesn't use it to send packets. The address would still be used as ULID in established communications, but i wouldn't be used as ULID for new communications just as in regular IPv6 when an address is deprecated.

So, i think this can be supported.

Now if we move to the mobility case, then i guess that we may need some additional information to handle it properly, but for now i think it may be feasible. I mean, in mobility we have HoAs and CoAs. HoA are likely to become unreachable for long periods, but still we want to keep on using them as ULIDs. I guess that this is slightly different from the case above, since we would use the message to inform the peer that the HoA is unreachable, but we want to keep on using it as ULID (as oposed to previous case, where unreachable addresses weren't used as ULIDs anymore). I guess this is not a big problem, just internal policy (within the host)
OTOH, the CoAs are likely to come and go quite frequently. In this case, the CoA will be reachable but we probably don't want to use it as ULID, just use it as locator, and once it is no longer reachable simply inform the peer that it should not be used anymore. Again i don't see this as particularly difficult... but maybe (and probably) i am missing some of the difficulties

 2) in particular, what to do in the circumstances are such that
    the locators get assigned to other hosts?


Well wouldn't this be similar to the MIPv6 case? I mean, this can happen in MIPv6 also, right?

I guess that the point here is what is the probability of this event? in ipv6 with 64 bit interface ids....

 3) specifically, then what if the host wants to communicate with the
    host which was given its previous locator, if the locator is
    still used as ULID?

Again, what is the probablity of this event? (even less than the previous one)

In addition, i would say that CoAs shouldn't be used as ULIDs in general. Moreover, i am not sure that this would be a problem, since one would simply be the ULID and the other a lcoator (i agree that would be really weird though :-)


For a site multihoming solution it might be able to assume the apps could continue using the old ULID as long as it works.

However, for mobility ("frequent renumbering") I doubt this would be sufficient. 

I am sorry but i am not sure i see the problem yet...

But having to change the ULID would defeat the purpose of IP mobility, so that's unacceptable. The sessions can't be changed to use a different ULID either (without changes to the transport protocols), so that's a no-go.


Agree

So, from the mobility perspective, a solution like HIP is better. 

Not sure about that... The HoA makes a very good ULID in anycase...

Shim6 could provide the same functionality, but only if the ULIDs would always use a unique, non-renumbering idenftifier (a ULA?). But if those weren't routable, then the shim6 context would have to be exchanged up front.


Yes, this is one of the possibilities that we are likely to explore i guess. The problem is that soem stuff breaks, like refferals...

So, this brings two main issues/observations:

 a) is the assumption 1) good enough for site multihoming?  and if
    not, what else would be needed?


I am sorry but i am not fully understanding what is the assumption and what are the implications of it.

 b) while shim6 could maybe be extended to also be a mobility
    protocol, mobility support seems to have very different
    requirements (e.g., about the identifier name space, when to
    exchange the identifiers) that ruling that out at this
    point seems justified.


I wouldn't support that for now. I think more analysis is needed (actually i think it could work)

Regards, marcelo


--
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings