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

Hi Alper, Peter and Jouni,

Sorry for jumping to this discussion, I have two comments below.

Best regards,
Hassan


>-----Original Message-----
>From: [email protected] [mailto:[email protected]] On Behalf Of Alper
>Yegin
>Sent: Thursday, July 25, 2013 9:04 AM
>To: Peter McCann
>Cc: [email protected]
>Subject: Re: [DMM] comments/questions on draft-yegin-dmm-ondemand-mobility-
>00
>
>>>>>> IP Address Reachability is defined as follows:
>>>>>>
>>>>>>  IP address reachability: The ability to maintain the same IP
>>>>>> address for an extended period of time.  The IP address shall stay
>>>>>> the same across independent IP sessions, and even in the absence
>>>>>> of  any IP session.  The IP address may be published in a
>>>>>> long-term  registry (e.g., DNS), and it shall be available for
>>>>>> serving  incoming (e.g., TCP) connections.  IP address
>>>>>> reachability is  essential for mobile hosts to use specific/published
>IP addresses.
>>>>>
>>>>>
>>>>> I can read that from the draft but it still does not answer my
>>>>> question. Say, I get an ANAA and the either the MN or the AN does
>>>>> dynamic DNS update. Assuming the AN does not intentionally block
>>>>> incoming connections for ANAAs the MN can be reachable. What is the
>>>>> rationale to rule out incoming connections? I recon you also mix
>>>>> the "IP address shall stay the same across independent IP sessions"
>>>>> with your definition but IMHO that has very little to do with
>reachability.
>>>>
>>>> I see Jouni's point, and I think the distinctions between different
>>>> types of addresses and their capabilities is a bit artificial in
>>>> both the Yegin draft and the prefix coloring approaches.
>>>>
>>>> I think that any given address may change its type and function over
>>>> its lifetime.  An address that was originally assigned as "Unanchored"
>>>> could be promoted to "Access Network Anchored" if needed by the MN,
>>>
>>> That's right.
>>> But that's the only transition possible.
>>
>> Depending on how you define these terms, you are right.  But I am
>> saying that the hard distinctions you make in the draft may not be
>> that intellectually useful.
>>
>
>
>Hmm, I still don't understand why you say so... At any point in time, a given
>IP address falls in one of these three categories.
>
>>>> and as Jouni
>>>> notes an "Access Network Anchored" address could be registered in
>>>> DNS to provide reachability, and then you just need to make sure you
>>>> maintain that address for as long as the DNS entry exists + TTL.
>>>
>>> It's a different type of reachability, with very distinct
>>> characteristic. Please see my response to Jouni.
>>
>> Sure, but maybe reachability of an IP address is not what's needed here.
>> Reachability of the host from nodes that don't yet know its IP address
>> is what counts.
>>
>
>
>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. 

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.

>
>>>> 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 :)


>
>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.