OK, so now at least I fully understand what this is. My recommendation is: - Please refine the issue definition in the tracker, so that people can understand this the same way, - And then let's ask the WG members their opinion about the issue (whether it's something worth tackling or not), - And if they agree to the issue, then we move to the solution space discussion.
Alper On Jun 3, 2015, at 1:12 PM, Seil Jeon wrote: > - A Sustained IP address that just got allocated from the currently serving > network (hence the "mobility is not activated" until the MN moves off link)? > > Yes. Thanks for your elaboration. > > > Regards, > Seil > > > From: Alper Yegin [mailto:alper.ye...@yegin.org] > Sent: Wednesday, June 03, 2015 7:03 AM > To: Seil Jeon > Cc: dmm@ietf.org > Subject: Re: [DMM] [dmm] #49 (ondemand-mobility): full on-demand mobility > support > > So, the idea is, when this flag is set along with a Sustained IP address > request from the app: > - if the host stack is already configured with a Sustained IP address > allocated from the serving network, then it gets selected (irrespective of > the presence or absence of any other Sustained IP address). > > >> No. I said "one that does not activate IP mobility" over the serving > >> network, among the existing ones in the IP stack, gets selected. If no one > >> in the IP stack is not matched, it will make an attempt to get a new > >> sustained IP address from the serving network. > > > What exactly is "(an IP address) that does not activate IP mobility"? Please > elaborate. > > Is it > - A nomadic IP address? > > - A Sustained IP address that just got allocated from the currently serving > network (hence the "mobility is not activated" until the MN moves off link)? > > - something else? > > Alper > > > > > On Jun 2, 2015, at 2:11 AM, Seil Jeon wrote: > > > Hi Alper, > > Regards, > Seil > > > -----Original Message----- > From: Alper Yegin [mailto:alper.ye...@yegin.org] > Sent: Monday, June 01, 2015 8:50 PM > To: Seil Jeon > Cc: dmm@ietf.org > Subject: Re: [DMM] [dmm] #49 (ondemand-mobility): full on-demand mobility > support > > > The point is that when the IP stack receives a flag with sustained IP > > address flag, it will check it has a sustained IP address, and if it > > has one or more, one that does not activate IP mobility will be > > selected. If not, the MN will be triggered to get a new IP sustained > > address not activing IP mobility. > > So, the idea is, when this flag is set along with a Sustained IP address > request from the app: > - if the host stack is already configured with a Sustained IP address > allocated from the serving network, then it gets selected (irrespective of > the presence or absence of any other Sustained IP address). > > >> No. I said "one that does not activate IP mobility" over the serving > >> network, among the existing ones in the IP stack, gets selected. If no one > >> in the IP stack is not matched, it will make an attempt to get a new > >> sustained IP address from the serving network. > > - if the host stack is not already configured with a Sustained IP address > allocated from the serving network (irrespective of the presence or absence > of any Sustained IP address from any other network), then the host makes an > attempt to configure one with the serving network. > > >> Yes. > > -- if the configuration succeeds, then the newly configured IP address is > selected. > > >> Yes. > > -- if the configuration fails. then the call fails (?? or some other behavior > -- you can define here). > > >> You mean the configuration fails when there is no sustained IP address, > >> right? > In my opinion, this issue belongs to address configuration mechanism based on > definition of the three DMM APIs. Those jobs are/will be asked on each > configuration mechanism, according to discussion of the previous > teleconference in the WT you’re leading. At that time, if I see any something > related to our proposal, we will raise our voice. > > > > > Alper > > > > > > > >>> #49: full on-demand mobility support > >>> > >>> The three proposed flags express a "type" of source IP address an > >> application wants to get to the IP stack. Particularly, the sustained > >> IP address is proposed to provide on-demand IP session continuity, > >> which activates IP mobility once the terminal moves across other > >> access > > network. > >>> While the terminal stays at the same network where the session is > >> initiated, regular IP routing is applied. > >>> > >>> The on-demand draft does not assure provide the full on-demand > >>> mobility > >> for all scenarios by merely indicating the Socket API, > >> IPV6_REQ_SUSTAINED_IP. An example scenario raising the aforementioned > >> issue is as follows; > >>> > >>> 0. The MN is configured with one or more Nomadic IP addresses. > >>> > >>> 1. Once an app. requests "sustained IP address" to the IP stack, and > >>> it > >> will obtain a sustained IP address through a protocol procedure > >> between the terminal and network. > >>> > >>> 2. Other app. initiated over the same access network will use the > >>> same > >> sustained IP address while the terminal remains connected at the same > >> access network. > >>> > >>> 3. The terminal moves to another access network and a new app. > >>> requests a > >> sustained IP address with the Socket API to the IP stack. Since a > >> sustained IP address is already available in the IP stack, the > >> sustained IP address is assigned to the new app. > >>> > >> > >> Yes, that's what happens. > >> You are not pointing to an issue up until this point, right? Because, > >> you continuing your email with a "Besides" gives the impression that > >> you are pointing to an issue, but I don't see any issue captured in > >> the > > above text. > >> > >>>> There is an issue. Maybe, we need to be synchronized how have you > >>>> thought > >> and defined the meaning of "on-demand mobility". As far as I know, > >> there are two meanings; one is that by imposing capability among IP > >> address reachability and IP session continuity, needed for an > >> application, into a source IP address, on-demand mobility could be > >> achieved; as the other meaning, it can be rephrased and detailed with > >> dynamic mobility, which should be applied in the use of sustained IP > >> address. A new application needs to have non-anchored sustained IP > >> address. This is our consistent claim. Non-optimal routing issue has > >> been raised in DMM Requirement document in RFC 7333, which should be > > critically considered in the solutions. > >> > > > > Sorry, I don't understand what you meant here. > > > >>>> You answer doesn't make us progress. Please specify where and what > >>>> you > > have understood. > > > > > >>> Besides, in case sustained IP address allocation is used default, > >>> there > >> may be multiple sustained IP addresses including newly obtained > >> sustained IP address over the new access network in the IP stack. > >> However, when an app. is initiated, the IP stack may not select the > >> new one in the context of the default source IP address selection > > mechanism [RFC6724][RFC5014]. > >>> > >> > >> OK, is the issue following: When there are multiple sustained IP > >> addresses, how does the IP stack pick one among them? (*) > >> > >>>> As mentioned and specified in our draft > >> http://tools.ietf.org/html/draft-sijeon-dmm-use-cases-api-source-00, > >> if there is no additional preference, we can leave selection to the > >> default source address selection mechanism. BUT if we have specific > >> preference among multiple sustained IP addresses and an initiated > >> application wants to have non-anchored sustained IP address over > >> currently attached access network, the proposed flag is essential. > >> > > > > I think you are meaning the same thing as I said above (*). > > Do you agree? > > > >>>> Yes. > > > >>> For providing the full on-demand mobility, a new flag is needed, > >>> letting > >> the IP stack request a new sustained IP address or choose a sustained > >> IP address not requiring IP mobility anchoring when an application is > >> initiated, among the existing ones in the IP stack. > >>> > >> > >> Your flag is not a solution to what I captured above. It does > >> something > >> else: Instruct the IP stack to go get a new sustained IP address > >> whether there is already one or more configured on the stack or not. > >> (**) > >> > >>>> Answered in the above. > >> > > > > There's a discrepancy between (*) and your solution (**). > > > > Are we talking about (*), (**), or something else? > > > >>>> There is no discrepancy between them. I said "a new flag", just an > > additional flag not intending to get a new sustained IP address all > > the time. And it should not request a new sustained IP address whether > > there is already one or more configured on the stack or not. It is > > given with the same expression in the ticket, though our draft is > > saying the meaning of a new sustained IP address, which will be revised in > > next update. > > > > The point is that when the IP stack receives a flag with sustained IP > > address flag, it will check it has a sustained IP address, and if it > > has one or more, one that does not activate IP mobility will be > > selected. If not, the MN will be triggered to get a new IP sustained > > address not activing IP mobility. > > > > > > Seil Jeon > > > > > > > > > >> Alper > >> > >> > >> > >>> -- > >>> -------------------------+------------------------------------------ > >>> -------------------------+- > >>> -------------------------+--- > >>> -------------------------+--- > >>> Reporter: | Owner: draft-ietf-dmm-ondemand- > >>> seilj...@av.it.pt | mobil...@tools.ietf.org > >>> Type: defect | Status: new > >>> Priority: critical | Milestone: > >>> Component: ondemand- | Version: > >>> mobility | Keywords: on-demand mobility > >>> Severity: Submitted | > >>> WG Document | > >>> -------------------------+------------------------------------------ > >>> -------------------------+- > >>> -------------------------+--- > >>> -------------------------+--- > >>> > >>> Ticket URL: <http://trac.tools.ietf.org/wg/dmm/trac/ticket/49> > >>> dmm <http://tools.ietf.org/dmm/> > >>> > >>> > >>> _______________________________________________ > >>> dmm mailing list > >>> dmm@ietf.org > >>> https://www.ietf.org/mailman/listinfo/dmm > >> > >> > > > >
_______________________________________________ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm
