Hi Danny,
Meeting is always good, even with you by f-to-f. But in the discussion, the main issue is whether we will allow the default source address selection rules defined in RFC6724 for selecting a Sustained IP address among several ones or fundamentally block them for a specific reason raised by a DMM need. The latter approach is not reasonable no matter how I try to think of.it. If an application has the specific preference of a newly obtained Sustained IP address, it uses the proposed API. Regards. Seil On Sun, Apr 5, 2015 at 12:22 PM, Moses, Danny <[email protected]> wrote: > Hi Seil, > > > > By now we have been discussing this for quite some time and clearly we did > not succeed in convincing each other. > > I suggest we try again when we have a chance to meet face to face. > Meanwhile, let's listen to what other people have to say on this matter. > > > > Regards, > > /Danny > > > > *From:* Seil Jeon [mailto:[email protected]] > *Sent:* Sunday, April 05, 2015 01:16 > *To:* Moses, Danny > *Cc:* [email protected] > *Subject:* RE: [DMM] Answer on raised questions for the proposed API > > > > Resent. > > > > Seil > > > > *From:* Seil Jeon [mailto:[email protected] <[email protected]>] > *Sent:* Saturday, April 04, 2015 1:35 PM > *To:* 'Moses, Danny' > *Cc:* '[email protected]' > *Subject:* RE: [DMM] Answer on raised questions for the proposed API > > > > Hi Danny, > > > > See the inline please. I marked current replies with “>>” and previous > replies with “>” for you to catch them easily. > > > > Regards, > > Seil > > > > > > *From:* Moses, Danny [mailto:[email protected] <[email protected]>] > > *Sent:* Thursday, April 02, 2015 2:16 PM > *To:* Seil Jeon > *Cc:* [email protected] > *Subject:* RE: [DMM] Answer on raised questions for the proposed API > > > > Hi Seil, > > > > Please see my replies (surrounded by >>2) to yours. > > > > Regards, > > /Danny > > > > *From:* Seil Jeon [mailto:[email protected] <[email protected]>] > *Sent:* Tuesday, March 31, 2015 15:23 > *To:* Moses, Danny > *Cc:* [email protected] > *Subject:* RE: [DMM] Answer on raised questions for the proposed API > > > > Hi Danny, > > > > See the inline please. > > > > > > Seil Jeon > > > > > > *From:* Moses, Danny [mailto:[email protected] <[email protected]>] > > *Sent:* Monday, March 30, 2015 4:44 PM > *To:* Seil Jeon > *Cc:* [email protected] > *Subject:* RE: [DMM] Answer on raised questions for the proposed API > > > > Hi Seil, > > > > As to the potential of abuse: > > Yes, I see your point and you are correct. If the IP stack will not > request a sustained IP address more than once after each movement to a new > LAN (with a different prefix), than there will be no abuse. > > > > > Yes, it’s true. Thanks for correction. > > > > As to the second comment, please let me elaborate: > > One potential implementation of the IP stack in the host, can be to > request a Nomadic IP address and a Sustained IP address whenever > connecting to a network, and whenever moving to a new LAN, regardless if > there are any applications requesting any addresses. This way, whenever an > application is launched and requests either a Nomadic or Sustained IP > address, the stack can provide one without having to issue a request to the > network. In this case, there is no need for this flag from the application. > > > > > Decision of which type of IP address by default will be depending on the > IP pool management policy by operators. You case may correspond to one of > them. What if only the Nomadic IP address is basically allocated upon a > network attachment? That is, a lot of applications require mere Internet > connectivity without session continuity support. So, the Sustained IP > address will be requested on demand, and the proposed flag will be used to > get a new Sustained IP address by expressing the explicit request by an > application. > > > > >>2 > > As I mentioned at the beginning of the description – it is a description > of one alternative. I am not assuming it is the only scenario. > > Yes, I agree that many apps require only Nomadic IP addresses, but in this > example, the IP stack in the host pre-allocates both Nomadic and Sustained > IP addresses upon attachment… > > > > >> As I said, it could be, but not as general one. The proposed API is > useful through the explicit expression for any potential scenarios. > > > > Yes, we can describe an alternative in which a Nomadic IP address is > pre-allocated upon NW connection (and after every movement to a new LAN) > and a Sustained (and/or Fixed) address is allocated on-demand. Even in such > a scenario, I do not see any use for this flag – see my reply to the second > item below… > > >>2 > > > > >> My answer was already given in following answer in previous email. > > > > Another potential implementation of the IP stack in the host is not to > request IP addresses in advance. In that case, it will issue a request for > a Nomadic IP address or a Sustained IP address the first time an > application requests one and use it for subsequent requests as long as it > is not moving to a different LAN. Once it moves, it will again request a > new IP address (Nomadic or Sustained – according to what is required) after > receiving the first request from any application. In this case as well, > there is no need for this flag. > > > > > Another application requested just Sustained IP address while the IP > stack has already a Sustained IP address. Why should the IP stack try to > get a new one, though the application indicated simply “Sustained IP > address type”? You case took a step towards a solution where you want to > draw. I don’t expect the action is generic when a Sustained IP address type > is requested. > > Besides, you assumption on IP address allocation seems not valid. A mobile > host would get an IP address whatever the allocated IP address type is when > it attaches at a network, regardless of an application’s IP address request. > > > > >>2 > > Looks like I did not express myself well enough (and did not fully > understand your reply). Let me list some events that might help clarify… > > > > Initial state: Mobile node is connected to a network; no Sustained IP > address is allocated. The IP stack sets a flag (SustainedIPAddressNeeded) > indicating that if an application requests a Sustained IP address, it will > have to request one from the network. > > > > Event1: An application that requires a Sustained IP address is launched. > > APP action: App requests a Sustained IP address from the IP stack using > the proposed new API. > > IP stack action: Since SustainedIPAddressNeeded is set, request one from > the network. > > Network action: Assigned a Sustained IP address to the mobile node. > > IP stack action: (1) Mark the new Sustained IP address as the one to be > associated to subsequent apps; (2) Reset SustainedIPAddressNeeded; > (3)Complete the API action and associate the marked Sustained IP address > with that port (app) > > > > Event2: A new application that also required a Sustained IP address is > launched > > App action: App requests a Sustained IP address from the IP stack using > the proposed new API > > IP Stack action: Since SustainedIPAddressNeeded is not set, complete the > API action and associate the marked Sustained IP address with that port > (app) > > > > Event3: The mobile node moves to a new LAN > > IP Stack action: Set a flag indicating that the currently available > Sustained IP address is not optimized > > > > Event4: An application that requires a Sustained IP address is launched. > > APP action: App requests a Sustained IP address from the IP stack using > the proposed new API. > > IP stack action: Since SustainedIPAddressNeeded is set, request one from > the network. > > Network action: Assigned a Sustained IP address to the mobile node. > > IP stack action: (1) Mark the new Sustained IP address as the one to be > associated to subsequent apps; (2) Reset SustainedIPAddressNeeded; > (3)Complete the API action and associate the marked Sustained IP address > with that port (app) > > > > Note that the behavior of the IP stack in Event4 is exactly like the one > in Event1. > > > > *I believe that this event is the one we have different of opinions: I > think that the default behavior of the IP stack is to request a new > Sustained IP address since it moved to a new LAN, and you think that it > should do so only if the application specifically requests a new Sustained > IP address via the flag you are proposing.* > > >>2 > > > > >> You can see my answer at the lowest “>>” in this mail. > > > > As a matter of fact, if such a flag is defined, I cannot think of an > example where it will not be used. It seems to me that applications will > always request a refreshed Sustained IP address (when requesting a > Sustained IP address). If this is correct, the flag is redundant. > > > > > Some applications, e.g. email, that are not relatively restricted from > optimal routing would consider a Sustained IP address without issuing the > new flag. More applications based on such network characteristic can be > thought more than expected. > > And such use of existing Sustained IP address is not extraordinary, since > IP address is a resource, even in the consideration of IPv6 deployment. If > as many as applications require new Sustained IP address, it will end up in > a lot of network resource consumption in the mobility routers where the > Sustained IP addresses are anchored as the terminal moves. > > >>2 > > I am sorry but I disagree with the email example. I categorize it as an > example of an application that will request a Nomadic address since it does > not break when the mobile node moves to a new LAN and the source IP address > is changed. It simply restarts the socket and continue with the new source > IP address (the user will not even notice this). > > > > >> The example was given as a benefit when the existing Sustained IP > address is used. You could get some insight from such kind of application > not caring much the routing distance even on the Sustained IP address. > > > > I did not understand the other text regarding resource consumption. I > thought we agreed that even of a new Sustained IP address is requested upon > each movement to a new LAN, the effect on IP address allocation is not > significant. Otherwise, my initial comment on applications abusing the > network using your proposed flag, becomes valid again > > >>2 > > > > >> No, our draft didn’t say so. Our idea is that a new Sustained IP > address is requested upon receiving *new* flag from an application, as a > preference for a source address selection. You need to read our draft > classifying the categories of IP address request again. > > > > Besides, I don’t understand what is abused. Delivering its preference > cannot be abuse. Regarding “abuse”, I see it in your default behavior > you’re assuming here. In your scenario, a new app initiated in a new > network will be forced to use a newly obtained Sustained IP address. You > see that? You totally block the possibility to be considered by the default > source address selection rules defined in RFC6724. But in our draft, in > case the need of a newly obtained Sustained IP address is prioritized, the > proposed *new* flag can be used by app’s request, thus it will be selected > with priority. > > > > Can you provide a scenario in which an application will not request to > refresh the Sustained IP address? > > > > > It was mentioned in the former comments. > > > > > > Regards, > > /Danny > > *From:* Seil Jeon [mailto:[email protected] <[email protected]>] > *Sent:* Monday, March 30, 2015 17:08 > *To:* Moses, Danny > *Cc:* [email protected] > *Subject:* FW: [DMM] Answer on raised questions for the proposed API > > > > Hi Danny, > > > > Any comments? > > > > Regards, > > Seil Jeon > > > > > > *From:* dmm [mailto:[email protected] <[email protected]>] *On > Behalf Of *Seil Jeon > *Sent:* Thursday, March 26, 2015 8:08 PM > *To:* [email protected] > *Subject:* [DMM] Answer on raised questions for the proposed API > > > > Hi, > > > > I could attend DMM Thursday meeting via MeetEcho. > > I could also hear some raised comments by Danny and Someone. Here goes > answers to the raised questions. > > > > > > First, regarding the need of the proposed API (IPV6_PREFER_SRC_NEW), > > > > The use of the proposed API is suggested in the SUSTAINED IP address case > in the draft. On receiving this API with the SUSTAINED IP address type at > the IP stack, it will try to get a new SUSTAINED IP address if there is no > available in the currently attached access network. So, actual obtaining of > the IP address will be tried one time while attached at a specific access > network. Even some applications put this API after, the already obtained > SUSTAINED IP will be used. So, no worries about abuse. > > > > Second question sounded to me like that this API is not needed because the > host can get a new SUSTAINED IP address, right? > > If the question is right, I don’t understand what the question is meant, > that is how the host can get a new SUSTAINED IP address? > > Based on the definition of three types of IP address, an application > should show its requirement with an API among them. If it is the SUSTAINED > IP address, how do we expect the IP stack will try to get a new SUSTAINED > IP address? > > > > Besides, the propsoed API is not used alone but with the three type APIs. > > > > > > > > Regards, > > > > Seil Jeon > > > > > > --------------------------------------------------------------------- > A member of the Intel Corporation group of companies > > This e-mail and any attachments may contain confidential material for > the sole use of the intended recipient(s). Any review or distribution > by others is strictly prohibited. If you are not the intended > recipient, please contact the sender and delete all copies. > > --------------------------------------------------------------------- > A member of the Intel Corporation group of companies > > This e-mail and any attachments may contain confidential material for > the sole use of the intended recipient(s). Any review or distribution > by others is strictly prohibited. If you are not the intended > recipient, please contact the sender and delete all copies. > > --------------------------------------------------------------------- > A member of the Intel Corporation group of companies > > This e-mail and any attachments may contain confidential material for > the sole use of the intended recipient(s). Any review or distribution > by others is strictly prohibited. If you are not the intended > recipient, please contact the sender and delete all copies. > > _______________________________________________ > dmm mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/dmm > >
_______________________________________________ dmm mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmm
