Hi Seil, You can refer to this: http://trac.tools.ietf.org/wg/dmm/trac/wiki/TracTickets
A simple way would be adding comment to the existing ticket. -- Dapeng Liu 在 2015年6月8日 星期一，下午11:56，Seil Jeon 写道： > Hi Chairs, > > We want to elaborate the issue created in the tracker for clarity. What > Action should I take in “Modify Ticket”? > > - leave as new > - resolve as … > - reassign to … > > > Regards, > Seil > > From: Alper Yegin [mailto:[email protected]] > Sent: Wednesday, June 03, 2015 11:34 AM > To: Seil Jeon > Cc: [email protected] (mailto:[email protected]) > Subject: Re: [DMM] [dmm] #49 (ondemand-mobility): full on-demand mobility > support > > 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:[email protected]] > Sent: Wednesday, June 03, 2015 7:03 AM > To: Seil Jeon > Cc: [email protected] (mailto:[email protected]) > 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:[email protected]] > Sent: Monday, June 01, 2015 8:50 PM > To: Seil Jeon > Cc: [email protected] (mailto:[email protected]) > 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- > > > >>> [email protected] (mailto:[email protected]) | > >>> [email protected] (mailto:[email protected]) > > > >>> 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 > > > >>> [email protected] (mailto:[email protected]) > > > >>> https://www.ietf.org/mailman/listinfo/dmm > > > >> > > > >> > > > > > > > > > > > > > > > > > > > _______________________________________________ > dmm mailing list > [email protected] (mailto:[email protected]) > https://www.ietf.org/mailman/listinfo/dmm > > >
_______________________________________________ dmm mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmm
