Re: comments/questions on draft-yegin-dmm-ondemand-mobility-00

Hello Hassan,
On Jul 25, 2013, at 4:24 PM, <[email protected]> <[email protected]> wrote:

> Hi Alper, Peter and Jouni,
> 
> Sorry for jumping to this discussion, I have two comments below.
> 

You are more than welcome :-)
Please see below.

>> 
>> That's another level of reachability.
>> See, there's a chain of mapping: ID at app-level -> FQDN -> IP address ->
>> L2 address -> L1 address.
>> 
>> I think you are referring to FQDN reachability.
>> But in this MIP-land, we are concerned about IP address reachability part
>> of the problem.
>> 
> 
> [Hassan] Why we need IP address reachability? Can you please address some concrete use-case scenarios. 
> 

Providing a fixed/stable IP address to the MN is a rare, but existing use case.

Mobile servers need that. They cannot survive client communication if their IP address changes.
An enterprise user connecting to his company intranet via cellular network gets an IP address out of his intranet. This is like a VLAN.
Cellular operators are already marketing "fixed IP" as part of their service. 



> Upper level reachability is sufficient for an incoming e.g. VoIP call or SMS to a typical MN, and also even if we imagine an MN acting as a server and hosting e.g. a website, no one memorize IP addresses.
> 

Most of the time, yes, no one memorizes the IP addresses. They memorize the DNS name. But once the DNS resolves a name to an IP address, they stick to that IP address. So, that IP address better be stay the same, otherwise the communication breaks. 


>> 
>>>>> A static coloring
>>>>> of prefixes at the time they are assigned is not good enough.  We
>>>>> really need to know how many references to an address are
>>>>> outstanding everywhere in the system, and garbage collect old
>>>>> addresses when these reference counts go to zero.  Of course, we
>>>>> cannot hope to keep track of all the places throughout the Internet
>>>>> that have cached a given IP address associated to an MN, but we can
>>>>> at least attempt to provide an approximation to this abstract idea.
>>>>> 
>>>>> Also, I take issue with the use of "anchored" to distinguish address
>>>>> types. It is possible for an address to be persistently assigned
>>>>> without being "anchored" on any one given endpoint, especially if we
>>>>> use routing instead of tunneling to maintain the connectivity.
>>>>> 
>>>> 
>>>> If one can propagate host routes across the Internet, then the anchor
>>>> aspect disappears.
>>> 
>>> Maybe you need an anchor after you have moved a certain distance in
>>> the Internet topology, but not before.  And there is no need for that
>>> anchor to be the same as the first access router that assigned the
>> address.
>>> 
>> 
>> That statement would be true assuming again there's some kind of
>> host/prefix-specific route propagation.
>> 
>>> 
>>> An MN should be able, at any time, to get a fresh IP address (in
>>> general, we should be talking about a prefix) that is topologically
>>> matched to its current attachment point.  That prefix will be routable
>>> over a certain set of other attachment points by network-based means,
>>> and some mechanism should be provided to inform the MN whether the
>>> prefix is still on-link at any new attachment point (perhaps as simple
>>> as an RA, or something more optimal could be developed for specific
>>> link technologies).  If the address is no longer on-link, the MN
>>> should be able to get a new prefix and set up a tunnel from an HA to
>>> its current attachment point.  The HA and the HA-MN security
>>> association should be established simultaneously with the assignment
>>> of the original prefix (this step is optional if the network that
>>> originally assigned the prefix doesn't want to provide global mobility
>> for that prefix).
>>> 
>>> The MN thus maintains a pool of prefixes, and should be able to renew
>>> its lease on any prefix remotely from wherever it happens to be
>>> currently attached.  It is entirely up to the MN to decide of which
>>> prefixes it needs to maintain ownership, whether to register any of
>>> these addresses in DNS, and to decide which prefixes are no longer
>>> needed by any applications and can be returned to the network(s) that
>> assigned them.
>>> 
>>> It's possible that one or more of these addresses are "permanently"
>>> assigned to the MN (for some definition of "permanent") and provide the
>> "reachability"
>>> property that you defined in the draft.  However, that's merely a
>>> configuration and deployment consideration.
>>> 
>> 
>> These above makes sense to me.
> 
> [Hassan] I agree that it makes sense to keep one of the addresses permanent (assuming we really need this). However, we will need one permanent anchor and data packets of incoming sessions/calls should be routed through it and then tunneled to the MN. Similar issues to the ones addressed to current IP mobility protocols in DMM problem statement will be raised, but only for incoming sessions/calls. 
> 
> In fact, I consider this approach as an integrated DMM--MIPv6 approach: MIPv6 manages a permanent HA and HoA for MN's reachability at IP address level for incoming sessions, and DMM for sessions initiated by the MN itself. Imagine mobile CNs --> DMM will be used less and MIPv6 more. I don't like semi-solutions :)
> 

Oh, actually I'm not saying every MN shall have a Home Network Anchored Address.
I'm saying some need it, and only those shall get it.

Alper




> 
>> 
>> Alper
>> 
>> 
>> 
>> 
>>> -Pete
>>> 
>> 
>> _______________________________________________
>> dmm mailing list
>> [email protected]
>> https://www.ietf.org/mailman/listinfo/dmm
> 
> _________________________________________________________________________________________________________________________
> 
> Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
> Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
> 
> This message and its attachments may contain confidential or privileged information that may be protected by law;
> they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and delete this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
> Thank you.
>

_______________________________________________
dmm mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmm