Sergio, >>> As Seil wrote, the problem which this ticket intends to reflect is that of >>> non-optimal routing as a result of not being able to request a non-anchored >>> (or local) source IP address. >> A non-anchored (local) address is called Nomadic IP Address. >> If the app needs one such address, then it can ask one and get one. >> API already supports that. > SF: You are right. But I didn't mean a Nomadic IP address, but a Sustained IP > address assigned by the current network. So, a description closer to what I > meant would be: > "...this ticket intends to reflect is that of non-optimal routing as a result > of not being able to request a Sustained IP address assigned by the local > network". >
OK, this I understand! But I understood this not from the ticket text but from the solution. Hence I've been extremely suffering trying to connect the solution back to the ticket definition :-( OK, if Seil also agrees with this, I hope you guys go back and clean up the ticket, so everyone can understand this the same way. Meanwhile, we can seek input from the WG members on the "issue" first (and then the solution). Alper > Best regards, > Sérgio > >>> This might be a problem in any scenario where new Sustained IP addresses >>> are not assigned by default at the new network. The intention of the flag >>> is not to request a new prefix, but to assure a source address associated >>> to a local network is used. Which, in cases where it is not available, >>> leads to the configuration of a new one. >>> >> Alper >> >> >>> Best regards, >>> Sergio >>> >>> >>> 2, rue Paul Vaillant-Couturier >>> 92300 Levallois-Perret >>> FRANCE >>> Tel. : +33 (0)1 46 17 46 17 >>> -----Original Message----- >>> From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Alper Yegin >>> Sent: sexta-feira, 22 de Maio de 2015 12:08 >>> To: Seil Jeon >>> Cc: dmm@ietf.org >>> Subject: Re: [DMM] [dmm] #49 (ondemand-mobility): full on-demand mobility >>> support >>> >>> Hi Seil, >>> >>> Thanks for creating the ticket. >>> >>> Please see below. >>> >>> >>>> #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. >>> >>> >>>> 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? >>> >>>> 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. >>> >>> >>> 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 > >
_______________________________________________ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm
